Practical attack against SSL certificates - Creating a rogue CA certificate

Tuesday, December 30th, 2008

In a presentation at the Chaos Communication Congress (Berlin, 27-30 December 2008) Alexander Sotirov, Marc Stevens and Jacob Appelbaum revealed how a weakness in the MD5 hashing algorithm could be used to create a rogue certificate.

Previous research showed the theory of this attack but this is the first practical implementation exploiting this flaw.

SSL uses server certificates to verify the identity of the server (this is the public key of the owner) and prevent man-in-the-middle attacks. When a user visits a secure (HTTPS) site the web browser retrieves the web server certificate issued by a CA (Certificate Authority). The fundamental security issue comes when a CA signs the certificate using a weak hashing function such as MD5.

Using “Chosen-prefix MD5 collisions” an attacker could manipulate a legitimate CA certificate and create a rogue one with arbitrary domain name with the same MD5 signature as the original one.

The researchers used a cluster of 200 PlayStation 3 to compute the correct MD5 hash. They used a field in the certificate called Netscape Comment Extension to inject the necessary code:

Injected code

A sample of the certificate can be found in the following URL:

https://i.broke.the.internet.and.all.i.got.was.this.t-shirt.phreedom.org/

The impact of this attack is that an attacker could sign fully trusted certificates and conduct perfect man-in-the-middle attacks.

As anyone could generate this kind of certificates, revocation of known malicious certificates is not a possible option. SECFORCE recommends that the content of the Netscape Comment Extension field (and other similar fields) are checked before accepting a certificate.

Tags: certificates, certificates authorities, md5, rogue certificates, signature collisions, ssl
Posted in Phishing, Risk Management | No Comments »

FTP bounce network scan - My printers are scanning my network

Wednesday, December 24th, 2008

Some time ago we were performing an internal penetration test an we identified a Canon iR C2880 printer within the IP range in the scope of testing. Printers is the kind of device that a penetration tester tend to dismiss as they don’t look very attractive from the attacker’s perspective.

It is a fact that printers are usually installed with all the settings by default. This includes having the default administration password (if any), default administrative interfaces enabled, default services running, default SNMP community string, etc.

It is interesting to note that some printers run an anonymous FTP server that users (and processes) can use to print documents. A user can upload a document to the FTP server running on the printer and it will be printed. Things get worse when you discover that the FTP server supports the PORT command.

The PORT command is sent by the FTP client to establish a secondary channel for data to travel over. This command can be abused by attacker to network scan other hosts on your network, as shown in the next diagram:

Why an attacker would want to do that? Well, there might be several reasons:

- The target host is not reachable from the network segment the attacker is connected but it is from the printer.
- The target host is reachable but there is a firewall filtering some of the traffic whereas the printer has full connectivity to it.
- The attacker wants to remain stealth and conduct the scans only using FTP connections to the printer without triggering any alarm from potential IDS systems.

This is an example of how the sniffed network traffic would look during an FTP bounce scan:

The network traffic screenshot shows that the attacker is using the printer as a bounce host and the only traffic exchanged is FTP based.

As you can see, IT security and penetration testing is about identifying every issue in your infrastructure and exploiting the weakest link.

Tags: FTP bounce scan, ftp port command, internal penetration test, internal penetration testing, network scan, penetration test, printer security
Posted in Penetration Testing | No Comments »

why penetration test? firewall is not secure enough?

Tuesday, December 9th, 2008

A few days ago someone visited our website after searching in Google “why penetration test? firewall is not secure enough?“. We are going to dedicate this post just to that topic.

A firewall is a device connected to two different networks and with a number of rules which determine what traffic goes from one network to the other and vice versa. That simple. For example, a recommended configuration for a firewall protecting a web server is to filter all inbound and outbound network traffic by default, allowing only inbound traffic to your web server port (TCP/80).

Firewall protecting web server at the network layer

No doubts this is a good configuration which will protect the web server from many attacks. The firewall will filter network access to many services, but the question is “why penetration test? firewall is not secure enough?”. Well, the answer is “no”, with just a firewall the above environment is not secure enough. A firewall is always going to allow some traffic, otherwise it would be better removing the firewall and having both networks disconnected.

In the configuration above the firewall allows connectivity to the web server, therefore an attacker targeting the website will have full network access to it. The firewall will do very little to protect the web application.

So back to the question, “why penetration testing?”. Penetration testing is a method of assessing the security of a system or network by emulating a real attack scenario whereby a security consultant assumes the role of a motivated but non destructive ‘hacker’. In the scenario above a penetration test will highlight any misconfiguration on the firewall and, what it’s more important in this case, will identify any vulnerability affecting your website which could be exploited by remote attackers.

In summary, a firewall is a great security tool which can protect your infrastructure from some threats, but they certainly can not protect you from everything. Additially, penetration testing can be beneficial to assure that your systems and applications are secure.

Tags: firewall, penetration test, Penetration Testing, web server security
Posted in Penetration Testing | No Comments »

GMAIL phishing attack saga

Monday, December 1st, 2008

It all started a week ago. Some news hinted that some attackers were stealing domains taking advance of a Gmail vulnerability. Even when it was not confirmed, the story was Digged and generated quite a lot of buzz in the security community.

It all seemed that a new version of an old GMail hijack technique

On Tuesday Google confirmed that no known vulnerabilities were affecting Gmail and that the incidents were phishing attacks whereby attackers set up fake websites asking for Gmail username and password.

This is very interesting because it reinforces the theory that simple attacks targeting human mentality are still very effective. At SECFORCE we work with our clients to increase security awareness and prevent this kind of attacks form happening.

Tags: gmail, hijack, Phishing
Posted in Phishing | No Comments »

Penetration testing, antivirus, firewalls and false sense of security

Sunday, November 9th, 2008

False sense of security is an ongoing issue. Fueled by inaccurate marketing strategies promising the ultimate security product and convincing clients that their product will make your system immune to every single attack.

Security professionals are used to hear all kind of comments from clients caught up by false sense of security; the three most common mistakes are:

Client - My application must be secure, it is running over SSL.
Penetration tester - That’s good, your IDS will not pick up my attacks.

Client - My web application must be secure, it is protected by my firewall.
Penetration tester - Sure enough your firewall is not going to filter web traffic on your web server.

Client - My server must be secure, it has an antivirus up to date.
Penetration tester - Your antivirus will only pick up known signatures, it will not pick up my custom made scripts.

We recently performed a back box web application peneration test for a client who expresed (before the penetration test) how secure his application was as he deployed SSL on the application layer, antivirus on the server and everything was protected using a firewall.

During the penetration test we managed to find a page which allowed uploading arbitrary files to the web server. When we tried to upload some of the standard web shells we saw how the antivirus was detecting them and removing them from the server. It is fair to say that an antivirus in this case provides a very thin layer of security. After doing some modifications to the scripts we easily bypassed the antivirus protection.

In this example achieving command execution required another step as the user the web server was running as had not enough privileges. However, it was easy enough finding a high privilege username/password for the MS SQL database also running on the server. The next steps were:

- Creating a custom script which connected to the MS SQL database using a high privileged account.
- Enabling xp_cmdshell stored procedures, as we found it disabled.
- Enjoying command execution.

Once we got to this point it was easy to execute Metasploit Meterpreter to bypass firewall protection, tunneling services over HTTP.

In conclusion, SSL, antivirus and firewalls are essential parts on the security of an infrastructure, however they need to be properly implemented and they don’t protect from all kinds of attacks.

Tags: antivirus, antivirus bypass, black box, false sense of security, firewall, firewall bypass, metasploit, meterpreter, Penetration Testing, web application penetration test
Posted in Penetration Testing | No Comments »

Black box penetration testing vs white box penetration testing

Monday, November 3rd, 2008

One of the common questions that we get from our clients is about the differences between a black box penetration test and a white box penetration test.

White box testing, also known as clear box testing or glass box testing, is a penetration testing approach that uses the knowledge of the internals of the target system to elaborate the test cases. In application penetration tests the source code of the application is usually provided along with design information, interviews with developers/analysts, etc. In infrastructure penetration tests network maps, infrastructure details, etc. are provided. The goal of a white box penetration test is to provide as much information as possible to the penetration tester so that he/she can gain insight understanding of the system and elaborate the test based on it.

White box penetration testing has some clear benefits:

• Deep and thorough testing
• Maximizes testing time
• Extends the testing area where black box testing can not reach (such as quality of code, application design, etc.)

However, there are also some disadvantages:

• Non realistic attack, as the penetration tester is not in the same position as an non-informed potential attacker

A black box penetration test requires no previous information and usually takes the approach of an uninformed attacker. In a black box penetration test the penetration tester has no previous information about the target system.

The benefits of this type of attack are:

• It simulates a very realistic scenario

The disadvantages of a black box penetration test are:

• Testing time can not be maximised in certain scenarios
• Some areas of the infrastructure might remain untested

When commissioning a penetration test, there is no right/wrong decision about white box or black box, it really depends on the scenario that needs to be tested.

Tags: black box, penetration test, Penetration Testing, white box
Posted in Penetration Testing | 1 Comment »

Penetration testing and risk management - Consultants vs Monkeys

Thursday, October 30th, 2008

There are no doubts that penetration testing is becoming mainstream now. It looks like business are eventually concerned about security. Compared to some years ago the number of companies requesting penetration tests has increased exponentially and therefore the number of companies conducting them has incresed too.

One of the important problems affecting some penetration testing companies is that they conduct penetration tests with a very narrow perspective, they don’t put things into context. I call it monkey work. It is quite easy running an automated vulnerability scanner and produce a nice report. However, vulnerability scanners are not clever enough to know how a specific vulnerability affects a bussiness.

A typical example is XSS vulnerabilities. Depending on the context they can be devastating or just a minor issue. It is up to the penetration tester to decide how important this security issue is for the business. I call it consultant work and it is where risk management comes into the game.

At the end of the day a business man just cares about the business. If he/she is conducting a penetration test it is not due to the pleasure of learning about buffer overflows and injection vulnerabilities - it is because he/she thinks the penetration test is good for the business (due to a number of reasons such as clients trust, compliance, etc.).

Therefore what they really want to know about a security issues is:

• What is the impact for the business
• What is the likelihood of happening
• How can be solved

What they are not interested in is:

• Why stack protection mechanisms can not protect you from a heap overflow
• How you control EIP on this exploit
• Why a fuzzer would have never discovered that vulnerability
• etc…

Tags: Penetration Testing, Risk Management
Posted in Penetration Testing, Risk Management | No Comments »

MS vulnerabilities and worms

Friday, October 24th, 2008

Time between vulnerability disclosure and worm spread has been drastically reduced.

The MS08-067 vulnerability has been published some hours ago. Microsoft rated this vulnerability as critical, as a remote unauthenticated attacker could exploit it to execute arbitrary code in the vulnerable host.

This vulnerability is caused due to a bug in the Windows Server service handling a crafted RPC request.

The vulnerability affects almost all the Windows operating systems family, with some differences. On Windows 2000, XP and 2003 an attacker could exploit this vulnerability without the need of a username and password. However, the exploitation in Windows Vista and Windows Server 2008 requires a valid username and password.

The really interesting thing about all of this is that Microsoft published the following in its Security Bulleting:

It is possible that this vulnerability could be used in the crafting of a wormable exploit.

Just after a few hours reliable exploits are already available and what is more, a worm has been already found in the wild exploting this vulnerability.

The name of the worm is Gimmiv.A and uses this vulnerability to spread over the network. On infection, the worm injects two DLLs into the services.exe address space. After that, the worm retrieves information from the compromised host (including passwords from the Windows protected storage) and posts it in encrypted form to a remote host.

The worm posts the details to a number of hosts, including http://perlbody.t35.com/

At the time of writing the host is up and running and contains details of 3779 hosts stored int the http://perlbody.t35.com/icon.txt file.

The worm also downloads the following image stored on the http://perlbody.t35.com/ server:

Microsoft and SECFORCE recommends that customers apply the update immediately as other versions of worms exploiting this vulnerability are likely to be released.

Tags: exploitation, Gimmiv.A, MS08-067, worms
Posted in Vulnerabilities | 1 Comment »

Penetration testing with IPv6

Tuesday, October 14th, 2008

Today has been released the Uninformed (number 10) magazine. As usual it is a very interesting read, with very nice and technical articles there. One of them caught my eye, written by H D Moore - Exploiting Tomorrow’s Internet Today, Penetration testing with IPv6.

IPv6 is an Internet layer protocol designed to substitute the current IPv4. The article covers the basics of IPv6 such as configuration and addressing standards.

Later in the article the author some of the common tasks of penetration testing focusing on IPv6 protocol:

Network Discovery

Van Hauser’s IPv6 Attack Toolkit contains a tool for this. The alive6 tool sends an ICMP6 packet using Neighbor Discovery protocol:

# alive6 eth0
Alive: fe80:0000:0000:0000:xxxx:xxff:fexx:xxxx
Alive: fe80:0000:0000:0000:yyyy:yyff:feyy:yyyy

Found 2 systems alive

Tools ip and ping6 can also be used for that:

# ping6 -c 3 -I eth0 ff02::1 >/dev/null 2>&1
# ip neigh | grep ^fe80
fe80::211:43ff:fexx:xxxx dev eth0 lladdr 00:11:43:xx:xx:xx
fe80::21e:c9ff:fexx:xxxx dev eth0 lladdr 00:1e:c9:xx:xx:xx
fe80::218:8bff:fexx:xxxx dev eth0 lladdr 00:18:8b:xx:xx:xx
[...]

H D More also covers the use of Nmap and Metasploit against IPv6 hosts.

It is interesting the use of socat to ‘translate’ from IPv4 to IPv6 and then being able to use the common penetration testing tools:

$ socat TCP-LISTEN:8080,reuseaddr,fork TCP6:[IPv6%eth0]:80

In the example above socat creates and binds a local IPv4 port (8080) to a remote IPv6 service which was listening on port 80. After running the command above, the penetration tester can confortably use the common web assessment tools such as nikto o web proxies even if they don’t natively support IPv6.

Tags: IPv6, metasploit, nmap, Penetration Testing
Posted in Penetration Testing | No Comments »

SCADA Security

Friday, October 10th, 2008

It is interesting to see how security research is a kind of a living being. Almost by nature security rearchers focus their efforts in whatever is more familiar to them, resulting in a vast amount of time dedicated to fairly accessible products such as Microsoft Windows operating systems, MS Office, Linux in its different flavours, etc.

This leaves a gap in the security industry where highly deployed systems (sometimes critical for government infrastructure) remain untested and its security is several years behind the avarage IT system.

Two clear examples of this are MPLS and SCADA systems. Given the fact that these systems are rarely found in penetration testing engagements and independent researchers struggle to find a suitable environment for testing, it doesn’t come to a surprise their security doesn’t match nowadays avarage.

Last week there was two vulnerabilities affecting SCADA systems:

• DATAC RealWin Preauth remote vulnerability, whereby a remote attacker can execute arbitrary code on the affected system.
• ABB PCU400 buffer overflow, whereby remote execution of arbitraty code is possible.

In a world where stack buffer overflows are among species threatened with extinction it is rather suprising reading this kind of vulnerabilities. There is no doubt that due to a number of circunstances security research has been appart from these technologies.

Tags: datac realwin, mpls, pcu400, Penetration Testing, scada, security, Vulnerabilities
Posted in Vulnerabilities | No Comments »