
5 gevaarlijke nieuwe aanvalstechnieken
Security in 2016: PowerShell-aanvallen, library-sores en compiler-issues.
Diverse beveiligingsdeskundigen merken op RSAc een aantal nieuwe trends op die we vaker gaan zien de komende jaren als het gaat om hacks en aanvalstechnieken, zoals de komst van malafide compilers die alle apps die ermee gemaakt worden voorzien van een backdoor.

5 gevaarlijke nieuwe aanvalstechnieken
Diverse beveiligingsdeskundigen merken op RSAc een aantal nieuwe trends op die we vaker gaan zien de komende jaren als het gaat om hacks en aanvalstechnieken, zoals de komst van malafide compilers die alle apps die ermee gemaakt worden voorzien van een backdoor.
5. Heimelijk aangepaste code
Laten we het ten slotte eens hebben over een stukje code dat admins van Juniper-appliances inmiddels bekend zal voorkomen:
<<< %s(un='%s') = %u
Dit stukje is een call naar een wachtwoord om authenticatie te omzeilen die niet is bedacht door de ontwikkelaars van Juniper (zegt Juniper). Kortom, een heimelijk toegevoegde backdoor door een onbekende partij. De toegangsoptie is goed verborgen: het gaat om een argument die net zo gestructureerd is als veel andere strings die worden gebruikt voor debuggen binnen de code van Junipers ScreenOS.
Volgens hardwarezoekmachine Shodan hadden 26.000 grootzakelijke firewalls - de software wordt onder meer gebruikt door backboneproviders - hadden een openstaande SSH-verbinding naar Juniper-producten.
Het stukje code is in 2013 toegevoegd en twee jaar later opgemerkt door Juniper zelf die erop stuitte tijdens een intern proces. Toen Juniper de melding maakte en de patch uitbracht, ontdekten onedrzoekers van het Nederlandse Fox-IT en onafhankelijk daarvan Rapid7's HD Moore al snel het wachtwoord. Je kunt er gemakkelijk vanuit gaan dat criminelen dat ook snel uitgevogeld hebben. De NSA zou het zelfs al enkele jaren weten.
Het enge van deze 'ongeautoriseerde code' is dat het is teruggevonden binnen Junipers eigen codebronnen. Onlangs had je bijvoorbeeld ook dat aanvallers een Linux Mint-ISO op de officiële downloadbron wisten te vervangen voor hun gebackdoorde versie, maar het inbreken via WordPress is heel andere koek dan het aanpassen van een interne en niet te vergeten propriëtaire bron.
Was het in het geval van de Juniper-backdoor een hack van buitenaf, een toevoeging door een malafide insider of toch een onzorgvuldigheid van een ontwikkelaar? Het zou al geholpen hebben als commits genummerd werden, zoals SANS oppert, zodat codeblokken kunnen worden herleid naar de auteur. Zulke enumeratie zou niet alleen helpen om onbetrouwbare code op te sporen, maar geeft ontwikkelaars ook meer inzicht in moment van wijziging.
Naast de comments die je aantreft in de code, zorgt dat voor een betere houvast om te zien of bepaalde delen van de programmatuur nog relevant zijn. Bovendien draagt het bij aan de punten van Mario Vuksan: het zou beter zijn als we net als bij voeding goed zicht hadden op de exacte content van code, zonder dat we het wel heel grondig moeten begrijpend lezen, als dat al überhaupt mogelijk is.
voor libraries zijn jullie er nog een vergeten. Wat te denken van alle referenties die allerlei websites maken naar bv. google (of andere) letter typen, java script code die van derden site opgehaald wordt. DNS injection is niet onmogelijk dus omleiden van sites naar andere servers waar alternatieve code staat zal ook vervelend zijn.
Reageer
Preview