Your Security is Our Business
13
herfst 2011
u p d a t e DE COLUMN
2
Arjan de Vet
HET COLOFON
2
HET NIEUWS
3
• Madison Gurkha en ITSX op vakbeurs Infosecurity.nl • ICS Cyber Security Training • Diginotar onderwerp van de dag • NLUUG Najaarsconferentie 2011
de actualiteit
4-5
Heeft het CA model zijn langste tijd gehad?
DE HACK
6-7
Daniël Dragicevic ˇ ´ over interne netwerken bij open organisaties
HET INZICHT
8-9
Tim Hemel over het nut van Secure Software Development
HET INTERVIEW
10
Andrew MacPherson van Paterva over het tool Maltego
HET VERSLAG Hack in The Box
11
I N Gjaar op G I OD n dit
t pd ITSX s U I TurN deze U reren. j i B . kha en 1 1 st aa
ate
l 20 regi on G urity.n u gratis te Madis c e s o f g om urs In vakbe odigin r a.s. n t i u embe en v e o u n t 3 vind n/of op 2 e Utrecht! g a a r urs nug aarbe Wij zie in de J
In iedere Madison Gurkha Update vindt u een leuke en informatieve column, die de lezer een verfrissende kijk biedt op uiteenlopende onderwerpen rondom IT-beveiliging. Deze keer Arjan de Vet over de beveiligingsrisico’s rondom social media.
de column
Social media de volgende aanvalsvector? Inmiddels is de Madison Gurkha Update toe aan haar 13e editie. Hopelijk brengt het lezen hiervan geen ongeluk, zeker niet op het gebied van uw IT security. Zoals ongetwijfeld bekend zit een ongeluk bij IT security in een zeer klein hoekje. Het is een permanente en vaak ongelijke strijd tussen de beveiligers die alle gaten moeten dichten en de aanvallers die er vaak aan één genoeg hebben. Hoe actueel dit is, blijkt wel uit de Diginotar hack, waar wij in deze Update verder op in zullen gaan. Toen ik, inmiddels alweer 10 jaar geleden, toetrad tot Madison Gurkha vroeg ik me eigenlijk wel een beetje af hoelang er werk zou zijn voor zo’n bedrijf. Op den duur zou iedereen het toch wel gaan snappen hoe je dingen veilig maakt? Dat bleek een misvatting. De IT-wereld groeide erg hard en het beveiligingsbewustzijn kon en kan die groei simpelweg niet bijhouden. Tijdens onze onderzoeken komen we daarom vaak dezelfde security problemen tegen en dat over periodes van jaren. De IT-wereld blijkt weinig tot niets te leren van fouten uit het verleden. Dit is ook de reden waarom wij onze ervaringen willen delen, bijvoorbeeld via onze training Secure Programming, die wij in samenwerking met AT computing ook klassikaal gaan aanbieden. Bij het testen van applicaties op Smartphones gaan we ongetwijfeld weer vele malen een deja-vu-gevoel krijgen: oude security problemen die in een net iets ander jasje weer terugkomen. Desondanks blijft het uitdagend en leuk werk. In deze Update, op onze Black Hat Sessies en op andere wijze probeert Madison Gurkha u hiervan op de hoogte te houden. Zijn social media de volgende aanvalsvector? (zie ook het interview met Andrew MacPherson van Paterva verder in deze Update). Op steeds meer sites staan tegenwoordig ‘Like’, ‘tweet’, ‘+1’ en dat soort buttons waarmee je via social media kunt delen wat je leuk vindt. Hierbij wordt gebruik gemaakt van het feit dat iemand in een en dezelfde browser ingelogd is op een social media site en tegelijkertijd allerlei andere sites bezoekt. Behalve dat social media sites zo erg veel over u te weten kunnen komen (hun privacyvoorwaarden wijzigen vaak
en zijn permanent onderwerp van discussie) zitten hier ook andere gevaren aan. Maar zit er onder die ‘Like’ button veilige code van Facebook of code van iemand anders met andere bedoelingen? Gaat u bijvoorbeeld elektronisch bankieren of vertrouwelijke bedrijfsinformatie raadplegen in dezelfde browsersessie als waar u al ingelogd bent op Facebook en graag op ‘Like’ buttons klikt? Enig idee hoezeer internetcriminelen uw geld ‘Liken’ of ‘-veel’ willen doen op uw bankrekening? Het beveiligen tegen dit soort aanvallen (Cross-Site Request Forgery geheten) is mogelijk maar niet triviaal en zeker nog niet algemeen geïmplementeerd. Social media lijken hiermee perfect geschikt om vooral social engineering media te worden. Social engineering aanvallen zijn op zich natuurlijk niets nieuws (denkt u eens aan het Paard van Troje), social media geven echter weer vele extra mogelijkheden. Madison Gurkha maakt hier bij haar social engineering onderzoeken in opdracht van klanten dan ook dankbaar gebruik van. Een internetexpert sprak onlangs het vermoeden uit dat het internet pas rond het jaar 2040 veiliger zou zijn. Het zou me inderdaad niets verbazen. Het is in ieder geval na mijn pensionering, dus vooralsnog zal het met mijn ‘job security’ wel goed moeten zitten. Arjan de Vet Partner, Principal Security Consultant
het colofon Redactie Tim Hemel Laurens Houben Remco Huisman Frans Kollée Maayke van Remmen Ward Wouts
2
Vormgeving & productie Hannie van den Bergh / Studio-HB Foto cover Digidaan
Madison Gurkha herfst 2011
Contactgegevens Madison Gurkha B.V. Postbus 2216 5600 CE Eindhoven Nederland
T +31 40 2377990 F +31 40 2371699 E
[email protected]
Bezoekadres Vestdijk 9 5611 CA Eindhoven Nederland
Redactie
[email protected]
Voor een digitale versie van de Madison Gurkha Update kunt u terecht op www.madison-gurkha.com. Aan zowel de fysieke als de digitale uitgave kunnen geen rechten worden ontleend.
In “Het Nieuws” belichten we iedere Madison Gurkha Update belangrijke recente ontwikkelingen die in het beveiligingsnieuws zijn verschenen. Ook alle nieuwe ontwikkelingen rondom Madison Gurkha komen in deze rubriek uitgebreid aan bod.
het NIE U W S
Bezoek dit jaar Madison Gurkha en ITSX op vakbeurs Infosecurity.nl Gedurende twee dagen laten wij u op een interactieve manier kennis maken met ons zeer complexe en snel veranderende vakgebied. Bezoek op 2 en/of 3 november onze stand (nr. 01.E145) om nader kennis te maken met (de mensen achter) Madison Gurkha en ITSX. Om ervoor te zorgen dat uw bezoek zeker de moeite waard is, hebben we een interessant programma opgesteld. 2 november 11.00 – 11.20 13.30 – 13.50 15.30 – 15.50
RFID demo Live hacking demo Korte presentatie Mobile Insecurity
3 november 11.00 – 11.20 13.30 – 13.50 15.30 – 15.50
Korte presentatie Mobile Insecurity RFID demo Live hacking demo
En vergeet vooraal niet uw hang/cilinderslot mee te nemen! Walter Belgers en Hans Van de Looy van Madison Gurkha, de experts op het gebied van lockpicking, zullen proberen binnen afzienbare tijd uw slot door middel van kleine metalen staafjes, zonder forceren te openen. Maar u kunt natuurlijk ook zelf de uitdaging aangaan! Voor de drie snelste lockpickers wacht een mooie prijs! Bij deze Update vindt u een uitnodiging waarmee u zich gratis kunt registeren via www.infosecurity.nl.
ics Cyber Security Training Het Control Systems Analysis Centre, onderdeel van het Idaho National Laboratory, is gespecialiseerd in Cyber Security. Speciaal voor Nederlandse ICT-professionals, wordt van 10 t/m 14 oktober 2011 een vijfdaagse training Industrial Control Systems Cyber Security voor gevorderden georganiseerd. Het programma bestaat uit drie dagen instructie gevolgd door een zogenaamde ‘red team/ blue team excercise’: een 12 uur durende oefening waarin het ene team de ‘aanvaller’ (red team) speelt en het andere team de ‘verdediger’ (blue team). Op de laatste dag vindt er een evaluatie plaats zodat de deelnemers lering kunnen trekken uit de uitgevoerde opdracht. Met name voor leveranciers, systeembeheerders, ICT’ers en managers die zich bezig houden met de procesbesturingssystemen in de vitale infrastructuur is deze training zeer interessant. Vanuit Madison Gurkha gaat Stefan Castille, M.Sc.Eng. naar Idaho Falls om aan de training deel te nemen. Voor meer informatie over de ICS Cyber Security training kijk op: https://secure.inl.gov/icsadv1011/
Diginotar onderwerp van de dag Het zal u niet ontgaan zijn dat recent duidelijk is geworden dat er elektronisch is ingebroken bij het bedrijf DigiNotar. Daarbij zijn frauduleuze certificaten aangemaakt en in omloop gekomen. Vrijdag 2 september jl. heeft de overheid bekend gemaakt dat de uitgevende Certificate Authority gecompromitteerd is en alle certificaten van DigiNotar zo snel mogelijk vervangen moeten worden. IT-beveiligingexpert Hans Van de Looy, partner en Principal Security Consultant bij Madison Gurkha is door verschillende media geïnterviewd om zijn mening omtrent het beveiligingsdebacle te geven. Hij laat weten geschokt te zijn door de omvang van de Cyberaanval. Hij spreekt niet over
fouten, maar over blunders. (zie ook het uitgebreide artikel door Hans Van de Looy elders in deze Update). Op 5 september jl. was hij te zien in een uitzending van het AVRO-programma EenVandaag. http://beta.uitzendinggemist.nl/ afleveringen/1110370
Verder heeft Van de Looy zijn kennis en expertise gedeeld met onder andere: • ISP Today, 5 september 2011: http:// www.isptoday.nl/nieuws/beveiligingsfout-nooitrustig-afwachten
• NU.nl, 6 september 2011: http://www. nu.nl/internet/2603449/mogelijk-nepsoftwareverspreid-naast-aftappen-gmail.html
20 oktober 2011
NLUUG Najaarsconferentie 2011, met een lezing door Walter Belgers Reehorst Ede, Nederland https://www.nluug.nl/activiteiten/events/nj11/ Op 20 oktober a.s. wordt de NLUUG Najaarsconferentie met als titel Networking: IPv6 en de rest… in de Reehorst in Ede gehouden. De keynote IPv6 -- Open Internet for Open Source zal gegeven worden door Owen DeLong CTO van Hurricane Electric, de grootste IPv6-provider van de VS. Maar ook de rest van de lezingen mag er zijn. Er zal uitgebreid aandacht zijn voor IPv6 maar ook andere thema’s komen aanbod. Walter Belgers van Madison Gurkha verzorgt een lezing IPv6 insecurities from a pentesting standpoint. In zijn presentatie gaat hij in op de nieuwe risico’s die de invoering en het gebruik van IPv6 met zich mee kunnen brengen.
Madison Gurkha herfst 2011
3
Uiteraard mag een artikel over Diginotar in deze Madison Gurkha Update niet ontbreken. We vroegen Hans Van de Looy van Madison Gurkha, die in verschillende media in het nieuws is geweest omtrent het beveiligingsdebacle, om zijn verhaal te doen.
de actualiteit
Heeft het CA model zijn langste tijd gehad? Ik denk niet dat het iemand ontgaan zal zijn, maar ik wil toch even stilstaan bij een recente gebeurtenis die wereldwijd een ware tsunami heeft verspreid over het internet. Een schokgolf ondertussen die nog steeds niet helemaal lijkt uitgedoofd. Wat kunnen we leren van Diginotar?
Wat is er eigenlijk gebeurd? De feiten zoals die er nu liggen, geven aan dat initieel een relatief kleine Nederlandse Certificate Authority (hierna CA te noemen) het slachtoffer is geworden van een digitale inbraak, waarbij de misdadigers zodanig toegang hebben kunnen verkrijgen tot de systemen dat deze persoon of personen zelf willekeurige certificaten konden laten ondertekenen door Diginotar. Deze werden daarna door alle bekende browsers als valide gezien. Hierdoor werd het potentieel mogelijk om, indien verkeer van en naar de werkelijke server kon worden omgeleid via een tussenliggend systeem (een zogenaamde proxy), beveiligd verkeer af te luisteren en/of te wijzigen. Nader onderzoek heeft uitgewezen dat deze valse certificaten uiteindelijk gebruikt zijn tegen Iraanse onderdanen. Niets wijst erop dat Nederlandse internetgebruikers slachtoffer zijn geworden van dit misbruik. Bijkomend saillant detail is dat Diginotar de betreffende inbraak, nadat deze is opgemerkt, nog enige tijd geheim heeft getracht te houden. Deze opeenstapeling van blunders heeft er natuurlijk voor gezorgd dat het vertrouwen in deze CA aanzienlijke schade heeft opgelopen, en er gaan op het moment van schrijven al stemmen op om na te gaan of Diginotar hiervoor verantwoordelijk kan worden gesteld. Iets dat uiteindelijk kan
4
Madison Gurkha herfst 2011
leiden tot aanzienlijke claims, aangezien alle klanten (bedrijfsleven en overheid) van dit bedrijf nu op korte termijn al hun certificaten hebben moeten wijzigen om het vertrouwen in de verschillende websites weer te herstellen. Naast dit incident is ondertussen ook duidelijk geworden dat GlobalSign (de op 4 na grootste CA) ook het slachtoffer is geworden van dezelfde criminelen en dat deze persoon of personen ook verantwoordelijk zijn geweest voor de problemen van Comodo (de nummer 2 CA) begin dit jaar.
Laksheid
juist inzoomen op twee aspecten die me zijn opgevallen. Allereerst de laksheid die schijnbaar heerst bij deze CA’s. Bij elk van deze organisaties hebben crackers toegang kunnen krijgen tot de belangrijkste systemen van de CA, maar is dit niet tijdig opgemerkt en zijn er ook onvoldoende snel mitigerende acties ondernomen om de geïdentificeerde problemen op te lossen. En dan heb ik het dus niet eens over proactieve acties die, zeker door dergelijke organisaties wiens product feitelijk alleen uit vertrouwen bestaat, noodzakelijk zijn om een organisatie voldoende veilig te houden.
aan een product kunt
We zien in alle gevallen dat er op papier wellicht wel het een en ander wordt gedaan aan informatiebeveiliging, maar dat het proces absoluut onvoldoende blijkt om de veiligheid van de belangrijkste systemen in voldoende mate te garanderen. Het heeft er alle schijn van dat informatiebeveiliging ook niet als een proces is ondergebracht in de organisatie, maar dat het een regelmatig terugkerend project was dat erop was gericht om aan de wensen en eisen van een auditpartij te voldoen. Een instelling die niet kan werken.
toevoegen
Informatiebeveiliging is noodzaak
Wat ik met dit artikel wil bereiken, is niet een volledige analyse van hetgeen heeft plaatsgevonden; daar is al een rapport over in de openbaarheid gebracht. Ik wil hier
Goede beveiliging is niet iets dat je nadien
De eerste les die hieruit geleerd moet worden is dat informatiebeveiliging
de actua liteit
Beelden van de TV-uitzending EenVandaag (http://beta.uitzendinggemist.nl/afleveringen/1110370)
tegenwoordig een noodzaak is en procesmatig in en door een organisatie moet zijn belegd. Daarnaast kan het niet zo zijn dat dergelijke incidenten waarbij vertrouwelijke informatie die voor gebruikers van cruciaal belang is, zo lang onder de pet wordt gehouden. Ik ben dan ook een groot voorstander van het instellen van een meldplicht waardoor deze misstanden aangepakt kunnen worden. En dan het CA model. Is dat nog wel van deze tijd? Ook hierop moet ik denk ik negatief antwoorden. Sterker nog het hele model is al vanaf het begin wankel. Laat me dat eens verduidelijken. Het model is erop gebaseerd dat je bij een centrale autoriteit gaat vragen of je een bepaald systeem waar je mee wilt gaan communiceren wel kunt vertrouwen. Je legt jouw vertrouwen dus volledig in handen van een of ander bedrijf dat je verder ook niet kent en gaat er dan maar van uit dat alles wat ze je voorschotelt klopt. Zeg nu zelf, als je dit leest dan voelt dat op zijn minst vreemd. Of zou je dit in het werkelijke leven ook zo doen? Je wilt iets kopen bij een winkel in een onbekende stad en belt even met een voor jouw onbekende organisatie (zeg de KvK in het land waar je je bevindt) om je te vertellen of je het betreffende bedrijf wel kunt vertrouwen.
Op zich lijkt het me dan ook niet verwonderlijk als uit onderzoek is gebleken dat het gehele autorisatiemodel dat in X.509 is ondergebracht een beetje als een afterthought is toegevoegd. Initieel ging het eigenlijk alleen om het beveiligen van de onderlinge communicatie door middel van SSL. Dat het wellicht ook handig zou zijn om na te kunnen gaan dat je ook werkelijk met de juiste andere partij sprak was iets dat daarna pas als een goed idee werd toegevoegd. En zoals elke beveiligingsexpert je zal vertellen: “Goede beveiliging is niet iets dat je nadien aan een product kunt toevoegen.”
Vertrouwen bij de cliënt leggen Hoe zou het dan wel kunnen werken? Allereerst denk ik dat het vertrouwen weer neergelegd moet worden bij de persoon die dat het beste kan beoordelen en dat is de cliënt zelf. Nu kun je daar natuurlijk tegen inbrengen dat de gemiddelde gebruiker toch zal blijven klikken op elke (fout)melding die getoond wordt zonder deze te lezen, zolang de achterliggende pagina maar geladen kan worden, maar ook het huidige model staat dit toe en het betreft hier denk ik ook niet de gebruiker die we willen en moeten beschermen. Er is nu eenmaal geen mogelijkheid om tegen domheid te beschermen.
Een systeem dat nu in bèta is en juist de nadruk legt om het vertrouwen weer terug te leggen bij de gebruiker, en dit proces zodanig inricht dat het naadloos kan aansluiten bij de huidige structuur (dus met gebruik van CA’s), is Convergence (http:// convergence.io/). Door het op de juiste wijze gebruiken van, over het internet verspreide notaries kunnen de browsers die hiervan gebruik maken, van verschillende partijen en via verschillende paden over het internet opgehaalde, certificaten verzamelen en met elkaar vergelijken. Op basis van gebruikersinstellingen kan dan het certificaat vertrouwd worden als dit van een of meer notaries overeenkomt met het certificaat dat vanaf het systeem zelf is verkregen. Pas als dat vertrouwen er is zal de browser een beveiligde verbinding opzetten, waarna de overige communicatie kan plaatsvinden. Naast het feit dat dit systeem een toevoeging is aan het huidige model, zal dit systeem ook werken met zogenaamde selfsigned certificaten. Hierdoor zou uiteindelijk het huidige model waarbij CA’s erg veel macht in handen hebben gekregen geheel of gedeeltelijk kunnen worden afgebroken.
Hans (J.C.G.) Van de Looy Partner, Principal Security Consultant
Madison Gurkha herfst 2011
5
In de Rubriek “De Hack” belichten we in iedere Madison Gurkha Update een opmerkelijke situatie die tijdens een beveiligingsaudit werd aangetroffen. Deze keer vertelt Daniël Dragicevic ˇ ´ over interne netwerken bij open organisaties zoals ziekenhuizen.
de h ack
Interne netwerken bij Hoe veilig zijn mijn patiëntgegevens bij zorginstellingen? Een vraag die als patiënt weleens door mijn hoofd schiet. Zijn mijn gegevens bij deze instelling in goede handen en hoe wordt ermee omgegaan? Een vervolgvraag is: Hoe veilig is de infrastructuur van deze instelling? In verschillende onderzoeken die door Madison Gurkha worden uitgevoerd, zien we een beeld ontstaan van een computernetwerk dat vaak net zo toegankelijk is als de betreffende instelling. Organisatie Wanneer we een zorginstelling zoals een ziekenhuis bekijken, zien we vaak een open en toegankelijke omgeving. Logisch ook, wanneer je kijkt naar de doelstelling van een ziekenhuis: het bieden van medische zorg. Ziekenhuizen worden dan ook gekenmerkt door een goed toegankelijke campus waar weinig tot geen fysieke toegangscontrole plaatsvindt. Naast de goede toegankelijkheid van de campus, is voor medewerkers, artsen en verpleegkundigen een goede en vaak ook snelle toegang tot benodigde informatie essentieel. Wanneer hier te veel technische beperkingen aan worden opgelegd, zien we vaak dat gebruikers met creatieve oplossingen komen om toch snel bij de juiste informatie te komen. In de rol van arts of verpleegkundige zou je zelfs kunnen stellen dat toegankelijkheid van gegevens in bepaalde gevallen belangrijker is dan de vertrouwelijkheid ervan. Vanuit beveiligingsoogpunt brengen deze punten natuurlijk een aantal risico’s met zich mee.
Risico’s De dreigingen waar een ziekenhuis mee te maken krijgt op het gebied van informatiebeveiliging, zijn in essentie niet anders dan bij een commercieel bedrijf. De impact van een aanval kan echter wel groter zijn. Wanneer (patiënt)gegevens worden verloren, gestolen of onbedoeld openbaar worden gemaakt, raakt dit natuurlijk het ziekenhuis. Reputatie- en imagoschade zijn hiervan potentiële gevolgen. Maar wat zijn de potentiële gevolgen voor een patiënt? Dit verschilt van persoon tot persoon. Maar zowel professioneel als privé, kan de openbaring van bepaalde medische gegevens verstrekkende gevolgen hebben. Naast verlies van gegevens, bestaat ook de mogelijkheid dat gegevens door een aanvaller worden gewijzigd. Ook
6
Madison Gurkha herfst 2011
dit kan verstrekkende gevolgen hebben. De mogelijkheid bestaat dat het aanpassen van patiënt- of onderzoeksgegevens kan leiden tot een medische misser, of erger, het verlies van mensenlevens. Beschikbaarheid van gegevens is nog een cruciaal punt. Wat gebeurt er als röntgenfoto’s, resultaten van MRI-scans, en laboratoriumuitslagen niet, of niet tijdig beschikbaar zijn? Kunnen artsen en verpleegkundigen hun werk nog wel goed uitvoeren wanneer dit soort systemen kampen met uitval?
Het onderzoek Een Black Box netwerkonderzoek zoals Madison Gurkha die uitvoert, begint met het maken van een verbinding met het betreffende netwerk. Vaak zien we dat zorginstellingen geen gebruik maken van toegangscontrole tot het netwerk. Gevolg hiervan is dat iedere computer verbonden kan worden met het netwerk. Wanneer op een netwerk toegangscontrole plaatsvindt, wordt hier direct een eerste barrière opgeworpen voor een aanvaller. De aanvaller zal aanzienlijk meer moeite moeten doen om een verbinding tot stand te brengen. Wanneer we een IP-adres hebben ontvangen, kunnen we met behulp van diverse scantechnieken zoeken naar benaderbare systemen. Ook onderzoeken we hiermee welke software er op een systeem aanwezig is en welke diensten door het systeem worden aangeboden. Uit dit soort scans blijkt vaak dat deze netwerken niet of nauwelijks zijn gesegmenteerd. Dit wil zeggen dat cruciale systemen bereikbaar zijn vanuit alle ‘hoeken’ van het netwerk. Er wordt geen beperking opgelegd Ook zien we dat het beheer van deze systemen niet op een apart netwerksegment plaatsvindt. Daarnaast komen we vaak een groot aantal onversleutelde diensten tegen. Diensten als HTTP, (T)FTP en Telnet worden op interne netwerken nog veelvuldig gebruikt.
de h ack
j open organisaties
wordt aangegeven dat de opstelling enkel met bijvoorbeeld Windows 2000 wordt ondersteund. Wanneer hier wijzigingen in worden aangebracht, werkt de opstelling niet, is het systeem niet meer gecertificeerd of wordt er geen ondersteuning meer op verleend. Dit soort systemen bevatten hierdoor vaak ernstige kwetsbaarheden.
Maatregelen De vraag is nu, welke maatregelen kunnen worden genomen om het netwerk veiliger te maken, zonder de gebruikers hiermee extra te belasten? Op infrastructureel vlak zijn een aantal stappen te zetten.
Deze combinatie van factoren maakt het voor een aanvaller mogelijk om zowel gegevens van artsen en verpleegkundigen als van beheerders en andere medewerkers af te luisteren. Wanneer we kijken naar gebruikte software, zien we vaak dat specifieke systemen zoals controlesystemen voor laboratoriumapparatuur of voor medische scanners vaak niet up to date (kunnen) worden gehouden. Dit zijn vaak gecertificeerde systemen waarbij door de leverancier
• Richt toegangscontrole in zodat alleen bekende systemen toegang kunnen krijgen tot kritieke delen van het netwerk; • Bekijk daarnaast of het systeembeheer vanaf een apart netwerksegment kan worden uitgevoerd; • Zorg ervoor dat zoveel mogelijk veilige (versleutelde) diensten worden gebruikt; • Zorg voor maatregelen die kwaadaardig verkeer kunnen detecteren en/of blokkeren; • Identificeer kritieke systemen en bijbehorende communicatiepatronen; • Segmenteer het netwerk op basis van deze communicatiepatronen en zorg ervoor dat enkel systemen die met elkaar horen te communiceren, dat ook kunnen; • Weet wat er op je netwerk speelt en geef extra aandacht aan de genoemde legacy systemen; • Spreek leveranciers aan op de geleverde producten en zorg samen met hen voor een veiligere en robuuste standaarden. Deze technische maatregelen vereisen een gedegen onderzoek vooraf, maar verhogen de veiligheid van het netwerk aanzienlijk. Ook kunnen deze maatregelen worden ingevoerd zonder de gebruikers teveel te belemmeren in het uitvoeren van hun werk. Want daar gaat het uiteindelijk om. Het bieden van zorg.
Madison Gurkha herfst 2011
7
In de rubriek “Het Inzicht” stellen wij bepaalde (technische) beveiligingsproblemen aan de orde. Deze keer geeft Tim Hemel uitleg over het nut van Secure Software Development.
het Inzicht
Secure Software Development Beveiliging kan in alle fases van het softwareengineering traject ingebouwd worden. Niet alleen biedt het een goed vangnet voor beveiligingsfouten, het geeft de bouwers ook meer controle en feedback over
Softwarebouwers zijn
de beveiliging. In sommige
immers ook maar mensen
gevallen wordt het bouwen zelfs leuker.
Als programmeur ben ik een creatief persoon, dat wil zeggen, het maken van dingen geeft mij plezier. Het liefst krijg ik mijn programma’s zo snel mogelijk werkend, zodat ze doen wat ze moeten doen en ik verder kan gaan met het volgende programma. Voordat ik bij Madison Gurkha kwam werken was ik heel gelukkig met deze leefwijze. In de loop der jaren ben ik een illusie armer en een stuk minder optimistisch. Ik herken mijn vroegere naïeve optimisme in veel applicaties die wij onderzoeken en voel me haast schuldig als ik in een rapport de ontwikkelaars moet
8
Madison Gurkha herfst 2011
teleurstellen. Ik kan me helemaal voorstellen dat het denken aan wat er allemaal mis kan gaan, de aandacht afleidt van het ontwikkelen zelf. En dat is vrij logisch: van slecht nieuws kunnen we behoorlijk moedeloos worden en geen zin meer hebben in het bouwen. De makkelijkste manier om hiermee om te gaan is dan ook om het slechte nieuws te negeren (dat komt later wel). Om deze neiging tegen te gaan is het belangrijk dat we het veilig ontwikkelen van software op één of andere manier in het soft-
ware-ontwikkelproces inbouwen, zodat we een aantal vangnetten hebben die ons eraan herinneren waarom beveiliging belangrijk is. Madison Gurkha raakt vaak pas betrokken bij een ontwikkeltraject als er een beveiligingsonderzoek moet worden gedaan. Soms is dit aan het begin van een traject, bij het bekijken van een ontwerp, maar meestal wordt onze hulp ingeroepen als een applicatie zo goed als af is. Tussen die twee momenten bestaan echter nog veel meer gelegenheden om aandacht te besteden aan de beveiliging van software.
het Inzicht
credentials
Gebruiker
In het bouwen van software zijn, onafhankelijk van de ontwikkelmethodologie die wordt gebruikt, een aantal fases te onderscheiden: 1 Verzamelen van requirements; 2 Maken van een ontwerp of architectuur; 3 Bedenken van tests; 4 Implementeren van de software; 5 Uitvoeren van tests; 6 Onderhoud (verwerken van feedback). In ieder van deze fases is het mogelijk om beveiliging te integreren.
1
Verzamelen van requirements Tijdens het verzamelen van requirements kunnen ook security requirements worden vastgelegd. Dit gebeurt op basis van een risico-analyse. We zien in de praktijk vaak dat deze requirements niet erg specifiek zijn. De technische kennis van beveiligingsrisico’s ontbreekt vaak bij de bedenkers van de requirements. Het gevolg is onduidelijkheid voor de softwarebouwers, waardoor belangrijke aspecten over het hoofd worden gezien. Een ander probleem van security requirements is dat deze alleen maar in de ontkennende vorm kunnen worden geformuleerd, we noemen dit antirequirements. Een voorbeeld is ‘ongeautoriseerde objecten zijn niet zichtbaar voor de gebruiker’. Met een dergelijke requirement dient in de hele applicatie rekening te worden gehouden. Een manier om de security requirements vast te leggen is door het schrijven van use cases die specifiek op misbruik van de software zijn gericht, de zogenaamde abuse cases. Wij merken hierbij altijd dat een verse blik en een kritische ‘hacker-mindset’ hier van grote waarde zijn.
2
Maken van een ontwerp of architectuur Op basis van de risico-analyse en de use cases kan een specifiekere risico-analyse worden gedaan tijdens de ontwerpfase. Door te kijken naar de datastromen in de applicatie kan worden besloten op welke punten beveiligingscontroles moeten worden geïmplementeerd. Een plaatje kan hierbij helpen, zoals een Data Flow Diagram (zie afbeelding). Bij ingewikkeldere systemen gebruiken wij zelf ook een DFD om aanvalsscenario’s te bedenken als we een applicatie onderzoeken. Het maken van zo’n analyse in de beginfase van de ontwikkeling kan al veel
session token
5
operations responses
authenticate user Klantapplicatie user info
session token
SSOserver LDAP server get user info
Met een Data Flow Diagram wordt zichtbaar waar de beveiliging moet worden geïmplementeerd.
beveiligingsproblemen voorkomen, omdat het de ontwerpers dwingt te kijken naar de beveiliging.  Bedenken van tests Met de abuse cases kunnen vervolgens tests worden gedefinieerd, die specifieke scenario’s testen. Hier is het belangrijk de dekking van de tests zo groot mogelijk te krijgen, vooral bij de scenario’s die anti-requirements testen.
3
4
Implementeren van de software De fase van de implementatie is uitermate belangrijk. De code is immers de plaats waarin alle beveiligingseisen tot uitdrukking komen. Een coding standard gericht op beveiliging en een corresponderende code review kunnen al veel implementatiefouten detecteren. Uiteraard moet binnen het ontwikkelteam enige kennis aanwezig zijn van secure programming, al is het maar in de vorm van een enkele expert.
Wij merken dat een verse blik en een kritische ‘hackermindset’ van grote waarde zijn
Uitvoeren van tests Testen die gericht zijn op beveiliging zijn wel bekend voor de klanten van Madison Gurkha. Zelfs als de eerder genoemde praktijken worden uitgevoerd, blijkt een onafhankelijk onderzoek door experts nuttig te zijn. De reden hiervoor is simpelweg dat softwarebouwers (het zijn immers ook maar mensen) zaken over het hoofd zien. Maar een extern beveiligingsonderzoek is niet de enige soort test. Geautomatiseerde fuzzing tests, waarbij de applicatie willekeurige invoer te verwerken krijgt, blijken verrassend vaak beveiligingsproblemen bloot te leggen.
6
Onderhoud (verwerken van feedback) Software-onderhoud bestaat uit het aanpassen van de applicatie op basis van ervaringen uit de praktijk. Beveiligingservaringen kunnen hier natuurlijk in worden meegenomen. Als blijkt dat bijvoorbeeld veel wachtwoorden makkelijk te raden zijn, kan gekozen worden voor een andere authenticatiemethode. Het is niet voor niks dat secure software development de laatste jaren steeds meer aandacht krijgt van beveiligingsexperts. Zo zien we meer boeken over dit onderwerp, wordt er actief gewerkt aan de OWASP Development Guide en brengt ook Microsoft hun Security Development Lifecycle onder de aandacht. Toch is deze aandacht nog onvoldoende. Vaak worden wij relatief laat in het proces betrokken en is er binnen projecten onvoldoende technisch inhoudelijke IT securitykennis voorhanden om IT security in het proces verankeren. We hebben dan ook besloten de bestaande Secure Programming training breder aan te bieden. Naast de in-company variant, biedt Madison Gurkha vanaf heden in samenwerking met AT computing een klassikale versie. Met de kennis die wordt opgedaan in deze training kunnen veel organisaties in de praktijk brengen wat ik in dit artikel beschrijf. Wellicht kunnen we daar eens van gedachten wisselen over dit onderwerp?
Voor meer informatie over de klassikale training zie: http://www.atcomputing.nl.
Madison Gurkha herfst 2011
9
Madison Gurkha interviewt voor iedere editie een gerenommeerd persoon in de IT-beveiligingswereld. Ditmaal een Engelstalig interview met de Zuid-Afrikaanse Andrew MacPherson (wellicht bij u nog bekend van de Black Hat Sessions Part X “The Human Factor) van Paterva.
het interview
Andrew MacPherson Could you summarize who you are and what you do? My name is Andrew MacPherson and I am the lead developer and chief tea maker at Paterva. I develop transforms for Maltego with Roelof Temmingh and together we handle a lot of the Maltego related work. Who uses Maltego? Maltego is used by law enforcement, pentesters, private investigators and individuals interested in looking at what kind of digital footprint they leave on the Internet. How/where does Maltego collect it’s data? Maltego uses open sources of information to collect data from services like DNS, PGP, Websites and anything else that we can find to get information out in an automated manner. It’s important to understand Maltego as more than a tool that simply collects data. Whilst Maltego does do this, its primary function is to show relationships and allow the analyst to gain intelligence from information collected. For example, if you were looking at a website which hosted a phishing application, Maltego can easily take this website to an IP address, take the addresses found and then identify other websites that are hosted on the same machine. You can then identify other links to these websites to gain more information on your original target. Should we be concerned that governments/agencies can use Maltego to gather information about individuals? I think this question is very difficult to answer and is all dependant on the use of the information. If the government can collect dangerous information on an individual, such that they can use it as leverage against the individual, he or she should also be concerned that other people can also do this. Additionally its also important to know that whilst Maltego does have many sources to find information, a skilled individual/group can also do it by hand. There are no ‘secret’ paths that Maltego uses to discover information. Often it is not only the information that is critical but how it relates to other information, especially in 2nd, 3rd and further orders away from the original data. However with that being said I think there should be a fair amount of concern and governments gathering information on individuals with Maltego or any other application/method. It is very important for individuals to know what they are putting into public space on the internet and how it can be used against them.
developers busy for the next few years without having to worry about competitors. How can people prevent personal information showing up in the results? This is probably one of the most difficult questions to answer and it’s a very difficult problem to solve. Ensuring your information is not on the net (if at all possible) on one hand means you are open to being impersonated by anyone. If you don’t have a Facebook profile for yourself or it is so locked down no one can find it then anyone else can make a competing open profile and start attracting your friends. On the other hand having too much information publicly available means that you are open to social engineering attacks. I think a middle ground is probably the best, whereby you identify what information can be found about you and limit it down to as small a subset as possible that still allows you to be functional on the internet but doesn’t open you too much to impersonation or social engineering. What are the plans for the future with Maltego? As I said before we have an absolutely massive list of new features we want in Maltego. And although I sadly cannot give away too much here, we are currently in two development branches, the 3.x series and the 4.x series. The 4 series (still early alpha) is what we think will be another “game changer” in open source intelligence and information gathering. The 3.x series is the current series of releases which we are constantly improving to provide further integration and meeting what our clients are looking for. We are also looking at integrating with more resources for gathering data and have 50 new transforms that were released at the upcoming conference (44con) in London. Voor meer informatie over het tool Maltego kunt U terecht op http://maltego.blogspot.com en http://www.paterva.com
Do you know if other companies/institutions developed alternatives to Maltego? We do know of a few other companies that offer alternatives to Maltego however we have enough features to keep Paterva
10
Madison Gurkha herfst 2011
Deze keer doet Jordy Kersten verslag van de jaarlijkse IT security conferentie Hack in The Box in het Grand Krasnapolsky hotel te Amsterdam. Jordy heeft hier als vrijwilliger meegeholpen met de voorbereidingen van de “Capture The Flag” wedstrijd.
Het
versl ag
Hack in The Box Hack in The Box is een jaarlijkse IT security conferentie dat volledig in het teken staat van hacking. Het wordt georganiseerd op een non-profit basis door hackers, voor hackers. De conferentie is enkele jaren geleden ontstaan in Kuala Lumpur (Maleisië), waar deze nog steeds jaarlijks gehouden wordt. Sinds enkele jaren wordt het evenement ook in andere landen georganiseerd, waaronder Nederland.
SpyEye trojan applicatie De Lezingen omvatten uiteenlopende onderwerpen in meerdere parallelle tracks. Daarnaast is er ook een technische track waarin demo’s gegeven worden waarbij onder andere tutorials gegeven worden voor het verkrijgen van een command prompt op android apparaten, worden malicious PDF bestanden geanalyseerd en wordt de broncode van de onder cybercriminelen populaire SpyEye trojan applicatie onderzocht. Dit jaar heb ik in plaats van het evenement te bezoeken, besloten mezelf aan te melden als vrijwilliger om zo de andere kant van een dergelijk evenement te bekijken. Uiteindelijk heb ik de verantwoordelijkheid genomen om een gedeelte van de Capture The Flag wedstrijd voor te bereiden.
Capture The Flag In een Capture The Flag wedstrijd nemen hackers het tegen elkaar op door het oplossen van verschillende opdrachten. Aan de hand van een voorselectie in de vorm van verschillende zogenaamde “binary challenges” worden de beste hackers geselecteerd. Het is mogelijk om individueel deel te nemen aan de wedstrijd of in teamver-
band. De winnaar krijgt vrijkaarten voor de volgende Hack in The Box te Amsterdam, waar deze de gelegenheid krijgt om zijn titel te verdedigen. Voordat het zover is moeten er punten gescoord worden door het oplossen van verschillende opdrachten.
Minder technische opdrachten De opdrachten voor de Capture The Flag bestaan onder andere uit het oplossen van beveiligingsfouten in programmeercode, het openbreken van sloten door middel van lockpicking en natuurlijk het “echte” hacken. Hieronder verstaan we het verkrijgen van systeemrechten op verschillende systemen door het exploiteren van zwakheden in aanwezige software of het besturingssysteem zelf. Ook zijn er enkele minder technische opdrachten aanwezig zoals een quiz met algemene kennisvragen en het extraheren van een tekst uit een plaatje door middel van steganografie. Uiteindelijk heb ik een aantal kwetsbare systemen ingericht waar door middel van verschillende hacks toegang tot verkregen kan worden. Nadat er toegang is verkregen, is het einddoel om systeembeheerderrechten te verkrijgen. Hier zal de hacker een hash code vinden
waar het desbetreffende team punten voor krijgt. Tijdens de wedstrijd worden de teams in real-time up to date gehouden van de huidige puntenstand. Dit gebeurd op een groot videoscherm dat in het midden van de zaal aanwezig is.
Geen gebruikelijke conferentie Ondanks dat dit de eerste keer is geweest dat ik een meerdaagse conferentie heb bezocht kan ik na vier (erg lange) dagen concluderen dat Hack in The Box geen gebruikelijke conferentie is. In tegenstelling tot veel andere IT-beveiliging conferenties blijkt uit de sfeer dat de insteek van Hack in The Box voornamelijk ligt in het ontmoeten van IT-beveiligingsenthousiastelingen en natuurlijk het delen van kennis. De conferentie onderscheid zich met name door de verschillende wedstrijden en workshops waardoor er interactie plaatsvindt met de bezoeker. Mede door dit aspect maakt een bezoek aan Hack in The Box een unieke ervaring. Ondanks dat dit pas de tweede keer is geweest dat het evenement in Nederland heeft plaatsgevonden zijn de plannen voor volgend jaar al bekend: Hack in The Box zal in 2012 wederom naar Nederland komen!
Madison Gurkha herfst 2011
11
Safe?
Goede IT-beveiliging is niet zo eenvoudig als vaak wordt beweerd. Bovendien blijkt keer op keer dat deze beveiliging van strategisch belang is voor organisaties. Alle IT-beveiligingsrisico's moeten op een acceptabel niveau worden gebracht en gehouden. Professionele en gespecialiseerde hulp is hierbij onmisbaar. Kies voor kwaliteit. Kies voor de specialisten van Madison Gurkha.
Your Security is Our Business
tel: +31(0)40 237 79 90 - www.madison-gurkha.com -
[email protected]
