We loved every moment, if only there was more time. Some photos are up courtesy of our photographers. Our informal engagement shoot, and photos from the wedding.
In the meantime, we're off on honeymoon!
Today my blog turned six, and I tweeted that fact with the following:
My blog http://singe.za.net/ turned 6 today. The fact that I'm tweeting this rather than blogging it is probably significant.
While blogging remains more a more satisfying and useful means of exploring a thought, twitter let's you skip the work and move onto the conversation (sometimes) a bit sooner, but without any decent record of that conversation occurring (twitter's searchable memory is too short). I'm certainly going to continue blogging, but I don't see my throughput increasing much. Luckily, subscribing to an RSS feed is only a cost if there are too many updates ;).
That being said, I think there's been some fun stuff on the blog in the last year, my favourite posts have been:
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.
In short, it's been awesome. I haven't done much real work as yet, but that will start soon. The people are smart and easy to get along with, and they're all geeks, a nice change (on the geeks bit, my old colleagues are smart too :) ). I'm also enjoying getting to know "how they roll" and recon living up to it will make me a better security person.
As an aside, my new work e-mail address is available here (or sans popup).
Brian Krebs, author of SecurityFix and one of the very few mainstream infosec journalists, is pulling a McLeodd1 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.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.
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).
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 ;).
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.
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.
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.
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.
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.
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!
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.
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:
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:
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.
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.
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.
Basically, there are some people I follow because they talk about a topic I am interested in, however, I'm usually not to interested in their personal lives. Likewise, there are many people I follow where I am interested in their personal lives. And I am never interested in tweets about what people had for lunch or their haircut. Ideally, people would just self-enforce, but it's really hard to do.
Because people are rarely consistent, or could have very interesting stuff between bouts of 40 blow-by-blow cricket updates, just following or not isn't granular enough to make sure the signal stays high. I tried creating a signal group, but it was still too noisy, and I missed some of the interesting stuff from some people.
This is where twilter came from. At the simplest level, twilter would filter tweets and only show you tweets about things you have explicitly asked for or explicitly not asked for. For example, anything with the words "haircut" in I would not like to see, ever. These filters could be grouped into blocks of concepts. For example, there could be a "soccer" filter which would look for words or phrases like: "soccer", "football", "Manchester United", "Bafana Bafana" etc. This filter could even be a sub-filter of a greater "sport" filter. Creating these filters would require a bit of work. For example, I've recently been working on determining sentiment from tweets, and words like "interesting" are over-used and can be misleading, whereas words like "awesome" almost certainly imply a positive attitude. At a later stage, or if the right people get involved up front, natural language processing could be used to do this better. There could even be a crowd-sourcing options with 'community' filters or an option to share your filters with others so easy the development burden.
These filter groups could then be applied as a blacklist or whitelist to your whole twitter feed, or more interestingly, individual people. Thus, if I use the examples above, if I follow someone because I'm interested in what they have to say about security only, I would apply an "information security" filter in whitelist mode (i.e. only show me those tweets); whereas if I follow someone I'm more generally interested in but who talks about sport and their haircut quite often, I could apply the "sport" and "minutiae" filters in "blacklist" mode (i.e. show me everything except those).
This brings me to the second part of twilter, the feedback mechanism. I can complain about how uninteresting someone's haircut tweets are, but they'll just look at their follower count and keep doing what they're doing. As twitter is a fairly self-involved activity (follower counts, quitter and all those other services), I would want a feedback mechanism where someone could look up their twitter user on twilter and see what tweets were being filtered and why. Hopefully, this would provide an incentive for people to keep themselves interesting. It will of course allow people to tune things to beat the filters, but if they're that desperate to talk about something many people are filtering, you can just unfollow them ;)
That's the idea. Now who's going to build it?
More advanced users like to know what is nailing their CPU, and have some form of hotkey of screen widget nearby to tell them. But sometimes it takes too much effort for the computer to show you this application while it's thrashing away and I've been looking for a nice unobtrusive on-screen "gadget" that gives me all the information I need. After going through hundreds of windows sidebar gadgets, Mac widgets and now Gnome screenlets, I've hit on a winning strategy (for Linux, but the concept remains the same).
I'm using a semi-transparent Output screenlet to display the contents of the following command:
top -b -n1 -s -i | head -n9 | tail -n3 | grep -v " top " | cut -b1-16,42-50,61-80
People often forget that disk IO is also an important indicator. Sometimes your CPU usage is moderate but your computer is frozen while your disk thrashes away. So I have a second screenlet with the output of:
iotop -n1 -b -o | grep -v "Total DISK READ:" | cut -b1-38,55-80
What does this buy me? Well, with a quick glance I can find out what process is currently killing my CPU or disk. It also includes the PID for quick "kill" or "renice" access (transparent terminals make reading the PID easy). Additionally, in a few weeks, it has given me a far greater understanding of how applications on my computer work and interact with others. For example, Crossover Office (aka wine) makes Xorg flatline a CPU core when it starts a new wineserver (I blame compiz funkiness). I don't actually care about that, what I do care about is I now know how and when to expect delays when starting crossover apps. The end result of this overcomplicated explanation is that the frustration of using a computer has significantly decreased now that I know what to expect.
Also, when I invariable break something, these strings will be here for me to copy paste back into existence.
We loved every moment, if only there was more time. Some photos are up courtesy of our photographers. Our informal engagement shoot, and photos from the wedding.
In the meantime, we're off on honeymoon!