Major cyber attack hits EU Commission and EEAS days before Brussels summit meeting

According to several media reports, a 'serious cyber attack', similar to those we saw against France's finance ministry, has hit the EU Commission and European External Action Service (EEAS).

The Commission is the executive body of the EU, while the EEAS manages the EU's response to crises.

The attacks took place just before the two-day EU meeting in Brussels, where the region's economic and nuclear strategies as well as the Libyan war are scheduled to be discussed. It is unclear whether the EU bodies were specifically targeted.

According to the BBC 'the European Commission has been assessing the scale of the current threat and, in order to prevent the 'disclosure of unauthorised information', has shut down external access to e-mail and the institutions' intranet. Staff have been asked to change their passwords.'

John Leyden at The Register reported that 'El Reg has come into possession of internal emails suggesting that although the attack was detected last week, systems might have been compromised much longer than this, perhaps for months. An apparently extensive investigative and damage assessment effort is looking at the possibility that infected images had been installed."

Detecting Malice with ModSecurity: Open Proxy Abuse

This week's installment of Detecting Malice with ModSecurity will discuss how to detect potential open proxy abuse.  HTTP Proxies excerpt section of Robert 'Rsnake' Hansen's book 'Detecting Malice' -

HTTP Proxies

HTTP proxies are specialized server applications designed to make HTTP requests on behalf of their users. As a result, web servers that receive such requests by default get to see only IP addresses of proxies, and not those of the real users. In many cases the requests will contain the identifying information, but you will need to actively look for it and configure your servers to log such information.

In HTTP, request meta-data is transported in request headers, so it is no surprised that there you may also find the information identifying the users of proxies. The following request headers are commonly used for this purpose:

Via

 Via – part of HTTP and designed to track HTTP transactions as they travel through proxy servers. The header can contain information on one or several proxies.

 X-Forwarded-For – a non-standard header introduced by the developers of the Squid proxy before the Via header was added to HTTP. X-Forwarded-For is very widely supported today.

Note: In addition to the two request headers above, reverse proxies (which typically route requests from many users to a single server) will set a number of different requests headers to convey the original IP address and, less often, SSL information. Such headers include X-Forwarded-Host, X- Forwarded-Hostname, Client-IP, and others. You will very rarely see such information unless you setup a reverse proxy yourself. If you do see one of these headers in your requests you are advised to investigate, because their presence indicates an unusual—and thus suspicious—setup.

...

X-Forwarded-For

The X-Forwarded-For header is simpler, and it is designed to only contain the IP addresses of the proxies that relayed a HTTP transaction. Here are some examples:

10.255.39.116, 203.144.32.176

10.140.37.84, unknown

212.23.82.100, 212.23.64.155, 195.58.1.134

209.131.37.237

unknown

Proxy Spoofing

The headers that proxies use to relay real user information are not at all required for normal web operation. While most modern proxies are pretty good about including this information, they all allow themselves to be configured not to send it—so you’ll be at the administrators’ mercy, essentially. You should also be aware that anyone not using a proxy can pretend to be a proxy, as the headers can be trivially spoofed.

Open Proxy Abuse - Proxy Chaining for Anonymity

In analyzing typical web-based attacker methodology, for example as part of the WASC Distributed Web Honeypot Project, SpiderLabs sees that the vast majority of attackers use proxy chaining techniques.  Proxy chaining is merely connecting to more than one proxy and then onto to the intended destination. Attackers can use as many proxy servers as they want. The more they have, the more anonymous they will be.  By using proxy chaining the http path may look like this:

attacker's computer => proxy1 => proxy2 => ... => proxy X => target web-site

In order to maximize the potential traceback challenges of security personnel, the savy attackers will choose to distribute their open proxy chaining across multiple geographic regions as this would complicate the process of obtaining log data.  It is this key fact that we can use to our advantage for detecting open proxy abuse.  

Detecting  Open Proxy Abuse

Due to the high use of international proxy chaining by attackers, we can look for GeoIP Country Code mismatches between the final host that is connecting to our web server and the first IP address listed in any X-Forwarded-For request header (as the first IP address is the origin of the request).  In a previous blog post - Detecting Malice with ModSecurity: GeoLocation Data - we showed that ModSecurity supports using geolocation data through the integration with the free MaxMind GeoLite Country or GeoLite City databases.

The first step is to download the database of your choice and put it somewhere on the local filesystem where ModSecurity can use it (for example in the same directory as the Core Rule Set).

Before you can use the GeoIP data, you first have to use the SecGeoLookupDb directive:

SecGeoLookupDb

Description: Defines the path to the geographical database file.

Syntax: SecGeoLookupDb /path/to/db

Example Usage: SecGeoLookupDb /usr/local/geo/data/GeoLiteCity.dat

Processing Phase: N/A

Scope: Any

Version: 2.5.0

Dependencies/Notes: Check out maxmind.com for free database files.

Once the SecGeoLookupDb directive is active, you can then use the following rule set to identify GeoIP Country Code Mismatches between the X-Forwared-For Request Header and the REMOTE_ADDR of the client connecting directly to your web server:

SecGeoLookupDb /usr/local/apache/conf/modsec_current/base_rules/GeoLiteCity.dat
SecRule REQUEST_HEADERS:X-Forwarded-For "^\b\d{1,3}(?<!192|127|10)\.\d{1,3}\.\d{1,3}\.\d{1,3}\b" "chain,phase:1,t:none,capture,block,msg:'Potential Open Proxy Abuse - GeoIP Country Code Mismatch of X-Forwarded-For Request Header and Client REMOTE_ADDR',logdata:'IP Country is: %{geo.country_code} and X-Forwarded-For is: %{tx.geo_x-forwarded-for}'"
        SecRule TX:0 "@geoLookup" "chain,setvar:tx.geo_x-forwarded-for=%{geo.country_code}"
                SecRule REMOTE_ADDR "@geoLookup" "chain,t:none"
                        SecRule GEO:COUNTRY_CODE "!@streq %{tx.geo_x-forwarded-for}" 

The first SecRule inspects the first IP address listed in any X-Forwarded-For headers and captures the data in a TX collection to be evaluated later against the REMOTE_ADDR fo the client.  The regular expression used in this rule uses a negative look-behind to exclude internal/private IP ranges in order to avoid false positives.  The 2nd SecRule takes the saved data and resolves it against the GeoIP DB and stores the Country Code data.  The 3rd SecRule resoves the REMOTE_ADDR against the GeoIP DB and then the 4th SecRule compares these two values together and if they do not match then it alerts.

Example Usage

Let's say that your web server receives the following request as shown by the ModSecurity audit log format entry:

--1f9d1914-A--
[24/Mar/2011:10:19:05 --0400] TYtS1cCoAWgAAQFSdscAAAAA 66.162.147.51 62641 ::1 80

--1f9d1914-B--
GET /path/to/foo.php HTTP/1.1
Host: www.example.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.151 Safari/534.16
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
X-Forwarded-For: 194.30.232.180, 196.2.126.171

--1f9d1914-F--
HTTP/1.1 200 OK
Content-Length: 1221
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/plain; charset=iso-8859-1

The bolded data under Section (A) is the REMOTE_ADDR of the client and the bolded data under Section (B) is the X-Forwarded-For data.  This request would You would generate an alert message like the following:

Message: Warning. Match of 'streq %{tx.geo_x-forwarded-for}' against 'GEO:COUNTRY_CODE' required. [file '/usr/local/apache/conf/modsec_current/base_rules/modsecurity_crs_15_customrules.conf'] [line '37'] 
[msg 'Potential Open Proxy Abuse - GeoIP Country Code Mismatch of X-Forwarded-For Request Header and Client REMOTE_ADDR'] [data 'IP Country is: US and X-Forwarded-For is: GR' 

Added to OWASP ModSecurity Core Rule Set (CRS)

This experimental rule set has been added to the OWASP ModSecurity CRS trunk repository.  If you would like to try out these latest CRS, you should follow these steps:

1. Create a local svn directory - $ mkdir svn/crs
2. Go into the the svn directory - $ cd svn
3. Use SVN to clone the CRS trunk - $ svn co https://mod-security.svn.sourceforge.net/svnroot/mod-security/crs/trunk crs

Fraudulent certificates issued by Comodo, is it time to rethink who we trust?

Fraudulent certificates issued by Comodo, is it time to rethink who we trust?: "

Today, Microsoft issued a Security Advisory warning that fraudulent digital certificates were issued by the Comodo Certificate Authority. This could allow malicious spoofing of high profile websites, including Google, Yahoo! and Windows Live.

The advisory states how 9 certificates were fraudulently issued by Comodo for the following names:

• login.live.com

• mail.google.com

• www.google.com

• login.yahoo.com (3 certificates)

• login.skype.com

• addons.mozilla.org

• 'Global Trustee'

The major issue is that Comodo is a trusted root authority on all default Windows and OS X installations. This means that an attacker could easily masquerade a malicious website as one of the above with the HTTPS authentication succeeding.

This kind of power would have any internet miscreant drooling over the opportunity to construct phishing sites, perform man-in-the-middle attacks, and any other content-spoofing attack that can be dreamed up.

That being said, Comodo claims in an incident report that only one yahoo.com certificate was seen live on the internet, and that site was promptly taken down.

All of the fraudulent certificates have been revoked and browsers with certificate revocation checking enabled (see below) will properly identify the certificates as invalid.

How did this happen?

According to a report by Comodo, an account used for the approval of certificate requests was compromised within one of their trusted partners.

An attacker obtained the username and password of a Comodo Trusted Partner in Southern Europe. We are not yet clear about the nature or the details of the breach suffered by that partner other than knowing that other online accounts (not with Comodo) held by that partner were also compromised at about the same time.

The attacker used the username and password to login to the particular Comodo RA account and effect the fraudulent issue of the certificates.

This highlights one of the major problems with digital signatures and the public key infrastructure (PKI) -- that being transitive trust.

When Comodo provided their partner with the ability to issue certificates in their name, they were not only trusting said partner to properly vet the identities for certificate applicants, but also trusting the partner to protect this power to issue certificates.

This is similar to the Stuxnet outbreak from last year, in which the private key compromise of hardware vendor Realtek enabled fraudsters to spread malware having a valid digital signature.

In that case, by issuing the certificate to Realtek, the certificate authority was similarly not only trusting Realtek to sign legitimate software themselves, but also trusting them to protect this power from abuse.

Trust is transitively passed down the certificate chain, where a compromise at any level breaks the chain completely -- and every chain has its weakest link.

Countermeasures

As stated above, Comodo has already revoked the 9 fraudulent certificates. The revoked certificate serial numbers are published in Comodo's Certificate Revocation List (CRL), which can be manually imported and consumed on most platforms; on Windows via certmgr.msc, on OSX via KeyChain, or directly into some browsers, like Firefox.

Enabling certificate revocation checking in your browser is also advisable, not only for this particular issue, but to benefit from past and future revocation information as well.

Notably, from my VB2010 presentation on digital signature abuse, neither Internet Explorer 8 nor Firefox have certificate revocation options set to safe defaults. Internet Explorer 8 has server certificate revocation checking off by default and Firefox only has Online Certificate Status Protocol (OCSP) revocation enabled. Microsoft has changed the default in Internet Explorer 9 to have server certificate revocation checking enabled by default.

Fortunately in this case, Comodo certificates support OCSP revocation, so Firefox users (including Firefox 4) as well as IE9 users will be protected by default, where as IE8 users will have to enable this setting, if they have not already.

In parallel, Microsoft have also issued an update that installs the 9 fraudulent certificates as 'Untrusted Certificates'. These are also viewable via the certmgr.msc tool on Windows.

And for the uber paranoid, you can perform an extra sanity check by examining the issuer of the certificate when visiting one of these sites -- as none of the genuine certificates have been issued by Comodo.

Closing thoughts

The immediate action items are clear; users on all platforms should ensure they've got up-to-date certificate revocation data and browser settings to keep it that way for the future.

The longer term solutions for the security industry are less so. While the detection of these fraudulent certificates was quick and published remediation swift, this fast response may well have been a fluke as a result of the particular way the attack was conducted.

In their incident response, Comodo reports the attacker used the compromised account to create a new account from which the fraudulent certificates were approved.

Perhaps if the attacker had been more covert, avoiding the user creation and separating the high-profile certificate request approvals by a longer time frame, the compromise may have gone unnoticed with far more drastic consequences.

In no way is this an easy problem to solve. Software has vulnerabilities; systems get broken into; malicious insiders aid and abet.

Hopefully this causes the industry players to audit not only their own security systems and policies, but those of their trusted partners as well. As the problem of transitive trust remains inherent in the PKI, it's about every link in the chain, not just your own.

Happy browsing.

Creative commons picture of a padlock courtesy of Trevor Blake's Flickr photostream.

"

Microsoft Advisory about fraudulent SSL Certificates

Published: 2011-03-23,
Last Updated: 2011-03-23 18:05:29 UTC
by Johannes Ullrich (Version: 3)
Rate this diary:
2 comment(s)
Update: Looks like the update is marked important, but will not install automatically. You may have to run Windows Update to install it.
Update 2: And Comodo just published an advisory: http://blogs.comodo.com/it-security/data-security/the-recent-ca-compromise/ also not that this is still the same issue we talked about this morning with respect to Firefox 4.

Microsoft just released an advisory [1] alerting its customers that a total of 9 certificates where issued using the leaked/stolen CA certificated from Comodo.
The affected domains are according to Microsoft:
login.live.com
mail.google.com
www.google.com
login.yahoo.com (3 certificates)
login.skype.com
addons.mozilla.org (already known from an earlier announcement by Mozilla)
"Global Trustee"
The advisory states that Comodo has revoked these certificates and listed them in its revocation list. Microsoft also is releasing an update that will blacklist these certificates.
Of course, this issue is "serious", not just considering the household brand names affected. Probably even worse then the possible man in the middle attacks that may have happened is the simple fact that this fundamentally breaks the trust model of SSL. SSL is using a "trust pyramid", A few certificate authorities are trusted to issue certificates to entities they trust. Of course this trust should be based on some kind of verification and the ability to secure the private key that goes with the root certificates and the signing certificates based on it. This event more and more looks like the trust pyramid was really more a stinking pile of doo . No surprise given the rush to the "no paper work required bargain basement certs". I recently started using free certs from startssl.com just for that reason: At least startssl doesn't charge me for not verifying who I am.

In short: Patch... and hope you will be ok until the next time this happens. It would be nice if Comodo would come forward with details. It was probably the APT Monster that ate it.
[1] http://www.microsoft.com/technet/security/advisory/2524375.mspx
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

A demonstration of Middles new sniffing tool + installer for Ubuntu

This new script for Ubuntu based systems will install all of the tools necessary to perform a man in the middle attack that sniffs traffic being transferred across the network. This will allow you to view all POST and GET data in plain text even if it is being transfered over HTTPS. This is thanks to the usage of sslstrip by moxie marlinspike. The program then uses arpspoof from the dsniff package to redirect traffic.

This is all tied together with a nice script coded by me, it will automate everything you need to do, apart from reading the captured data, that bit is easy though.

You can download it here:

http://www.mediafire.com/?ydppuuc8on396o3

Hacker gets Microsoft Kinect to work with Sony Playstation3

A HACKER has made Microsoft's Xbox360 accessory Kinect work with Sony's Playstation 3.

Using his technical knowledge and a little rule bending, software programmer Shantanu Goel managed to make the Kinect work as an input controller for the PS3.

The Playstation 3 has a similar gadget in the Playstation Move, but Goel said, 'Nothing beats the lure of making something work with just the 'The Force'.

Goel posted up a YouTube video of the Kinect PS3 in action working with the game Killzone 3. After logging into his PS3 account, Goel played the game by simply using his hand movements.

Double push controls select or the X button, scrolling left, right and up follows the hand movements. If you run out of scrolling space, you use a backward push to stop scrolling, move your hand back, do another backpush and start again. This is similar to way you work with a touchpad.

It wasn't perfect, though. From the beginning you could see problems Goel was having getting rid of the intro scenes. And when you got to the game the game didn't look particularly easy to control and Goel needed to sit down to get the Kinect to track his movements properly.

In fact Killzone 3 was probably the wrong game to really showcase PS3 Kinect in action. But you can see possibilities for other games. Sony might not be particularly happy, as a properly working PS3 Kinect has the potential to hit Playstation Move sales. µ

Critical Security Updates for Adobe Acrobat, Flash, Reader

Adobe today released a software update to plug a critical security hole in its Flash Player, Adobe Acrobat and PDF Reader products. The patch comes a week after the software maker warned that miscreants were exploiting the Flash vulnerability to launch targeted attacks on users.

The Flash update addresses a critical vulnerability in Adobe Flash Player version 10.2.152.33 and earlier; versions (Adobe Flash Player version 10.2.154.18 and earlier versions for Chrome users) for Windows, Macintosh, Linux and Solaris operating systems; and Adobe Flash Player 10.1.106.16 and earlier versions for Android.

Adobe is urging all users to upgrade to the latest version — Flash v. 10.2.153.1 (Chrome users want v. 10.2.154.25, although Google is likely to auto-update it soon, given their past speediness in applying Flash updates). Update: According to The Register’s Dan Goodin, Google updated Chrome to patch this Flash flaw a full three days ago!

Original post: Click this link to find out what version of Flash you have installed. If something goes wrong in your update, or if you’re just a stickler for following directions, Adobe recommends uninstalling the current version of Flash before proceeding with the update (Mac users see this link).

As always, if you use Internet Explorer in addition to other browsers, you will need to apply this update twice: Once to install the Flash Active X plugin for IE, and again to update other browsers, such as Firefox and Opera. Updates are available by browsing to the Flash Player Download Center. A manual installer for Windows should be available at this link.

If you have Adobe Reader or Acrobat installed, you are going to have to update these programs, too, because they contain the same vulnerability Adobe said attackers have been using against Flash users. For users of Adobe Reader 9.4.2 for Windows and Macintosh, Adobe has made available Adobe Reader 9.4.3. Adobe says the “protected mode” built into its Adobe Reader X version would prevent an exploit of this kind from working, so the company doesn’t play to address the issue in Reader X until the next quarterly update, due out June 14, 2011. In the meantime, Adobe X users on Windows and Mac should make sure they have the latest version installed (10.0.2). If you want to check your version of Reader, open the program and click the “Help” menu, and the look for an entry that says “About Adobe Reader.”

Reader users on Windows and Mac can use the software’s built-in update mechanism, by choosing “Help,” then “Check for Updates.” Alternatively, the download page is here (note that updating via the Web site may pre-check the option for installing other software, such as security scanners: If you don’t want those extras, pay close attention during the install process).