Tuesday, January 25, 2011

Netragard Challenges your PCI Compliance

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).

Sunday, January 16, 2011

Netragard: Connect to Chaos

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.

Friday, January 14, 2011

Pentesting IPv6 vs IPv4

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 2128 possible addresses with IPv6, which is far more than the 232addresses 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 2128 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.

Friday, January 7, 2011

Hacking your car for fun and profit.

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.