'Lek in gSOAP-softwarebibliotheek maakt veel iot-apparaten kwetsbaar'

Beveiligingsbedrijf Senrio heeft een lek gevonden in de softwarebibliotheek gSOAP, die wordt gebruikt in iot-apparaten. Het bedrijf trof de kwetsbaarheid aan in een beveiligingscamera van Axis, maar zegt dat door de populariteit van gSOAP veel andere apparaten ook kwetsbaar zijn.

Senrio heeft de stack buffer overflow-kwetsbaarheid met kenmerk CVE-2017-9765 zelf de naam Devil's Ivy gegeven, naar eigen zeggen omdat deze zich net als de gelijknamige plant snel verspreidt en moeilijk te verdelgen is. Het lek maakt het voor een aanvaller mogelijk om op afstand code uit te voeren op een kwetsbaar apparaat en het op deze manier over te nemen. Canon-dochter Axis bevestigde dat de kwetsbaarheid aanwezig was in 249 van zijn cameramodellen. De fabrikant heeft patches uitgebracht.

Vervolgens nam Senrio contact op met Genivia, dat de gSOAP-code onderhoudt. Dat bedrijf kwam in juni met een patch. Volgens Senrio werd de software dit jaar dertigduizend keer gedownload en zegt Genivia dat er in totaal meer dan 1 miljoen gSOAP-downloads hebben plaatsgevonden. Onder meer Microsoft, IBM en Adobe zijn klanten bij het bedrijf. Senrio zegt dat moeilijk te schatten is op welke manieren apparaten met de lekke software kwetsbaar zijn, maar schat dat 'tientallen miljoenen apparaten' risico lopen. Zes procent van de bij het Onvif-standaardisatieconsortium aangesloten bedrijven zou gSOAP-gebruiken.

Uit een technische analyse van de kwetsbaarheid blijkt dat exploitatie vereist dat er 2,14GB aan data naar een apparaat wordt geüpload. IPVM-expert Brian Karas liet aan onderzoeksjournalist Brian Krebs weten dat de kwetsbaarheid zich niet leent voor het opzetten van een botnet als Mirai. Zo zouden veel apparaten bijvoorbeeld een limiet stellen aan de grootte van uploads en zou het moeilijk zijn een soort universele aanvalstool te ontwikkelen. Daarnaast helpt het om apparaten niet direct via internet benaderbaar te maken. Dat is dan ook het advies van Senrio, naast het uitvoeren van patches.

Reacties (16)

Zo zouden veel apparaten bijvoorbeeld een limiet stellen aan de grootte van uploads en zou het moeilijk zijn een soort universele aanvalstool te ontwikkelen.

Rare argumentatie, dat is het laatste waar ik aan zou denken.

Het feit dat verschillende fabrikanten verschillende software, hardware etc.. gebruiken maakt universele aanvalstool moeilijk en praktisch onmogelijk.

Men zou dus alle merken/versies moeten hebben en per stuk rooten en aanval/shellcode moeten meeleveren inclusief een remote detectie mechanisme om te juiste aanvalscode te kunnen inzetten na identificatie van betreffende hardware/software platform.

Bovendien alleen als aanval afhankelijk is van upload mechanisme zal limiet een rol spelen.
Maar dan is de vraag hoeveel kilobytes je nodig hebt voor aanval en dat zullen geen megabytes zijn voor een reserved shell.


Tenzij je een worm wilt maken die uit zichzelf verder gaat scannen en infecteren en daardoor zoveel mogelijk "bij zich moet hebben".

Maar dan loop je tegen iets anders aan, storage en dat is wel een HARDE limiet.

[Reactie gewijzigd door totaalgeenhard op 19 juli 2017 11:45]

Voor de aanval is al 2.14 GB aan data nodig, zoals aangegeven in het artikel. De grootte van de uploads zal dus vaak het limiet zijn van de aanval. Welke webserver staat immers uploads van vele gigabytes groot toe?

Daarnaast, hoeveel iot apparaten hebben ook zoveel ruimte? Wij gebruiken Axis camera's op het werk, zonder sd-kaart er in, die hebben echt geen ruimte om een 2,14GB payload te downloaden.

Het staat niet expliciet in het artikel of de data echt op het apparaat opgeslagen moet worden. Er staat dat een 'stack buffer overflow' gebruikt wordt, dus ik zou verwachten van niet. Opslag is dus niet van belang, zolang er voldoende RAM in zit.

Ik verwacht ook niet dat er voldoende RAM aanwezig moet zijn, na een kleine steekproef ben ik geen Axis camera's met meer dan 1GB aan RAM tegen gekomen. Het lijkt me dan sterk dat ze 249 camera's hebben die wel over meer dan 1GB beschikken.

Bovendien beschikken de camera's ook over niet meer dan 512MB opslag, een sd-kaart lijkt me dan wel degelijk nodig of het geheugen zou door de library overschreven moeten worden.

Het zijn niet alleen camera's die geïnfecteerd kunnen worden, dat waren enkel de apparaten waarop het getest was. veel meer apparaten gebruiken de gSoap library.

Als het gaat om een stack buffer overflow dan verwacht ik juist wel dat die hoeveelheid RAM aanwezig moet zijn, anders zou de buffer veel eerder al overflow dan bij 2,14GB aan data...

De stack size is doorgaans vrij klein, enkele KB tot enkele MB afhankelijk van de implementatie. Dat komt omdat die data steeds op voorhand gereserveerd is, vandaar de benaming stack, je kan er je data op stacken. :-)
Tot je natuurlijk een oveflow hebt. Data op de heap plaatsen is the way to go.
Tegenwoordig wordt dit in C++ met std::unique_ptr en std::shared_ptr gedaan, dan heb je ook geen gezeik meer met memory leaks.

Het zal dus afhangen van hoe groot de stack size staat ingesteld op het gebruikte toestel, verwacht niet meer dan enkele MB. Daarbij zal andere data ook gebruik maken van de stack dus een stacksize van 2MB betekent niet automatisch dat 2MB nodig is om een overflow te veroorzaken.

On Linux/x86-32, the default stack size for a new thread is 2 megabytes
http://man7.org/linux/man-pages/man3/pthread_create.3.html

De content hoeft ook niet perse gedownload te worden. Je kunt bijvoorbeeld een POST request construeren waarvan de content wordt weggegooid door de handler. Moet je wel een idee hebben wat met de data gebeurt, anders loopt de RAM snel vol...

Ik heb nog wel ooit een webserver gemaakt die backups opsloeg. Je kon gewoon terabytes uploaden naar die server, die analyseerde je tar (voor de file index) en knipte 't in stukjes om naar tape (400GB per stuk) te streamen.

Als je een "streaming" audiospelertje hebt, die krijg in wezen ook een enkele request van gigabytes binnen, maar heeft nauwelijks enige storage.

Al zat er een SD kaart in, Axis configureert geen swap op de SD kaart. Het gevolg is dat bij minder dan 1 GB upload de Linux Out-Of-Memory handler al processen gaat afsluiten. Dat beëindigt dus ook de upload ruim voordat de gevarenzone in zicht komt.

In dit artikel wordt gesproken over IoT (Internet of Things), maar dit zijn toch kleine apparaten die van het NB-IoT (Narrow band) netwerk gebruik maken?

Lijkt me dat dit gewoon een netwerk camera is?, of begrijp ik het gewoon verkeerd?

Dit lijkt me meer M2M communicatie en een koelkast die een berichtje naar je smartphone stuurt een IoT device waarvan het netwerk toch niet toereikend is om 2, 14 GB te versturen

Een IoT device hoeft niet per se van het NB-IoT netwerk gebruik te maken. Een slimme meter die je Wifi netwerk gebruikt is ook gewoon een IoT apparaat. En een Raspberry Pi kan ook een IoT apparaat zijn als die zo is ingesteld.

IoT is uiteraard een extreem gehypte term en iedereen claimt dat zijn "smart" prulleria of "connected" hassle een IoT device is; de meeste definities van IoT vertrekken van iets vaag als "aan een netwerk geconnecteerde apparaten die gegevens uitwisselen" ... dat doen we ondertussen al 70 jaar ofzo, dus echt werkbaar is deze definitie niet.

Voor mezelf hanteer ik de stelregel dat er een interactie moet zijn tussen de fysieke wereld & de "virtuele" (computer) wereld. De bedoeling van IoT is te kunnen interageren met de fysieke wereld "out there", buiten de datacenters van bedrijven of megaspelers zoals Google, Microsoft of Amazon. Het gaat dus over het verzamelen van data uit die omgeving "out there" en er (door het collectief aan data) iets intelligent mee te doen (in de datacenters), en eventueel terug te koppelen naar deze wereld "out there" (sensor/actuator). Je komt zo snel op een interactie tussen devices, een aantal machine learning/big data/AI algoritmes in een datacenter van de verkoper van het toestel, en een eventuele terugkoppeling naar het device/een ander device. Veel troep zoals "smart lighting" valt buiten deze meer praktische insteek op IoT, dat is ook geen echt nieuwe toepassing die enkel en alleen mogelijk is doordat de compute power zo goedkoop is, er overal netwerkconnectiviteit is, of de low power mogelijkheden extreem lange levensduren toelaten etc... (wat ik dan persoonlijk als "onderscheidende kenmerken" zie voor "echte" IoT toepassingen).

Voorts heb ik nog een zeer praktische definitie: if it runs Linux, it is not IoT. Dan heb je een mini computer. En het spijt me, ik verklaar iedereen gek die het in zijn hoofd haalt een minicomputer 24/7 aan het internet te hangen zonder regelmatige patching (en dat zijn toch al snel X MB aan patches per maand, niet heel praktisch voor de "echte" IoT toepassingen die op een AA batterij 20 jaar moeten draaien). Die minicomputers zijn ontzettend nuttig en ik gebruik ze zelf ook elke dag, maar zou nooit durven claimen dat een webserver of python script op een RPi een IoT toepassing is.

Embedded systems/microcomputers/minicomputers... wordt vaak op 1 hoop gesmeten maar een wereld van verschil naar mijn mening. En een totaal andere aanpak naar security...

https://sourceforge.net/projects/gsoap2/ zegt ook genoeg tegenwoordig