Man-in-the-middle fun with Perl LWP

Note: If you don't care about Perl anymore, and you never have to audit projects that have PERL in them, just skip this entirely.  This is basically about a perl gotcha that seems to have hit every project I've come across that uses LWP.  Nothing more, nothing less.


When you use perl and you want to access HTTP/HTTPS/FTP content, you'll typically use a pre-made module to accomplish the task.  One of the most common modules to do this is LWP.  LWP is not only used directly, but by several other popular modules to handle network communications.  And this scares me...


Why? Because perl programmers often use LWP to handle "web stuff".  Code I have encountered that uses LWP may disallow certain protocols that can be accessed, such as "file:" because they know that they only want to access remote URLs, but does not often do anything special to handle HTTPS securely.  This may be because the entire notion of validating certificates the LWP-way is so counterintuitive that even the most experience perl folks I know have never encountered this.


Here's the issue with LWP and HTTPS:


Unless you define a custom HTTP request header called "If-SSL-Cert-Subject" and set it to a regular expression that properly matches the subject field of an SSL certificate, you won't be doing proper hostname validation.  Without hostname validation, you might as well not be using SSL.


I have not come across a single project that uses LWP and has hostname validation enabled.  There's a lot of code out there and I'm sure someone has done it right somewhere.  I have a feeling this lack of validation is because (a) programmers expect HTTPS libraries to do this by default, and (b) the interface basically makes no sense. 


Here's a snippet from the LWP perldoc that describes this functionality:

       The request can contain the header "If‐SSL‐Cert‐Subject" in order to make the request conditional on the content of the server certificate.  If the certificate subject does not match, no request is sent to the server and an internally generated error response is returned.  The value of the "If‐SSL‐Cert‐Subject" header is interpreted as a Perl regular expression.

Remember that a certificate's subject may look like this:


https://www.google.com:

subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com

or like this:

https://www.godaddy.com:

subject=/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc/OU=MIS Department/CN=www.GoDaddy.com/serialNumber=0796928-7/2.5.4.15=V1.0, Clause 5.(b)

As the value of this header is a regex, one cannot simply use a hostname.  Remember that /domain.com/ will match "someotherdomain.com" or even "hacker.anotherdomain.computerparts.topleveldomain".  Your code will still be vulnerable to attackers unless your regular expression is properly anchored and you take the time to properly parse the subject line which is a chore to say the least.  Additionally, subjects are not guaranteed to all follow the same order or format, which makes writing a general purpose check rather difficult.

And remember, if you don't do this (correctly), you might as well not be using SSL.

I have filed a couple of bugs against the larger perl projects I am aware of that use LWP.  I would strongly suggest that any perl programmers reading this check to see if they have used LWP and if so, if they have actually enabled correct hostname validation. 

Here's a snippet of perl blatantly ripped out of the perldoc for LWP::UserAgent that demonstrates setting the header so you can play around with it:

#!/usr/bin/perl

require LWP::UserAgent;

my $ua = LWP::UserAgent->new;

# If no If-SSL-Cert-Subject header exists, no hostname validation is on

# Here's a certificate check that can by bypassed by anyone. Think attacker.domain.combinationlockfactory.com

#$ua->default_header("If-SSL-Cert-Subject"=>'domain.com');

# Any of the following lines will validate https://www.godaddy.com...

#$ua->default_header("If-SSL-Cert-Subject"=>'Domain Control Validated');

#$ua->default_header("If-SSL-Cert-Subject"=>'www.Go');

#$ua->default_header("If-SSL-Cert-Subject"=>'www.GoDaddy.com');

$ua->timeout(10);

my $response = $ua->get('https://www.godaddy.com/');

if ($response->is_success) { print $response->content; } else { die $response->status_line; }

This seems like a pretty dangerous, hard to use interface.  I've reached out to some people in the perl community about trying to fix this.   I'm interested in your comments.  Hopefully reading this has not been a waste of your time.

iOS Safari text search - a feature that boldly ignores user privacy and security

In case you missed it, Apple added a new feature -- one that I don't understand how they haven't had until now -- the ability to search for text in the current page. They must have thought pretty highly of it, given that they tout it on their main iOS feature page (here).  Here's their description of the feature:

In Safari, you can do a quick text search to find and highlight specific words and phrases on even the longest web pages.


I'm highlighting this feature because the way this feature works is ridiculous.  I mean, staggeringly ridiculous.


1. You go to a web page
2. You start entering the text you want to find in the search box
3. If your search term is found in the page, the you'll see it in the search results and can select it to be found in the current web page.


Here are some screenshots of this in action searching for "iPhone" at https://www.paypal.com (note the nice green EV title!):

And the corresponding request:

GET /complete/search?json=t&nolabels=t&client=iphonesafari&q=iPhone HTTP/1.1

Host: clients1.google.com

User-Agent: Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_2_1 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8C148 Safari/6533.18.5

Accept: */*

Accept-Language: en-us

Accept-Encoding: gzip, deflate

Okay, so what's wrong with this?  Clearly anyone using this interface knows they are typing data into the search box from Google (or whatever search engine is selected).

Wait, stop, what?

You mean they designed a brand new feature to let you search the text of the current page, but only on the condition that you give up your privacy and security by sending it cleartext over the wire to your search provider and everyone watching the network? Yes.

Well, it's a good thing that sniffing local networks is not much of an issue.. oh wait.. ever heard of FireSheep?  The fact that FireSheep caused such problems not only highlighted the lack of basic encryption on popular websites, but also that there are indeed often attackers on the network sniffing your data.

I've always been a big fan of the way Apple makes user interfaces work.  The settings I need are normally right where I'd look for them, nice and integrated with each other.  Whoever made this feature was probably hoping for that kind of elegance, but clearly fell on their face.

Here's why I think so:

1.  You shouldn't force users to do something insecure to get the job done.  Users will do that insecure thing, and you really can't blame them.  They need to get their job done on their smart phone.

2. You shouldn't mix security context in such an irresponsible way.  I doubt most users understand they are sending this data cleartext over the wire, for everyone to see.  A traditional text search in a web page doesn't do this.  I'm not sure why you think users will get it.  Especially since they probably have faith that Apple will do its job properly.

This was a fail.  Apple is setting users up for failure.  There is absolutely no reason for this data to be disclosed, let alone in the clear, on the wire in order to search on the current web page.

I urge Apple to fix this, because they are good enough, smart enough, and doggone it people like them.  Also, it's about to be 2011.  You should make a new years resolution not to let people work on Safari UI who don't understand at least the basics of web security.

Apple's iOS 4.2.1 addresses two iPhone security issues that I found

Apple released iOS 4.2.1 today, which addresses two bugs I found and reported to them.  Their description of the issues are pretty accurate, but I do have some additional comments.  You can check out Apple's description of these bugs at http://support.apple.com/kb/HT1222


Apple has included this text in the description for both bugs:  "An attacker with a privileged network position may...".  I do not agree with this.  We have seen countless demonstrations of data on the internet traveling through networks it is not supposed to because of attacks using BGP, DNS, and other protocols.  I feel like this wording should be reserved for cases where the attacker has to do something more than hijack data over the public internet.  For example, if you must be able to get on some private internal network, like a 10.x network inside the attacker's house, perhaps that is a privileged network position.  I don't think China was in a privileged network position when they (supposedly?) hijacked traffic destined for US websites.


I understand that these attacks are much easier if you are on the local network of the victim.  I just think the days of implying this is the extent of the problem are long over.  It is possible Apple did not intend to imply this -- and I just wanted to make sure I clarified how I see the risk.


1. Photos.app CVE-2010-3831
Using this vulnerability, someone in a "privileged network position" (read: Pretty much anyone on the internet) could hijack your MobileMe password.  Users of MobileMe understand that this is more than just access to your photo album.  While that may be embarrassing, access to your MobileMe provides a ton of services which an attacker would find useful.  I guess webmail is probably a more realistic target.
To be vulnerable, you had to attempt to post an image from your iPhone to your MobileMe Gallery.


2. iAd Content Display CVE-2010-3828
An attacker leveraging this issue could cause an iPhone application that has implemented iAds to automatically FaceTime dial a destination of their choice.  I originally believed this was a lot more severe because applications can run in the background.  However in my testing iAd content was never accessed by applications unless they were frontmost.  Of course, if you leave Safari open and the application can be launched via  a URL handler it may be possible to cause something that was not previously frontmost to trigger a phone call.
I suppose that makes it similar in some respects to the issue Nitesh recently highlighted using Skype as an example when talking about URL handling on the iPhone (link).


I would like to thank Apple's Product Security team for getting these issues addressed quickly and for providing me updates about the status of the issues as they were being addressed.  I just installed the update, which appears to address a ton of other serious issues.  I recommend everyone go install it now.. unless you need to keep your device vulnerable so you can test your exploit modules :)


Aaron

Splunk releases 4.1.5 to address SPL-31061 and SPL-31094

Splunk 4.1.5 addresses XXE and CSRF issues

Splunk was really cool to coordinate with by being responsive, communicative, and open.  I was really impressed with their professionalism.

About the bugs:

1.  XXE

XXE bugs are fun.  For a good example of how XXE bugs work, I'd point at the following advisory by Chris Evans:

http://scary.beasts.org/security/CESA-2009-006.html

Note that in the above bug the XXE existed on the client, allowing an attacker to access the client's local files.  In this case the XXE occurs on the server side, so your external entity can point at a resource accessible to Spunk. (Steal files off the server.)

2.  CSRF (because it feels dirty to use Fortify's term "Javascript Hijacking")

Certain requests returned Javascript containing the Splunk session key.  Attackers could include that script in a malicious page, and obtain the user's session key.

Their advisory is available at: 

http://www.splunk.com/view/SP-CAAAFQ6

Apple fixes CVE-2010-1810 in iOS 4.1

Apple's description from http://support.apple.com/kb/HT4334 :

FaceTime

CVE-ID:  CVE-2010-1810

Available for:  iOS 2.0 through 4.0.2 for iPhone 3G and later,

iOS 2.1 through 4.0.2 for iPod touch (2nd generation) and later

Impact:  An attacker in a privileged network position may be able to

redirect FaceTime calls

Description:  An issue in the handling of invalid certificates may

allow an attacker in a privileged network position to redirect

FaceTime calls. This issue is addressed through improved handling of

certificates. Credit to Aaron Sigel of vtty.com for reporting this

issue.

The difference between redirecting and fully Man-in-the-middle attacking FaceTime is kind of big gigantic, but this still leaves room for certain attacks.  As a side note, I wonder if those guys from packetstan.com are planning on issuing any retractions from their FaceTime analysis.

Apple fixes CVE-2010-1800 in Security Update 2010-005

Apple just fixed an issue I reported to them.

To quote Apple's Security Update 2010-005 advisory text:

CVE-ID: CVE-2010-1800

Available for: Mac OS X v10.6.4, Mac OS X Server v10.6.4

Impact: An attacker with a privileged network position may intercept user credentials or other sensitive information

Description: CFNetwork permits anonymous TLS/SSL connections. This may allow a man-in-the-middle attacker to redirect connections and intercept user credentials or other sensitive information. This issue does not affect the Mail application. This issue is addressed by disabling anonymous TLS/SSL connections. This issue does not affect systems prior to Mac OS X v10.6.3. Credit  to Aaron Sigel of vtty.com, Jean-Luc Giraud of Citrix, Tomas Bjurman of Sirius IT, and Wan-Teh Chang of Google, Inc. for reporting this issue.

In other words, this means you can be any site, with a lock, as long as you can do some DNS trickery.  Try for yourself:

1.  openssl s_server -debug -accept 8080 -nocert -cipher 'ALL:NULL'

2.   https://127.0.0.1:8080/

You'd normally want an error to show up there.... looks like this didn't go totally unnoticed, though!

Props to cstone!