Wednesday, 14 April 2010

Who's letting me become ssladmin?

Slashdotters! - Hi there! Apparently I am a "security expert". Way too much credit to me! I am just an enthusiast more than anything else. Anyway, thanks for coming!

With news that it is rather ridiculously simple to mimic authority with many webmail providers in order to coax an SSL certificate authority (CA) into creating one for the domain, I decided to take it upon myself to see who out there is actually vulnerable and provide information to the public on how prevalent this issue is as we speak.

Out of eleven webmail services chosen at random and without prejudice, just under half of them permitted me to register with credentials (ssladmin) that allowed me to create an SSL certificate in their name. In most of these cases, there was a pre-existing, legitimately-acquired certificate.

All of them were contacted prior to this blog entry being posted. Out of the five that I contacted, one responded to me directly and informed me that the issue was being addressed, another one had a ticket filed but has no followed up nor closed the account, one had my account banned outright, and the rest did not comment. I was successful in registering a new account for a CA service for one of the providers, but did not complete the request and didn't bother for the rest of them.

Backstory



News of the issue came out late last month that it was "trivially easy" to register certificates for webmail services. Typically, you'll see accounts such as "administrator", "postmaster", and "root" barred from registering as either they'll already exist or they'll have been included in some sort of blacklist.

Many CAs will issue certificates to a list of pre-existing e-mail accounts typically containing the administrator, postmaster, and root accounts, but also including ssladmin. Because of this irresponsible method, you have the situation that we have here.

With all of that said, it's a bit muddled on who is exactly at fault, but I will elaborate on this a bit later.

Offending services



As I had said earlier, I chose at random and without prejudice eleven free webmail services. Let's just cut to the chase and list off the services I attempted to register ssladmin with:


Mail2World lets me register!


Mail.com does not.

Sites that let me register


Sites that won't let me



I would also like to point out that with Inbox.com, in order to register and use my account, I had to install some horrid, pointless, useless toolbar. It refused to permit me to log into the service without it being installed. I'd hate to imagine what the toolbar does outside of Inbox.com.

Why is this a problem?



The simple summary: man in the middle.

The not so simple situation: it takes a bit to pull off.

The easiest example I can make of how one can take advantage of this is with Nokia's Ovi service. Ovi is not only an e-mail service, but it also provides software updates, access to an application store, picture sharing, maps, and music. It can also provide access to personal data such as your contacts and files.



Being that Ovi is accessible from a wireless LAN, one could theoretically place an access point in a strategic point (such as a coffee shop) and wait for a Nokia user to check into their Ovi service. If the access point is setup to intercept traffic going to Ovi and the victim's phone connects via the wireless LAN, it could be setup with a certificate that is completely valid by the phone's standards. Once that is done, whatever else is up to the attacker.

While this may seem minor, this same problem could be pulled off via an ISP that allows self-registration of e-mail addresses. Seemingly trustworthy websites could end up becoming subject to attacks that otherwise would not be easily doable without severe compromising of existing accounts.

Demonstration



Being that it was the Easter long-weekend, I decided to register all accounts using the name "Jesus Christ"--this includes the Certcom certificate that I am about to demonstrate.

Since Inbox.com was the first and only one that I bothered to try and make an SSL certificate for, here are two screenshots demonstrating the problem at hand.



As you can see above, this is a normal account that was registered using normal means just like every other service.



And here's my SSL CA account registration. This is prior to providing a certificate signing request that I could have easily done on my own without using any webmail service's servers.

You'll also notice in the second screenshot that that HTTPS is not in use, but Inbox.com does have a valid certificate provided by Thawte.



This is what you should see when you attempt to register. It's funny how Hushmail here gave me alternatives but none of them worked anyway.

Aftermath



I contacted almost all of the noted offending webmail providers with a basic form letter explaining my method and suggested that they repaired the problem immediately. A form letter was created and sent to the individual postmaster and abuse accounts with a deadline of April 17th before this would be made fully public.

However, as I was able to pull off a Certcom registration with Inbox.com, I immediately filed a ticket telling them to close the account. They did so without any response to my alternative e-mail address and for whatever reason, Certcom had decided to block my home Internet connection.


This ticket was filed out of pure frustration, so it seems a bit terse and short.



Nokia's Ovi.com service still permits me to login. I did make an attempt to register a FreeSSL certificate for the site, but nothing came out of it.



Excite's customer support auto-responded no more than ten minutes after I had sent the message with the incident number 100407-000013. The account is still active as we speak.



Lavabit responded to me first within a half-hour of my message being sent. They have addressed the issue. Honestly, these guys were most on the ball.

Mail2World has yet to respond.

Conclusion


The simplest solution using pre-existing infrastructure is to force CAs to send e-mails only to contacts listed in the WHOIS. Provided that the record is valid and complete, it'll provide a much more secure method to registering and renewing certificates.

Beyond that, it may also be time to scrap CAs all together and adopt solutions such as DNSSEC. Being that becoming a trusted authority is rather trivial and that more and more it is appearing that the whole SSL CA system is littered with holes, an alternative is needed to take care of potential eavesdropping and certificate hijacking. DNSSEC is not the complete solution, but is definitely a part of the direction.

The fault in all of this doesn't completely reside with the webmail providers but really the CAs. With that said, those allowing customers to register e-mail accounts without proper and reasonable filtering need to be aware of potential abuses. A simple review of what is allowed and is not allowed as a name would do a lot of good.

Thursday, 25 March 2010

Serious security flaw in Personas for Firefox


Firefox proves it's capable of beating
Internet Explorer in silly exploits.
With the release of Firefox 3.6 and the automatic inclusion and enabling of Personas, the popular alternative to Microsoft's Internet Explorer is showing signs that it's no better. For the unaware, Persona is a feature of Firefox that allows one to 'theme' their browsers with images. Once a Mozilla-developed addon, it's now included, installed, and enabled by default in the latest browser release.

The problem with the addition to the default install of Firefox is that it introduce a gaping hole.

The Problem



Besides it being shoved down the throat of the unsuspecting installer, it would not take much effort to introduce graphic images or even worse potential code into the Persona, thus creating grief for the user. Shortly after the release of 3.6, an exploit was found where a website could potentially hijack the displayed image and then display something else. This is done without the user's intervention or permission.

Persona appears to rely on a set, arbitrary list of domains that are permissible to make changes based on specific code embedded on a theme site. This essentially means that there are pages that are capable of changing the look based on an action such as a MouseOver or OnClick.

However, just as the previously-mentioned exploit demonstrated that Persona made no authenticity of the data being fed and thus made a cross-site scripting (XSS) attack possible, it has now become apparent that there is a man-in-the-middle (MitM) attack that is doable. By simply redirecting the unencrypted, unverified traffic to an alternative server, one can simply perform the same functions that of the Persona website itself.

The lack of forced-SSL creates this problem as Firefox and Persona are unable to differentiate between the two servers. It is because of this that the 3.6 release is still subject to a serious security hole that remains to be patched. If one were to discover a method to have execute code instead, this could create a rather large security problem that would obviously be quite embarassing.

To add to this, the problem is worse in browsers 3.5 and lesser that have the addon as opposed to the integrated feature. In this case, there are multiple domains that the extension looks for and permits to changing the look and feel.

Demonstration



By simply forcing all traffic to the Persona site from a virtual machine to one of my personal servers, I was able to create an environment where Firefox 3.6 presumed it was on the appropriate website and enabled me to use the MouseOver feature to change the Persona's theme.


Click to enlarge and see the effects of the problem.


As you can see, the page has been modified and even though it goes through with the event trigger without batting an eye. No modification or changes had been made to the browser priorĂ¢€”this is a stock browser.

Affected software



All Mozilla 3.6 releases up to 3.6.2, and any pre-3.6 release that includes the Persona addon. This is not operating system-specific either.

The Mozilla Foundation has been contacted and the problem is filed under bug 554856.

Workaround



It appears that disabling Personas in 3.6 requires a significant amount of effort as it's included automatically and without any means of exemption during install. The simplest solution until Mozilla addresses this would be to either drop to a 3.5 release without the extension or stop using the browser all together.

Fix



Mozilla can address this in a few ways:


  1. Force all Personas to require user permission before installation.

  2. Just like how extensions are installed via Mozilla's addons page, enable forced-SSL and do not allow Personas to be installed without.

  3. Have all Personas signed.

  4. Allow the user to completely disable Persona with ease.



Point two should be one of the most important things done to prevent this from becoming a further problem.

Conclusion



Because of this flaw, I advise to take the workaround to heart. I would like to thank aydiosmio on 2600net for initially pointing out the flaw to me. Be this a reminder to all to not allow software to update without your permission.

Sunday, 7 February 2010

A look at data retention and law enforcement

Ever since Cryptome was shutdown via a DMCA request by Microsoft, I have been itching to compile a small table that shows how long it should normally take before a popular online service deletes your account. This really applies to just American law enforcement officials, but I am certain that the rules for data retention are the same internationally barring any privacy laws.

So if you're looking to disappear or choose "the right service", this may be a handy little guide to show you how long it takes before your "private" data is deleted off of these systems. This is not a guide on how to delete your items off of these services for the purposes of thwarting law enforcement, but rather a guide to show you how these companies are engaging in data storage.

And for the record: I have been following Cryptome for years and if you're not making it a part of your daily digest, you should.

Quick glance at how the services work themselves out



This is a rough guide on how long these companies will store the data before certain conditions are met. Links to the appropriate guides are also included.












ServiceDateData periodProfile deletionMail deletionEOL deletionDownload
Windows LiveMar-08365 days120 days *120 days365 daysMicrosoft-Spy.pdf (1.7 MB)
AOLSep-08Indef. ***n/aIndef. ***n/aaol-spy.pdf (330 KB)
Yahoo!Nov-0830 days min.n/a4 months18 monthsyahoo.PDF (124 KB)
FacebookFeb-0890 daysn/an/an/afacebook.PDF (167 KB)
MySpaceJun-0610-90 days **n/a30 daysn/amyspace.PDF (53 KB)
Paypal/eBayn/a2 yearsn/an/an/apaypal-guide.pdf (930 KB)
SkypeOct-07n/an/an/an/askype.PDF (27 KB)
MyYearbookn/an/an/an/an/amyyearbook.PDF (34 KB)
StickamSep-0890 days-indef.n/a90 days ****n/astickam.PDF (236 KB)


* As per Microsoft: "If the associated [Windows Live ID] is not used for 365 days from the first day of the 120 day inactivity period, then the associated [Windows Live ID] is deleted." A further explaination is provided later.
** Data is deleted after 10-days unless law enforcement are involved with the account. IP address information is retained for 90-days, however.
*** AOL's statement about data retention is anywhere between 3-days and infinity. A further guide is provided later.
**** User generated content is kept for up to 90-days, but they make mention that the data may still be retrievable.


I made an effort to note down the dates that these documents were supposedly created. With that said, the MySpace guide may be slightly different now than when it was first released. The same probably goes for the rest, especially Skype; but I would wager that any released in 2008 are similar to what they are now.

Some of these documents provided zero information regaridng how long their data retention periods were while in the case of AOL and Stickam, it may be anywhere between 90-days and indefinite. If you go over these documents and then find an error in this document, let me know.

Microsoft and Yahoo! are the only ones who provided an apparent end-of-life for an inactive account. Once the account has been inactive for that period, the data is supposedly deleted permanently. AOL states that it is 120 days for an e-mail account, but doesn't specify for other services.

Lastly, these documents were taken straight from Cryptome. I am not the originator of any of these documents and I am not aware of who leaked them out.

Microsoft's Windows Live service



Besides being the reason for Cryptome's brief downtime, their document is probably the most clear. As well, seeing that they tried to have it yanked off the website in the first place, it's probably up-to-date.

There appears to be a great deal of effort put into explaining how they keep their data as obviously the average law enforcement official isn't likely to be knowledgable in these areas. On top of that, they also provide an interface for these officials to interact with and retrieve data.

Here's how the data retention works for the Windows Live Mail (aka "Hotmail") service:


  • Account Creation - User must sign in within the first 10 days to keep account active.

  • Account will become inactive after 30 days of inactivity. No e-mail content is deleted but the account will not receive e-mail.

  • If account owner does not sign in after 120 days of inactivity, all e-mail is deleted and the account becomes a Windows Live ID only account.

  • If the associated WLID is not used for 365 days from the first day of the 120 day inactivity period, then the associated WLID is deleted.

  • After 365 days of inactivity, the account name is recycled and is available for creation by another customer.

  • Users may self delete an account at any point along this process. The 30 day inactivity period is canceled if someone tries to create the same account name ~or~ attempts to access it. Between 120 and 365 days, users can recreate an e-mail mailbox.



This is really straightforward when compared to the other services--Yahoo! is the only other service that comes close. Live Spaces and MSN Groups works like this:

What Records are Retained and for How Long?
Windows Live Spaces: Only the owner of a Windows Live Space can upload content (e.g. images, documents, videos), and when they do so, the IP address and date and time is also captured. In addition, if someone posts a comment to the blog, Microsoft captures the text of the comments as well as the IP address, date and time of upload and the nickname. These transactional records are retained for 90 days.
MSN Groups: When a manager or member of an MSN Group uploads content, Microsoft captures the IP address and date and time of content upload. These transactional records are retained for 60 days.


Xbox Live data retention isn't very clear, but they do make the point that since the volume of data that goes through that service is rather significant, they want specific time periods. Here's a screenshot that'll show a Gamertag's online activity:


Other images are provided in the document, but this one is the most clear and easiest to adjust.


The document makes mention of other services such as Office Live and SkyDrive. However, no mention is made about retention of data on either of these services.

AOL services



Thanks to AOL's infinite wisdom of sucking up everything and anything on the Internet in the late-90s and early-00's, data retention is anywhere between 3-days and indefinite. My guess is that thanks to the umpteen amounts of branding and the lack or poor attempt of synergy, nothing is easy to explain.

Just to make it clear how messed up AOL is, here are their properties:

  • AOL

  • Compuserve

  • ICQ

  • Netscape

  • AOL Instant Messenger (AIM)

  • AIM.com

  • Xdrive

  • MapQuest



Unlike the other documents, this particular one provides contact information for their Canadian offices in Toronto--kind of unusual and pointless to mention, but.

Before I dive into the complexity of the e-mail service, here are the retention periods for their map service and their instant messaging service:






ServiceData periodIP Logs
MapQuest45 daysn/a
ICQ90 days90 days
AIMn/a90 days


Now for e-mail. Besides what is in the table, AOL's documents does state that 120-days of inactivity (by not logging for 120-days) will result in account deletion.












 Compuserve 2000AOL Mail *
Inbox (New) **27 daysIndefinite
Inbox (Unread)27 daysIndefinite
Read27 days ***Indefinite
Sent27 daysIndefinite
Deleted24 hours7 days
Spam (Unread)n/a5 days
Spam (Read)n/a1 day
Saved Mailn/aIndefinite
Webmail sessions ****
90 days




* Includes both free and paid accounts.
** E-mails marked as "unread" but have been previously opened.
*** As per the document: "3 to 7 days after it is read, or 27 days from deposit (whichever is less)".
**** These are IP connection logs.


This is probably as clear as I am going to make it.

Interesting notes from MySpace



Here's an interesting bit from the MySpace guide (section D, part 2):


  1. Deleted Accounts

    1. Basic user identity information, stored user files, and general records:
      User identity and date in the user profile is generally available for up to ten days after account deletion. Other stored files, such as photos, may be lost at the time of account deletion.

    2. IP address logs
      User ID, IP Address and Login date stamps are retained for up to 90 days after account deletion.

    3. Private user communications:
      No mail (inbox or sent mail) is available for deleted accounts.






Now, before you start thinking that once you delete a MySpace account that it becomes permanently gone afterward, you'll have to read the part that comes in the next section (section E):

MySpace will honor requests by law enforcement to preserve information in accordance with 18 U.S.C. Ă‚§ 2703(f). In response to such requests, MySpace will preserve the specific information identified in the request for 90 days, and for an additional 90 days if the law enforcement entity requests the original period be extended.


So obviously if you're thinking your data is safe in 10-days, it may not be if you're already under investigation.

Paypal/eBay and stolen items



In the scanned document that was released via a leak from Paypal, there is an interesting approach to stolen items.

eBay has partnered with L.e.a.d.s.online to make certain listings and eBay user data available to law enforcement immediately to assist in their investigations. These services are available 24/7 to registered L.e.a.d.s.online customers. L.e.a.d.s.online offers two separate services to assist law enforcement in eBay Investigations: eBay site search and Internet (eBay) Drop-Off Store Search. Visit www.leadsonline.com for more information.
Turnaround Time: Immediate.


From what I can see here, it's unlikely that law enforcement will go to extreme measures to get information on something selling stolen items--like that it is uncommon on eBay in the first place.

With all of that said, eBay will only hold data regarding contact details and transaction history (albeit limited) for a maximum of 12-months after the request and only going back 12-months from that start.

Skype



Being that Skype is a VoIP/IM service with PSTN functionality, having a look at this guide produced no surprises. However, there are a few things from the document that you'll want to keep in mind. Here's an excerpt:

  • Due to the way by which Skype works, Skype does NOT have any records of user "logins", "log offs" or other general online/offline status

  • The Skype system is designed in such a way that voicemail is not centrally stored

  • Calls, IMs and other activities between Skype users do not create billing records



As you had seen in the initial table, there is no information regarding how long Skype keeps its records on file.

Yahoo!



Yahoo! was nice enough in their document to outline their data retention periods in a convenient table! This is copied verbatim from their document.













Record TypeAccessible for?Purged After?
Subscriber InformationAs long as account is active18 months of inactivity or 90 days if subscriber self-deletes account
Account Log-in IP addressesUp to one yearN/A
Email (free or premium)As long as user chooses to keep it4 or more months of inactivity depending on how long user's account was open
Flickr Account Contents, including Flickr EmailAs long a account is active (Email stored as long as user chooses to keep it)Upon deactivation of account
Groups - Activity LogsLife of the GroupMinimum of 30 days after termination of Group
Groups - ContentLife of the Group (only current version of Group stored; not past versions)Minimum of 30 days after termination of Group
Chat/Instant Messenger Logs45-60 daysN/A
Web Messenger Contents
(Yahoo! does not store contents of communications sent via the downloadable Messenger client)
As long as user chooses to keep itN/A
GeoCities, Domains, Web-hosting - Activity Logs and ContentAs long as website or domain is activeMinimum of 30 days after termination of website or domain
ProfilesAs long as the Profile is activeMinimum of 90 days after deactivation


Of course, the Geocities part doesn't apply anymore because it's now closed.

And just a bit more on data preservation from the document:

Will Yahoo! preserve information?

  • Yahoo! will preserve subscriber/customer information for 90 days. Yahoo! will preserve information for an additional 90-day period upon receipt of a request to extend the preservation.


  • If Yahoo! does not receive formal legal process for the preserved information before the end of the preservation period, the preserved information may be deleted when the preservation period expires.



Honestly, Yahoo is probably the most cut and dry out of the bunch after Windows Live.

Closing



Hopefully this will help you choose the right service. I'd love to get my hands on Google's data retention policies, but I guess we'll have to wait and see.