2011: alles is te hacken

Inleiding

Dit jaar vierde het Anna Kournikova-virus zijn tiende verjaardag. De e-mailworm beloofde gebruikers een foto van Anna Kournikova, maar bevatte in feite een in Visual Basic geschreven worm die zichzelf aan alle personen in iemands adresboek doorstuurde. Veel mensen konden de verleiding niet weerstaan, waardoor het virus zich snel verspreidde.

In die tien jaar is veel veranderd. De Anna Kournikova-worm richtte geen schade aan, hoewel sommige mailservers overbelast raakten. Vandaag de dag hebben hackers en andere kwaadwillenden juist het veroorzaken van schade als doel: het stelen van geld van bankrekeningen, het versturen van spam of het locken van een pc totdat de gebruiker een geldbedrag overmaakt.

In de afgelopen tien jaar is er ook op het web veel veranderd. Het aantal websites is explosief gestegen; iedereen die het wilde, kon webontwikkelaar worden. Maar dat heeft ook tot gevolg gehad dat het aantal beveiligingsproblemen op internet is toegenomen, want niet elke webontwikkelaar wist wat veilig programmeren was.

Afgelopen jaar haalden beveiligingsproblemen ongekend vaak de media. DigiNotar verstrekte malafide ssl-certificaten, hackers stalen informatie over de werking van RSA-sleutelgenerators, 'hackersgroep' Anonymous publiceerde privégegevens uit databases en het PlayStation Network werd gekraakt.

Kortom, 2011 was een heel ander jaar dan 2001, toen een 20-jarige man uit Sneek een simpel Visual Basic-'virus' de wereld in stuurde. Tweakers.net blikt terug op een bewogen jaar.

Anonymous en sql-injecties

In 2011 waren Anonymous, AntiSec en LulzSec geen begrippen die grotendeels op 4Chan en weblogs bestonden, maar die je ook bij het lezen van de krant kon tegenkomen. Hack na hack en datalek na datalek werden naar buiten gebracht door deze groepen, door Tweakers.net steevast omschreven als een 'los-vast verband', bij gebrek aan een betere omschrijving.

Wat Anonymous en de aanverwante groepen precies zijn, is moeilijk te zeggen, maar interessanter is wat ze dóen. In 2011 was dat vooral het aantonen van beveiligingsproblemen in websites, waarbij vaak ook persoonsgegevens werden gepubliceerd die dankzij de hack konden worden achterhaald.

Sql-injectie

Het waren doorgaans eenvoudig te vinden kwetsbaarheden. Vrijwel altijd ging het om sql-injecties. Een sql-injectie maakt het mogelijk om via een slecht beveiligde website eigen tekst toe te voegen aan een database-query, waardoor bijvoorbeeld informatie uit een database kan worden getrokken die eigenlijk privé zou moeten blijven. Ook kan vaak informatie worden weggeschreven.

Sql-injecties zijn eenvoudig te voorkomen. Het devies voor ontwikkelaars is eenvoudig: sanitize your database inputs, zoals XKCD in een beroemde comic al stelde. Toch voeren veel ontwikkelaars input van gebruikers rechtstreeks door naar een query.

Dat is iets wat het Sinterklaasjournaal deed, waardoor de gegevens van 13.000 kinderen toegankelijk waren. Net als poppodium Tivoli. En webwinkels. Omroep Llink. Belegger.nl. Nokia. InHolland. De VARA. De NAVO. Een reseller van Comodo. De Politiebond. Een datingsite. Apple. En zelfs de website van de MySQL-databasesoftware zélf.

En het is niet alsof sql-injecties moeilijk zijn om uit te voeren: er zijn talloze tooltjes te vinden die de kwetsbaarheden kunnen opsporen en vervolgens een hele databasedump kunnen maken.

Maar een sql-injectie is nog een spannende technische noviteit, vergeleken met de blunders die sommige bedrijven maakten. Zo zette Vakantieveilingen.nl privégegevens in de html-broncode van pagina's - perfect als json geformat en dus eenvoudig geautomatiseerd te misbruiken. De Woonbond plaatste een administratiemodule voor enquêtes onbeschermd op internet, waardoor iedereen persoonlijke onthullingen van huurders over bijvoorbeeld burenruzies kon opvragen.

Over het algemeen kunnen websites zich redelijk eenvoudig wapenen tegen dit soort basale beveiligingsfouten - beter dan tegen andere bedreigingen, zoals virussen die zijn ontworpen om kerncentrales te ontregelen. We hebben het over Stuxnet.

Stuxnet en Duqu

Dit jaar bleek dat het Stuxnet-virus, dat vorig jaar opdook en onder meer Iraanse uraniumverrijkingsfabrieken zou saboteren door frequentieregelaars uit te schakelen, een broertje heeft: het zogenoemde Duqu-virus, dat sterk zou lijken op Stuxnet. Duqu zou echter vooral bedoeld zijn voor het stelen van informatie.

Misschien hebben Stuxnet en Duqu zelfs nog meer 'broertjes'. Onderzoekers van Kaspersky hebben ontdekt dat de twee virussen zoeken naar registersleutels die daar op wijzen.

Het was al bekend dat Stuxnet en Duqu bij installatie op zoek gaan naar bepaalde registersleutels om elkaars aanwezigheid te kunnen herkennen, maar Kaspersky stelt dat nieuw ontdekte componenten van de virussen zoeken naar drie nog onbekende sleutels.

Die drie sleutels zouden elk een bepaald virus vertegenwoordigen. Alle vijf virussen zouden afkomstig zijn van hetzelfde 'platform', waarbij virussen kunnen worden samengesteld door componenten toe te voegen of te verwijderen. Of dat zo is, is speculatie, net als de vraag wie er achter het virus zit. Veel analisten verdenken de Verenigde Staten en Israël achter de aanval te zitten, omdat beide virussen waarschijnlijk zijn gebruikt om Iran aan te vallen.

Maar meer dan een educated guess is dat niet, hoewel ook het Iraanse regime die beschuldiging heeft geuit. Siemens, dat systemen heeft ontwikkeld die in de uraniumverrijkingsfabrieken worden gebruikt, heeft volgens Iran zelfs geholpen bij de aanval. De aanval had veel schade kunnen berokkenen als deze niet tijdig was gedetecteerd, geeft Iran toe.

Geen supervirus

Volgens sommige beveiligingsexperts moet er in ieder geval een land achter de virussen zitten, omdat deze zo geraffineerd zijn. Een beveiligingsexpert van Sophos relativeert in een opiniestuk op de website van BBC News echter hoe geavanceerd Stuxnet is. Het is geen unblockable supervirus, stelt hij, maar een redelijk eenvoudig te detecteren virus dat kan worden tegengegaan met gangbare beveiligingsmaatregelen. Uit onderzoek van McAfee blijkt dat Stuxnet regelmatig bij energiebedrijven wordt aangetroffen, maar dat slechts een klein deel van die bedrijven de juiste beveiligingsoplossingen gebruikt.

Dat neemt niet weg dat Stuxnet en Duqu aantonen dat een virus ook gevolgen kan hebben voor de echte wereld. Uraniumverrijkingsfabrieken kunnen worden verstoord, waterpompen vernield - hoewel dat wordt ontkend door de FBI - en banken opgelicht. Shell gaf onlangs aan bang te zijn voor hackaanvallen op zijn infrastructuur.

De overheid en DigiNotar

Ook overheden zijn niet gevrijwaard van beveiligingsproblemen. Zo waren vijftig gemeentesites nauwelijks beveiligd, sloot de Europese Unie externe toegang tot systemen af na een hack, drongen hackers Canadese overheidscomputers binnen, probeerden aanvallers Franse overheidsdocumenten te ontfutselen en liet de overheid van Texas de privégegevens van 3,5 miljoen burgers uitlekken. En dat zijn nog maar enkele van de beveiligingsproblemen die überhaupt in de openbaarheid zijn gekomen.

DigiNotar

Het grootse beveiligingsprobleem voor de Nederlandse overheid was dit jaar de kwestie DigiNotar. Het Beverwijkse bedrijf DigiNotar leverde certificaten, om bijvoorbeeld websites te beveiligen en voor vertrouwelijke communicatie tussen overheden onderling en tussen overheden en bedrijven.

Van een bedrijf dat een cruciaal onderdeel van de beveiliging van websites en vertrouwelijke communicatie levert, zou je verwachten dat het zijn systemen goed beveiligt.

Niets bleek minder waar. Eind augustus verschenen berichten in de media over een ssl-certificaat dat door DigiNotar zou zijn uitgereikt en in Iran werd misbruikt om verkeer van en naar de Gmail-servers te onderscheppen. Al vrij snel bleek dat dat kwam door een beveiligingsprobleem bij de ssl-boer.

DigiNotar ontdekte het beveiligingsprobleem al in juli, maar stelde niemand, ook browsermakers niet, op de hoogte. De morgen nadat het frauduleuze Gmail-certificaat werd ontdekt, kondigden Microsoft, Google en Mozilla aan de root-key van DigiNotar te verwijderen, zodat door DigiNotar uitgegeven certificaten ongeldig werden. De bedrijven vertrouwen DigiNotar niet meer.

Uiteindelijk stelde Microsoft een update die DigiNotar-certificaten zou blokkeren uit, op verzoek van de Nederlandse regering. Die was bang dat het blokkeren van de certificaten voor grote ict-problemen zou zorgen, omdat de infrastructuur van de overheid zo zwaar op die certificaten leunde. Ook vertrouwde Firefox DigiNotar-certificaten korte tijd alsnog, op verzoek van de overheid.

DigiNotar probeerde de ernst van de zaak aanvankelijk te bagatelliseren. Zo stelde woordvoerder Jochem Binst van Vasco Security, eigenaar van DigiNotar, dat er geen gevolgen zouden zijn voor de overheidscertificaten die het bedrijf leverde. Die waren immers niet getroffen, stelde Binst - die op dat moment ook nog niet wist hoe het kwam dat er een vals certificaat was uitgegeven. Dat was op zijn minst voorbarig en in het ergste geval een leugen. Er bleek van alles mis met de beveiliging bij DigiNotar en ook van de overheidscertificaten kon niet meer worden gegarandeerd dat ze veilig waren, waarop het kabinet het vertrouwen in het bedrijf opzegde.

De DigiNotar-affaire was een van de grootste beveiligingsblunders van de afgelopen jaren. Hackers bleken meer dan 500 certificaten te hebben vervalst. Bovendien bleek een deel daarvan uitgegeven nadat DigiNotar de hack ontdekte - het bedrijf was er dus niet in geslaagd om de problemen te bedwingen. Het is nog onduidelijk wie achter de hack vanDigiNotar zat, maar er zijn aanwijzingen dat deze uit Iran kwam.

Niet de enige

DigiNotar is inmiddels failliet verklaard. Dat het niet zo had hoeven lopen, bewijst Comodo. Dat bedrijf kampte dit jaar met een hack waarbij negen frauduleuze certificaten werden gegenereerd. In tegenstelling tot DigiNotar, stelde Comodo het publiek en de makers van browsers en besturingssystemen op de hoogte, zodat erger werd voorkomen. Bovendien slaagde Comodo er voor zover bekend wél in om de beveiligingsproblemen te bedwingen. Later kampte een reseller van Comodo overigens ook met een hack, maar daarbij werden geen certificaten buitgemaakt.

Ook KPN kampte dit jaar met een certificaatprobleem: het bedrijf haalde een website van zijn dochteronderneming Gemnet offline. Deze site, waarop overigens niet rechtstreeks certificaten konden worden aangevraagd, bleek te hacken. Een maand eerder staakte het bedrijf nog de uitgifte van certificaten bij het voormalige Getronics, nadat er 'verdachte' sporen werden aangetroffen. Er bleek echter geen sprake van misbruik.

PlayStation Network en RSA

De hack die dit jaar wellicht nog het meeste stof deed opwaaien, was die op het PlayStation Network. Wat aanvankelijk nog leek op downtime, bleek een omvangrijke diefstal van persoonsgegevens te zijn, waarbij mogelijk ook creditcardgegevens zijn buitgemaakt. Welke gegevens de hackers precies hebben gestolen is nog altijd onduidelijk.

Wie er achter de hack zat, is ook nog altijd niet bekend. Het is wel min of meer duidelijk dat de hack eenvoudig te voorkomen was; het Duitse magazine Bild bemachtigde bewijs waaruit bleek dat software op PSN-servers verouderd was. Zo werd een vijf jaar oude versie van OpenSSH gebruikt en was de Apache-installatie niet bijgewerkt.

Uiteindelijk duurde het ruim een maand voordat Sony's gamenetwerk weer volledig operationeel was. Dat heeft Sony veel directe inkomsten gekost, bijvoorbeeld doordat betaalde PSN-abonnementen niet doorliepen en gebruikers in de PSN Store geen games konden aanschaffen. In de maand na de hack zei het bedrijf 14 miljard yen aan schade te verwachten. Dat is tegen de 140 miljoen euro.

De directe schade valt waarschijnlijk echter in het niet bij de gigantische imagoschade die Sony heeft geleden, hoewel die moeilijk in geld is uit te drukken.

RSA

Ook de hack op beveiligingsbedrijf RSA veroorzaakte de nodige media-aandacht. Wat er precies is gebeurd, heeft RSA altijd geheim gehouden. Wel is bekend dat aanvallers het hadden voorzien op informatie over de werking van SecurID-sleutelgenerators, die worden gebruikt voor two factor authentication.

De hackers hebben daarbij informatie buitgemaakt - welke informatie is onbekend, maar de hack was ernstig genoeg voor RSA om sleutelgenerators wereldwijd te vervangen.

Daarbij ging het om fysieke sleutelgenerators, apparaatjes waarop een code wordt getoond die gebruikers moeten invoeren bij het inloggen, maar ook om software-implementaties met dezelfde functionaliteit.

De hack kwam volgens RSA van twee groepen hackers en een regering zou achter de aanval zitten. RSA was niet het einddoel, maar een middel om ergens anders te kunnen inbreken. Dat einddoel was waarschijnlijk Lockheed Martin, waarvan bekend is dat het in het voorjaar met ernstige beveiligingsproblemen kampte.

RSA heeft enkel toegegeven dat het gaat om een bedrijf uit de defensiesector. Lockheed Martin doet veel werk voor het leger en ontwerpt onder meer ballistische raketten, munitie en radarsystemen. Het is onduidelijk of er een succesvolle aanval is uitgevoerd op het bedrijf.

F-Secure ontdekte dat de aanvallers een besmet Excel-bestand met een embedded-Flash-exploit gebruikten om binnen te komen bij RSA. Honderden andere bedrijven, waaronder Microsoft, Google, Intel, IBM, VeriSign en Cisco zouden op vergelijkbare wijze zijn aangevallen.

De aanvallers zouden geraffineerd te werk zijn gegaan. Volgens RSA voerden ze een aanval op een bepaald onderdeel van RSA uit, maar was dat slechts een afleidingsmanoeuvre, om de aandacht af te leiden van de daadwerkelijke aanval op een ander onderdeel van het bedrijf.

Mobiele malware

Ook mobieltjes worden steeds meer het doelwit van criminelen. Dat valt te verwachten: hoe meer een mobiele telefoon dienstdoet als een kleine computer, hoe interessanter het apparaat wordt voor criminelen. Vooral Android-telefoons lijken een interessant doelwit te worden, om drie redenen: het open ecosysteem - apps hoeven niet in de Android Market te staan om te worden geïnstalleerd -, de geringe controle op de inhoud van applicaties in de Android Market en het langzame patchbeleid.

Malware-besmetting op Android per gebied. Bron: Looktout

Om beveiligingsupdates toe te passen, moet een nieuwe Android-versie worden uitgebracht die op zijn beurt moet worden uitgerold door telecombedrijven of smartphonefabrikanten. Daardoor kan het zo een paar maanden duren voordat een nieuwe Android-versie zijn weg vindt naar de eindgebruiker - als hij de update überhaupt al krijgt. Fabrikanten stoppen op een gegeven moment vaak met het uitrollen van updates voor een bepaald toestel.

Volgens beveiligingsbedrijf Lookout verdubbelt de hoeveelheid malware voor Android dan ook elke paar maanden, hoewel daarbij moet worden aangetekend dat Lookout niet onafhankelijk is: het verkoopt antivirussoftware voor mobieltjes.

Het bedrijf claimt dat Android-gebruikers vier procent kans hadden om in een jaar tijd met malware in aanraking te komen. Aan het begin van dit jaar werd die kans nog op één procent vastgesteld. Malafide applicaties kunnen gebruikers geld kosten, bijvoorbeeld als deze ervoor zorgen dat telefoons ongemerkt dure nummers bellen. Ook is er malware die telefoongesprekken opneemt.

SpyEye

Meer geavanceerde malware is er ook, bijvoorbeeld een mobiele variant van de SpyEye-toolkit. De mobiele versie onderschept sms'jes met tan-codes en stuurt die door naar een externe server, waardoor bankfraude kan worden gepleegd. Gebruikers moeten de app actief downloaden. Wanneer een gebruiker op zijn desktop met SpyEye is geïnfecteerd, krijgt hij bij het internetbankieren een melding dat de app moet worden geïnstalleerd, ironisch genoeg omdat de app zogenaamd het onderscheppen van tan-codes moet voorkomen. Na installatie werken de mobiele versie en de desktopvariant samen om geld te stelen.

Google heeft een belangrijk wapen in de strijd tegen mobiele malware: een 'kill switch' waarmee het applicaties op afstand kan verwijderen van telefoons. Dat gebeurde bijvoorbeeld in maart, toen 58 Android-apps op afstand werden verwijderd. Dat is echter wel een wapen dat alleen achteraf kan worden ingezet.

Apple heeft een strenger beleid voor zijn App Store, maar daarmee kon niet worden voorkomen dat een beveiligingsdeskundige er in slaagde om malware in de App Store te plaatsen, zonder dat Apples beveiligingssoftware alarm sloeg. Apple reageerde op een uiterst twijfelachtige manier: het strafte de onderzoeker door zijn ontwikkelaarslicentie in te trekken. Overigens heeft ook Apple een kill switch, al heeft het die nog niet gebruikt.

De toekomst

Het is moeilijk te zeggen of 2012 een veiliger jaar wordt dan 2011. Moeilijk vooral omdat we enkel af kunnen gaan op de beveiligingsproblemen die in de media komen. Beveiligingslekken en virussen die respectievelijk in de doofpot worden gestopt en onder de radar blijven, komen niet in dit jaaroverzicht voor, maar vormen ook een bedreiging.

Wat we wel weten, is dat de overheid in 2012 maatregelen gaat nemen om cybercrime tegen te gaan. Half januari wordt het cyber security center van de Nederlandse overheid officieel geopend. Dat centrum, waarin onder meer Govcert in opgaat, moet de digitale beveiliging van de overheid coördineren en bedrijven helpen bij beveiligingsproblemen. Ook komt er een meldplicht voor datalekken, waarbij bedrijven de overheid op de hoogte moeten stellen wanneer klantgegevens worden buitgemaakt.

Dat zal er wellicht toe leiden dat bedrijven meer gaan samenwerken, zowel met elkaar als met de overheid, om te pogen het onstaan van datalekken en beveiligingsproblemen te voorkomen. Wat het niet gaat voorkomen is het bestaan van datalekken en beveiligingsproblemen: die zullen er ook in 2012 blijven. Sql-injecties, mobiele virussen, gehackte certificaat-autoriteiten, buffer overflows - we zullen er in 2012 meer dan genoeg nieuwsberichten over kunnen schrijven.

Reacties (39)

[Brazza]

Tja we kunnen altijd nog terug naar 1985 met Michael J. Fox. Maar ik denk dat aan de ene kant de gebruikers 'willen leren' maar dat 13-jarige script kiddies 3x zoveel informatie verwerken. En dan krijg je problemen als zo iemand het slechte pad op gaat.

Maar ik vind 'Hacken' zo'n gehypt woord. beveiliging 101. Ik bedoel als systeem/netwerk beheerder behoor je te weten of je safe of niet bent.

Maar leuk artikel enzo verder

[Reactie gewijzigd door Brazza op 25 juli 2024 13:07]

[Dutchiee.tv]

Ansich vind ik hetgeen je zegt "...Ik bedoel als systeem/netwerk beheerder behoor je te weten of je safe of niet bent...."
Dat, zoals kenbaar gemaakt door Mrgrafx, werkt inderdaad alleen maar als je weet wat voor lekken er zijn. Microsoft brengt vaak genoeg nieuwe updates naar buiten, om de oudere en 'niet' bekende lekken te dichten.

Zelf ben ik ook informatiebeveiliging, in opleiding danwel. Foute informatie

Inderdaad goed artikel. Even een 'mooie' terugblik op het jaar.

Edit: MySQL was fout van mij. Zat zelf niet op te letten.

[Reactie gewijzigd door Dutchiee.tv op 25 juli 2024 13:07]

[RobertMe]

En toch zie ik zelf ook vaak dat er veel proberen zijn in MYSQL databases.

Incorrect. Er zijn veel problemen waardoor databases uitgelezen kunnen worden. Meestal MySQL, omdat dat gewoon veel gebruikt wordt. Maar het probleem zit niet in MySQL. Het probleem zit in de applicatie die MySQL aanspreekt. MySQL ziet geen verschil in, en mag geen verschil zien, in:
SELECT post_date, article FROM news WHERE article_id = '1'
en
SELECT post_date, article FROM news WHERE article_id = '-1' UNION SELECT username, password FROM users -- a'

Dit simpele SQL Injection probleem kan op twee manieren worden voorkomen, de "correcte" manier van controleren of het in de request opgegeven id wel een integer is (m.a.w. valideer de input of het geldige waardes zijn). Of de, over het algemeen veiligere, manier van escaping, in PHP met mysql_real_escape_string, waarmee backslashes voor quotes worden gezet en de DB deze ook leest als tekst en niet als "speciaal karakter" (begin/einde string). Deze manier is veiliger dan input validatie omdat input validatie niet altijd kan (als het gewoon over tekst gaat dus), en input validatie vergeten kan worden bij aanroep X of Y. Als je altijd doet escapen is er geen kans dat er een pad door de code is waarbij de validatie niet, of incorrect, plaatsvind. Daarnaast is escapen niet in alle programmeertalen mogelijk (via interne functies), en is er alleen de optie voor prepared statements. Een optie die overigens door de meeste programmeertalen ondersteund wordt. Bij prepared statements zeg je simpelweg tegen de database: Ik heb deze query, en op plek X moet dadelijk een waarde komen die ik je later ga aanleveren. Op dat moment weet de database precies wat de query is, bv: SELECT post_date, article FROM news WHERE article_id = ? en dat er op de plaats van de ? later een waarde wordt aangeleverd. Bv 1. Op het moment dat dan toch iets als -1' UNION SELECT username, password FROM users -- a erdoor komt, gaat de database dus zoeken naar de waarde -1' UNION SELECT username, password FROM users -- a in de article_id kolom, in plaats van dat er een extra stuk code aan de query wordt geplakt.

De databases, inclusief MySQL, hebben met prepared statements dus een goed wapen tegen SQL injection (naast andere voordelen die het bied), alleen wordt het te vaak niet toegepast, waardoor lekken ontstaan in de applicatie en de (hele) database uitgelezen kan worden. Maar dit probleem zit dus niet in de database zelf. Deze verwerkt alleen maar de gegevens en voert bij SQL injection netjes de query uit die aan hem wordt gevraagd om uit te voeren.

Edit: ACM beat me to it In het vervolg sneller tikken.

[Reactie gewijzigd door RobertMe op 25 juli 2024 13:07]

[Ex-KPN-er]

Wow thnx....
ik krijg nu zowaar eens een smile op mijn face als ik dit lees...

Dat is nu eens een post waar de n00b's wat aan hebben; en de echte IT-bloedigen een bijzonder goed en sereen gevoel bij krijgt..

Er zijn dus toch mensen die het snappen

(en sorry als het offtopic is; maar hij slaat de spijker precies op de kop

ontopic dan maar:

99% van alle 'hacks' zijn MAKKELIJK te voorkomen; maar kosten net even dat stapje meer als iemand zal doen die de kennis wel leert; maar er geen gevoel bij heeft..

en kom alsjeblieft niet aanzetten met 'mijn baas blabla' want je bent of een it-PROFESSIONAL of je bent het niet. Ook een hersenchirurg zal dingen weigeren als zijn manager/baas iets idioots wil)

[Rapier]

Ik ben met je eens dat met een beroep/functie bepaalde minimum vereisten komen.
Maar je kan het niet op op persoon schuiven, en verwachten dat die het wel allemaal in zijn eigen tijd oplost.

Inderdaad een hersenchirurg krijg je waarschijnlijk niet zo gek dat hij moedwillig schade toebrengt, net zoals je een IT'er niet zo gek krijgt een Stichting te hacken. Kleinere ethische "overtredingen" komen echter overal voor, IT'ers die patches niet doorvoeren of code niet 100% controleren komt geregelt voor, want er is tijdsdruk en geld tekort. Lame excuus, maar denk eens aan die 2 ziekenhuizen die geen patienten aannemen omdat een zorgverzekeraar er niet voor wenst te betalen. (budget 2011 op)

Is dat "minder" erg? Het moge dan geen acute gevallen zijn, maar is er niet een kleine kans dat het toch mis gaat? (Kwaaltjes hebben de neiging erger te worden als je er niets aan doet, en een arts die je niet kent interpreteerd je misschien toch net ff slechter)

Je moet denk ik eerder de "schuld" leggen bij de manager/baas/opdrachtgever/wetgever die bewust de keuze maken om de professional iets wel of niet te laten doen.
Overigens is het wel de taak van de specialist om leidinggevende te wijzen op problemen, maar als die er vervolgens voor kiezen om er geen tijd aan te besteden dan komt het niet terug op het bordje van de specialist.

(overigens betekent "Professional" niets anders dan dat je je geld ermee verdient, onbetaald = amateur, betaald = professioneel)

[Reactie gewijzigd door Rapier op 25 juli 2024 13:07]

[ACM]

Die SQL-injection zit doorgaans niet in de MySQL-database... Maar in de software die ermee communiceert. Het is ook niet echt relevant dat het een MySQL-database is, dezelfde problemen bestaan voor elke variant waarbij een statement uit een communicatietaal samengesteld wordt aan de hand van (blijkbaar ongecontroleerde) gebruikersinvoer. Als een hacker domweg toegang tot je database heeft, dan is er geen reden alternatieve SQL in andere queries in te injecteren

[Verwijderd]

"...behoor je te weten of je safe of niet bent."

Dat werkt alleen als je weet waartegen je je moet/kunt beschermen. Een onbekend lek blijft lekken (denk aan je wasmachine...).Het blijft een soort haasje-over gebeuren, alleen loopt de anti-virus/beveiligingsbranche bijna per definitie achter op de hackers & malwaregasten.

[South_Styler]

Ik vraag me echt af waardoor het komt dat Android en Windows zoveel malware en virussen hebben, terwijl Apple in vergeljking er maar weinig heeft. Een argument is natuurlijk dat Android en Windows meer domineren, maar de iPhone heeft toch ook een behoorljk aandeel en daar hoor je zowat nooit wat van . Is hun software dan zo goed?

On topic: goed overzicht, het toont des te meer aan dat websitesbeter beveiligt moeten worden. Gezien het grote aantal sites zullen er altijd (helaas) wel een paar hackbaar blijven. Zeker wanneer je bedenkt hoe snel de techniek zich ontwikkelt. Een site onderhouden kost soms veel geld, zeker als het niet is bijgehouden... En dus doen ze het maar niet, met gevolg dat ineens veel gegevens op straat liggen

[Reactie gewijzigd door South_Styler op 25 juli 2024 13:07]

[mdeb]

heel simpel op een android kan je buiten de Market programma's installeren en de programma's in de Market worden niet gecontroleerd op malware, terwijl op een iPhone moet je via de App Store en die programma's worden gecontroleerd op malware en virussen door Apple.

[iChaos]

Onthoud hierbij echter wel dat wanneer er een jailbreak is toegepast, i.c.m. software om die IPA's buiten iTunes om te installeren, gemodificeerde IPAs evengoed geinstalleerd kunnen worden. Daarbij was de 4.0 jailbreak van Comex gebasseerd op een fout in de PDF parsing van iOS, en die exploit kon toen ook gebruikt worden door anderen om er wel een kwaadwillende payload mee op te sturen (en met die PDF exploit kan er rootaccess verkregen worden, dus een kwaadwillende payload kan ook redelijk wat schade aanrichten). Daarnaast verscheen in Cydia ook een package om de PDF exploit te dichten, dus werd er toen een exploit gebruikt, om die exploit te dichten.

Wat me toen wel zorg baarde was dat die jailbreak open-source werd uitgebracht (voor zover ik weet staat het project op Sourceforge onder de codenaam 'star'), waardoor iedereen die exploit voor andere doeleinden kon gebruiken.

[tim427]

Mooie opsomming!

Ik zie inderdaad heel veel mooie nieuwe web2.0 websites, maar helaas zijn er nog te weinig (web)ontwikkelaars met verstand van Informatie Beveiliging.

Ook de hele mind-set is bij de meesten niet goed. Ik heb genoeg opmerkingen gehoord:
-PhpMyAdmin is juist handig, wie gebruikt dat nou?
-HTTPS, ach wie gaat mij nou sniffen?
-Emergency plan? Ach, we zie dan wel!
-Patch plan? Die lekken lopen toch niet zo'n vaart..
-Event logs bekijken? Waarom, teveel werk!
-Poorten dicht gooien? Services op andere poorten draaien?
-IP-adres filtering?
-Etc. etc.

Vind ik toch jammer. 99% van de fouten kunnen voorkomen worden door logisch na te denken. Natuurlijk is een 0-day-exploid erg lastig, maar een SQL injection is gewoon slordig.

[sfranken]

phpmyadmin, wanneer goed geconfigureerd, is gewoon net zo veilig als elk ander (mini)DBMS imo

[tedades]

Ik heb vaak genoeg het antwoord "wie doet dat nou?" gekregen. Soms lijken mensen niet te begrijpen dat het internet 24-uur per dag draait en veel lekken geautomatiseerd gevonden kunnen worden.
Dus dan kun je lijkt me beter het zekere voor het onzekere nemen en je spulletjes op orde hebben. Hoewel de meeste data lekken volgens mij door interne mensen gedaan worden, dus ergens zul je een goede verhouding moeten vinden.

[tenpo]

Ik ben persoonlijk hobby sitebeheerder van een kleine site. Ik heb vrij goede basiskennis van html en ondertussen al wat basis php. Maar het probleem blijft dat ik als hobbyist nooit zeker weet of ik goed werk en daar ook de tijd niet voor is. Ik heb dit al aangebracht bij het bestuur en hun logisch antwoord is dat er a) geen belangrijke gegevens op de site staan en b) content eigenlijk belangrijker is dan code/beveiliging. Daarom is het opstellen van een emergency plan ook te tijdrovend, logs ook te tijdrovend. Alle sql query's worden wel zo goed mogelijk opgevangen door het php-framework met ingebouwde functies maar ik vermoed dat niet alles dicht staat. Nu voor volgende versies wordt gekeken naar een overstap naar joomla en onze eigen functies te vervangen door ingebouwde modules van joomla. Met nog verreiste van https en software zo veel mogelijk up to date samen met gesanitisede sql query's hoop ik al toch wat aanvallen af te houden.

[niki_lauda]

Ik heb een vraag over de DigiNotar kwestie. Notarissen gebruiken de certificaten om bijv digitaal met het kadaster te communiceren. Er zijn nog tientallen van dit soort communicatie's mbv diginotar certificaten. Zijn die transacties in de tijd tussen de hack en het vervangen van de certificaten onbetrouwbaar??

[Pjotr]

Het punt is: dat weet je niet. En dat maakt het nou net zo vervelend, als een mechanisme dat gebaseerd is op vertrouwen, gecompromitteerd is.

[bwerg]

Ze zijn niet 100% betrouwbaar, omdat alle diginotar-certificaten dus vervalst zouden kunnen zijn. De vervalsingen zijn (voor zover bekend) alleen in Iran gebruikt, dus als er na de de bekendmaking van de diginotar-faal geen nieuwe certificaten meer zijn verstrekt is de kans klein dat de certificaten op dat soort plekken terecht is gekomen.

[marrs]

We beginnen ons langzaam te beseffen wat voor schade er kan worden aangericht door hackers, maar ik heb sterk het gevoel dat we daar nog geen passende maatregelen tegenover stellen. Ik vrees dat de huidige trend zich in 2012 zal voortzetten en dat we aan het einde van dit jaar een soortgelijke lijst zullen krijgen, met meer nadruk op mobiele telefoons en cloud applicaties.

Die laatste categorie loopt een heel ander risico: cloud applicaties draaien op gevirtualiseerde hardware en ik ben bang dat het hackers op een gegeven moment gaat lukken om in te breken op de laag hieronder. De economische gevolgen van het "uit moeten zetten" van een complete cloud zijn aanzienlijk, dus ik hoop dat ik ongelijk krijg.

[TD-er]

Het gevaar op mobiele apparaten is nu al duidelijk dat het niet alleen vanuit hackers en malware komt, maar ook vanuit de provider/fabrikant/overheid. Kijk naar CarrierIQ en dat onze eigen overheid nu al probeert spyware op computers van verdachten te installeren.
Dat zal alleen maar erger worden en de mobieltjes zullen zeker niet ontzien worden.

Een cloud die offline moet wegens een hack acht ik voor 2012 ook niet onwaarschijnlijk. Maar met een beetje pech zou het ook wel eens kunnen zijn dat blijkt dat er massaal enkele overheden meekijken met onze cloud-data. Hoe dan ook, de kans is inderdaad zeer aanwezig dat "cloud" over een jaar een heel andere smaak geeft bij velen.

[Stoney3K]

Het gevaar op mobiele apparaten is nu al duidelijk dat het niet alleen vanuit hackers en malware komt, maar ook vanuit de provider/fabrikant/overheid. Kijk naar CarrierIQ en dat onze eigen overheid nu al probeert spyware op computers van verdachten te installeren.
Dat zal alleen maar erger worden en de mobieltjes zullen zeker niet ontzien worden.

Ik mis dan ook een groot stuk over het 'hacktivism' in Nederland in dit artikel.

Dit jaar zijn we bijvoorbeeld met Stichting Hxx als grote groep naar het Chaos Communication Camp 2011 in Finowfurt gegaan, één van de grootste hacker-conferenties van de wereld, en we gaan voor 2013 weer een soortgelijk evenement in Nederland organiseren als vervolg op Hacking At Random (2009) en What the Hack (2005). Stichting HXX is de overkoepelende organisatie van de Nederlandse hackerspaces en -groepen en is ook de organisatie die achter dit soort evenementen zit. Sinds Hacking At Random is de hele hacker-scene daardoor ook 'serieus' geworden.

Dit jaar zijn er bijvoorbeeld ook veel hackerspaces, plaatsen waar 'hackers' (op deze FP, beter, Tweakers genoemd) hun projecten kunnen opzetten en onderling informatie uit kunnen wisselen. Voorbeelden hiervan zijn de ACKSpace in Heerlen, de RevSpace in Den Haag, Tkkrlab in Enschede en #42 in Arnhem. Een volledig overzicht vind je op de site van de VNHO, http://www.hackerspaces.nl

Wat ik ook mis is een hoop nieuws over de jacht op klokkenluiders en journalisten. Waar is het verhaal over Bradley Manning en de (eventuele) uitlevering van Julian Assange, het opvragen van Twitter-gegevens van Rop Gonggrijp en alle berichten van 'hacker-journalist' Brenno De Winter?

De keerzijde van de medaille mag ook worden belicht, en ik vind het nog altijd schandelijk dat we als hackers met lui als Anonymous, LulzSec en virusbouwers op één hoop worden gegooid.

[Reactie gewijzigd door Stoney3K op 25 juli 2024 13:07]

[Asgaro]

Wat een jaar!!
Op naar 2012, hopelijk een jaar met nog meer hacks!
* haalt de champagne boven *

[SirBlade]

Hopelijk niet, op die manier krijgen we alleen maar meer wetten om de vrijheid op internet in te perken.

[Asgaro]

True true, m'n post was sarcastisch bedoeld.

[Brazza]

Okay je kan ook niet alles weten, daar moet ik jullie ook wel in gelijk geven. Zoals dat printer gedoe nu. Maar ik wilde een punt maken over hacken, als sys/net beh. heb je dat vast wel eens geprobeerd. Niet dat je met een standaard Win Xp firewal denk dat je safe zit

[pibara]

"Beveiligingslekken en virussen die respectievelijk in de doofpot worden gestopt en onder de radar blijven, komen niet in dit jaaroverzicht voor, maar vormen ook een bedreiging."

Ik krijg meer het omgekeerde beeld. AV leveranciers zijn constant bezig om FUD (Fear Uncertainty and Doubt) de media in te stuwen zodat iedereen hun nieuwe spul gaat kopen.
Zodra de media gaat begrijpen dat security toch echt van OS leveranciers en software schrijvers moet komen en niet meer van 'add-on' AV software, dan krijgen we pas een goed beeld van (in)security.

[kimborntobewild]

...het stelen van geld van bankrekeningen, het versturen van spam of het locken van een pc totdat de gebruiker een geldbedrag overmaakt.

Misschien dat dat ook voorkomt, maar een belangrijker voorkomend probleem is het locken van bestanden (en dus niet van de PC zelf).

[Verwijderd]

Dit artikel bulkt van de eigenbelang uiteraard. Men beperkt zich hier tot een beschouwing van wat er gebeurde anno 2011. Wat men niet doet is de dieper liggende vraag stellen, de vraag die je dient te stellen voordat je in de problemen raakt qua beveiliging. We kunnen er lekker in mee gaan maar ik wil liever een analyse van de mate waarin het allemaal zo noodzakelijk en/of onvermijdelijk is dat er zo veel zaken zijn die te hacken zijn. M.a.w. moeten we blijven ontwikkelen in een richting waarin privacy en de gevolgen van schendingen daarvan o.a. door hacking steeds groter worden.
De tijd dat technorealisme aanwezig zou moeten zijn in de ICT ligt alv er achter ons maar ik zie nauwelijks enig beef bij ontwikkelaars en admins en bedrijven etc. hoe kritiek de situatie is en hoe schrijnend het is om te moeten vaststellen dat bijna dagelijks privacy onder druk komt te staan.

Is dat wat we willen? Ik niet. De ICT in ons leven raakt te belangrijk.