debug=1. Een onschuldig uitziend statement, zo zou je denken. Maar in mei 2009 had het een heel wat minder onschuldig effect als het werd toegevoegd aan de URL van de vacaturesite Juristenbank.nl: er werden dan telkens maximaal 10 kandidaten, dan wel werkgevers, in willekeurige volgorde volledig onomkeerbaar verwijderd. Dat bleek een logisch bommetje van een gefrustreerde werknemer te zijn. De vraag voor het Gerechtshof Arnhem: was hierbij sprake van computervredebreuk, oftewel binnendringen op de webserver?
De verdachte was ICT-medewerker bij een bedrijf dat geavanceerde webapplicaties maakte ten behoeve van arbeidsmarktcommunicatie. Daarbij had hij een tool ontwikkeld, zo te lezen een library met handige standaardfuncties. De geweldige neutrale formulering “Een verslechterde werkrelatie lag aan het einde van het dienstverband ten grondslag” uit het arrest doet al nattigheid vermoeden, en inderdaad: na het vertrek van deze meneer bleken diverse records van werkzoekende juristen verdwenen te zijn.
Dit bleek terug te traceren tot websiteaanroepen waarvan de URL was voorzien van “debug=1” (en soms “debug=2”), die code triggerde die het feitelijk weggooiwerk verrichte. Die code bleek geïmplementeerd met precies de tool van de werknemer met de ‘verslechterde werkrelatie’, plus de aanroepen waren vanaf zijn IP-adres gedaan. Reden dus om meneer op het politiebureau uit te nodigen, en daar vertelde hij dat hij inderdaad (“het kan zijn dat”) deze code had toegevoegd. Wat zijn verklaring daarvoor was, blijkt niet uit het arrest. Maar hij ontkende ten stelligste de destructieve code te hebben aangeroepen na zijn dienstverband. Iemand had zijn IP-adres gespooft om hem in de problemen te brengen.
Het Hof acht dat verweer “op geen enkele wijze aannemelijk”. Alleen de verdachte kende die code, en hij was de IT-guru bij het bedrijf. De code in kwestie was in productie genomen op zijn laatste werkdag, én de arbeidsovereenkomst was vanwege een verslechterde arbeidsrelatie beëindigd. Het is dan nauwelijks voorstelbaar dat een derde hiervan heeft kunnen profiteren, en dan ook nog binnen een dag nadat de code was ingecheckt in productie én vanaf het IP-adres uit de woning van de verdachte. (Het kan, maar dan komen we in serieus aluhoedjesland.) Ook speelde mee dat een specialist bij het Team Digitale Expertise had verklaard dat het na sporenanalyse
zeer veel minder waarschijnlijk dat een computer waaraan het IP adres [nummer IP adres]niet is toegewezen de sporen in de logbestanden heeft veroorzaakt dan dat de computer waaraan het IP adres [nummer IP adres] wél was toegewezen dit heeft veroorzaakt.
Deze vorm van misbruik van de website levert volgens het Hof computervredebreuk op. Er is binnengedrongen in de server dus. Oftewel, het aanroepen van een URL die niet geautoriseerd is, is binnendringen in de webserver? Een tikkeltje eng als conclusie. Ik ben geen fan van dingen strafbaar verklaren enkel en alleen omdat ze ongeautoriseerd zijn. Er moet meer zijn dan alleen “u mocht dit niet intypen” (en eigenlijk vind ik dat een adequate beveiliging een harde eis moet zijn, maar goed) voordat je de intyper strafrechtelijk gaat vervolgen.
Natuurlijk, er is data vernield, maar daar hebben we een apart wetsartikel voor: het opzettelijk en wederrechtelijk veranderen, wissen, onbruikbaar of ontoegankelijk maken van gegevens die door middel van een geautomatiseerd werk of door middel van telecommunicatie zijn opgeslagen, worden verwerkt of overgedragen, (art. 350a Strafrecht). Om dat feit te plegen, hoef je niet binnen te dringen in een computersysteem. Dit wordt subsidiair ook bewezen geacht, daar niet van.
Misschien was de achterliggende gedachte dat niet slechts de URL het binnendringen opleverde, maar de URL plus de kwade code in de webserver. Daarmee werd toegang verkregen tot de database, een plek waar een ex-werknemer (of willekeurige derde) absoluut niet hoorde te zijn. De debug-instructie was dan slechts de trigger om het binnendringen te starten. Net zoiets als een kopietje van de sleutel van de achterdeur van het bedrijfspand maken en dan daarmee naar binnen gaan.
Iemand tips om dit soort ongein tegen te houden? Wat doe je tegen een IT-er die op zijn laatste dag een logisch bommetje achterlaat?
Arnoud
“Wat doe je tegen een IT-er die op zijn laatste dag een logisch bommetje achterlaat?”
Misschien moet je gewoon gezond verstand gebruiken? En ale code uit de laatste dagen van iemand die met ruzie weggaat even in quarrantaine houden en goed laten bekijken door een andere programmeur?
Overigens het zou de eerste niet zijn die dergelijke fratsen niet op zijn laatste dag maar al veel eerder in een project al in het systeem stopt.
Doet me denken aan de The Daily WTF reeks over “Disgruntled Bombs”: http://thedailywtf.com/Articles/The-Disgruntled-Bomb.aspx (of http://thedailywtf.com/Articles/Disgruntled-Bomb-Java-Edition.aspx).
De kwetsbaarheid is hier oa dat meneer de guru was. Dat brengt heel veel risico’s met zich mee. Niet alleen dit, code toevoegen zonder review, maar ook wat te doen bij uitval van deze persoon. Probleem is dat de risico beheersing (veel) geld kost voor een wat kleiner bedrijf. Externe code review, (deels) extern netwerk beheer zodat er een overlap bestaat en je op voorhand weet of de code te lezen is en of het netwerk over te nemen is door een ander.
Overigens dom om het zo te doen. Dit valt gelijk op in de weblogs. Wil je dan gepakt worden?
Van een HR-man hoorde ik ooit de quote “Onmisbare mensen moet je meteen ontslaan.” Want ja, je hebt een gigantisch probleem als die persoon ziek wordt, onder de tram komt of boos weggaat.
En je opmerking over ‘dom om het zo te doen’ in combinatie met de “Disgruntled bomb” hierboven triggerde me: hoe zou je wél met een URL-aanroep een logische bom in de webserver kunnen triggeren?
Misschien een POST naar het contactformulier met een speciaal gekozen afzendernaam? POST-data wordt zelden gelogd.
Mooie uitspraak van die HR man. Zelf werk in in kwaliteitsborging en een van mijn standaard vragen aan mensen in een spilpositie is “Wart gebeurt er als jij morgen onder de tram komt?” Het kan acceptabel zijn als er maar een man/vrouw/mens is die alles weet maar dan moet die wel heul goed documenteren zodat een ander het op zijn minst ook kan vinden. een beetje vertraging is dan onvermijdelijk maar dat is meestal wel te overleven
Deze dader heeft duidelijk niet nagedacht over opsporing. Hij heeft zelf de code in gebruik genomen en dan via zijn eigen IP getriggered. Niet eens een proxy gebruiken, een internet café, een open access point. Bij een dergelijke incompetentie als aanvaller is een code review door een competente programmeur een goede manier om het te vangen (maar waarschijnlijk vonden ze dat te duur bij de oorspronkelijke werkgever, als die dader de enige programmeur is en overdracht niet geregeld was). Gewoon netjes uit elkaar gaan was natuurlijk veel goedkoper en betrouwbaarder.
Je kunt makkelijk derde partijen zo ver krijgen dat ze het voor je doen: een link ergens zetten en dan de search-engines hem laten indexeren (“Google hackt me”), als een image/script url in een email (bonus: kun je iemand anders gericht verdacht maken) of webpagina (referrer gaat je daar wel snel verklappen) en er zijn zat proxy-services die effectief ontraceerbaar zijn (TOR, anonymizer, etc).
(Hmmm ik mag geen GET voorbeeld gebruiken in de text want dan zou ik PHP kunnen hacken van je hoster Arnoud…)
“Wat doe je tegen een IT-er die op zijn laatste dag een logisch bommetje achterlaat?”
Die stuur je met betaald verlof tot zijn laatste werkdag is aangebroken. Of je controleert extra goed wat hij schrijft. En if ($debug) executeQuery(‘delete * from users limit 10’); moet wel erg opvallen, ook bij niet-guru’s.
Even tussendoor: diverse mensen mailden me dat ze hun comments niet geplaatst krijgen omdat mijn provider (bHosted) de URL kwaadaardig vindt. Dat klopt en ik heb daar geen invloed op. Vermijd dus a.u.b. concrete GET- en POST-voorbeelden alsmede Javascript-statements.
@Arnoud Heel eenvoudig, ergens in je code een “fout” maken. Ipv met params je query bouwen ergens een stukje “oude” code waar je door middel van string concat je sql bouwt. Dan kun je ergens op een form in veld x een sql-injection doen. In de weblogs zie je alleen dat contactform.php/aspx/whatever is geopend. Maar ondertussen staat er ‘; delete some stuff — in de query en worden er records gewist. Niet teveel tegelijk en langzaam wachten tot ze gek worden.
En inderdaad vanaf een proxy doen of via tor.
Dan moet er al heel veel logging etc aan staan om dat te ontdekken (maar ja wie had dat ook alweer ingeregeld)
Dit soort problemen hou je alleen tegen als je een team programmeurs aan het werk zet, en deze elkaars werk ook moeten evalueren. Dus Jantje schrijft een stuk code en voordat deze wordt opgeleverd kijkt Pietje deze nog even na en stelt eventuele verbeterpunten voor. Dit komt de kwaliteit van de code ten goede en kan voorkomen dat een enkele werknemer kwaadaardige code toevoegt. Het nadeel is dat je dan veel minder werk kunt laten doen dan wenselijk is! Projecten duren dan veel langer dan wanneer iedere programmeur alleen zijn eigen werk hoeft te doen. De kwaliteit is misschien iets minder maar als een mindere oplossing gewoon werkt is er niets aan de hand. Grote bedrijven kunnen dit wel betalen maar kleine software-bedrijfjes die voor grote bedrijven porjecten ontwikkelen hebben meestal niet de financiele middelen om meerdere programmeurs op hetzelfde project te laten werken. Immers, ze moeten een scherpe offerte kunnen bieden en de extra controle maken de kosten alleen maar hoger zodat de concurrent een scherpere offerte kan bieden!
Het gebruik van open-source code kan uitkomst bieden. Je zou je project openbaar kunnen maken als open-source en er enige aandacht aan geven. Die enkele programmeur kan dan wel gaan knoeien maar waarschijnlijk dat iemand in de open-source gemeenschap meekijkt en meteen een waarschuwing geeft over dergelijke sabotage. Je hebt dan “medewerkers” die “gratis” meewerken. Nadeel is dan weer dat je project dus open en bloot beschikbaar is voor de gehele wereld en of de opdrachtgever dat op prijs stelt? Maar goed, stel je bent een internet-advocaat en je hebt een medewerker die voor jou een speciale blogsite schrijft. Delen ervan gebaseerd op een open-source project en andere delen gewoon nieuwe code om de site beter aan te sluiten bij de wensen van de gebruikers. Omdat de basis open-source is kun je dus vanuit de open-source gemeenschap meldingen krijgen indien er problemen zijn in de code. Als je daarnaast de overige code die zelf is ontwikkelt openbaar maakt zodat de open-source gemeenschap dit in kan kijken dan kun je daar ook waarschuwingen over krijgen als er iets in mis is! En dat kunnen gewoon domme programmeerfoutjes zijn maar ook dergelijke bommen die een kwade ex-medewerker kan afvuren…
@Wim (10) en zelfs daar kan het fout gaan. http://www.zdnet.com/blog/security/open-source-proftpd-hacked-backdoor-planted-in-source-code/7787 http://www.h-online.com/open/news/item/Backdoor-in-popular-WordPress-plug-ins-1265289.html
Of toch geen backdoor (maar wel bugs)
http://arstechnica.com/open-source/news/2010/12/openbsd-code-audit-uncovers-bugs-but-no-evidence-of-backdoor.ars
Er zijn zelfs wedstrijden 🙂 https://backdoorhiding.appspot.com/
@Wim(11) in mijn geval(9) heb je alleen “slechte” code (en gezien het Lulz suc6 nog zeer veel in gebruik). Valt niet / minder op.
En als ze het goed doen zullen ze de site eerst veilig stellen voordat ze hem gaan aanpassen/publishen (bv door een snapshot van de virtual machine te maken) dus bewijs blijft, deels, bestaan
IS dit heel toevallig niet gerelateerd aan het item over expert-ict-rechters van eenvandaag van gisteren? Daar zat ook een man, en die zou heel goed deze persoon kunnen zijn…
Dat denk ik wel Mark. Die meneer schrijft op De rechter zit fout en daar wordt verwezen naar een arrest in hoger beroep van 10 juni 2011. Ik kan zijn relaas echter volstrekt niet rijmen met wat ik in het arrest teruglees. Dat het Team Digitale Expertise komt opdraven spreekt toch “bij de rechter ICT-kennis ontbreekt” tegen.
@Arnoud is het een optie dat die op een pastebin (bijv. yourpaste.net) gezet wordt en daar naar gelinkt wordt? Dat is misschien wel mogelijk. Overigens (maar dat terzijde) vind ik het niet aan de hoster om te bepalen wat iemand op zijn blog zet (of als commentaar op zijn blog toestaat).
Code Review is de enige oplossing; niet om dit soort achterdeurtjes te vangen, maar vooral om de kwaliteit van de software in de gaten te houden.
@16 apart verhaal, op die website. Aan de ene zijde claimt meneer 70.000 euro schade te hebben geleden, aan de andere kant had hij geen geld voor een advocaat (kan dat trouwens, in NL?). Het relaas gaat alleen over procedurefouten maar meneer claimt geen onschuld. Hij geeft zelfs toe dat hij de “debug” code in de site had aangebracht (maar zegt dat die er al vanaf het begin in zat). Ik vraag me af hoe zulke code een doel kan dienen anders dan te kwader trouw.
@Franc (12) Klopt wel, maar de kans is groter dat backdoors en bugs worden ontdekt. Zeker in open-source, zolang er maar genoeg ervaren programmeurs naar de code kijken. Dat maakt het dus een stuk lastiger om backdoors in code op te nemen. Niet onmogelijk, maar wel riskanter…
@Franc (14) Jij hebt slechte code, ik heb geen code. 🙂 Immers, het kwade bronbestand heb ik verwijderd en in plaats daarvan ziet het bedrijf alleen de onschuldige kopie. De kwaadaardige code is wel meegecompileerd omdat ik de binaries maar om te zien wat ik deed moet je die reverse engineren. En zoals ik al aangaf, als er een nieuwe build wordt gemaakt en in productie wordt genomen dan is het laatste bewijs van die kwaadaardige code al helemaal verdwenen. Ik kan dan die bom niet meer gebruiken maar tot het moment van die nieuwe build heb ik dus wel genoeg schade kunnen aanrichten die niet naar mij is te traceren… Okay, als ze de backups erbij halen en gaan reverse engineren. Maar waarom zou men dat doen als men gewoon de broncode heeft? Dan moet je als bedrijf echt een aluhoedje op hebben. Dan moet je echt aanwijzingen hebben dat er kwaadaardige code aanwezig was. En zelfs als je in de binaries de kwaadaardige code terugziet heb je nog steeds het probleem om dit terug te koppelen aan de programmeur.
Paf, en toen was die website weg !
Wat ik in de stukken tot dusver heb gelezen komt het verweer van deze meneer neer op “waarom zou ik dit doen” “ik zou toch wel mijn IP adres kunnen verbergen” en “het is heel makkelijk om mijn IP adres aan te nemen”. Dit terwijl hij nota bene op basis van een firewall rule met zijn IP adres toegang kon krijgen tot het netwerk!
Toevallig ook vandaag gelezen: soort gelijke kwestie waarbij informatie over gebruikers doorgestuurd werd naar een onbekend adres. http://www.techcentral.co.za/in-defence-of-open-source/24105/
Wat nl-x al schrijft: Dit soort mensen stuur je met betaald verlof zodra duidelijk is dat er geen toekomst meer voor hem is bij de onderneming. Meelopen naar het bureau, alles inpakken en naar huis. De kans is te groot dat iemand in een emotionele opwelling enorme schade aanricht.
@Wim. Ik kan dezelfde truuk ook uithalen met mijn slechte sql injectable code. In jouw geval is er of meer fout (geen backup van sources) of heb jij een probleem als je even vergeet je truuk weg te halen dan staat jouw code in een backup. En stel dat ze middels een inval je machine pakken dan ben je ook de bok.
Ik heb altijd plausable deniablility “Maar meneer de rechter, dat form heb ik in de haast door mijn slechte baas die mij altijd aan hte pesten was niet netjes geschreven maar het werkte toch ja doh! sql injection even niet aan gedacht moets snel stress etc etc” 🙂 In mijn geval is er nergens code die dingen verwijderd, die bestaat eenmalig in de SQLinject.
Tenzij ze natuurlijk al het verkeer gaan loggen met wireshark 😉 Maar ja dan zit ik via een proxy via tor via een wifi verborgen in de vuilnisbak bij de mcD 😀
Ik had deze knakker ook gisteren na het item op TV opgezocht en de initiele stukken gelezen.
Het ging op TV over rechters die onvoldoende kennis hadden van ICT en dit mannetje werd daarbij als voorbeeld gebruikt maar de rechter die hem veroordeeld heeft had het volgens mij wel helemaal goed.
Zijn verweer was in feite dat het bedrijf ( en de externe medewerker die ze haddeen ingehuurd) informatie had vervalst om hem erin te luizen en onterecht veroordeeld te krijgen.
Totaal wereldvreemd beeld over hoe rechtspraak werkt ook. Vond dus ook alle bewijzen afkomstig van het bedrijf dat hij had benadeeld niet geldig zouden mogen zijn en omdat de rechter geen verkeersgegevens had opgevraagd hij niet veroordeeld had mogen worden.
Je ziet dat wel vaker bij ICT’er in disccusies op het internet. Zij hebben vreemde ideeen over bewijzen en rechterlijke beslissingen.
@Richard 21 : Kwestie van in Google de URL intikken en op cache clicken 😉
Op zich had hij daar wel een punt, zijn argument dat zijn IP adres was vervalst in de logbestanden had weerlegd kunnen worden met de verkeersgegevens. En daarmee zou een belangrijk punt van de discussie zijn opgelost. En er had bv ook naar de User-Agent string van zijn browser gekeken kunnen worden of die matchede (de HTTP log was vrij verbose).
Maar het is een raar verhaal. – dat hij geen advocaat had want hij had de zaak onderschat. Blijkbaar had hij ook bij het hoger beroep van het OM nog niet door dat dit serieus was ?
Zinnen als “Het is inderdaad (helaas) correct dat deze melding niet naar u is doorgezet door de helpdesk. Desalniettemin ben ik van mening dat er contructievere manieren zijn om om een reactie van onze servicedesk te vragen dan het openen van grote hoeveelheden tickets”
“Ik ben bereikbaar via 06 xxxx xxxx maar vanzelfsprekend neem ik dubieuze afzenders zonder caller-id niet op (zijn op mijn telefoon geblokkeerd) (…) Aub liefst geen reactie per control panel; want er is natuurlijk geen mens dat dat de hele dag open heeft staan,??? vooal niet omdat het irritant genoeg steeds vraagt opnieuw in te loggen want echt teveel gevraagd is “
uit mailwisseling met WideXS geven een mooi beeld van de persoonlijkheid van deze meneer.
@Sjoerd, jaja ik weet hoe Google werkt. En ik had de website zelf al grotendeels bekeken. Maar desalniettemin vond ik het vermeldenswaardig dat de website nu weg is.
@Franc, natuurlijk is er wel een backup van de sources! Ik check namelijk een dummy bronbestand in dat dezelfde routines bevat als mijn kwaadwillende code. Alleen op mijn systeem vervang ik het dus door het kwaadwillende bestand dat ik dus niet incheck. De backup van de broncode zal dan juist aantonen dat ik niet fout heb gehandeld want er staat niets schadelijks in! Nee, ze moeten dan echt de binaries weer terugvertalen naar broncode om te onderzoeken waar het schadelijke stukje code staat. Vervolgens zal dit weer met mij in verband gebracht moeten worden en dat zal lastig zijn. Er kunnen namelijk genoeg andere oorzaken zijn waardoor de binaries plotseling schadelijk worden. Moet alleen niet vergeten dat ik alle sporen van het schadelijke bronbestand vernietig. Simpelweg verwijderen kan al genoeg zijn want hoe paranoide zal mijn ex-werkgever uiteindelijk zijn?
Ik heb zijn site zojuist doorgelezen en de uitspraak. Zijn enige argument is het niet opvragen van verkeersgegevens, want zijn IP zou gespoofd zijn. Maar hij heeft wel die foute code geplaatst, en was de enige die ervan wist. De rechter heeft mijn inziens dus correct geoordeeld.
Wat een knuppel die man. Hopelijk komt hij niet gauw meer aan de slag in de IT/Software ontwikkeling.
Natuurlijk heeft die rechter gelijk, Mark! Die knuppel heeft immers toegegeven dat hij die code heeft toegevoegd. Zijn ex-werkgever heeft vervolgens een papieren uitdraai van het log overhandigt als bewijs dat hij vervolgens die code ook heeft uitgevoerd en hij beweert vervolgens dat zijn ex-werkgevers dit heeft vervalst! Hij vergeet alleen een reden om aan te geven waarom zijn ex-werkgever dit zou kunnen doen. Hij had immers ontslag genomen om elders te werken. (Hij is er dus niet voor ontslagen!) Let overigens op: de toegang tot de website was alleen mogelijk vanaf een beperkt aantal IP adressen en het IP adres van die knuppel was de dag na zijn ontslag nog steeds toegelaten. (Zeker af en toe thuis gewerkt?) Zijn werkgever had eigenlijk die toegang moeten blokkeren maar omdat de volgende dag al meteen schade was veroorzaakt kan ik het begrijpen dat hij toch toegang had. Geeft ook aan hoe het kan dat zijn ex-werkgever zijn IP adres kende en dus kon herkennen. De bewering dat iemand anders zijn IP adres heeft gespoofd… Kan dat wel? Je kunt een MAC adres clonen maar een IP adres? (Nazoeken…) Ah, ja… Dat lijkt te kunnen maar is niet eenvoudig. Irritante is alleen dat de response naar het werkelijke adres gaat dus een dergelijke aanval is niet erg handig. Je weet immers niet wat er gebeurt. Plus, je moet een specifieke browser schrijven die de IP headers kan vervalsen en die zich ook volledig als een webbrowser gedraagt, ook al weet deze niets van de responses die de site terugstuurt. Daarvoor moet je dus enorm veel kennis hebben van hoe de webserver is opgebouwd. Aluhoedje += 1; maar weer? Ex-werkgever had ook de uitdraai kunnen vervalsen. Maar waarom eigenlijk? Hij had al bekend de code toegevoegd te hebben en was er eigenlijk als enige mee bekend. Zijn werkgever kende zijn IP adres dus ook hier hoeft geen verdere navraag meer voor te gebeuren.
Hij is dom bezig geweest en is daar nu strafrechtelijk voor veroordeeld. Het levert hem mogelijk ook een strafblad op en aangezien hij voor een juristensite heeft gewerkt lijkt een strafblad mij lastig voor de rest van zijn juridische loopbaan. Zijn “onbesproken gedrag” is in ieder geval ten einde. Zijn huidige werkgever zal er ook niet al te blij om zijn. Geen wonder dus dat hij zich eruit probeert te kletsen. Maar volgens mij heeft hij geen straf verdiend, maar heeft hij psychiatrische hulp nodig. Wie doet nu zoiets mafs? Dit heeft hij gewoon van tevoren uitbedacht, grondig uitgewerkt en uiteindelijk uitgevoerd en nu beweert hij dat iemand anders zijn kwade plannetjes uitvoerde. Maakt het uit? Hijzelf is nog steeds diegene die verantwoordelijk was voor het uitvoeren ervan…
Hoe stop je dit soort kwaadaardige ITérs? Heel simpel: met goede backups voorzien van goede backup procedures.
Het “spoofen” van een IP adres is niet zo moeilijk, je kunt een IP adres naar eigen keuze opgeven in “network preferences”. Het opzetten van een TCP verbinding naar een webserver zal waarschijnlijk niet lukken omdat de antwoordberichten (met name het SYN-ACK pakket) van de webserver niet naar jouw computer gerouteerd worden. De voorwaarde dat je een TCP verbinding met een webserver kunt opzetten wijst er op dat de routes tussen webserver en client opgezet zijn; een spoofer zal een aansluiting “dichtbij” de werkelijke bezitter van het IP adres moeten hebben om een kans op succes te hebben. (Of we moeten een ??ber-hacker hebben die routering op Internet core routers aanpst.)
@MathFox, het spoofen zelf is inderdaad het probleem niet. Het probleem is vooral de communicatie met de webserver, waarbij je in dit geval ook nog eens langs een firewall heen moest. Dat is eigenlijk niet de moeite waard. Handiger zou het zijn indien een andere werknemer het IP adres van deze knuppel kende en met die kennis de logbestanden was gaan vervalsen. Dergelijke fraude is best lastig te detecteren, zeker als je alleen maar de papieren afdruk van dit log hebt. Blijft natuurlijk nog de vraag waarom iemand dit zou doen. Een vervalst log zou een betere verklaring zijn dan een gespoofd IP adres.
Maar goed, het gaat hier om een ICT’er die opzettelijk een schadelijke backdoor in de code had aangebracht. Dat heeft hij zelf immers bekend. Vervolgens neemt hij geen advocaat in dienst om zich te verdedigen en gaat dus keihard ten onder. Idem tijdens het hogere beroep zodat hij gewoon zichzelf de schuld moet geven van al zijn huidige ellende. Het zijn wel kenmerken van iemand die geestelijk een beetje labiel lijkt. Jammer alleen dat dit soort strafzaken te licht zijn om TBS te kunnen eisen. Toch?
@Mark, een kwaadaardige ICT’er kun je niet stoppen. Net zoals je terrorisme niet kunt stoppen. Hoe meer je dit probeert, des te meer de beveiliging in de weg zit van wat je daadwerkelijk wilt bereiken. Maar de kwaadaardige ICT’er vindt wel een manier om schade te doen. Als het moet door ook de backups en de backups van de backups te beschadigen. Of door op een andere manier schade te berokkenen door b.v. gevoelige informatie naar buiten te lekken of bedrijfsgeheimen door te spelen naar klanten en concurrenten. Dat voorkom je niet met een backup.
@Wim, 33: Ja het is niet moeilijk om logbestanden te vervalsen, maar ik vraag me af of iemand bij het bedrijf daarvoor de moeite zou nemen. En je moet op het moment van vervalsen het goede IP adres weten; de politie kan NAW gegevens opvragen bij de ISP, maar hoe kom jij aan het externe IP adres van mijn LAN? (Het aanbrengen van de backdoor is ook iets dat een goed werknemer niet hoort te doen en maakt de schijn tegen de “knupppel” een heel stuk sterker.)
@Mathfox: Zou je niet kunnen voorspellen wat de inhoud van het ACK bericht gaat zijn als je vanaf een gespooft IP adres een SYN stuurt? Dan kun jij gewoon een FIN sturen die daar weer op reageert, en dan denkt de server dat jij dat IP-adres hebt. Kies een rustig moment en dan kun je de sequencenummers wellicht voorspellen.
@35 Sequence number prediction werkt tegenwoordig eigenlijk vrijwel alleen als MITM attack: om je eigen pakketten in plaats van orginele pakketten te injecteren. Kortom er moet al communicatie tussen twee hosts plaatsvinden en dan kan je – als je goed je best doet – je eigen pakketten in plaats van die van een van de twee communicatiepartners plaatsen.
Het is tegenwoordig vrijwel onmogelijk om dat te doen zonder het netwerkverkeer tussen de twee ‘ware’ hosts af te luisteren. Reden is dat de TCP stacks van tegenwoordig de sequence numbers randomiseren zodat ze niet meer te raden zijn zonder dat er werkelijke communicatie plaatsvindt.
Dat zijn dus nogal wat randvoorwaarden en ik durf wel te zeggen dat de kans dat er in deze zaak gespoofed is, nihil is.
@Mathfox:
Ik ben het met je eens hoor, maar het argument is net zo brak als het argument van meneer waar hij beweerde dat als hij dit echt zou hebben gedaan, hij toch niet zo stom zou zijn geweest om het vanaf zijn eigen IP adres te doen. Dat IP adres stond dus in de firewall geconfigureerd met in commentaar de naam van de medewerker erachter. Dat was dus niet zo heel moeilijk.Kortom: de case van het OM was sterker geweest indien ze de log file hadden kunnen aantonen door middel van verkeersgegevens van meneer zijn provider. Dat had deze discussie in ieder geval uitgesloten.
@Mathfox, het IP adres van de ex-medewerker was bekend bij het bedrijf omdat het werd toegelaten door hun firewall. Kennelijk had hij zijn IP adres in het verleden doorgegeven zodat hij thuis kon werken of zo. Dan valt er ook niet veel meer uit te zoeken, toch? 🙂 Als jij de IP adres aan mij doorgeeft zodat ik je toegang kan verlenen tot zaken achter mijn firewall, dan hoef ik later niet meer uit te zoeken of IP adres X.X.X.X wel van jou is. Dat weet ik al!
@Arnoud, het zou natuurlijk lastiger worden indien de website tevens via SSL beschermd was. 🙂
@Arnoud, 35: Je beschrijft een bekende aanval waartegen in moderne TCP implementaties maatregelen genomen zijn. Het initiële “sequence number” is nu een willekeurig door de server gekozen getal en je moet desbetreffende 32 bits goed raden om een verbinding te spoofen. Een complicatie bij deze aanval is dat de “gespoofde host” RST pakketten naar de server gaat zenden als hij de antwoorden van de server ontvangt en daarmee de gespoofde verbinding verbreekt.
De hamvraag blijft: Hoe weet een spoofer van de “debug” code?
@35: Om een TCP verbinding te blind te spoofen (i.e. je zit niet in het pad) moet je het initiële sequencenummer voorspellen en dat is met een beetje modern OS echt niet meer zo makkelijk. (En je ISP waar vanaf je spooft moet niet aan egress filtering doen, geen eigen NAT/firewall in de weg, etc). Een blinde aanval is ongeveer 2^16 pogingen (32-bit veld, birthday attack) en lijkt als je niet oppast op een SYN-flood. Het zou kunnen, maar het is zeer onwaarschijnlijk t.o.v. de kans dat de enige die wist dat die backdoor erin zat, het van zijn eigen adres gedaan heeft.
@34: Je lekt je externe IP adres op veel plekken, voor passieve aanvallen denk aan email headers, voor actiever denk aan webbugs. Van een willekeurig iemand het IP-adres achterhalen is lastig, maar van iemand die je goed genoeg kent om je te willen framen is dat makkelijker.
Maar als ik een stapje terug zet: wat hadden die verkeersgegevens van de ISP überhaupt kunnen aantonen als tegenbewijs? Die gegevens zijn toch niet meer dan de DHCP lease? Dus daar had in het beste geval in kunnen staan dat hij de DHCP lease niet had (onwaarschijnlijk in de tijd dat je je modem normaliter gewoon aanlaat), of mis ik iets?
Bedankt voor de toelichting Wouter. Zoiets vermoedde ik al.
De verkeersgegevens hadden kunnen aantonen of dat IP-adres in het gewraakte tijdsinterval aan hem was toegekend. Of mogelijk omgekeerd, aan welke Nederlander dat IP-adres in dat interval was toegekend. (Als het voor in NL uitgegeven IP-block betreft.)
Het was waarschijnlijk een statisch IP, het was immers in de firewall geconfigureerd om die man toegang tot het bedrijfsnetwerk te verlenen. Dat doe je niet met een dynamisch IP.
Verkeersgegevens zijn volgens mij wel wat uitgebreider, denk aan bandbreedtegebruik per tijdsinterval, gemeten op het modem of de router van de ISP. Als dat niet-nul was op het moment van debug=1 dan wordt het spoofing verhaal nog minder aannemelijk dan het al was.
@Richard: Als het gaat om wat er volgens de Wet bewaarplicht moet worden bewaard, dan heb je géén bandbreedtegebruik of zelfs maar eindpunten van TCP verbindingen. Het enige dat je weet is “IP-adres toegekend 27/6 13:08; IP-adres afgenomen 28/6 23:59” plus wat details over het modem (zoals MAC-adres). Zie de lijst van gegevens zoals ik die in 2009 postte nadat de wet erdoor kwam.
Je kunt met die logs dus vaststellen dat meneer wel of niet dat IP-adres toegekend had toen deze actie gebeurde. Maar dan is nog steeds theoretisch gezien een spoofing aanval niet uitgesloten. Sterker nog, als iemand zat te spoofen is het waarschijnlijk dat die echt zijn IP-adres zou gebruiken. Als je iemand te pakken wil nemen, moet je het wel goed doen immers. Afijn, aluhoedjesland.
@arnoud beide kanten worden toch opgeslagen? IP verzender en waar naartoe? Dus de header src en dst.
Dan is er toch een log bij de isp waarin duidelijk is dat hij vanaf zijn statische ip (anders heeft fw rule geen zin) naar de website een connect heeft gehad op dat tijdstip.
Wat betreft de spoofing dat moet ergens op de lijn zijn zo dicht mogelijk bij de webserver. Hoe verder je weg zit des te groter de kans dat halverwege de route anders wordt ivm bv drukte en je de boel kwijt raakt. In dit geval wil je een complete sessie opzetten dus je moet ook verkeer kunnen ontvangen. Maar dan moet je al gauw inbreken bij een isp of kabels gaan knippen. http://stackoverflow.com/questions/1180878/spoofing-the-origination-ip-address-of-an-http-request met plaatje 🙂
Voor (D)DOS is spoof makelijker want dan wil je geen verkeer retour hebben (en dus de server met een grote stapel geeltjes achterlaten van wie hij ook al weer nog een antwoord verwacht.
@Franc: Nee, er wordt niet per internetsessie opgeslagen tussen welke IP-adressen er gecommuniceerd wordt.
Wie zegt dat dat IPadres en die logregels niet door de ex-werkgever zelf zijn toegevoegd aan die logfile? Er is geen enkel forensisch onderzoek gedaan naar de authenticiteit van die logfiles en er is geen forensische detective of politieagent geweest die de logfiles heeft “veiliggesteld”. Alleen al daarom zou ik deze logfiles willen verwerpen als bewijs.
@WhizzMan, dat had de ex-werknemer dus moeten zeggen. Wie zwijgt, stemt toe. Als hij had beweerd dat de ex-werkgever dit log vervalst had, dan was dit bewijs mogelijk van tafel geveegd…
@Whizzman: Dat is zeker theoretisch mogelijk, maar de maatstaf is of er gerede twijfel is aan de authenticiteit van de log. Een theoretische optie is nog geen gerede mogelijkheid. De belangrijkste vraag voor de rechter: waarom zou die werkgever dat willen doen? Waarom zou hij moedwillig zelf records weggooien om langs die weg een ex-werknemer te kunnen aanspreken?