Dominic White - Security

Breach at iContact exposes my (and your) details to Spammers

nospam@example.com (Dominic White) — Tue, 02 Feb 2010 08:25:09 +0200

This week something special happened, something I'd been saving for the right person, something magical. Today, hackers took my private data. Everything's changed, I feel like a part of the world, connected to so many other people who have shared in this experience. Today, I'm a woman! (Ok, I may have gone a bit far with that last bit)

The skinny is that I use unique e-mail addresses for each service provider that I want to continue communicating with (for the ones I don't I use one-shot addresses). I noticed on the weekend that I was being deluged with pharmaceutical spam to three of these addresses, namely my Threadsy, Numbuzz & Share-it (via a product I bought there, ChatterBlocker) contacts. This lead me to tweet: "Either a security or ethics breach at @threadsy & @nimbuzz Getting Viagra spammed hard on the unique e-mail addresses I gave them."

Chatterblocker got back to me with the equivalent of "What? Wasn't me." Scott Kendall from Threadsy jumped into an investigation however and contacted me for more details. He also passed on results of his investigation to Nimbuzz, much kudos. Scott then informed me this morning that there has been a breach at iContact, evidently a shared service provider to the affected entities, resulting in the theft of customer contact details that must have been sold to spammers (or by a horizontally integrated crime crew). We're assured by iContact that only our e-mail addresses were stolen. However, we're not given any reason to believe that; unless the data is segmented somehow I don't see why an attacker wouldn't take the whole caboodle.

What concerns me is first that I wasn't even aware I had a relationship with iContact. A quick look of the websites of Threadsy and Nimbuzz don't make reference to them apart from the generic "we may share your data with business relevant third parties" in the privacy policy. Even if it is made explicit in the privacy policy, it doesn't mean you understand it, take this Facebook friendlist leak for example. Maybe if we had a "nutritional label for privacy" with disclosure of who the third parties were I would feel more in control of my data and more importantly the decisions I make.

Second, I'm not aware what data of mine had been given to iContact and what could potentially be at risk. Was it just my contact details, or did it include behavioural data too? Even if I can't do anything about it, I'd like to know what was breached with some solid factual basis. More importantly, I'd like to see what is shared with the third-party up front. I believe the small externality of writing that down in human readable and explicit form may encourage service providers to limit it.

Third, this was a consumer-lead breach-discovery. People with custom e-mail addresses tracked the source and informed iContact they had a breach. We see the same thing with credit card breaches, and with the likes of Google notifying other companies that the APT (do I get points for using it?) got them too. Is it any wonder those are the breaches we see frequently reported. IT shops usually aren't aware they've been breached until an affected third party tells them.

In conclusion, if you're getting spammed hard with pharmaceutical spam, this is probably why. There's nothing you can do about it, and there's probably a near infinite number of variations of your private (by which I mean data you don't want publicly exposed) data floating around at service providers you know nothing about that doesn't have the same canary-in-a-mine like properties that can make you (and hence the service provider) aware of the breach. Good luck.

Brain Krebs Leaves The Washington Post

nospam@example.com (Dominic White) — Wed, 30 Dec 2009 08:48:34 +0200

Brian Krebs, author of SecurityFix and one of the very few mainstream infosec journalists, is pulling a McLeodd¹ and leaving the Washington Post to go on his own. He will be reporting from Krebs on Security from today.

Apart from the coverage, Brian has also got involved in or instigated responses to some threats, and I hope that fewer editorial restrictions allow him to do and say more.

In truth, I only really like Brian because he's linked, to me before, encouraging up to 1.5 people to read the abstract on my thesis ;), but more seriously providing data and inspiration to me and several other researchers.

Good luck Brian

Footnote 1: I probably shouldn't mix my ZA and Infosec references, but Duncan McLeodd left the Financial Mail to form independent tech news startup TechCentral.

"Up to Date" isn't the same as "Knowledgeable"

nospam@example.com (Dominic White) — Mon, 14 Dec 2009 07:39:10 +0200

Eugene Spafford has a warning for us in his latest entry that I thought worth remembering:

Generally, hackers who specialize in the latest attacks dismiss anyone not versed in their tools as ignorant, so I have heard this kind of criticism before. It is still the case that the "elite" hackers who specialize in the latest penetration tools think that they are the most informed about all things security. Sadly, some decision-makers believe this too, much to their later regret, usually because they depend on penetration analysis as their primary security mechanism.

In many ways, I worry that mechanisms like RSS & twitter and the associated behaviour help us to be up to date, but not knowledgeable, and that the implied arrogance of being up to date stops us from realising it.

ZaCon - Information Security for the Rest of Us

nospam@example.com (Dominic White) — Thu, 19 Nov 2009 09:50:46 +0200

Update: Haroon's talk "Why ZaCon" at the con provides more of an overview. Including some aspects I didn't consider.

Our first South Africa fledgling unconference-like security conference, ZaCon, takes place this Saturday (21 Nov). Our intention was to have something which fits in the gap between corporate conferences like the ITWeb security summit and academic conferences like ISSA. The former is huge and can afford to bring over some of the big names, but also has plenty of "paid for" opinions and a sometimes less meaty content. The latter is peer-reviewed and requires more than a slide deck and a grin to present at, but also sometimes values theory over pragmatism and places a large burden on people already holding down a job.

And so ZaCon was born, a security conference both "for security geeks by security geeks" and open to new entrants to the industry. It's on a Saturday, on purpose, you don't get a free day off work. It's also non-aligned, giving speakers the freedom to say what they want, how they want, and also preventing us from having to push agendas in return for money, or people attending so they can be seen in the right places.

None of this is a middle finger to ITWeb, ISSA, vendors, security companies etc. It serves to outline what we felt was a need, and how we plan on meeting it. We will continue to contribute and support the other conferences, and most of us work for security companies anyway.

The CFP had a great response, we've managed to secure a killer venue (directions) thanks to the University of Johannesburg and their Academy for Information Technology, we're getting more coverage than we deserve from DiscussIT, should have full video/audio+slides to distribute afterwards and even have free wifi courtesy of IS AlwaysOn Hotspots.

All in all, apart from the expected teething problems, I'm expecting an awesome day of security geekery. If that interests you, then details are available at the site. Please remember to RSVP to rsvp-@-zacon-org-za if you'll be attending. If you can't make it, follow the zacon09 twitter feed (or #zacon hashtag) for coverage and I'll see if I can get a liveblog or two in. We're hoping to publish full Defcon-style video of each talk too.

Efficient extraction of data using binary search and ordering information

nospam@example.com (Dominic White) — Tue, 01 Dec 2009 08:50:41 +0200

I'm quite excited and honoured to host a guest entry from Yusuf Moosa Motara covering his talk at ZaCon (a video of which can be found here, and the slides here).

Caveat

I make no claims about the novelty of this technique. For all I know, it's been widely known for some time, but I could find no record of it. The target server is SQL Server in this text, but the technique is applicable to other implementations. If nobody else bothers to claim it, I hereby name the technique after myself: nothing impresses random chicks quite as much as having an obscure and totally-irrelevant-to-their-lives technique named after oneself, after all.

On second thought -- call it whatever you want to ;).

Background

Some injection points are worse candidates than others. A difficult injection point is found in the ORDER BY clause of a SQL statement, since there can be no further statement after an ORDER BY and our only real "in" is the ability to put in expressions, though those expressions may do nothing more than change the resulting order. Such a change of ordering does provide us with a 1-bit channel to slip data along. We could do so a simple manner:

[...] ORDER BY case when (select top 1 substring(username,1,1) from
users)=<91>a<92> then ID else Address end

... but a quick examination will tell us that the time taken to extract data with this technique is around 0.5*/n/*/m/, where /n/ is the length of the data, and /m/ is the size of the alphabet, assuming that (on average) the correct character is found after half the search-space has been traversed. Reordering the character test order in accordance with the frequencies that we expect to find in the text can yield better results, but not results that are significantly better.

A better way

We can do more than directly compare letters: we can get ordering information out. This allows us to use a binary search algorithm to find the correct text efficiently. In other words, we can use a query similar to:

[...] ORDER BY case when (select top 1 cast(username as varbinary(255)) from
users where username not in ('')) __OP__ cast('__CANDIDATE__' as varbinary(255))
then ID else Address end

The subselect provides us with a way to get the first row of data. After getting the column data for that row, we can modify the "not in" clause to include the retrieved data, thus shifting us to the next row. __OP__ is either ">" or "<", depending on whether we would like to search the upper or lower space. __CANDIDATE__ is the string that we are comparing against.

Obtaining __CANDIDATE__ is a simple enough matter of converting text to a number that reflect the ordering of the text. Unfortunately, SQL makes things difficult by supporting concepts like collation; therefore, the lexicographic ordering of the text in your language may not align with the ordering of the text in SQL. We can solve this problem by using the same injection point and asking the SQL server to order our alphabet for us. For a ~90-character alphabet, this takes ~300 queries. We will make up for this setup cost within the first two or three records.

SQL Server doesn't play well with strings. If there are trailing spaces, they aren't counted towards the string length; if there are apostrophes, comparisons become more interesting (for example, "mooo" < "moo''a", but "mooo" > "moo''z" [ed: note single and double apostrophes look similar in that example]). To get around both of these (and a few other string-related idiocies), we cast to binary and compare as byte-sequences.

A binary search searches a range, and we should set our initial range. A lower bound of 0 will do, and the upper bound should be set to the largest /n/-valued sequence, where /n/ is the length of the string to be retrieved, as determined by a preliminary length-seeking binary search using the same injection point.

The alphabet used must cover all of the possible letters. Failure to do this will cause the binary search to fail; more importantly, it will make it difficult to proceed to the next record unless one can identify that record by ROWID or some other method.

Web-specific Complications

Certain sequences, such as "\e<zmo~~" or "Lor,w&#$Jo" get detected, incorrectly, by WAFs as being XSS vectors. This illustrates the stupidity of blacklist-based security precautions. The only workaround I can think of at present is to remove the "<" and "&"/"#" characters from the alphabet, and ensure that we skip past sequences that contain such things by modifying our SQL injection query.

As the number of retrieved items grows, the length of the query grows as well. Therefore, this technique is of limited use when faced with a GET injection. A solution to this might be to use adaptive queries: when the strings "Alice", "Alison", "Albert", "Alyssa", and "Bart" have been retrieved, it might be possible to change the seen strings to "Al%" and "Bart", thus reducing the length of the query. I leave this extension as an exercise to the reader.

Pay-off

A binary search finds its target in log2(n)+1 probes, at worst. In real-world terms, this leads to an average of a 6x increase in efficiency (and hence speed) for pulling out data, as compared to the simplistic method of exploiting the ordering side-channel: basically, the difference between waiting 10 minutes for a long text blob or 1 hour for the same blob.

Notes

Though we apply the technique to free-form text extraction here, it would be trivial to apply it to the extraction of GUIDs, or numeric data. Numeric data extraction would be a particularly interesting exercise, since a binary search works by continually narrowing the search-space. It might be sufficient to get a "ballpark" figure in some cases, and thus obtain better than O(log2(n)) efficiency.

I have created a small proof-of-concept, consisting of a toy ASP.Net application that is susceptible to injection, a SQL Server database, and the extraction tool coded in Python3. If the code differs from the explanatory text (which is the text that you are reading right now, of course!), please place your trust in the code.

Further work

There are a number of optimisations that could be done to the existing proof-of-concept. More importantly, the idea of using remote comparison functions to efficiently draw out previously-inaccessible data via binary search is an intriguing one, and one which deserves more attention. Andrew MacPherson has pointed out to me that a similar technique is used by the Metasploit framework when trying to determine the EIP in some cases, and I am grateful for the knowledge; I am sure that there are even more applications for the idea just waiting to be found!

SuperGenPass

nospam@example.com (Dominic White) — Tue, 17 Nov 2009 20:20:33 +0200

As someone who uses a lot of web apps, I run into the problem of trying to remember multiple passwords. Most people resolve this by just using the same password across all the sites. However, as numerous, examples, have, demonstrated, that's not a good idea. The knee-jerk counter is to use a different password (or groups of passwords) across the sites, but that becomes difficult to remember. If you want the quick solution I'm proposing then check out SuperGenPass (or my customised version). The security geek details follow after the jump.

Some of my colleagues use password databases such as KeyPassX, or the browser's "remember password" feature. These solutions are significantly better than using the same password across all sites, but suffer from a few problems:

You have all your passwords written down somewhere - at some point you may not be the only one looking at this list
That list isn't always protected - e.g. using Firefox's "remember password" feature without a master password could expose your password on physical theft of the device
Portability - if you aren't at your machine you can't log in. KeePassX is quite portable, but then ends up making more copies of the password list.

None of these are killers, but they aren't ideal. This is where SuperGenPass comes in. SuperGenPass hashes a password with the domain to make a unique password per-site, meaning that a compromise or malicious admin on one site won't give them the password for another site. The main advantage is that there's no database or list of passwords lying around that could be compromised and you only need remember one password. If you wear lots of tinfoil like me, you can remember groups of passwords e.g. critical, important, arb sites. It's ridiculously portable with a bookmarklet (don't use this, see below), data URI, straight JavaScript, Python (alternative) and J2MEE implementations.

There are a few potential problems that need to be considered (they all have solutions) however:

The bookmarklet runs in the same context as the website you're logging into. This means javascript on the site (or POST'ed/GET'ed information) has access to it. This allows a malicious or hacked site to get hold of your master password. There's a better explanation here, and I put up a demo here. So DO NO USE THE BOOKMARKLET. Any of the other versions are good enough, but are vulnerable to shoulder surfing (something the bookmarklet is not vulnerable to).
The algorithm doesn't include za.net and za.org as top level domains. This means that all your passwords for the approximately 30k domains hosted under these could have the same password. As it is unlikely that the majority of internet users use more than one web-app in these domains, this isn't a huge risk. Although, it does technically make finding the correct MD5 collision slightly easier. When I notified the developers of the bug, the response was that a change in the algorithm would affect users with existing passwords on these sites and hence they would not change it. So I made my own, more on that later.
The default password length is 10. That's fine, but given research like this, and that setting the default to 12 costs the user nothing and potentially buys them $7,700,102,463 extra protection per password, that sounds like a good deal.
MD5 - this isn't a problem. The knee jerk I hear from some security people is that is uses MD5 and that's broken. However, the vulnerability in MD5 allows other values to be found that hash to the same value (a collision). This does not let you work out the reverse i.e. the original value (master password in this case) from a single hash however. So we're safe here (I think, crypto nerds got any comments?)

In light of the above, I've made my own customised version of sgp. It includes customised versions of all but the J2MEE version (which is partially customised by it's author to include za.net/org already). My recommendation is to use the Data URI as a bookmark loaded in your sidebar (in Firefox). While it is slightly slower logging in to one site because you will need to type the domain, it is faster when logging in to many because you can just change the domain without re-entering your master password. It is vulnerable to shoulder surfing however.

In summary. SuperGenPass provides a convenient way to use different passwords across different sites. There are some potential problems and improvements, to which I recommend using my customised version, with the preferred method being the Data URI as a Bookmark loaded in your sidebar.

Thanks to Russell for pointing SGP out in the first place, and Michael for the Python and J2MEE version and the changes.

"Evil Thug" goes after Full-Disk Encryption

nospam@example.com (Dominic White) — Mon, 19 Oct 2009 22:35:32 +0200

Boy do I have news for you security people out there; I have a 100% reliable way of breaking all encryption! I call it the "Evil Thug" attack. I provide this service for a small fee. The entry level service will get me or an employee for a hour, this is all it will take to break any encryption in the world (and no we don't need a prostitute, even for 2048bit RSA encryption).

The basic methodology is to approach the encrypted device... and punch the owner in the face until they decrypt the device. The premium service will have this punch-up upgraded to a rubber hosing, and the platinum version will get you some drugs and a $5 wrench. Unlike our competitors, you won't need to involve a notoriously unreliable Latino third-party stereotype.

Okay, jokes aside. Joanna Rutkowska, who has done some hardcore stuff in the past, has done a write-up and released a tool showing how easily the passphrase for a full-disk encryption product can be retrieved by an example person who has access to your physical laptop, even if powered off and without requiring the complexity of coldboot attacks. While she acknowledges that "the concept behind the Evil Maid Attack is neither new, nor l33t in any way" the amount of non-critical coverage it has gotten has irked me.

Her scenario involves someone who not only has access to your laptop without you being around, but has repeat access to your living space, and if they choose, *you*. Of the one squillion options available to a thief at this point, some complicated boot-loader jiggery pokery (not to mention extensions to support other full disk encryption software, AV evasion and the inevitable arms-race/maintenance overhead these things turn into) seems far less viable than beating it out of the victim, or even poisoning their toothpaste and only giving them the antidote once decryption has occurred.

Arguably, actually beating someone exposes you to all sorts of potential law enforcement nastiness, like getting ID'ed in a perp walk. However, if you are going to train an army of maids, *and* have them chain gang laptops out of hotels, you can still get ID'ed by a maid, and you're setting up a fairly big bread trail to your operation by involving that many people, and stealing that much stuff. In short; No, this does not provide you some magic-anti-police ability to scale the theft and is less violent but no more effective than our platinum wrench service.

In future, please don't look to encryption to stop bullets, or pretend that when it doesn't something interesting has happened.

When AntiVirus was the Virus

nospam@example.com (Dominic White) — Mon, 19 Oct 2009 12:38:48 +0200

This weekend was rather eventful, and we learned a valuable lesson about viruses, security software, and professional scepticism in IT environments. I've briefly documented it below so you can learn from our mistakes.

Last week Wednesday a virus was detected on a client's network. The anti-virus (AV) host intrusion prevention system (HIPS) was updated to block access to the URLs the virus was using to fetch its payload and other control instruction.. However, the domain lookups[1] to these URLs increased massively by Friday, so much so, they caused the internal firewalls to fail due to the load from trying to inspect this traffic. Domain lookups were then blocked at the firewall, but the source of the lookups persisted. However, network access was restored and outwardly there was nothing wrong.

We now needed a sample of the virus. Without it we could not get a signature from our AV vendor and get it removed from the whole environment. We also needed to know what it did so we could advise on appropriate remediation (e.g. changing facebook passwords). We tried all sorts of things. We isolated one machine and tried to work out what would make the lookups stop (our test for the existence of the virus). We replaced the local domain cache with static links (in hosts and lmhosts files) to try and make the lookups not traverse the network (and hence not cause outages in future), while we tried looking for the virus. We ran multiple tools and scoured 'infected' hard drives looking for the virus. We even dumped running programs from RAM fearing the virus had injected itself into a legitimate windows process. We killed processes until bluescreen or reboot, everything we could think of to try and find a failure criteria that would identify a sample. Meanwhile, our AV vendor's highest level escalation analysts were connecting in to our machines, we were uploading hundreds of potentially infected files to them, and a hard drive had been priority couriered to them. This continued 24 hours a day during the weekend with IT personnel working 24hr shifts until breaking point.

Eventually, on Sunday it was discovered that there was no virus (or not as widespread as we believed) and that our AV's HIPS had in fact been causing the domain lookup flood. By assigning the HIPS to block traffic to the viruses' domain, the HIPS would perform a domain lookup to find where the domain current resides and block that. However, instead of caching the lookup's result, our AV would regularly re-lookup the domain. This is likely because of 'fast flux'[2] malware domains which bounce their actual location all over the internet. The unintended consequence however, was a DNS flood. Even then, DNS should not be large enough to cause significant network latency, and it was this in conjunction with the firewalls attempting to inspect and apply policy to this traffic that caused the failure. What's more, is that the domain lookups should have gone to local DNS resolvers and not the internal top-level DNS (which is behind the firewalls), but were bypassing their local cache due to advised against misconfigurations.

In summary, our own security software caused an unintended consequence, that behaved much like a highly complex virus. In future, I would recommend that at least two solid points of evidence for the existence of a virus be discovered before a sample is attempted to be recovered (usually an infection vector and behaviour, if you see behaviour after infection but not before, then you have something). While, on the surface, I feel quite stupid, in reality not even the top level analysts at our AV spotted the behaviour of their own software. The truth is that IT environments are sufficiently complex, that these sorts of mistakes are more likely than not. As security people, our job is to know this, and make sure we can guide people to get enough evidence to know what is happening before they waste an entire weekend. This is why I want all of you to learn from our mistake :)

[1] The internet works on IP addresses, these are four sets of numbers. However, they are not very human readable, so the domain name system (DNS) was created to allow human readable names e.g. www.google.com which a domain lookup would translate to something like 209.85.227.103

[2] Virus writers have worked out that if they rely on one domain then it is fairly easy to get them shut down. So they usually make their viruses query a couple to several thousand domains, and make those domains regularly change the IP address returned (see [1]) providing two layers of rapidly changing complexity, thus making them that much harder to stop.

Conficker Claims its First Human

nospam@example.com (Dominic White) — Wed, 01 Apr 2009 09:02:29 +0200

Conficker has claimed it's first victim, this time a live one. Conficker, a computer virus that security researchers have warned will do severe damage to computing systems from April 1st, has claimed millions of computer victims to date. However, Harry Hermulen's computer was luckier than he was.

Mr Hermulen, fearing a computerised Armageddon would occur on April 1st due to Conficker, barricaded himself in his log cabin outside the small town of Pofadder in South Africa last week. After missing the town's weekly "sokkie", a type of traditional Afrikaans dance, town members went to visit Harry. One witness described what they found as "horrifying". "We knocked on the door, but Harry didn't answer, a jean-pant were drying outside, but Harry only had one pair, so we knew he was inside." said Maggie van Schoonstad. "We opened the door and found yellow, red and blue devil's signs on all the walls," continued Maggie These were later confirmed as the logos of well known Anti-Virus vendors. "We found him dead in front of his computer, his face was all blue from the screen."

Later analysis confirmed Mr Hermulen had starved to death. Computer experts determined that while waiting for his Vista computer to boot, then clicking through the thousands of 'Allow' dialogs presented to him by the multiple Anti-Virus products installed, Mr Hermulen had not had time to eat. "His finger was full of blood and stuck to his mouse." said Frikkie Steyn a close hunting friend of Harry.

When asked for comment, Norton Symanteck, a spokesperson for Fckng-Secure Anti-Virus said, "What happened to Mr. Hermulen is a tragedy, BUT YOU'RE ALL GOING TO DIE UNLESS YOU BUY ANTI-VIRUS." Oh the humanity.

Happy April First.