The Need for New Taxonomic Views of Malicious Code & Content
Today’s blog post has been kicking around in the recesses of my mind for a while. I have been re-writing it for a while and decided to just get it out there so I can move on to other entries while still doing it justice. It deals with a subject that over time has become much more popularized though not to the degree that other subjects within our space have. Customized, designer malware. Some industries and security practioners are much more familiar with this particular family of malicious code and content than are others. Certainly key elements within the public sector (DoD, Intelligence Community) and private (Defense Industrial Base, High-Tech R&D, Biomedical R&D) are no strangers to this family but as for the majority I have to believe that it is still largely the stuff of myth and folklore. When one considers the premise of these types of threats and payloads it becomes apparent that they are unique and quite problematic. It’s a simple value proposition for the attacker:
- Study your target(s)
- Collect and qualify intelligence while making discretionary decisions on what to discard or retain
- Study and evaluate targets of opportunity – technical and non-technical
- Develop a strategy which takes into account tactical and strategic goals and allows for fluid diversion from one path to another should the opportunity cost be deemed too high or unreasonable
- Engage and begin insertion within the target environment
- Locate, identify and observe targets of interest paying special attention to people, process and technologies put in place to protect the targets
- Assess opportunity cost
- Engage in compromise
- Secure targeted object of mission
10. Extricate data and or target (remember the target could be something of a non-digital order, say a next generation telecommunications hand held for example)
11. Secure the target
12. Initiate process to either extort the rightful owners for profit or identify and initiate potential buyers who themselves have been qualified and are ready to engage in a transaction to secure the rights to the target in question
Sounds complex, perhaps even a bit fanciful or fictitious but rest assured dear reader it is anything other than fictitious. Methodologies of this sort and other similarly enacted methodologies are utilized often within operations that focus on the use of customized and designer malware targeted at an organization or a specific individual within that organization for the express purpose of illegally acquiring information or assets belonging to that organization which – were they to be sold on the open market or destroyed, would have grave impacts upon the way in which the target or victim organization conducts its affairs.
As an industry we should take these threats and their growing prevalence every bit as seriously as some of the other more recently noted families of threats which have recently permeated the cultural zeitgeist. In the same breath we as an industry need to be quite careful to avoid hysteria and any potential for ushering in an era of cyber-McCarthyism that sees us descend into a chaotic state fraught with implications, finger pointing, blinder-driven views and a lack of the irrefutable.
So how do we begin fighting these threats? We begin very much in the same way in which we always do by preparing ourselves and forgoing the tendency to take the path of least resistance. Many times attacks and compromises seen which fall into the family of customized, designer malware leverage as a basis, technologies which are well known and documented. Root kits, backdoors, and Trojans amongst others have been noted effectively in these scenarios as have been various and sundry examples of ransomware. I believe that new, enhanced taxonomic views are necessary in the modern world of malicious code and content analysis for combating these challenges. These views must be much more comprehensive and at the same time reflect the realities occurring within the Internet threat landscape which at times are denounced as being fiction (e.g. if an attack is launched by a nation state or sub national entity for financial gain it cannot be an apt – this is rubbish). Customized, designer malware may very well be a significant portion of the signal penetrating the noise in an effort to compromise and exploit our businesses, governments and personal lives on scale much more grand than had ever previously been considered.
When Antivirus becomes the Virus
Full Disclosure – I am a former McAfee employee, and currently draw a paycheck from a McAfee partner. The following are clearly my own thoughts and do not represent McAfee, my current/former employer(s) or anyone else.
Having been in the IT security industry for at least a decade, I have come to two key realizations:
1.) The IT security industry, as it relates to vendors selling products is largely based on FUD (fear, uncertainty, doubt), and
2.) Antivirus in almost no significant way equals comprehensive security
As many across the interwebs have already brought to light, McAfee had a very public snafu with one of their DAT updates (DAT 5958). Here is a mildly humorous link from Engadget’s site. To be clear, the point of this post is not to say the antivirus market poor or is dead, that McAfee has substandard products or solutions (usually the contrary), but that mistakes like this hurt not just one vendor or end customer, but the entire industry at large suffers.
That last part is an important point, especially in the case of endpoint security. Mistakes happen. QA processes are not perfect, vendors are trying to cut costs at every turn to increase profitability, so these things happen. In this specific case, if you were running VirusScan Enterprise with default settings, you will be a bit better than those who enabled “scan process by enable” or ran an on-demand scan with the 5958 DAT and scanned svchost.exe as the SVP of McAfee Support mentions in his blog post.
I see this with a lot of security practitioners where they turn on non-default options and get burned. Again, not picking on McAfee, but they also had a recent issue in their Patch 3 release of VirusScan Enterprise 8.7i where you enable “Prevent Windows Process Spoofing” (also an option that is disabled by default). This does not affect you if you don’t start turning on options you don’t fully understand. So, if you are responsible for endpoint security, a few simple tips:
1.) Have an IT test environment in place. Like Noah’s Ark, have representative systems (hardware, OS levels and apps installed) to test before you deploy. Many large enterprises wait 12-24 hours before rolling out DATs, and those who did were largely unaffected by this issue. Vendors like to throw around FUD here and push people to deploy reactive DAT coverage, and in few instances does security supercede system availability.
2.) Stick with the default options unless you are ready to accept the consequences – if you left the default options in place, neither of these two recent McAfee issues would have affected you. Quit turning knobs when you don’t fully understand what they do. A lot of us in IT assume instead of “trust but verify”.
3.) On-Demand scans are of minimal help on end workstations. AV scanning, especially on a scheduled basis is reactive. You already have malcode. Use realtime protection/on-access scanning, whatever. Save the scheduled reactive scanning for your file servers, SharePoint, and other file and data repositories.
4.) Antivirus is not total security, it is only one countermeasure. And, most importantly it is a reactive countermeasure at that. Regardless of what spin vendors put on it (heuristics, sandboxing, lookups in the cloud, etc.) by its very nature it is a reactive countermeasure. Implement more/better countermeasures, which leads me to …
5.) Complement endpoint security with more than just desktop and network firewalls. If you don’t use Host-based Intrusion Prevention on your laptops and critical systems, you probably should. Big difference in detecting malicious code or signature viruses versus stopping malicious traffic, and there is way more to it than blocking a port or protocol.
The point of this is not to unleash a hit piece on a specific vendor or technology, but to make sure practitioners frame the security tools and countermeasures in the appropriate context. AV won’t save you from malicious traffic for the most part, or from a targeted attack. Just like network security is not the answer to all of your security issues. The answer is an honest assessment of your countermeasures and their configurations, and if that maps to an acceptable level of protection versus risk. Sounds so simple, yet the devil’s in the details.
Introduction:
Just when you thought it could not get any weirder we bring you yet another installment of Bombs, Bullets, and Bits! In fact this is Episode V and of the ongoing series and today’s installment focuses on the wonderment of open market promotion, marketing, and salesmanship within the sub-economic ecosystems of the underground. Before we get going though I feel it is important to address a few key areas of economic theory in order to set the stage accordingly.
Adam Smith and Underground Sub-Economic Ecosystem of the Internet:
Adam Smith is revered the world over by economists and non-economists alike. Smith (b.1723 – d.1790), wrote what is considered to be by many as one of the most important texts in economics and philosophy, The Wealth of Nations. He is credited with coining the phrase and concept of the “invisible hand of the market” which, when allowed to move of its own volition, influences and churns economic cycles, conditions and markets in a natural manner reflecting basic and complex principles of conditions such as supply and demand. If you’ve not studies Smith’s works I would suggest picking up his The Wealth of Nations, as it is timeless. In the event you have not but are interested in understanding the basic premises of Smith’s philosophy (and if you intend on reading the remainder of this installment while being able to tie it all together), here is a short synopsis of the salient points contained therein:
- Every good and / or service has a “natural price” as determined by the weight given to it by its supplier, seller and the potential buyers
- If the price for a good and / or service exceeds that natural price then more resources (sellers, suppliers etc.) will be attracted to that market seeking to make a profit
- The price will return to it’s “natural” level over time as a result of market conditions
- ‘Supply’ should be viewed as a force or condition that tents to impact the price of a good or service based on availability and demand
- “Demand” should be viewed as a force that increase the price of a good or service. Demand is also driven and influenced by supply (depending on what the good or service is)
- If the two (‘Supply’ and ‘Demand’), are in equilibrium; a state of stability in the market than they will remain in balance. Should that stability fluctuate away from equilibrium, the natural cycle associated with competition rises once more and a return to ‘normalized’ pricing occurs
- These cycles never cease; they are in effect, in a state of kinetic motion
Relevance to the Underground and You:
Ok, at this point you may be thinking “thanks for the economic philosophy lesson, but what does this have to do with the underground, malware, hackers etc.”, I’m glad you asked. As we established above, every good and or service has what Smith called a “natural price”. This “natural price” is determined by a variety of factors including at a high level:
- Supply
- Demand
As one might expect availability, efficacy or desired effect (what it does vs. what it does not do), and application are all capitalized upon by the seller when targeting potential buyers and consumers. This is true in all markets to and including the various ‘sub-ecosystems’ of the underground. In conducting research on botnets I recently ran across quite a bit of ‘marketing’ and solicitation, the likes of which would’ve made any professional sales team proud. Want access to source code for a botnet to do with what you will? DDoS? SPAM? Malicious Code Infection? No problem, you can do it all with the right package. In fact, in one case, the case of the ‘Blazebot’ botnet which I originally began tracking around a year ago, the author offered the following features to the highest bidder in the botnet’s final form factor:
Figure 1: Examples of Marketed Features In the Underground
| Installation: | |
| Service Startup ActiveX Startup Anti Debugger thread Anti Dumping Mechanism File Protection (can be seen on video) Two types of process protection Windows Firewall exception Shared memory between service and userland app (ring 3) User impersonation (Service steals a token from userland App to steal their data) Pure API sockets (no ocx, csocketmaster or whatever) Ring3 API unhooking |
|
| Commands: | Update -Allows users to update the bots with a newer version Dump -This will cover the retrieving of: |
In this case the author decided to take his project to the open market and solicit private bids. Bids (which were rejected by the author), ranged from $50 USD to $400 Euros. In the end the author sold the entire source code package to a private party who wished to remain anonymous for an undisclosed amount. As part of the author’s campaign for a purchaser, he engaged in competitive marketing initiatives specifically targeting the ZeuS Botnet and community. A key selling point made by the author was that unlike ZeuS he was selling the entire source code package not simply binaries thusly enabling the buyer to establish their footprint in the Botnet world in any number of ways all of which were at the command of the new owner. Additionally, the author demonstrated the ability of the code to bypass detection of some 22 Anti-Malware engines.
Up On Olympus:
ZeuS is another wonderful example of this. Currently, active orders are being solicited for 1.4.x.x of ZeuS with prices ranging from $4000 USD to $8000 USD depending on which modules are desired for specific functionality. ZeuS is an interesting case in that older versions of the Botnet are easily had in the wild and can be used effectively though newer, more easily obfuscated versions of the code are available. ZeuS is in extremely high demand, selling on a pre-order basis. A testimony to its popularity and continued success for its authors, sellers and suppliers is its continued effectiveness in bypassing detection and delivering extremely high success rates in compromising hosts, impregnating them with malicious code & content packages with the end game being the establishment of participation within the greater command & control fabric. These examples are certainly not representative of all examples of activity within the underground however they provide a clear and concise view of just how supply and demand are working on a routine basis.
We are tied to our worlds, tethered if you will, in many respects by our mobile devices. Our Apple iPhones and RIM Blackberries among others, aid us in keeping up with our professional and personal lives. They provide us a near real time (and in some cases real time depending on the platform and connectivity), window to the world. Information is available as quickly as electric signals are converted to light and back again over terrestrial and non-terrestrial infrastructure. It’s an amazing time to be alive. But for every convenience there is a price to pay. Isn’t that always the case? As the old saying goes there is no such thing as a free lunch and technological advancement is no different in that respect. We pay a price for convenience. We sacrifice aspects of humanity for expedience. We trade willingly many of those commonalities which all mankind shares in order to ensure we can check our email, reply to a twitter posting, conduct online financial transactions, post a photo on facebook or find a movie online.
There is nothing intrinsically wrong with this. In fact, it is quite normal to see some elements of human life become retired as technological advancement occurs. Take for example the written word. Writing letters in centuries past was an art form. Manipulation of language and style enabled individuals and groups to establish identities; voices via pen and paper. With the advent of the telegraph, then the telephone, then data communications etc. the medium and styles seen changed to meet the times. To meet the needs; the urgency of communication and coupled with the ability to provide near real time responses to questions or statements.
In late November I wrote a piece that discussed exploitation of jail broken iPhones and the introduction of worms to the world of Apple handhelds. As a RIM Blackberry user, I took a certain amount of pride in this as I secretly coveted the coolness of the iPhone then yet another mobile vulnerability was announced only this time; it was for the RIM Blackberry platform. This is not the first time malware for RIM platforms has been developed or identified. Back in 2006, Jesse D’Aguanno, director of professional services and research with Praetorian Global LLC. wrote and released what many of us believe was the first Trojan for the RIM platform. At the time, RIM stated that the exploitation was dependent upon whether or not the Blackberry Enterprise Server Administrator enabled the IT policy settings for mitigating such threats. However, this is not where the story ends. On December 1, 2009 RIM released a security advisory that addressed multiple vulnerabilities in the PDF distiller of some released versions of the BlackBerry Attachment Service. Within the advisory RIM stated that the following versions of BlackBerry Enterprise Server running on the following Microsoft Windows platforms were affected:
- BlackBerry Enterprise Server 5.0.0 running on Microsoft Windows version 2003 or 2008
- BlackBerry Enterprise Server 5.0.0 running on Microsoft Windows 2000
- BlackBerry Enterprise Server software versions 4.1.3 through 4.1.7, and BlackBerry Professional Software 4.1.4.
In convincing a user to view a specially crafted PDF file, an attacker might be able to execute arbitrary code or cause a denial-of-service condition on the system that hosts the BlackBerry Attachment Service. This of course is not the first nor will it be the last time we hear and see advisories such as these for mobile device platforms (I suspect that Palm’s WEBOS will be the next victim just as the Android by Google has been). For better than 90% of those who use these devices, what we are discussing will not resonate in the same way as it would with security researchers and analysts. For that percentage of the populace these devices are merely extensions of themselves; windows to the world as mentioned earlier, which allow them to access and be accessed. That access of course runs deep and wide through their lives and sees their worlds become more risk inclined than not.
But are we so different than the 90%? Don’t we use these devices in similar fashion? Certainly we look at the technology differently than do most as our business is the business of security and as a result we are naturally or artificially disposed to being suspicious of that which we do not know intimately or understand. As a result, you and I might conduct analysis on a device prior to using it or examine in an isolated lab environment a sample of malicious code using debuggers and other tools & techniques to assess behavior, payload and net effect of said code on a system or platform. However, corporations find themselves enabled and ready to deal with the advent of the introduction of malicious code and content, who is taking first watch in defense of those who use these devices independent of a corporate IT security program?
Botnets, Malware and the Fortune 100
After a much too long hiatus and sabbatical of sorts, I’m back to contributing to the efforts here at Cassandra.
Anyhow, I came across this article very recently and, while it was published in September, it is a very timely topic given some of the conversations I’ve had with my colleagues here at Cassandra. Follows is my philosophical post. But first I have to give the folks at Defence Intelligence the proper credit and recognition as the Fox News article referenced above comes from their work.
The first line stating that at least 50 of the companies in the Fortune 100 are compromised by an information stealing botnet was not surprising to me at all. But it did get me to thinking about the state of security programs, processes and technology in these organizations, among others. While it might be easy to blame specific industries and their focus on regulatory compliance rather than security (yes, they’re different and we’ll discuss that in another article) or lay blame at the feet of lack of budget and resources, lack of technology savvy or some other excuse. We must first understand that the Fortune 100 are the largest companies in the U.S.
Let’s start with a few assumptions:
1 – The Fortune 100 are likely to be among the most savvy companies in the world when it comes to adopting and using people, processes and technology to enable their business.
2 – They are more likely to have the resources to enable effective information security programs than smaller companies.
3 – They are likely to have established an CISO or equivalent position.
4 – They are likely to be considered very coveted accounts by technology and security vendors. Therefore, we can expect that they are at least made aware of the latest innovations in technology and security and should certainly be made aware of those vendors’ research efforts into current threats.
Now that I’ve made a few assumptions, I want to dive in to the thoughts that I had on this article.
As I read the article and made these assumptions in my mind, I asked myself – “If over 50% of the Fortune 100 has been compromised, what does that say about the rest of the companies in the US?” The reality is that there is really no way to know what it means for the rest of the companies, however we can probably very safely assume that over 50% of them are compromised as well.
What is not made clear in the article or in the research details I’ve been able to review thus far is how deep the compromise goes into these organizations. Are we talking hundreds or thousands of systems or are we talking a few to tens? That would help put some of this into a better context for this article, but lacking that information I’m going to do my best to illustrate what this could mean from an information security perspective.
Maybe the question to ask is, “What did the other 47% do right?” or were they not tested? There is much to be learned from the research and this report but one thing is very clear to me, these companies have plenty with which to be concerned when it comes to the state of their information security programs.
More later…
NSS Labs IPS Test: Why We Should Not Shoot The Messenger
Yesterday something big occurred in the world of information security. Something which is bound to have a massive impact on the world of Intrusion Prevention Systems (IPS). Perhaps IPS units and vendors will never be viewed in the same light. Perhaps that’s a good thing. I suspect the use and application, of these devices in addition to the ever coveted vendor-client relationship, will require some adjustment. It would were in the market for IPS appliances or worse yet, already owned a given number of them and they failed to perform accordingly in testing. NSS Labs released a new IPS test report which is raising a great deal of controversy with respect to some industry players while seeing others reap the rewards of delivering product that performs as promised. For the ones which did not perform as expected, I believe the words of the immortal Desi Arnez character Ricky Ricardo are appropriate “..you got alot of explaining to do”.
Utilizing a revised testing methodology designed to ensure the highest degree of integrity possible, NSS Labs employed 1,159 live exploits against the vendors who submitted to the tests. The tests rigorous and beyond simply important. They are necessary for ensuring the the rubber meets the road with respect to claims being made by vendors with respect to their products effectiveness. Without tests of this nature, individual organizations would be left to either employ internal testing methods (which by the way, I personally advocate in addition to third party tests), or rely solely on the word of the vendor which, given the nature of the results of the current NSS report, may not be enough.
We as an industry have an obligation to ensure that what is being developed and designed meets the expectations of the target audience in addition to those set forth by the vendors themselves. I found it interesting to see the response to the tests in speaking with peers throughout the industry. All expressed concern about the potential implications for environments where those vendors which did not fair too well are employed. Some felt the results should be released in a bit of a vacuum, others felt the delivery was spot on. Whatever your feelings on this topic happen to be, my assertion to you is this: providing appropriate disclosure protocol was followed we should not shoot the messenger.
Who should be shot? Tough call. I believe that this can be answered on a case by case basis however there is an expectation that all vendors currently marketing and selling solutions today meet at least a minimum criteria deemed acceptable to themselves and third party testers such as NSS Labs. In perfect world this would translate to 100% effectiveness and genuinely easy process. As this is not a perfect world we can only assume that the vendors who are designing these solutions are doing so in order to address evolving threats identified within the threat landscape in the most comprehensive manner possible.
NSS Labs has always been known for integrity in their testing and I believe this test (in addition to the work they’ve done in ensuring maturity and growth in their processes over the course of the last two years demonstrates this), demonstrates this in spades. Demanding that integrity be seen within products being sold for the express purpose of defending against advanced malicious code & content and next generation threats is not only intelligent it is the expectation.
I believe NSS Labs should be applauded for their efforts in pursuing integrity driven testing methodologies and results. More of this is needed within our industry to ensure the greatest degree of care is taken in selecting a vendor product when the time comes to do so. I do not believe that the NSS Lab team should be critiqued for this. Was there a better way of approaching the disclosure of the results? I am not sure. I personally believe bad news, unlike wine or cheese, does not get better with age and as a result (provided proper disclosure measures were taken with the vendors), there is a responsibility on behalf the NSS Labs team to report the truth. This ensures their independence and credibility. To do otherwise would be a disservice to themselves, the consumers, the vendors, and the industry as a whole.
This article has been making the rounds around the IT/Security blog world, and I couldn’t help but weigh in and comment on it. The story being passed around is a scary one: An employee of the Massachusetts state government was found to have a fairly large quantity of child pornography in the browser cache of his state-issued laptop. He was, of course, arrested and charged with possession of child porn. During the course of mounting his defense against these charges, it was found that his machine had some form of malware that was “programmed to visit as many as 40 child porn sites per minute,” a clearly impossible task for a human who actually wants to see what’s on those sites. It became clear to all involved that the pornographic images found were very unlikely put there by him, and the charges were dropped. All’s well that ends well, right? Wrong.
The first problem here is that this opens Pandora’s box a crack, as it tends to raise the standard of proof for the conviction of real offenders. In fact, prosecutors are already calling this the “SODDI” (Some Other Dude Did It) defense. Their skepticism is probably warranted here: every real offender will point to this case and try to make the government (who has the burden of proof, at least in a United States court) prove that a virus wasn’t the reason illegal child pornography was on a particular machine.
There’s another problem here, though. This opens up a whole new world for profit-motivated malware authors. It’s actually a play on the old ransomware attack: traditionally, ransomware works on a “we’ve encrypted your files. Pay up or you’ll never see them again” basis. One problem in the business model for ransomware authors is that some people back up their machines (really!), and others simply won’t care about the data that is being held hostage. You can’t get someone to pay when they can simply respond “Screw you, I’ll just restore from backup”. The new twist on this is that, at least in concept, a ransomware author, instead of holding files hostage, can hold a person’s entire life hostage by planting a piece of malware of this type on someone’s machine and then threatening to expose that person.
Take for example the case of the person in the article. In this case this guy lost his job, his reputation, many of his friends, close to 250,000 dollars spent on his defense – and you can’t restore that from backup. Crimes involving the sexual exploitation of children are (justifiably) considered to be among the most grave transgressions against not only individual children, but society as a whole, and people who commit these crimes have richly earned society’s reproach. One unfortunate side-effect of that, however, is the fact that the mere accusation, even a false one, of a crime of that magnitude is enough to irrevocably harm one’s reputation. If the profit-motivated malware gangs hadn’t already figured this one out, they certainly have now, and I’d be willing to bet that we’re going to see at least sporadic attacks of this type (attacks against the reputation of an individual) in the very near future.
For years the debate has raged on regarding the validity of signature based solutions — regardless of where they lie within an enterprise environments ecosystem, versus those of a signatureless order. Questions around the effectiveness of the signatures, the time to market, the ongoing resource consumption concerns all have been and will likely continue to rage on. Can signature based solutions, regardless of how automated they become, truly provide enough value to warrant continued spend given the nature of the threats we face today or has their day come and gone? Are we holding onto them, thereby forcing their relevance in order to satisfy audit control requirements such as those presented by the PCI DSS? In a time when malicious code and content is more intelligently, and voluminously developed than ever before — endowed with various means by which to detect, identify and bypass mitigation technologies, one must ask whether or not we as an industry, are jousting windmills with ineffective solutions hoping for victory.
Now, to be clear, I want to get something straight right out of the gate: I am not saying there is no need for signature based technologies at all within our enterprises or homes. What I’m suggesting here is that the role in which they have been traditionally positioned by vendors, service providers and others has, for several years in my opinion, warranted preemptive solutions rather than reactive ones. Our world and its demands have changed. It’s that simple. Due to this change, we need to espouse and endorse a more mature form of thought; one which takes into consideration the threats we face, the likelihood of these threats to achieve (successfully) the exploitation of identified vulnerabilities and the subsequent risk this perfect storm of circumstance represents. We need to ask ourselves, our peers and our industry to reconsider its position on these ideas while at the same time achieving a state which allows us to repurpose these signature based solutions where they can do the most good within our environments. 
You wouldn’t utilize a 22 year old engine in to compete against modern, more ergonomically designed and better optimized for purpose modern ones in an automobile race would you? Similarly, you wouldn’t ask fighter pilots to engage modern jet aircraft in P51 Mustangs either. So why would you task your staffs, your peers, and yourself with combating emerging, evolving threats with tools which are dependent upon the knowledge of a threat (e.g. patient “0″), as opposed to retooling yourselves and your environments. The technology is there; it has been for some time. Could it be improved? Well, nothing is perfect however even in its imperfection it has been my experience that modern signatureless solutions as first line of defense solutions are more effective than their signature based counterparts.
I would remiss if I did not mention the roll of the backdoor within the context of this discussion. Backdoors are well known within the information security world. They come in a variety of flavors however can be traditionally categorized as either symmetric or asymmetric (today their study is commonly referred to as cryptovirology). Adam Young and Moti Yung spoke about this back in 1996 defining the terminology and use cases. Backdoors are used (in authorized or unauthorized manners) largely for bypassing normal or traditional authentication mechanisms. The reality is that they are used to gain secure remote access to these systems with the endgame being the obtaining access to plain-text data in some form of privilege escalated state. All while remaining or attempting to remain undetected by administrators.
Backdoors can be independent applications or programs. They can also be the result of a modification made to an existing application, program or even hardware devices (e.g BIOS backdoor passwords etc). The possibilities are quite broad; limited only by the imagination of the designer and the weaknesses, flaws and vulnerabilities identified in the target application, program or device in question design. Examples of this type of activity are abundant. In November of 2003 just such a threat was identified and addressed in the common Linux Kernel. A two-line addition to a development copy of the source code made to look like a harmless error-checking feature was identified. At first glance, it appeared to be quite harmless; benign in both function and intent. Why such a serious matter then? The answer stems from what the code was truly architected to do: if it identified an invalid combination of flag pairings, it would grant the process root privileges, turning the seemingly innocuous wait4 () into backdoor allowing for complete control of any machine found susceptible to it. 
Many other such examples of this type of threat can be seen historically, some associated with worms such as MyDoom for example, and others manifesting as cleverly marketed DRM styled protection mechanisms such as the SONY/BMG Rootkit I discussed in my last post. It’s important to bear in mind that all of them play a role in today’s threat landscape and have not gone the way of the dinosaur as some researchers and vendors would have you believe. Their uses and application are limited only by the intent and imaginations of those wielding them. Their role in the rise of Advanced Persistent Threats and Designer Malware is irrefutable and must not be dismissed as ideal held over from the antiquity of computing.
Yesterday I wrote a quick blog entry regarding new trends associated with Trojan’s, particularly those involving ‘Command and Control’ functionality. It is something that I will be expanding upon in detail in a later post. Today however, I wanted to discuss another of my favorite malware related topics, one which I enjoy conducting analysis on in detail (within the safety and sanctity of my environment), and that is the realm of the root kit. As we have discussed previously, there are scores of ways in which malware (any malware, not root kits or Trojans in particular), can be introduced into an environment. Some of which are more effective than others are, and yet in this brave new world of high-speed broadband connectivity to homes throughout the land (not to mention the world), one must conclude that the likelihood or probability of introduction, compromise and infection has grown (and likely will continue to do so), in an exponential manner. Still, one of the most effective threat vector lies with the human factor as discussed in yesterday’s post. In order to avoid beating a dead horse I will simply say this: much can (not all but much), be avoided if end users (whether they are ‘corporate’ end users ‘private’ citizens such as my mom), are properly and thoroughly educated with respect to the dangers associated with malware such as root kits.
This education and awareness needs to be ongoing and should never fall to the wayside; it should be at the forefront given the continued popularity and adoption of advanced technologies. OK back to root kits, root kits are not new (sound familiar?), in fact, they are quite mature and some might even say “old school”.
For arguments, sake let suppose you do not know what defines a root kit. Quite simply, root kits are software systems which often contain one or more programs used in order to prevent anyone (end users, administrators etc.), from discovering that a system has been compromised. They come in a variety of forms including:
- Hardware/Firmware
- Hypervisor level
- Kernel level
- Library level
- Application level
They do not necessarily grant a user administrative permissions or privileges however they are often times leveraged by attackers to replace system files (e.g. executables etc.) which may then be used to hide processes and files the attacker has installed in addition to obfuscating the presence of the root kit itself (this is most often accomplished via subversion or evasion of traditional OS security and monitoring mechanisms such as Anti-virus and / or Anti-Spyware technologies). In effect, their mission is simple: compromise the host and subsequently seize control of the operating system.
In many cases, they are Trojans as well and just as we discussed yesterday they attempt to convey a sense of benignity and usefulness to the user in order to convince the user in question they are safe in executing them on their system. Additionally, many root kits implement backdoors into the systems they have compromised by corrupting or replacing the legitimate login mechanism with one designed by the attacker (e.g. /bin/login). No one is entirely certain of their origin however there are some who feel it is reasonable to believe they were originally designed to perform similar functions provided by utilities such as VNC for remote command and control of an unresponsive or failing machine. Whatever the case with respect to their origins, their use and popularity continue to grow; manifesting in some of the most unlikely places. In the last three years for example, we have seen some rather profound instances of use (at least those which have been publicly reported after having been disclosed), and proliferation of root kits.
Take for example the Sony Root Kit. In 2005, Sony began distributing their XCP (Extended Copy Protection), software in some of their products. In effect, XCP was a digital rights management program, which employed techniques (e.g. cloaking), normally associated with malicious root kit developers which was a security risk. As a result, in addition to a loss of face, credibility and some branding, Sony was forced to recall millions of CDs. What makes this case unique is that Sony knowingly distributed XCP to their customer base and in effect acted in the same manner as those who traditionally operate for malicious ends. The net effect was a public relations disaster for Sony, which has yet to fade in the minds of the information security community much less the world at large.
2008 saw two interesting examples of root kit activity the first being the Pandex Trojan. The Pandex Trojan was interesting in that it would identify the presence of a root kit, remove the incumbent’s hooks into system calls and subsequently stop the first root kit. Upon stopping the incumbent, Pandex would install its own root kit. Similar ‘turf’ wars had been seen during the heyday of worms but this was unique amongst root kits. Sebastian Muniz, a security researcher with Core Security Technologies, developed the next example of interest, which caught my eye. Muniz developed a root kit for the Cisco IOS, which he debuted at EUSecWest in London. Muniz’s root kit work increased the already present scrutiny associated with routers due to Mike Lynn’s presentation in 2005. Muniz’s root kit (which runs in the router’s flash memory –which contains the first IOS commands used for system boot), though reliant upon an alternate means of introduction to the host in question, would, once present allow for obfuscated monitoring and command & control of the device. The impact of such an event occurring on a massive scale is simply staggering.
This year in March, we saw the SMM (System Management Mode) root kit (which uses an Intel CPU caching vulnerability) identified by Joanna Rutkowska and Loic Duflot. The attack in question allows the root kit to hide in the SMM space and subsequently secure control of the system in question. The second example was that which was discovered by Alfredo Ortega and Anibal Sacco from Core Security Technologies. They identified what proved to be a dangerous, pre-installed root kit (Computrace LoJack for Laptops — which was estimated to be present on 60 percent of all new laptops), that resides in BIOS, and periodically calls home to a central authority for instructions. This call functionality allows the central authority to wipe the system in the event the device is stolen or it is unable to track the location of the device in question. What makes this truly dangerous is the potential for exploitation of the call home process. Should a hacker compromise this function he or she has access to a great deal of information. One might ask how it is possible that an authorized and unauthorized party might both be able to leverage that mechanism and according to the authors, it was due to the technologies dependency on a configuration method that contains the IP address, port and URL all hard-coded in the OPTION-ROM…where is my Excedrin.
As you can see these are just a few examples of what root kits are and how they are leveraged. This topic truly warrants a greater degree of time and perhaps one day soon, I will have the time to write something a bit more formal, but in the meantime bear in mind their presence and the dangers associated with them. They were once thought to be out of style yet clearly the evidence suggests otherwise.
