Archive for the ‘Malware’ Category

Whistleblower Series – The real problem with China isn’t China, its you.

Terms like China, APT and Zero-Day are synonymous with Fear, Uncertainty and Doubt (FUD).  The trouble is that, in our opinion anyway, these terms and respective news articles detract from the actual problem.  For example, in 2011 only 0.12% of compromises were attributed to zero-day exploitation and 99.88% were attributed to known vulnerabilities.  Yet, despite this fact the media continued to write about the zero-day threat as if it was a matter of urgency.  What they really should have been writing about is that the majority of people aren’t protecting their networks properly.  After all, if 99.88% of all compromises were the result of the exploitation of known vulnerabilities then someone must not have been doing their job. Moreover, if people are unable to protect their networks from the known threat then how are they ever going to defend against the unknown?

All of the recent press about China and their Advanced Persistent Threat is the same, it detracts from the real problem.  More clearly, the problem isn’t China, Anonymous, LulzSec, or any other FUD ridden buzzword.  The problem is that networks are not being maintained properly from a security perspective and so threats are aligning with risks to successfully affect penetration.  A large part of the reason why these networks are such soft targets is because  their maintainers are sold a false sense of security from both the services and technology perspective.

In this article we’ll show you how easy it was for us to hack into a sensitive government network that was guarded by industry technologies and testing best practices.  Our techniques deliberately mimicked those used by China.  You’ll notice that the  techniques aren’t particularly advanced (despite the fact that the press calls them Advanced) and in fact are based largely on common sense.  You’ll also notice that we don’t exploit a single vulnerability other than those that exist in a single employee (the human vulnerability).  Because this article is based on an actual engagement we’ve altered certain aspects of our story to protect our customer and their respective identity.  We should also make mention that since the delivery of this engagement our customer has taken effective steps to defeat this style of attack.

Here’s the story…

We recently (relatively speaking anyway) delivered a nation state style attack against one of our public sector customers.  In this particular case our testing was unrestricted and so we were authorized to perform Physical, Social and Electronic attacks.  We were also allowed to use any techniques and technologies that were available should we feel the need.

Lets start off by explaining that our customers network houses databases of sensitive information that would be damaging if exposed.  They also have significantly more political weight and authority than most of the other departments in their area.  The reason why they were interested in receiving a nation-state style Penetration Test is because another department within the same area had come under attack by China. 

We began our engagement with reconnaissance.  During this process we learned that the target network was reasonably well locked down from a technical perspective.  The external attack surface provided no services or application into which we could sink our teeth.  We took a few steps back and found that the supporting networks were equally protected from a technical perspective.  We also detected three points where Intrusion Prevention was taking place, one at the state level,  one at the department level, and one functioning at the host level.

(It was because of these protections and minimalistic attack surface that our client was considered by many to be highly secure.)

When we evaluated our customer from a social perspective we identified a list of all employees published on a web server hosted by a yet another  department.  We were able to build micro-dossiers for each employee by comparing employee names and locations to various social media sites and studying their respective accounts.  We quickly constructed a list of which employees were not active within specific social networking sites and lined them up as targets for impersonation just in case we might need to become someone else.

We also found a large document repository (not the first time we’ve found something like this) that was hosted by a different department.  Contained within this repository was a treasure trove of Microsoft Office files with respective change logs and associated usernames.  We quickly realized that this repository would be an easy way into our customers network.  Not only did it provide a wealth of META data, but it also provided perfect pretexts for Social Engineering… and yes, it was open to the public.

(It became glaringly apparent to us that our customer had overlooked their social points of risk and exposure and were highly reliant on technology to protect their infrastructure and information.  It was also apparent that our customer was unaware of their own security limitations with regards to technological protections.  Based on what we read in social forums, they thought that IPS/IDS and Antivirus technologies provided ample protection.)

We downloaded a Microsoft Office document that had a change log that indicated that it was being passed back and fourth between one of our customers employees and another employee in different department.  This was ideal because a trust relationship had already been established and was ripe for the taking.  Specifically, it was “normal” for one party to email this document to the other as a trusted attachment.  That normalcy provided the perfect pretext.

(Identifying a good pretext is critically important when planning on launching Social Engineering attacks.  A pretext is a good excuse or reason to do something that is not accurate.  Providing a good pretext to a victim often causes a victim to perform actions that they should not perform.)

Once our document was selected we had our research team build custom malware specifically for the purpose of embedding it into the Microsoft Office document.  As is the case with all of our malware, we built in automatic self-destruct features and expiration dates that would result in clean deinstallation when triggered.  We also built in covert communication capabilities as to help avoid detection.

(Building our own malware was not a requirement but it is something that we do.  Building custom malware ensures that it will not be detected, and it ensures that it will have the right features and functions for a particular engagement.)

Once the malware was built and embedded into the document we tested it in our lab network.  The malware functioned as designed and quickly established connectivity with its command and control servers.   We should mention that we don’t build our malware with the ability to propagate for liability and control reasons.  We like keeping our infections highly targeted and well within scope.

When we were ready to begin our attack we fired off a tool designed to generate a high-rate of false positives in Intrusion Detection / Prevention systems and Web Application Firewalls alike.  We ran that tool against our customers network and through hundreds of different proxies to force the appearance of multiple attack sources.  Our goal was to hide any real network activity behind a storm of false alarms.

(This demonstrates just how easily Intrusion Detection and Prevention systems can be defeated.   These systems trust network data and generate alerts based on that network data.  When an attacker forges network data then that attacker can also forge false alerts.   Generate enough false alerts and you disable ones ability to effectively monitor the real threat.)

While that tool was running we forged an email to our customers employee from the aforementioned trusted source.  That email contained our infected Microsoft Office document as an attachment.  Within less than three minutes our target received the email and opened the infected attachment thus activating our malware.  Once activated our malware connected back to its command and control server and we had successfully penetrated into our customer’s internal IT infrastructure.  We’ll call this initial point of Penetration T+1.  Shortly after T+1 we terminated our noise generation attack.

(The success of our infection demonstrates how ineffective antivirus technologies are at preventing infections from unknown types of malware.  T+1 was using a current and well respected antivirus solution.  That solution did not interfere with our activities.  The success of our penetration at this point further demonstrates the risk introduced by the human factor.  We did not exploit any technological vulnerability but instead exploited human trust.         )

Now that we had access we needed to ensure that we kept it.  One of the most important aspects of maintaining access is monitoring user activity.  We began taking screenshots of T+1’s desktop every 10 seconds.  One of those screenshots showed T+1 forwarding our email off to their IT department because they thought that the attachment looked suspicious.  While we were expecting to see rapid incident response, the response never came.  Instead, to our surprise, we received a secondary command and control connection from a newly infected host (T+2).

When we began exploring T+2 we quickly realized that it belonged to our customers head of IT Security.  We later learned that he received the email from T+1 and scanned the email with two different antivirus tools.  When the email came back as clean he opened the attachment and infected his own machine.  Suspecting nothing he continued to work as normal… and so did we.

Next we began exploring the file system for T+1. When we looked at the directory containing users batch files we realized that their Discretionary Access Control Lists (DACL’s) granted full permissions to anyone (not just domain users).  More clearly, we could read, write, modify and delete any of the batch files and so decided to exploit this condition to commit a mass compromise.

To make this a reality, our first task was to identify a share that would allow us to store our malware installer.  This share had to be accessible in such a way that when a batch file was run it could read and execute the installer.  As it turned out the domain controllers were configured with their entire C:\ drives shared and the same wide open DACL’s.

We located a path where other installation files were stored on one of the domain controllers.  We placed a copy of our malware into that location and named it “infection.exe”.  Then using a custom script we modified all user batch files to include one line that would run “infection.exe” whenever a user logged into a computer system.  The stage was set…

In no time we started receiving connections back from desktop users including but not limited to the desktops belonging to each domain admin.  We also received connections back from domain controllers, exchange servers, file repositories, etc.  Each time someone accessed a system it became infected and fell under our control.

While exploring the desktops for the domain administrators we found that one admin kept a directory called “secret”.   Within that directory were backups for all of the network devices including intrusion prevention systems, firewalls, switches, routers, antivirus, etc.  From that same directory we also extracted viso diagrams complete with IP addresses, system types, departments, employee telephone lists, addresses, emergency contact information, etc.

At this point we decided that our next step would be to crack all passwords.  We dumped passwords from the domain controller and extracted passwords from the backed up configuration files.  We then fed our hashes to our trusted cracking machine and successfully cracked 100% of the passwords.

(We should note that during the engagement we found that most users had not changed their passwords since their accounts had been created.  We later learned that this was a recommendation made by their IT staff.  The recommendation was based on an article that was written by a well-respected security figure. ).

With this done, we had achieved an irrecoverable and total infrastructure compromise.  Had we been a true foe then there would be no effective way to remove our presence from the network.  We achieved all of this without encountering any resistance, without exploiting a single technological vulnerability, without detection (other than the forwarded email of course) and without the help of China.  China might be hostile but then again so are we.

 

 

PDF Printer    Send article as PDF   

The 3 ways we owned you in 2012

Here are the top 3 risks that we leveraged to penetrate into our customers’ networks in 2012. Each of these has been used to affect an irrecoverable infrastructure compromise during multiple engagements across a range of different customers. We flag a compromise “irrecoverable” when we’ve successfully taken administrative control over 60% or more of the network-connected assets. You’ll notice that these risks are more human-oriented than they are technology-oriented, thus demonstrating that your people are your greatest risk. While we certainly do focus on technological risks, they don’t fall into the top three categories.

The general methodology that we follow to achieve an irrecoverable infrastructure compromise is depicted below at a high-level.

  1. Gain entry via a single point (one of the 3 referenced below)
  2. Install custom backdoor (RADON our safe, undetectable, home-grown pseudo-malware)
  3. Identify and penetrate the domain controller (surprisingly easy in most cases)
  4. Extract and crack the passwords (we have pretty rainbows and access to this GPU cracker)
  5. Propagate the attack to the rest of the network (Distributed Metastasis)

 

Social Engineering

Social Engineering is the art of manipulating people into divulging information or performing actions usually for the purpose of gaining access to a computer system or network connected resource. It is similar to fraud, but the attacker very rarely comes face-to-face with his or her victims. Today, Social Engineering is used to help facilitate the delivery of technological attacks like the planting of malware, spy devices, etc.

During an engagement in 2012, Netragard used Social Engineering to execute an irrecoverable infrastructure compromise against one of its healthcare customers. This was done through a job opportunity that was posted on our customers website. Specifically, our customer was looking to hire a Web Application Developer that understood how to design secure applications. We built an irresistible resume and established fake references, which quickly landed us an on-site interview. When we arrived, we were picked up by our contact and taken to his office. While sitting there, we asked him for a glass of water and he promptly left us alone in his office for roughly 2 minutes. During that time, we used a USB device to infect his desktop computer with RADON (our pseudo-malware). When he returned we thanked him for the water and continued on with the interview. In the end, we were offered the job but turned it down (imagine if we accepted it).

If you aren’t subjecting your staff to real social engineering then you aren’t receiving a realistic penetration test. While the example above represents an elevated threat, we test at a variety of different threat levels. The key is to keep it realistic.

Malware

The word malware is derived from “Malicious Software.”  Any software that was written for the purpose of being malicious is by definition malware. This includes but is not limited to trojans, worms, and viruses.  Today malware is evolving and is becoming harder and harder to detect. Most people are under the pretense that their antivirus software will protect them from malware when in reality their antivirus software is borderline useless. Antivirus software can only detect malware if it knows what to look for. This means that new, never before seen variants of malware are undetectable so long as they don’t behave in any known way that would trigger false positives but never the less result in detection. What’s more interesting is that we found that antivirus software can’t even detect known malware if the known malware has been packed.

We used RADON, our home-brew “safe” malware, in nearly every engagement in 2012. RADON is designed to enable us to infect customer systems in a safe and controllable manner. Safe means that every strand is built with an expiration date that, when reached, results in RADON performing an automatic and clean self-removal. Safe also means that we have the ability to tell RADON to deinstall at any point during the engagement should any customer make the request. RADON is 100% undetectable and will completely evade all antivirus software, intrusion prevention / detection systems, etc. Why did we build RADON? We built it because we need to have the same capabilities as the bad-guys, if not then our testing wouldn’t be realistic.

One last thing that you should know about malware is that it doesn’t usually exploit technological vulnerabilities to infect systems. Instead, it exploits human gullibility and we all know that humans are far more easy to exploit than technology! The “ILOVEYOU” worm is a prime example. The worm would email itself to a victim with a subject of “I LOVE YOU” and an attachment titled “LOVE-LETTER-FOR-YOU.txt.vbs,” which was actually a copy of the worm. When a person attempted to read the attachment, they would inadvertently run the copy and infect their own computer. Once infected, the worm would begin the process again and email copies of itself to the first 50 email addresses in the victim’s address book. This technique of exploiting gullibility was so successful that in the first 10 days, more than 50 million infections were reported. Had people spent more time educating each other about the risks of socially augmented technical attacks then the impact may have been significantly reduced.

Configuration Vulnerabilities

Configuration Vulnerabilities most commonly seem to be created when third parties deploy software on customer networks.  They often fail to remove setup files, default accounts, default credentials, etc.  As a result, hackers scan the internet for common configuration vulnerabilities and often use those to penetrate into affected systems.  Sometimes configuration vulnerabilities aren’t particularly useful other than being destructive.

For example, our team was recently performing an Advanced External Penetration Test for a small bank on the southern part of the east coast. This bank had an online banking web application that was deployed by a vendor. The portal worked fine, but the vendors consultant didn’t clean up the setup files after configuration. During our engagement, we performed directory enumeration against the poorly configured target using wfuzz (standard practice during any penetration testing engagement). Our enumerator identified a directory called “AppSetup” and when it requested the page from that directory we received a message that read “Database Initialized Successfully.” Yes, that’s right, simply visiting the page wiped out one of the bank’s customer databases. What’s more scary is that this was done from the internet, didn’t require any authentication, and was unavoidable for anyone that would have simply accessed that specific URL.

Another common Configuration Vulnerability exists within networks of all sizes and has everything to do with Active Directory and the account lockout after login failure setting. When delivering a Penetration Test to two separate customers in 2012 we inadvertently created a company-wide denial of service. In both cases, the reason for the outage was because the customer had bad configurations established in Active Directory. Specifically, their lockout after 3 login failures was set to 24 hours. During both engagements, we were authorized to perform password guessing attacks against all external points of authentication. During both engagements, we managed to lock out nearly every user account for a 24-hour period. One of the customers (a large bank) couldn’t remember their master domain admin password and so their outage was extended to nearly 24 hours. In this particular case, setting a lockout to 24 hours creates a critical availability impacting vulnerability. We really don’t see any point in setting your lockout to anything greater than 5 minutes (if you want to know why feel free to leave a comment).

In closing, configuration vulnerabilities are the product of unsafe configurations. What is unfortunate is that these vulnerabilities are almost always identified through triggering, which results in an outage or damage of some sort. It’s important to remember that its not our fault that your systems might not configured properly.

 

 

Create PDF    Send article as PDF   

Conficker C and friends – Defeating worms with architecture

The first line of technical defense against any computer intrusion is the architecture of the network infrastructure that the computer is connected to. The fact that worms like Conficker are so successful in their metastasis is “in your face” proof of just how insecure today’s IT Infrastructures are.  If they weren’t so insecure then these worms would have a minimal impact.  What’s even more interesting is that worms are “dumb” and people can’t seem to keep them out of their networks, so what are people going to do when hackers come knocking?
In simple terms a worm is little more than a dumb, self replicating, repeating computer program that uses some mechanism (network, usb sticks, etc) to send copies of its self to other computer systems . A worms survival hinges on its ability to communicate with other computer systems and on its ability to gain entry into new uninfected computer systems.  If it can’t do one or the other then it can’t spread and it will eventually die.  If it can do both with relative success then it will likely survive for some time. The more hosts that a worm infects, the more potential hosts it can infect assuming that its method of gaining access isn’t patched before the host is infected.Â
With that said, the not so obvious but highly effective way of defending against worms is to undergo an Advanced Penetration Test. The reality is that worms and hackers use the same techniques for gaining access to networked infrastructures.  The primary difference is that a worm only has one method of attack and is restricted by its programming while a hacker is unrestricted and has many methods of attack.  Therefore it is reasonably safe to say that if your network can stand up to an Advanced Penetration Test, then it can also resist a worm.Â
Lets use the Conficker C worm as an example of what I am talking about.  On April 1st the Conficker C worm will enter its Domain Generation Algorythm.  It will go out and download a new command and control file over HTTP, install that file, and then do god knows what. Conficker C is dependent on most networks allowing unrestricted outbound HTTP access.Â
In the last penetration test we (Netragard) did my team used a PDF document infected with a payload that was designed to establish an outbound connection back to our office over HTTP. Specifically, the PDF docment contained an exploit for a vulnerability in Adobe Acrobat. When the document was opened it injected connect back shellcode into memory of the victim’s computer system. That computer system then established a connection back to us over HTTP and we were able to tunnel back in over that connection to gain control over the victim’s system and eventually the network.Â
As a step toward remedation we recommended to our customer that they only allow authenticated and authorized outbound HTTP and HTTPS connections.  They took that recommendation to heart and implimented controls to prevent those unauthorized connections.  An unforseen result of our services is that our customer’s network disrupts Conficker’s communications channel. (Conficker relies on unrestricted oubound HTTP).  Now, even if they have infected nodes on their network, those nodes will not be able to establish outbound HTTP connections to the command and control servers.  Conficker on their network is mostly disarmed.Â
PDF Creator    Send article as PDF   

ROI of good security.

The cost of good security is a fraction of the cost of damages that usually result from a single successful compromise. When you choose the inexpensive security vendor, you are getting what you pay for. If you are looking for a check in the box instead of good security services, then maybe you should re-evaluate your thinking because you might be creating a negative Return on Investment.

Usually a check in the box means that you comply with some sort of regulation, but that doesn’t mean that you are actually secure. As a matter of fact, almost all networks that contain credit card information and are successfully hacked are PCI compliant (a real example). That goes to show that compliance doesn’t protect you from hackers, it only protects you from auditors and the fines that they can impose. Whats more is that those fines are only a small fraction of the cost of the damages that can be caused by a single successful hack.

When a computer system is hacked, the hacker doesn’t stop at one computer. Standard hacker practice is to perform Distributed Metastasis and propagate the penetration throughout the rest of the network. This means that within a matter of minutes the hacker will likely have control over the most or all of the critical aspects of your IT infrastructure and will also have access to your sensitive data. At that point you’ve lost the battle… but you were compliant, you paid for the scan and now you’ve got a negative Return on that Investment (“ROI”).

So what are the damages? Its actually impossible to determine the exact cost in damages that result from a single successful hack because its impossible to be certain of the full extent of the compromise. Never the less, here are some of the areas to consider when attempting to calculate damages:

  • Man hours to identify every compromised device
  • Man hours to reinstall and configure every device
  • Man hours required to check source code for malicious alterations
  • Man hours to monitor network traffic for hits of malicious traffic or access
  • Man hours to educate customers
  • Penalties and fines.
  • The cost of downtime
  • The cost of lost customers
  • The cost of a damaged reputation
  • etc.

(The damages could *easily* cost well over half a million dollars on a network of only ~50 or so computers. )

Now lets consider the Return on Investment of *good* security. An Advanced Penetration Test against a small IT Infrastructure (~50 computers in total) might cost something around $16,000.00-$25,000 for an 80 hour project. If that service is delivered by a quality vendor then it will enable you to identify and eliminate your risks before they are exploited by a malicious hacker. The ROI of the quality service would be equal to the cost in damages of a single successful compromise minus the cost of the services. Not to mention you’d be complaint too…

(Note: the actual cost of services varies quite a bit depending on what needs to be done, etc.)

So why is it that some vendors will do this work for $500.00 or $2,000.00, etc? Its simple, they are not delivering the same quality service as the quality vendor. When you pay $500.00 for a vulnerability scan you are paying for something that you could do yourself for free (go download nessus). Never the less, when you pay $500.00 you are really only paying for about 5 minutes of manual labor, the rest of the work is automated and done by the tools. (If you broke that down to an hourly rate you’d be paying something like $6000.00 an hour since you’re paying $500.00 per 5 minutes). In the end you might end up with a check in your compliance box but you’ll still just as vulnerable as you were in the beginning.

Free PDF    Send article as PDF   

Brian Chess, CTO of Fortify Software – Creating Confusion

So this entry goes to support my previous post about Insecure Security Technologies and some of the confusion that these vendors can cause. Recently Networkworld published an article named ”Penetration Testing: Dead in 2009″ and cited Brian Chess, the CTO of Fortify Software as the expert source. 

The first thing that I want to point out is that Brian Chess is creating confusion amongst the non-expert people who read the article linked above.  The laymen might actually think that Penetration Testing is going to be dead in 2009 and as a result might decide to buy technology as a replacement for the service.  Well, before you make that mistake read this entire entry. I’ll give you facts (not dreamy opinions) about why Penetration Testing is required and why its here to stay.
As a side note, Brian Chess has a vested interest in perpetrating this fantasy because his objective is first and foremost to sell you his technology.  
Technology, like Brian Chess’s technology is a solution to a problem, which by definition means that the problem came first and the technology was always a few steps behind.  With respect to IT Security, hackers are always creating new methods for penetrating into networks (the problem). Because those methods of attack are new, the technology is not able to defeat them (because the solution doesn’t yet exist). So if technology can’t protect you, then how do you protect yourself?

The best way to protect yourself is to use a combination of technology (to solve known problems) and Penetration Testing (to identify the unknown). A properly executed penetration test will reproduce the same or greater threat levels that your infrastructure will likely face in the real world.  This is akin to testing the armor of the M1A2 tank.  You shoot the armor with RPG’s and armor piercing rounds so that you can study the impact and improve the armor to the point where it defeats the threat.  As a result Penetration Testing can move your security posture well past the limits of what technological solutions have to offer.  My professional recommendation is that both Technology and Penetration Testing should be used.  Sorry Mr Chess, but telling people that Penetration Testing will be dead by 2009 is just fiction. 

Moving on…

As a general rule of thumb I try to avoid saying that anything is 100% secure or invulnerable to attack because that sort of claim is impossible.  But while reviewing the Fortify website I found the following text and thought it was worthy of note: “Fortify 360 renders software invulnerable to attacks from cyber predators.” This sort of marketing fluff falls under the same class of confusing noise as Brian Chess’s claim that Penetration Testing will be dead by 2009, total fiction.  It is mathematically  impossible for Fortify 360 to render software “invulnerable to attacks from cyber predators.” unless the software is mathematically proven to be secure, and it hasn’t.  

If anyone disagrees with what I’ve said here by all means leave me a comment. If you can prove me wrong then I’ll happily make corrections, but I’m pretty sure I’m on the ball with this one.   And Mr. Chess, if you think that your technology renders your customers “invulnerable to attacks from cyber predators” then I challenge you to let my research team test an evaluation copy of your technology, after all the skills that we posses according to you are outdated and shouldn’t pose a threat to your software.  ;]

PDF    Send article as PDF   
Return top

INFORMATION

Change this sentence and title from admin Theme option page.