Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 51 reacties

Onderzoekers van de Vrije Universiteit uit Amsterdam hebben de pers gehaald met hun werk over de combinatie van computervirussen en RFID-technologie. Hoewel de ene site na de andere krant weet te melden dat 'RFID-tags vatbaar voor computervirussen' zijn, komt het er in de praktijk op neer dat het juist de backend van een RFID-systeem is die de kwetsbaarheden vertoont. Men mag veronderstellen dat de recente aandacht voor privacyproblemen met de 'elektronische barcodes' de aandacht op het project vestigde, maar juist privacy is voor het Amsterdamse onderzoek van geen enkel belang. Het blijkt daarentegen dat de apparatuur die de radiografische tags leest, niet altijd voldoende beveiligd is tegen invoerfouten. Voor programmeurs geldt het onderzoek dan ook als een zinvolle waarschuwing, maar voor niet-ingevoerden lijkt het onderzoek weinig meer te betekenen dan de mededeling dat ook deze techniek bepaald niet onkwetsbaar is.

RFID-tag close-up Promovendus Melanie Rieback beschrijft diverse manieren om zwakheden in bijvoorbeeld databases of interface-software te exploiteren. Vrijwel het hele verhaal is echter ook van toepassing op, zeg, pasjes met een magneetstrip: met beide kan een achterliggend systeem worden voorzien van data, waarmee bijvoorbeeld SQL injection- of buffer overflow-aanvallen kunnen worden uitgevoerd. De consequentie van een gecompromitteerde backend is uiteraard dat ook nieuw geprogrammeerde RFID-tags onbetrouwbaar zijn, en met de groeiende populariteit van RFID zou de verspreiding een stuk harder kunnen gaan dan met alternatieve datadragers. Interessanter is wellicht het werk dat Rieback c.s. verrichtte aan de RFID Guardian, een soort stoorzender die aan RFID-tags gerichte signalen onderschept en in plaats van hen antwoordt met een sterk signaal, dat de respons van de tag overschreeuwt. Ironisch genoeg is juist een dergelijk apparaat uitstekend bruikbaar om een RFID-backend mee aan te vallen.

Lees meer over

Moderatie-faq Wijzig weergave

Reacties (51)

Two words, "Input verification".

Wat staat er volgende week op de FP? "Editboxen vatbaar voor computervirussen"? Beetje jammer dat de VU zo'n opgeklopt artikel schrijft...
Wat staat er volgende week op de FP? "Editboxen vatbaar voor computervirussen"? Beetje jammer dat de VU zo'n opgeklopt artikel schrijft...
2 dingen...

http://www.cs.vu.nl/~melanie/index.html
"In my spare time, I also have written the first RFID virus "

Bovendien is het hoog nodig dat een paar duizend slapende RFID systeem programmeurs worden wakker geschud over het feit dat zij ook in een publiek systeem werken, net als webprogrammeurs.
als je even had doorgeklikt, had je gelezen dat het RFID virus niets meer dan een sql injection...
Dat is een goed uitgangspunt. Toch doe je ook dan bepaalde aannames over de hardware (je software draait op de echte hardware en niet op een of andere VM met rootkit ofzo).
Ik vind het zinvol onderzoek dat deze kwestie aan het ligt brengt en het is niet een voor de hand liggend idee. Het een originele variant van bestaande exploits in een andere domein.
SQL-injection for dummies

1) RFID-lezer leest ID-code van tag in
2) Deze ID-code is in het geval van een virus niet een nummer (bijv. 123123), maar een stuk slechte SQL-code

Stel dat het volgende programma gebruikt wordt om de nummers in de database te zetten:

zet X in database;
toon X op scherm;

Zolang X een nummer is, heb je geen probleem. Wel als X zelf ook een stuk programma is: bijv. "12312 in database; delete database;":

zet 12312 in database;
delete database;
in database;
toon X op scherm;

Het stukje "in database" geeft dan (wellicht) een foutmelding, maar intussen is wel het commando "delete database" uitgevoerd!
Oftewel: een simpele escape is voldoende.
Zet de X tussen haakjes en escape de string. Geen enkele SQL injection die er meer tegen kan.

("Zet 'janus \'; delete database;' in database;" resulteert erin dat "janus \'; delete database;" in de database wordt gezet en er niets wordt uitgevoerd)
Ja maar als X een nummer had moeten zijn en je nu dus een string erin gooit dan treedt er wellicht weer een buffer overflow.
En dus gewoon je invoer checken, je mag er NOOIT van uit gaan dat invoer van buiten te vertrouwen is.
En dus gewoon je invoer checken, je mag er NOOIT van uit gaan dat invoer van buiten te vertrouwen is.
En dat is nu juist de hele clou. Het zijn niet allemaal half goden die onze electronische systemen programmeren. Veel programmeurs doe het mischien een beetje erbij, of hebben geen opleiding gehad en zijn maar wat gaan scripten.

Andersom worden door bedrijven HEEL ERG VAAK stagiares die net een vakje programmeren van 3 maanden in hun eerste jaar hebben gehad aan bedrijfs kritische systemen gezet.

Deze mensen kunnen zich met geen mogelijkheid voorstellen dat data door hun schein-beveiliginkjes heenkomen. Voorbeeld:

Stagiare A vond dat het absolute onzin dat je hidden field parameters uit een FORM serverside moest checken. Via een URL kon ie nog wel voorstellen, maar hij zag niet in hoe hidden parameters konden veranderen. Zijn commentaar: "Alsof mensen daar bij kunnen!" |:(

Dit was dan een persoon die al herhaaldelijk van de wat meer volwassen developpers in ons bedrijf te horen had gekregen hoe ie dingen moest aanpakken. Nou stel je eens voor dat een dergelijke persoon in z'n eentje iets bouwt. Je wilt toch niet weten welke gaten zo iemand veroorzaakt?

Ander voorbeeld:

Stagiare B vond het onnodig om serverside parameters te checken. Zijn reactie: "Ik heb al een javascriptje op de pagina gezet die alles controlleerd. Ik ga dat echt nog niet een keertje aan de server herhalen. Door dat javascriptje komt niks heen hoor!"

Hier zie je duidelijk dat iemand zo gelimiteerd denkt dat ie zich met geen mogelijkheid kan voorstellen dat een request naar een server helemaal niet vanaf de draaiende HTML pagina hoeft te komen, maar dat een andere applicatie deze ook zo direct kan sturen.

Zo zal het ook met deze RFID tags zijn. Tanenbaum is natuurlijk een top onderzoeker en z'n pupil is ook een ster (heck, ik heb ooit voor precies die AIO positie gesoliciteerd alswaar voor zij was aangenomen ;) ), maar op de keper beschouwd is de huidige media aandacht wat groot voor iets wat eigenlijk redelijk triviaal is.
Er bedankt voor je toelichting, want ik kon maar niet bedenken hoe dit mogelijk is. Maar goed een stuk goed beveiligde software moet daar gewoon tegen kunnen.
Ja lijkt mij ook...


lezen:
lees X
wanneer X = geen getal; voer lezen opnieuw uit
zet X in database
toon X op scherm
Kan makkelijk opgelost worden :

1/ - converteer in de software de rfid code naar een integer of een long -> als fout dan slechte RFID code
2/ -filter de sql code uit de rfid code vb. met replace
Dit wordt in goede webpagina's ook allang gedaan. In PHP heb je daar zelfs speciale commando's voor zoals mysql_escape_string, mysql_real_escape_string en addslashes. Deze commando's zorgen ervoor dat de opgegeven SQL commando's gewoon als tekst gezien worden en niet als deel van je eigenlijke commando.
Natuurlijk kan het makkelijk opgelost worden. Het punt is dat mensen dat mensen dat niet doen. Waardoor we straks niet alleen een virusgevoelig internet, maar ook nog een virusgevoelige wereld hebben.
En dat is weer makkelijker gezegd dat gedaan.
Je kunt nog zo groot op de kaft van elk RFID-developers handboek zetten "vertrouw nooit de gegevens die je vie de ether ontvangt!", toch zijn er legio programmeurs die dit 'vergeten'. En hoe vaak gebeurt het niet dat een proof of concept of prototype wordt ingezet?

Hetzelfde geldt nl voor internet sites, maar zelfs bekende pakketten zitten vol met dergelijke fouten.
Dit doet me gelijk weer denken aan het GoT-topic over buffer-overflows en SQL-injections van het trajectcontrolesysteem dat boven een aantal snelwegen hangt ;)
Je bedoelt het topic waar ze serieus denken SQL query's op nummerborden te laten plaatsen? :o
Tja, de AIVD denkt hetzelfde over dataverkeergegevens ;)
naar een dagje shoppen heb je straks een "buffer overflow" in de tas zitten en een "buffer underflow" op de bank rekening
Het is niet echt de tag zelf die vatbaar is voor virussen / malware maar vaak achterliggende databases en websystemen die niet goed zijn beveiligd tegen bv sql injection. De sql query plak je dan als "tag" op de rfid tag.

De term virus vind ik eveneens misleidend gezien de tags elkaar niet echt kunnen besmetten.
RFID als techniek is vatbaar voor virussen, er staat niet dat de chip er vatbaar voor is! maar je zou dus een chip kunnen bouwen/programeren met een virus erop.

RFID chip is dus gewoon een usbstick/floppy/cd of DATtape, niks anders als een DATA drager!
RFID beschrijft niet zo veel over de achterliggende systemen als databases, web enabled systemen etc. Het zijn juist die systemen die vatbaar blijken voor sql injection etc door de info op de RFID tags te voorzien van een payload.
Ze kunnen wel elkaar besmetten, maar dan via een tussengastheer [zoals eerder een parasiet als malaria doet]: namelijk door de database te infecteren, die dan weer de volgende RFIDtags die ingelezen worden, besmet.
nee, een systeem zal nooit een RFID-chip kunnen besmetten, omdat die in feite read-only zijn.
De goedkoopste en meest gebruikte tags zijn readonly, maar er zijn zelfs tags met eigen GPS en WiFi. Als je uitgaat van de zandkorrel-formaat tags voor in een melkpak heb je helemaal gelijk. Als je uitgaat van een doorsnee container-tag met een redelijk wat storage in de vorm van flash, een batterij, een baken (beacon) en behoorlijk wat intelligentie sla je plank volkomen mis.

http://www.axcessinc.com/prod_rfidoverview.php
nee, een systeem zal nooit een RFID-chip kunnen besmetten, omdat die in feite read-only zijn.
RFID-chips bestaan legio in herprogrammeerbare variant. In het onderzoek heeft men zich gericht op een RFID virus dat zich in de back-end applicatie nestelt en zich verder verspreid via alle door die back-end applicatie ge-herprogrammeerde RFID-tags.

Voor meer info zie ook het paper waar in het persbericht over deze zaak naar verwezen wordt:
Het IEEE PerCom paper van Melanie Rieback(Is Your Cat Infected with a Computer Virus?)
In jouw stijl geldt dan ook dat email niet vatbaar is voor virussen.
een vriend van mij heeft aan dit project meegewerkt. Toen ze een rfc hadden uitgeschreven was het eerste commentaar, dat dit geen nieuwe exploit is.

In feite bestaat het al heel lang, alleen verwacht iedereen dat rfid heel veilig is. Dat is dus niet altijd zo.
Dat hele RFID is naar mijn mening een beetje spookie.
Stel je voor. je koopt een jas bij C&A. Je loopt met die jas bij H&M binnen. Daar word geregistreerd aan de hand van je RFID tag, die je niet hebt kunnen vinden, dat je de jas bij C&A hebt gekocht. H&M dumpt slechte code op jou RFID. Nu loop je weer bij C&A naar binnen. Daar scannen ze je RFID en inplaats van: Hey, dat is een C&A klant, gaat hun database omzeep.........

Of nog erger. Bij H&M: je bent een C&A klant. we willen je niet met je C&A jas in onze H&M.

(nu moet je C&A en H&M eens vervangen door andere bedrijven, organisaties of winkels die hier baat bij zouden kunnen hebben. Spookie)
Marketing Walhalla: PIN gegevens koppelen aan tags; kun je precies zien wie waar en wanneer inkopen doet, favoriete winkels, circulatiepatronen, etc.
Winkels waar je pint weten nu ook al wat de eigenaar van bankrekeningnr xxxxxxxxx allemaal koopt...

Helemaal als je ook nog een klantenkaart hebt. Dan weten ze zelfs wat Jan de Vries uit die en die buurt koopt.

Je kan door die RFID rommel hoogstens zien of iemand ook iets elders heeft gekocht.
Maar aangezien een RFID chippie zend simpelweg een nummertje uit (het ID).
Bij de C&A weten ze dat dit een spijkerbroek maat 54 is. Zij hebben dat ID aan dat artikel gekoppeld.

Maar bij H&M kunnen ze met dat nummertje echt niks. Het kan een broek van C&A zijn maar ook een velletje postzegels of zak pinda's.

Paniek om niks.
Een RFID nummer is helemaal niet uniek. Het nummer wordt er in geprogrammeerd door C&A en zal zeer waarschijnlijk voor iedere spijkerbroek van een bepaald merk maatje 36 dus hetzelfde zijn. Het is hetzelfde als met barcodes. De barcode op een pot pindakaas is ook niet uniek. het geeft alleen aan dat het een pot pindakaas van een bepaald merk is.
O, o ,o... wat tenenkrommend kortzichtig. Sorry hoor. ;) H&M kan je nu wel identificeren aan de hand van een UNIEK RFIDnr! Het maakt geen zak uit wat die code betekend. :(
Of RFID metingen met GPS bepaling, dan weet je ook nog WAAR die persoon zich bevind.
met 2 meter reikwijte van lezer naar chip lijkt me GPS een beetje onzinnig met een nauwkeurigheid heeft van ongeveer 15 meter (normale goekope ontvangers) |:(
ik denk dat de C&A mijn tandarts allang heeft betaald om een RFID in mijn vulling in te bakken!
Zal wel meevallen.

Analoog voorbeeld:
Als ze bij C&A de poortjesbeveiliging in het aangekochte artikel niet om zeep helpt, gaat het poortje bij de H&M piepen.

Net zoals ze die beveiliging uitzetten kan je ook zo'n RFID chip de nek omdraaien.
Je moet ze dan wel op hun blauwe ogen geloven dat ze het echt doen en niet zitten te faken.

Daarom zal er ongetwijfeld een zap-device komen zodat je de RFID rommel in je aangekochte spulletjes kan slopen.
Bv. door laten fikken met een magneetpuls o.i.d.

Bij een winkel waarik ooit werkte werd zo de poortjesbeveiliging uitgeschakeld: magneetveld liet dun metalelen draadje doorgloeien.

Edit: typo
erger nog, ze laten je zien wat je had kunnen besparen bijde H&M!
Als je zegt "SQLServer.Excute \[ID-code]" zou het inderdaat een probleem kunnen zijn, maar al je zegt "INSERT INTO [table] (veldX) VALUES ('\[ID-code]')" zie ik geen probleem, al staat er in de ID-code "DROP TABLE [table]" het is en blijft dan een string en geen code. Dan staat er mooi in je tabel een extra record met in veldX een string die zegt "DROP TABLE [table]"

Je gaat als programeur niet zomaar query's uitvoeren op de database die je uit de RFidtag uitleest lijkt mij....
Dan zijn code128 barcode's ook zo lek als een mandje. Die zijn immers ook alphanumeriek zonder checksum

Edit:
Is een reactie op:
SQL-injection for dummies door Reckor
No prob hoor gewoon nog wat haakjes en quotejes, een punt komma en je kunt al heel wat uithalen :). Als ze de content encoden is er niks aan de hand. Heel simpel, maar het moet wel ff gebeuren.
en wat als \[ID-code] nou ['); DROP TABLE table;] bevat oid?
Je hebt gelijk als er in de idtag staat "');delete from [table];INSERT INTO [table] (veldx) VALUES ('"

Heb ik net ff getest....

Had ik ff niet aan gedacht..... |:(

Maare voordat ik die string er in gooi, vervang ik (uiteraard) de singlequote door dubbelsinglequote dus wordt het weer een string... dus hij zou als nog moeten lukken en geen commando uitvoeren :?
besmette tags moeten we dan ook maar ophokken.
De mogelijke nadelige gevolgen zijn echter niet te overzien... er werd o.a. gesuggereerd dat 'tags' van bagage omgewisseld kunnen worden en dat vervolgens bagage ongecontroleerd de bagegeruimte van een vliegtuig in kan.

Je snapt wel wat voor repercussies dat zou hebben - als het een werkelijk probleem is.
Dat nog niet alleen: binnenkort kan je kat dus je koelkast 'ziek' maken :o En die weer de magnetron.

Oh dear :'(

Ik heb nu al problemen met uitleggen aan m'n ouders wat spyware en virussen zijn. Laat staan hoe ik ze dat uit moet gaan leggen..

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True