SECFORCE          
SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing
   
HOME SECFORCE - penetration testing COMPANY SECFORCE - penetration testing SERVICES SECFORCE - penetration testing RESEARCH SECFORCE - penetration testing BLOG SECFORCE - penetration testing INITIATIVES SECFORCE - penetration testing CONTACT
 
SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing
    SECFORCE - penetration testing

Blog ■

 
SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing
    Home : Blog  
SECFORCE - penetration testing SECFORCE - penetration testing
   
Archive for December, 2008
 

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

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.

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:

FTP Bounce example - Network scanning from a printer
FTP Bounce example – Network scanning from a printer

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:

Network sniffer capturing 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.

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

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.

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.

 
   
 
BLOG

Archives

July 2014
April 2014
March 2014
February 2014
August 2013
June 2013
February 2013
January 2013
December 2012
November 2012
October 2012
January 2012
October 2011
September 2011
July 2011
June 2011
April 2011
February 2011
January 2011
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008

Categories

Aircraft security (1)
Business Continuity (2)
CREST (1)
cyber security (2)
Embedded devices security (2)
exploit (8)
Fuzzing (1)
Penetration Testing (41)
Phishing (3)
Risk Management (5)
SECFORCE (17)
Security architecture (2)
Security Books (1)
Security Compliance (1)
Security research (9)
social engineering (1)
social media (1)
sql injection (3)
SQL Server (3)
Tools (13)
Uncategorized (2)
Vulnerabilities (10)
 
SECFORCE - penetration testing
  SECFORCE - penetration testing Aegon House, 13 Lanark Square
Canary Wharf - E14 9QD, London
SECFORCE - penetration testing Direct Line +44 (0) 845 056 8694
E-mail SECFORCE - penetration testing
  Follow us in Twitter Check us out in LinkedIn SECFORCE is CREST certified. Click on the logo for more information ISO9001 ISO27001
SECFORCE - penetration testing
    Copyright (c) 2014 SECFORCE Ltd · All Rights Reserved