So, SQL injection.

It has been around for quite a while now
It has worked its way to being one of the biggest baddies on OWASP's top 10 before
It is working its way to claiming that spot once again in 2013
And, despite all of the world's efforts to get rid of it with nice solutions like prepared statements,
it just… won't…  disappear…

And, to be quite honest, I don't think SQL injection will ever completely disappear, as long as (My/MS/T/PLG) SQL itself only allows parameterization of certain subsets of its statements (WHERE clauses, VALUES clauses, etc.).
The reason for this is simple: developers desperately want, crave, even need dynamic SQL statements – statements whose structure and / or referenced tables/columns can change depending on the current state of the application.

Why? So they can make fancy, user friendly applications that allow the user to choose the way their data is or isn’t filtered.
Because users have come to expect being able to customize every part of everything they interact with.

(Because users are spoiled)

Not too long ago, I was testing an application for a client, and everywhere in the code they were using prepared statements. It was beautiful! Every little bit of database interaction was parameterized.
However, that was mainly because their code was only concerned with security checks and requests with fixed inputs.

The part of the application where the user interaction became more flexible, was the reporting section. This was all done using the open source Business Intelligence Reporting Tool, lovingly called BIRT, or more specifically the BIRT Viewer.

Now, the BIRT Viewer itself (aside from containing a juicy little bug that is still waiting to be reported) only uses prepared statements.
To create a report in BIRT as a developer, you must define all the things that need to be in the report, define the different variables that will be used in generating the report, and give the parameterized SQL statement that BIRT needs to use to get its information from the database.
All of these definitions are stored in a nice XML structure file on the server and used whenever a user wants to generate a report based on that report-definition.

Sounds great so far, right? Yes it does. And if that's is where it stopped, things would be fine. Things would be great. Things would probably even be secure.
But things would most certainly not offer the dynamism that users always scream for and things would be abandoned. (Just for fun, try googling '"dynamic query" BIRT. Nearly 7000 hits!). So BIRT had to find a way to make their reports and the corresponding queries dynamic / customizable, and so they did…

Can you see where this going?

Yep, BIRT included support for scripting languages (i.e. javascript) in its report files, allowing developers to customize the content of report definition files, including any and all SQL statements it defines, at runtime, perhaps even based on user input.

So now the people who create the report definitions suddenly have to think about nasty things like input validation and sanitation. And perhaps they have never heard  of these things, because they are designers instead of programmers. Or maybe they are programmers, but because they are working on report definitions, they don't feel like they're 'coding' and forget to apply their best practices.
Or maybe they have actually tried to apply the best practices, but find themselves unable to apply them as they are now working within the confines of javascript, which doesn’t know anything about SQL and so does not provide any support for prepared statements or magic functions like super_sql_ultimate_escape_string(),  that might help with encoding.

So they either end up reinventing the wheel of input sanitation (probably thinking that a square should be good enough); copying it from some blog post that somebody on birt-exchange found on google (which for some reason is shaped like a triangle); or they just forget about wheels all together and decide to wing it.

And sure enough, when going through the report definitions there were the familiar string substitution techniques that told me that, yes, even in a development environment where prepared statements are the norm, SQL injection is going to find a way.

The offending (anonymized) snippet from one of the report definitions:

<method name="beforeOpen"><![CDATA[
if (params["optional_filter"] ) { 
    this.queryText = this.queryText.replace("/*PLACEHOLDER_FILTER*/", " AND (optional_filter= '" + params["optional_filter"] +"')");
};
}]]>
</method>
<xml-property name="queryText"><![CDATA[
SELECT some_column, some_other_column FROM data_table WHERE (main_argument = ?) /*PLACEHOLDER_FILTER*/
</xml-property>

And that’s it, game over.

Because it doesn’t matter how well you have parameterized the majority of your queries; if there is still even one query that remains injectable, you’re gonna have a bad time.

Happy Hacking!

Het jaar 2012 is (bijna) voorbij, het is een druk jaar geweest, ook op het gebied van security.
Qua incidenten zijn er een paar grote geweest, persoonlijk vond ik het incident bij het Groene hart ziekenhuis een indrukwekkende, niet technisch maar een incident wat wel erg dicht bij komt. 493.000 patiënten waarvan de gegevens op straat lagen is niet niks. Het mag duidelijk zijn dat het beveiligen van informatie een steeds belangrijker onderwerp wordt.

Informatie
Kennis is macht, of het is gewoon echt geld waard, afgelopen jaar is er weer veel informatie gestolen en gelekt. Oorzaken?
Uiteenlopend van "fouten" als het publiek beschikbaar stellen van backups tot meer geavanceerde aanvallen. Bovenliggende oorzaak? Ja, informatie management is nog steeds niet op orde, "men" weet vaak niet wat voor informatie er wordt verwerkt en überhaupt waar het wordt verwerkt. Ik geloof nog heilig in het Jericho principe waarbij we informatie gaan beveiligen in plaats van infrastructuur, maar dan moeten we wel eerst weten wat we in huis hebben.

Werkstation
Aan de werkstation kant is het  al weer een bewogen jaar geweest, Adobe, Java en browser exploits zijn nog steeds het onderwerp van de dag. Het blijft uitkijken geblazen en gedegen kwetsbaarhedenbeheer is en blijft een belangrijk onderwerp.

Aan de browserkant worden nog regelmatig exploits gevonden met grote impact, een kwart van de kwetsbaarheden in IE9 waren "extreme vulnerable". Op de valreep komt er nog een zero-day binnen voor IE6, 7 en 8, iets wat dit jaar niet meer gerepareerd gaat worden.

Firefox en Chrome deden het iets beter, maar ook daar waren/zijn gaten in te schieten al dan niet via Flash of java exploits. Soms ook wel ten vreugde van de goedaardige security onderzoekers :-) Als je gaat kijken hoe deze kwetsbaarheden misbruikt worden zie je een verandering in de manier waarop. "Vroeger" werd een enkele exploit wel toegepast om mensen te infecteren met mallware of een virus, echter worden ze tegenwoordig opgenomen in zogenaamde "exploit kits" waarin een "soep" van exploits wordt opgediend om de kans op een infectie te vergroten. Enkele voorbeelden zijn grote websites als nu.nl en Telegraaf  geweest in 2012 maar zeker niet de enige.

Serverside/Infra
Aan de server kant mag zeker java niet ontbreken qua exploits, helaas is er voor Java nog geen stabiel vaarwater en blijft het een risico vormen voor organisaties. Microsoft heeft afgelopen jaar zijn patches goed op orde gehad en ook in de Linuxsfeer was het zeker mogelijk de zaken uptodate te houden.

Afgelopen jaar hebben we een hoop tijd besteed aan systemen waarvan we niet 100% wisten wat er onder de motorkap zit. De "appliances" zeg maar, die stiekem toch Open-SSL draaide, of een kwetsbare java of PHP versie. Steeds vaker zien wij dat dit soort systemen een oorzaak van problemen zijn op security vlak, de grote vraag is ook "Wat is een appliance?" en vertrouw je deze ook echt? Toch zou je zeggen dat je er vanuit moet kunnen gaan dat dit soort omgevingen sneller gepatched zouden kunnen worden omdat ze geïsoleerd zijn en focussen op hun primaire doel zonder complexe combinaties.

De oorzaak van dit probleem zijn twee ledig:
- De vendor heeft te weinig focus op security en neemt patches alleen mee in een reguliere patch cyclus
- De vendor released wel patches maar het patchproces is niet geautomatiseerd waardoor systemen achterlopen.

Mobiel
Bring Your Own en smartphones is enorm in opkomst, iedereen wil de beschikking hebben over zijn agenda en email, het liefst overall en altijd. Het is nog steeds een nieuwe markt waar veel onvolwassenheid heerst, de risico's zijn niet goed in beeld en of men last heeft van infectie's of dataverlies is onduidelijk. Komend jaar zullen er zeker meer mogelijkheden komen om de risico's beter te beheersen, toch zien we nog een aantal grote uitdagingen waar tooling geen antwoord op kan geven maar waar awareness een steeds belangrijker component wordt.

Heeft uw organisatie een antwoord op deze voorbeeld vragen?
- Mag ik de prive telefoon van een personeelslid wel wissen als werkgever?
- Welke telefoons zijn veilig en welke niet? Of hoe maak ik ze veilig?
- Een telefoon is gestolen, wat is het werkelijk risico dat de lokale data toegankelijk is?

Cloud
Alles in de cloud, een statement welke menig CxO lid het maar al te graag zou willen maken. Toch denk ik dat we daar nog lang niet zijn, tenminste de "publieke cloud". Ik ben in de veronderstelling dat we nog leven in "the fog", waarom? Het is niet duidelijk wat het gevolg is van een cloud, zowel private als publiek. Ook denk ik dat er sommige mensen en bedrijven al meer in de cloud doen terwijl ze het helemaal niet weten, neem als voorbeeld het synchroniseren van data naar de Apple Icloud of misschien wel Cloud applicaties als facebook of Dropbox?

Security in non-ICT infra
In 2012 zijn er een aantal incidenten geweest op het gebied van kritische infrastructuur. Veelal SCADA problemen waarbij systemen aan het internet waren gekoppeld zonder dat men heeft nagedacht over de beveiliging daarvan. ICT Security is daarmee niet alleen ICT gerelateerd (nooit geweest trouwens) maar wel degelijk ook zeer afhankelijk van andere security componenten. Hoe veilig is uw server als iedereen het Datacentrum in kan lopen? En hoe is uw continuïteit gewaarborgd als de klimaat beheersing gehacked wordt?

Telefonie is een onderwerp in opkomst hebben we gemerkt, bellen via internet is een goed gemeen en bijna vanzelfsprekend. Toch kleven hier andere risico's aan dan dat we gewend zijn in het verleden waarbij we het in beperkte mate gebruikte. Zogenaamde VOIP telefoons zijn ook computers welke communiceren via netwerken welke kwetsbaar kunnen zijn en "ICT Security" aandacht vereisen.

Kennis en Conferenties
Als ITQ mogen we op een mooi jaar terugkijken met een geweldige opkomst op de Hack In The Box Amsterdam conferentie waarvan wij local partner zijn. 5 hele dagen stond het Amsterdamse Okura hotel op zijn kop van Bruce Schneier, het Iphone dream team, appliance security, en heel veel meer. Ook in 2013 zullen wij weer ons best doen om Hack In The Box Amsterdam een groot succes te laten zijn.

Bij het Cyber Security Congress mochten we presenteren waarom je hackers en huis moet halen om jezelf te verdedigen en op de Web Application Security Session vertelde we hoe deze community in Nederland er uit ziet.

Regelmatig waren we op events aanwezig om kennis te delen zoals Hack In The Box Kuala Lumpur, Eth0, CCC, B Sides London, HITR2NDB en nog veel meer.

Voor ons was het een mooi jaar met veel beweging, tot slot wensen wij u alvast een veilig 2013!

Op 8 September kwamen de drie groepen Hack In The Box, Randomdata en 2600NL weer bijeen om met elkaar de laatste informatie op het gebied van security uit te wisselen. ITQ was één van de sponsoren en natuurlijk waren we er bij.
 
De presentaties waren zeer divers: de opening gaf een overzicht van de activiteiten van afgelopen 10 maanden, waarna Dave van der Poel volgde met een presentatie over hoe ver video beveiliging tegenwoordig kan gaan en welke technieken beschikbaar zijn. Daarna werd het tijd om het IP protocol van alarm systemen onder de loep te nemen en de nodige tekortkomingen bloot te leggen. Dit onderzoek is gedaan door Wilco Baan Hofman en de conclusie is redelijk duidelijk: XOR is niet voldoende qua versleuteling voor systemen die gemaakt zijn met 1 doel: beveiliging.
 
Tijdens de 3D printer pauze werd getoond hoe 3D printers werken en er werd live gedemonstreerd hoe je kunststof "sleutels" en attributen kunt maken. Na deze pauze was het tijd om Spacenet te openen in de hackerspace van Randomdata door AK47. Spacenet is een netwerk waarop hackerspaces kunnen aansluiten. Via deze weg krijg je op andere locaties met Spacenet ook toegang tot internet of misschien wel andere diensten via je persoonlijke login.
 
Voor de hardcore techneuten hadden we 2 talks met een hoog skill-level. De eerste werd gepresenteerd door Blasty en ging over het aanpassen van code in het geheugen in plaats van op disk. Blasty had niet de eenvoudigste software hiervoor gekozen (OpenSSH), maar na de nodige tweaks, truuks en hacks was het mogelijk om met zijn eigen persoonlijke sleutel in te loggen op het systeem. Aczid volgde het niveau van Blasty en had een talk over het debuggen (en het voorkomen ervan) van bestanden in het ELF formaat. Een mooie truckendoos werd opengetrokken om debuggers te omzeilen: soms met ideeën waarvan je je afvraagt waarom niemand anders daar ooit over nagedacht had.
 
Voordat de eind presentatie werd gegeven, werd er eerst goed gegeten van een door ITQ gesponsorde wok maaltijd en op een volle maag was het tijd voor security legende Winn Schwartau. "Hiring The Unhirable" was de titel van zijn presentatie waarin hij duidelijk maakte dat er wat moet veranderen: voornamelijk onze houding over wie we voor welke taak inzetten, is goed duidelijk gemaakt. Zijn advies is dat je mensen om hun kwaliteiten moet inhuren en gebruik moet maken van hun sterke kanten. Knap niet meteen af op "stempels" welke worden opgelegd zoals: "hij heeft ADHD", "ze is autistisch", "hij heeft een zwart T-shirt aan" maar kijk naar hun kwaliteiten en goede eigenschappen.
.
.
Al met al weer een zeer geslaagd event met techniek en ook de nodige sociale kanten.
Mocht je interesse hebben in de details:

Slides
- Opening - Fish_ & Drwhax
- TBD Video Surveillance - Dave van der Poel
- Cracking the SIA-HS alarm IP transmit protocol - Wilco Baan Hofman
- SpaceFED & live connect RD - AK47
- TBD Runtime injection - Blasty
- Linux ELF binary debugging and anti-debugging - Aczid - (sources)
- Hiring The Unhirable Winn Schwartau

Video:

Hack in the Box (http://conference.hitb.org/)

Wall of Text in one sentence: I can't wait for the next edition :)

If you're a computer security enthousiast, have an interest in the latest iOS jailbreaks or just happen to have been in contact with ITQ the last few years, then chances are you already know what Hack in the Box is. If not, then here's a short introduction: Hack in the Box is a series of security conferences which has grown from a simple get-together of Malaysian security enthousiasts in 2002 to one of the must-attend global security events. In 2010, Hack in the Box partnered with ITQ to organize a European installment: Hack in the Box Amsterdam. This experiment turned into a great success and has since become an annual event, with its 3rd installment in May 2012.

The setup of Hack in the Box is somewhat different from / larger than B-Sides. Instead of a single-day conference, Hack in the Box is a near-week long event. The event is split in two sub-events: the Training Days and the Conference Days.
During the Training Days, security specialists from all over the world can touch up on their skills in their choice of subject. This year, there were three single-day trainings sessions and three two-day trainigs, culminating in a total of three training days.
After the Training Days, it's time for the Conference Days, which offer a more traditional conference experience, with several tracks of security-related presentations, several competitions and an exhibition area for seurity related organizations.

This year, it was my privilege to participate in the organization of two of the competitions that were held on the Conference Days: the Bank0verflow Capture The Flag competition and the HackWEEKDAY programming competition.

Bank0verflow CTF

A CTF can be thought of as a sort of hacking competition and can come in one of two flavors: attack-only or attack & defense. In the former, participating teams are presented with a set of challenges which they have to complete in order to gain points. In the latter, participants are given control of identical (virtual) machines that host a set of (potentially) vulnerable services and are assigned to find and exploit those vulnerabilities in the machines of their competitors while preventing their own machine from being exploited in a similar fashion. After two years of attack-only games, this year it was time to create an attack & defense game.

From the start, it was clear that attack & defense was going to be more challenging than attack-only, both from a challenge-creation perspective as from an organizational / infrastructural perspective.

As a creator of challenges, you have to deal with the fact that you're going to be creating a service of some sort. This means that you're going to be dealing with networking, not buts about it. You had a nice idea for a reverse engineering / obfuscation challenge? If it's not network accessible and can't be used to abuse other competitors' machines, you're going to have a bad time.
Also, as the participants will (eventually) have full access to the machine running your service, every part of your service will be completely exposed. This means that competitors are, by definition, given white-box access to all your challenges. So, you have an idea for a challenge that relies on exposing hard-coded secrets (perhaps a web-challenge with LFI)? Better make sure it won't be reduced to `strings <chal> | grep -i 'passw'`.
And don't forget, your service has to be 'fixable' somehow within the rules of the CTF. That is, teams should be able to mitigate or remove the vulnerability in such a way that it doesn't affect the functionality and interoperability of the service. After all, it wouldn't be much of an attack & defense game if there was no way to defend (other than outright killing the challenge) ;)

From an organizational perspective, you've got a lot more to think about too. Where in an attack-only game you only have to deal with keeping the virtual machines that run your challenges and the scoreboard alive, you now also have to deploy, administer and monitor all of the competitor vm's. You're faced with questions about how you're going to distribute flags and challenges. If challenges rely on retrieving a hard-coded secret, how are you going to make sure that these secrets are unique to each competitor? Will you be deploying all challenges at once, or will you distribute them separately as the competition progresses? How will you deploy new challenges at run-time without disturbing the rest of the game? How do you respond when challenges break and need to be fixed? How do you determine whether teams are abiding by your rules? Not that easy, eh?

In the end, we decided to be pragmatic and create a sort of hybrid attack & defense game. All of the teams were given a vm which would be fully updated so that any and all succesful attacks would either have to be related to our challenges or 0-day (in which case you deserve the pwnage). Every vm would include the organization's ssh rsa pub key and teams were forbidden from removing it, so at any time we would be able to monitor activity, distribute new flags and add or fix challenges. Challenge creators were instructed to provide challenge-specific deployment scripts that would create a challenge-specific user and group (so challenges wouldn't interfere with one another) and customize the challenge for a specific machine based on ip (for instance to generate unique hard-coded secrets). We also set up a centralized challenge server which could host bonus challenges that were deemed inappropriate for a pure attack & defense game. The scoring system was a punishment / reward system, where points were awarded for keeping services alive and functioning (and of course for finding flags) and deducted for having them disabled or disrupted. Checks on service availability and functionality were inplemented as automated unit tests for core functionalities, that were run at semi-random intervals.

In the end, I ended up creating three challenges for the CTF, two of which were actually released. The first one that was released was a Digital Cash system called ByteNote, which contained several cryptography-related issues that allowed teams to create or falsify digital IOU's that could be turned into points at the central server.
The second challenge was a bonus steganography challenge called Invisible Ink, which consists of a disk image that contains two files that each encode half of a flag. The catch? Upon inspection of the files, you will notice both contain nothing but null bytes :)
My third challenge, which was planned to be released on the second day, sadly remained unreleased due to organizational preoccupation with other issues. The challenge was a centralized Security Scanner's host agent that contained a variety of issues that could be elevated to, among other things, Denial of Service and Remote Code Execution.

We are currently discussing how to publicly release the challenges we made for the CTF, so if you're interested in giving them a try, keep your eyes posted on this blog :)

HackWEEKDAY

HackWEEKDAY is a relative new comer to the Hack in the Box repetoire, with its first installment at Hack in the Box KL 2011. The idea of HackWEEKDAY is simple, but fun: it is a programming comptetition where, during the course of the Conference Days, teams of programmers design, implement and present a Proof of Concept solution to their choice of one of several coding challenges. These PoC's are then evaluated by a team of judges on aspects such as functionality, originality, applicability, etc. and the winner gets the Big Prize of $1337.

When I joined the organization of HackWEEKDAY, the theme had already been determined: Browsers and their Extensions, so all we had to do was translate this into a series of programming challenges; invite and select suitable participants; create a shared development environment so different team members could cooperate on their chosen assignment; and, last-but-not-least, provide a comfortable physical environment in which the participants could be stimulated and supported throughout their undertakings.
The first two aspects turned out to be the most challenging from an organizational point of view.
At the first edition of HackWEEKDAY, the competition ran non-stop for a full 24 hours. This time, due to practical limitations with the venue, we would not have the luxury of continuing throughout the night. This meant that the time available for the competition was reduced to a span of 12 hours. This is not a lot of time in the world of software development, so we would have to be careful with the scope of our challenges. Make the challenges to broad or too complex, and you risk ending up with non-functioning/non-presentable PoC's, which not only makes the results less interesting to present, but also harder to judge. Luckily for us, the theme of Broswer Extensions lends itself perfectly for relatively small projects, as a lot of basic functionality is provided through the browser's api.
Inviting and selecting the right candidates was challenging mostly due to the novelty of the HackWEEKDAY. With only one previous edition at the other side of the globe, it was difficult to gauge and predict the level of interest in the various potential target audiences and the best communication channels to reach them. Although we did manage to find a nice selection of participants, this is definitely an area in which we still have a lot to learn.
Once these things were deal with, the rest was a breeze. With a simple SVN setup to enable collaboration; a nice conference room at the Okura hotel with a good sound system for physical comfort; and the presence of a few representatives from Mozilla (who sponsored the event) that helped both in supporting / stimulating the participants and in judging the submissions, the competition ran perfectly smooth.

In the end, we had a total of 4 teams, that chose to work on 3 different challenges:

• Automatic hash verification of downloaded items (1 team)
• A password re-use detection / warning system (2 teams)
• A client-side encryption tool (to be used, for instance, with unencrypted webmail) (1 team)

Although not every team started at the same time (some taking longer to reach a decision on their choice of challenge than others) each of the teams managed to create and present a functioning PoC. To me, as part of the organization, that meant a job well done. As icing on the cake, some of the developers expressed their intention to continue working on their PoC's and turn them into full-fledged extensions. Among them was the winning team, whose github for the project can be found here: https://github.com/DevNerd/YAP

All in all, I had a blast during Hack in the Box, from the preparations to volunteering during training sessions, to the last minute CTF fixes, to the final presentations of the HackWEEKDAY. Although with one Conference Day fully dedicated to the CTF and one Conference Day fully dedicated to HackWEEKDAY I didn't get to attend any but the Keynote presentations and one of my challenges sadly got benched, I would do it again in a heart beat. I can't wait for the next edition :)

Security B-Sides London (http://www.securitybsides.org.uk/).

Wall of Text in one sentence: 8/10, would definitely go again

Security B-Sides, as a name, is not so much a conference, as it is an entire conference concept. In essence, Security B-Sides is the idea of a free, community-driven conference, usually held along side another Security related event, where the speakers are chosen from and by its target audience.

As the B-Sides traditionally do not charge an entrance fee and budgets are fixed, there is usually a set limit on the number of tickets, which are either distributed first-come first-serve or on an invitation basis. B-Sides London uses the first approach, with a waiting list for when people cancel their reservation. Rumour has it that this year, the waiting list went up to over 300, which is quite impressive.
Luckily for yours truely, who was a tad late with his reservation, some of the sponsors of B-Sides were giving out tickets as prizes for challenges (http://www.securitybsides.org.uk/challenges2012.html). One of these was was KMPG's Finding N3ro fox hunt, which ended for me with the happy notification that I was taken off the waiting list and allowed to claim a ticket.

As the conference would be held on the 25th of april, starting at 8 am and ending with an after party, I decided to plan my trip so I would arrive the day before and wouldn't have to leave untill well in the afternoon the next day. As luck would have it, this choice meant that not only would I be able to attend B-Sides, but I would even be able to drop by at DC4420, a mini con organized by the local Defcon chapter the evening of the 24th. Being situated only 30 minutes from my Hotel, with two interesting talks about hacking a mobile hotspot and reverse engineering wireless devices using sound analysis (not to mention the free drinks during the 44Con Happy Hour), this was definitely worth a visit.

I already mentioned that B-Sides was set to start at 8 am. What I haven't mentioned yet, is that thanks to the online challenges, I had been in contact with Iggy / GeekChickUK (http://twitter.com/#!/geekchickuk), one of the organizers of B-Sides. Being somewhat related to Hack in the Box, I had been talking to her about bringing along some HitB flyers and perhaps lending them a helping hand where necessary. So it came to be that at 7:30 I was at the conference location, putting up B-Sides raffle posters while HitB flyers were being disributed among the B-Sides swag bags. Not a bad start.

From thereon, it was time for the main event: the actual conference. Thinking back to the whole thing, I still have no idea how they managed to finance it without any ticket revenue. The location, with its indoor garden and aviary, was huge and very nice. Some would say it was a bit too big, as walking from one side of the venue to the other could take severl minutes, but I'll take too big over too small any time. Upon arrival, attendees were greeted with a free t-shirt, a swag bag, a bottle of Club Maté to kick the brain into early morning information absorption mode and *the* nicest conference information booklet I have seen to date. The lunch, though nothing truely exceptional with pre-made sandwiches and juice, was nonetheless pretty darn edible. The after party, however, proved to be the true icing on the cake. Situated at walking distance from the conference, the venue provided two stories (including a lounge area) with ample supply of free beer and delicious snacks to satisfy every nerd's needs.

Booklet front

Booklet inside

Of course, a conference is more than just free food, drinks and swag, so I can't leave without saying something about the actual content, i.e. the presentations. B-Sides London offered three Tracks, between which attendees could freely switch throughout the day. Two of these tracks were filled with pre-determined presentations. The third track, also known as the Unconference Track, offered an open stage to anybody with a message to share. I spent my time divided between Track 2 and Track 3, listening to talks about Elegant Security; Social Engineering; Incident Response expriences; attack vectors in HTML 5; the origin of security holes in SAP implementations; and a collection of short presentations with practical tips and tricks for a variety of attack vectors. The highlight of the day was definitely the talk about Elegant Security by Stephen Bonner, not so much due to its technical content, but because of Bonner's exceptional ability to capture and interact with the audience (how often do you see a Frankenstein's Monster in a lab coat throwing Ferrero Rocher at the audience for guessing the name of a dead mathematician?).

Overall, I have to say Security B-Sides London was a great succes. 8/10, would definitely go again :)

One of the beautiful things about Security (with a capital S) is that it is continually and rapidly evolving. This means that there is an endless stream of new technologies and ideas that somehow need to be shared, scrutinized and showcased.

The Internet as a whole provides a nice set of tools for such activities, such as mailing lists, link aggregators, (micro) blogs, fora, etc., but sometimes it's nice to take step back from the safe, anonymous, digital environment that we've grown accustomed to and return to an arena of straight up face-to-face human interaction, i.e.: a Conference. This is not just because it allows us to rediscover the fact that the brilliant ideas and hacks we hear and read about on a daily actually come from people just like you and me, but also because it provides the perfect opportunity to celebrate that realization with said people by sharing your (potentially alcoholic) beverage of choice with them.

In the last two months, it was my privilege to attend not one, but two conferences: one as an attendee and one as part of the organizing crew. In the next two posts, I'll divulge some of my experiences with them :)

De wereld van security is op alle vlakken continu in beweging. Om op het gebied van crypto de Nederlandse wiskunde (en security!) community een beetje op de hoogte te houden, wordt vier keer per jaar een Cryptography Working Group bijeenkomst gehouden. Dit is een dag van lectures waar recente ontwikkelingen gepresenteerd en besproken worden.

Afgelopen vrijdag was de eerste sessie van 2012, en als geïnteresseerde in crypto was ik er natuurlijk bij.

Hieronder een kleine samenvatting / introductie van wat er de revu is gepasseerd.

De toepassing van Principal Component Analysis binnen (Differential) Power Analysis.

Power Analysis is een bekende vorm van zogeheten side channel aanvallen op implementaties van cryptografische oplossingen. Bij side channel aanvallen wordt niet zozeer gekeken naar fouten in de wiskunde van een aanpak, alswel naar wat voor informatie gelekt wordt door de physieke en softwarematige implementatiekeuzes. Bij Power Analysis wordt gekeken naar het stroomverbruik van een cpu tijdens verschillende cryptografische operaties, omdat vaak blijkt dat hier patronen in zitten die direct aan de encryptiesleutel gecorreleerd kunnen worden.
Een bekend probleem bij Power Analysis is dat je vaak gebruik moet maken van meerdere metingen, en dat metingen nogal eens ruis of timingverschillen (versnellingen, vertragingen, etc.) kunnen bevatten. Lejla Batina e.a. houden zich bezig met de vraag in hoeverre Principal Component Analysis (een bekende techniek binnen de wiskunde om een set variabelen die mogelijk gecorreleerd zijn te verkleinen naar een set ongecorreleerde variabelen) nuttig gebruikt kan worden om ruis en timingproblemen te compenseren / filteren. De eerste resultaten hiervan zijn te vinden in onderstaande paper: http://www.springerlink.com/content/nn32124r42n88383/

Parallellisering van Pollard's Rho functie binnen Elliptische Curves:

Veel asymmetrische crypto systemen zijn tegenwoordig gebaseerd op het zogenaamde Discrete Logaritme Probleem, dat stelt dat als je van de vergelijking x = g^a mod(n) alleen x, g en n weet, dat a dan moeilijk te berekenen is. Een van de manieren om a dan toch te berekenen, is de Rho methode van John Pollard, waarbij willekeurige y_i van de vorm y_i = g^{(q_i * a + r_i)} gegenereerd worden met q_i en r_i bekend, totdat er twee getallen y_j en y_k gevonden zijn die congruent zijn modulo n. Op dat moment wordt het berekenen van a vereenvoudigd tot het oplossen van de vergelijking q_j  * a + r_j = q_k * a + r_k (mod n), waarbij alleen a onbekend is. De moeilijkheid van het berekenen van a is zo teruggebracht tot een functie van de kans dat twee willekeurige getallen congruent zijn modulo n en de kosten van de functie waarmee de willekeurige getallen gegenereerd worden.
Peter Schwabe e.a. hebben zich gefocust op het ontwerpen van een efficiente implementatie van een parallelle Rho functie voor specifieke Elliptische Curves. Hierbij heeft hij een resultaat bereikt dat bijna twee keer zo snel is als het huidige record. Dit verschil komt hoofdzakelijk door het gebruik van een negation map bij het berekenen van de willekeurige waarden. Deze techniek is niet nieuw, maar was tot op heden lastig te implementeren in een parallelle omgeving omdat de benodigde berekeningen afhankelijk zijn van if-statements, welke niet goed ondersteund worden in het SIMD model. Schwabe e.a. hebben dit probleem opgelost, door de if-statements te vertalen naar wiskundige berekeningen. De details hiervan, samen met een leuke verzameling van do's en don'ts voor als je zelf een keer een implementatie wil schrijven, kun je vinden in het volledige paper op http://cryptojedi.org/papers/#negation

Smart Grid Security en Privacy

Het Smart Grid is een technologie die er al een tijdje aan zit te komen en die bij sommige mensen beter bekend staat als de Slimme Meter of de Smart Meter. Het idee van het Smart Grid is relatief simpel: als ieder gebouw in de meterkast een computertje heeft dat bijhoudt hoeveel energie er gebruikt dan wel geproduceerd
wordt dan wordt het

1. makkelijker voor energieleveranciers om te voorspellen hoeveel energie waar wanneer nodig is
2. makkelijker voor energieleveranciers / het energienet om energie uit lokale bronnen te routeren wanneer dit mogelijk is
3. makkelijker voor consumenten om in te zien waar ze kunnen bezuinigen op hun energieconsumptie

Het nadeel, echter, is dat een smart grid ervoor kan leiden dat een deel van onze kritieke infrastructuur (energie) open komt te staan voor een versheidenheid van nieuwe aanvallen.
Klaus Kursawe houdt zich bezig met de ontwikkeling van de security kant van toekomstige smart meters en heeft een boekje opengedaan over de problemen die in dit veld leven en de horrorverhalen de je vanuit een security en cryptografisch perspectief tegenkomt. Dit varieert van SQL injection via meetwaarden tot compleet gebroken authenticatie protocollen tot het moeten uitleggen van hash functies met lego autootjes.
Een bekend, maar interessant probleem dat hij aandroeg met betrekking tot smart meters was het probleem van profiling aan de hand van stroom consumptie. Met andere woorden, dat je allemaal (soms zelfs medische) eigenschappen van een persoon kunt afleiden puur door te zien hoeveel stroom hij gebruikt (al dan niet gecombineerd met tijdstip). Een manier om dit probleem (gedeeltelijk) in te perken is door verbruik niet per individueel huis te analyseren, maar per blok van x huizen. Dit vereist wel dat het verbruik per blok berekend kan worden zonder het verbruik van individuele huizen vrij te geven, wat kan via zware wiskunde als (al dan niet volledig) homomorfe multi party computation, maar ook via simpele XOR operaties in een Dining Cryptographer netwerk.
In ieder geval is er nog een wereld aan uitdagingen met betrekking to Smart Grids, zeker met een wanneer je rekening moet houden met een budget van € 0.50 / meter.

Joint local collisions in sha1

Hash functies vormen een van de pijlers waar de huidige security wereld op rust. Ze worden vaak gebruikt om integriteitschecks te doen of om geheime waarden te maskeren.
Het idee van de hash functie is simpel: het is een functie die aan de hand van input (van over het algemeen willekeurige lengte) op deterministische wijze een output genereert die vervolgens niet meer te herleiden is naar de input, oftewel een functie die maar een kant op berekend kan worden. De sterkte van een hash functie wordt grotendeels bepaald door de vraag hoe moeilijk het is om twee inputs met dezelfde hash waarde (een zogeheten collision) te vinden. Van MD5 weten we ondertussen dat het relatief simpel is om twee inputs met dezelfde hash waarde te vinden, zo lang je geen al te strenge eisen stelt aan hoe de inputs eruit mogen zien. Dat is dan ook een van de redenen dat je steeds vaker hoort dat MD5 aan het eind van zijn levensduur is. Voor SHA-1 is het genereren van collisions zelfs zonder eisen aan de inputs behoorlijk lastig. De beste gepubliceerde manier tot nu toe kost een slordige 2^69 berekeningen. Marc Stevens heeft onderzoek gedaan naar het verbeteren van dit getal en zegt een manier gevonden te hebben om het aantal benodigde berekeningen terug te brengen naar 2^57,5, een aanzienlijke verbetering. Het paper waarin hij zijn werk uiteenzet is helaas nog niet gepubliceerd, maar het klinkt veelbelovend.

Op 26 November kwamen de groepen HITB, 2600NL en Randomdata bij elkaar. De naam "Hack in The Random 2600 NL Data Box" was ooit ontstaan door het verblijf van deze 3 community's op Hackin At Random in 2009. Door gezamenlijke inspanning van deze 3 groepen zijn er nadien diverse activiteiten en evenementen onstaan. Deze keer werd het tijd voor een mini-event in de hackerspace van Randomdata te Utrecht. ITQ was sponsor om er voor te zorgen dat deze groep hackers niet zouden verhongeren, een wokmaaltijd volledig in HITB stijl was een welkome aanvulling tot het mini-event.

Voor het mini-event waren de mensen welke betrokken zijn met deze drie community's uitgenodigd om samen kennis te delen en weer eens informeel bij te praten. Ook waren er een aantal sprekers uitgenodigd, de onderwerpen liepen uiteen van hardware hacking met lazzors, het "pwnen" van een 4G data netwerken tot Air travel hacking. Daarnaast was er ruim de tijd om bij te praten onder het genot van een kopje koffie, wat te drinken of wat te eten.

Nieuwe initiatieven voor de HITB conferentie in 2012 zijn tijdens de opening van het mini-event gepresenteerd waardoor de community weer volledig op de hoogte is van de toekomst plannen. Het mini-evenment was een groot succes en in de toekomst is de kans groot dat er meer mini-events gaan volgen.

Tijdens het event zijn er video's en foto's gemaakt, de video's zijn via onderstaande links te bekijken.
De foto's kunnen via deze link bekeken worden: http://hackintherandom2600nldatabox.nl/

Je kent het wel: je twijfelt aan jezelf en je vraagt jezelf af: “Had ik hem nou op het terras laten liggen? Of niet?”
Of je komt bij je auto, met als resultaat een ingeslagen raam. Je bent je telefoon kwijt. En nu?
 
Hoe je het ook went of keert, de telefoons van vandaag zijn heuse computers en worden steeds belangrijker in ons (zakelijke) leven. Bewust of onbewust ben je ineens een sleutel(apparaat) kwijt dat toegang geeft tot vele poorten. Je e-mail staat er op, smsjes, agenda's, contacten en wellicht nog wat documenten. Natuurlijk synchroniseer je deze met systemen als MS Exchange, Gmail, iCloud etc. Je bent je data niet kwijt want die staat netjes opgeslagen, maar je je smartphone heeft wel live toegang tot deze omgevingen. Denk eens na wat er dan allemaal mogelijk is: het resetten van je Facebook of paypal account? Aankopen doen op Amazon of Ebay? Je baas of die ene klant een vreemde email sturen? Of... het wissen van alle gegevens welke in deze systemen staan opgeslagen.
 
In de toekomst verwacht ik dat het nut van je mobieltje, smartphone of tablet alleen maar gaat toenemen. Nu al kun je je telefoon gebruiken voor toegangscontrole (vervanging van de bekende witte toegangspas) of voor betalingen (NFC). De functionaliteit van mobiele apparatuur wordt alleen maar groter.

Indien je je smartphone kwijt bent is het van groot belang om snel te reageren, maar ook niet overhaast omdat acties misschien wel voor meer problemen zorgen i.p.v. minder.
Wat doe je wel en wat doe je niet:

• Blokkeer je simkaart pas als je er zeker van bent dat niets meer mogelijk is. Als je deze laat blokkeren zal de telefoon van de buitenwereld zijn afgesloten, het automatisch vernietigen van data of eventuele GPS tracking is dan ook niet meer mogelijk. Dit geld ook voor je eventuele wachtwoorden van bijv. Exchange.
• Indien je de data op afstand vernietigd, ga er niet blindelings vanuit dat alle data ook echt verwijderd is. Veel telefoons hebben bijvoorbeeld een geheugenkaart met opgeslagen documenten of een backup.
• Indien gevoelige informatie op de telefoon was opgeslagen is het belangrijk eventuele gevolgen direct in te schatten. Meld deze gevolgen aan betrokkenen, het is beter vroeg te acteren dan dat men later de gevolgen moet opruimen.
• Doe aangifte, via deze weg kunnen instanties criminelen opsporen en wellicht te telefoon terug vinden. Als deze is terug gevonden controleer dan de status van het apparaat.
• Indien je twijfelt: zoek hulp bij professionals

ITQ assisteert haar opdrachtgevers regelmatig als er een security incident heeft plaats gevonden, ook op het gebied van mobiele apparatuur. Daarom hebben we een aantal voorbereidings tips:

• Denk er over na welke informatie er op een smartphone gebruikt mag worden: voorkomen is immer beter dan genezen en informatie die niet aanwezig is, kan ook niet zoek raken. Leg dit vast in een beleid en verbind er eventueel voorwaarden aan. En wat vooral belangrijk is: breng het beleid onder de aandacht van de medewerkers.

• Zorg voor beheersbaarheid, hierbij kun je denken aan:
  
  • Het afdwingen van een (sterke) wachtwoorden
  • Het verplicht stellen van een gedegen versleuteling
  • Automatische vernietiging van data (ook op afstand) bij misbruik/diefstal/verlies van de telefoon/pincode.
  • Lifecycle en patch management, telefoons met kwetsbaarheden kunnen bijvoorbeeld informatie op de telefoon in gevaar brengen.
  • Onderzoek naar track&trace functionaliteit van telefoons. Denk bijvoorbeeld aan telefoons die de GPS locatie kunnen  doorgegeven.

• Leg vast hoe er met smartphone security incidenten omgegaan dient te worden. Welke stappen pas je wel toe en welke niet? Wie mag deze stappen ondernemen en wat zijn de escalatie mogelijkheden?

• Het is verstandig om van te voren contact te zoeken met lokale instanties, specialistische bedrijven of telefoon providers en hiermee afspraken te maken. Op deze manier kan er snel geacteerd worden als een telefoon gestolen is.

Want ook voor verlies van smartphones geldt:
Een goede voorbereiding is het halve werk.

Ik ben op 14 juni op het IT Asset Management Congres van Heliview met een goede businesscase voor Provisior i.c.m. een software asset management tool. De voorbereidingen zijn in volle gang dus volg ook http://itam.heliview.nl/