Het is niet allemaal slecht nieuws: de aanvallen zijn te pareren, maar ze demonstreren wel de asymmetrische relatie die Bruce Schneier beschrijft: beveiligers hebben een gigantisch (en immer uitdijend) oppervlak om te verdedigen en aanvallers hebben slechts één gaatje nodig om binnen te komen. Beveiliging is om die reden te vaak een reactief vak waarin putten gedempt worden zodra we weten dat er kalveren in kunnen donderen.

Met dat in het achterhoofd kijken we naar de technieken waar aanvallers het afgelopen jaar mee experimenteerden en grote successen mee boekten. Deze methodes houden, met verdere automatisering en mainstream raken ervan, IT-admins en beveiligers de komende jaren aan de bak.

Een gewaarschuwd mens telt voor twee, dus bij deze de trucs die ongetwijfeld populair gaan worden. Laten we beginnen bij een techniek waarvan de impact tot 2020 hopelijk langzaam afneemt, maar die we op grote schaal gaan voelen de komende jaren: PowerShell dat tegen je wordt gebruikt.

1. PowerShell-aanvallen

"PowerShell is een taal die is geoptimaliseerd voor aanvallen", vertelt SANS-deskundige Ed Skoudis die vooral nadelen ziet van de admin-taal. Het enkele maanden geleden verschenen PowerShell Empire demonstreert goed de kracht van de scripts voor aanvallers. Empire zorgt ervoor dat pentesters (en aanvallers) PS-exploits kunnen uitvoeren in een netwerk.

Als je even de tijd hebt is het zeker de moeite waard dit uitgebreide voorbeeld te bekijken waarin UAC wordt omzeild, credentials worden geroofd, rechten worden geëscaleerd en alle andere snode dingen die aanvallers doen als ze actief zijn in een vijandig netwerk.

"PowerShell beperkt toepassingen, maar dat is een veiligheidsfeature, geen beveiligingsfeature", merkt Skoudis op. Die beperking zorgt er namelijk voor dat admins niet per ongeluk scripts met een te brede scope inzetten. De feature is dan ook uit te schakelen door admins die goed begrijpen wat ze doen - en dus ook door aanvallers. Kortom, het maakt de beveiliging niet sterker.

Vorig jaar ging deze techniek mainstream en in augustus verscheen Empire op GitHub. Microsoft reageerde afgelopen zomer al op de relatief nieuwe technieken door PowerShell 5 te voorzien van nieuwe methodes om malafide gebruik van PS-scripts en agents te detecteren en frustreren.

"Er is ook een diepere integratie met AppLocker." Dat zorgt ervoor dat je de rechten van applicaties kunt beperken en daarmee voorkom je alvast dat PowerShell wordt ingezet voor doelen die jij niet op het oog hebt. "Je kunt dat zien alsof je PS-opdrachten op een whitelist zet."

Maar de komende jaren draaien verscheidene organisaties nog oudere versie van PowerShell en je kunt er de donder op zeggen dat aanvallers laterale bewegingen maken en rechten escaleren met behulp van deze technieken. Hierdoor wordt een mogelijk beperkte inbraak op een achteraf servertje een hack met potentieel rampzalige gevolgen voor de bedrijfsvoering - of zelfs de ondergang van de organisatie.

Op beveiligingscongressen dit jaar zullen ongetwijfeld meer presentaties volgen die deels zijn gebaseerd op PowerShell Empire. Deze laat bijvoorbeeld zien hoe malafide macro's langs mailfilters gesmokkeld kunnen worden.

2. Malafide ontwikkelomgevingen

Een nieuwe truc in het arsenaal van aanvallers: vervang de ontwikkelomgeving van developers met een malafide versie. Hierdoor zorg je ervoor dat alle apps die legitieme ontwikkelaars produceren worden gecompileerd met jouw backdoor en in officiële app-stores verschijnen. Dit gebeurde vorig jaar met een nepversie van Xcode, de programmeeromgeving van Apple voor iOS-apps.

Dat leverde een aantal malafide apps op. Vanwege de infectie-oorsprong kreeg de techniek de naam XcodeGhost mee. XcodeGhost demonstreert een nieuwe aanvalsvector: pak de compiler en je pakt alle apps die ermee worden geproduceerd. Dat heeft als bijkomend voordeel dat de malwaremaker zelf geen moeite meer hoeft te doen en de ontwikkelaar de malafide app moet binnenloodsen in een officiële appwinkel.

Daarbij vergroot de aanvaller zijn arsenaal exponentieel: in plaats van enkele losse kwaadaardige apps, laat je vele tientallen in één keer los - soms zelfs van populaire ontwikkelaars. Zo was het grote Chinese WhatsApp-alternatief WeChat een van de verspreiders van malware in Apple's appwinkel. Het gaat dus niet om zomaar apps van kleine ontwikkelaars; WeChat is van Tencent, een van 's werelds grootste internetbedrijven.

"Je vraagt je misschien af waarom ontwikkelaars niet gewoon rechtstreeks van Apple downloaden", zegt Skoudis. "In regio's als China is het qua bandbreedte niet handig om via de officiële Apple-site te downloaden en ontwikkelaars gebruiken al snel een mirror die er redelijk betrouwbaar uitziet." De gevolgen zijn niet beperkt tot de Aziatische markt: legitieme apps met een backdoor-optie verschijnen vervolgens in de internationale App Store.

De altijd heldere securitydeskundige Graham Cluley vertelt over hoe hoe en wat van XcodeGhost en de impact daarvan:

3. Onbetrouwbare third party-library's

Een van de grotere verhalen vorig jaar op beveiligingsgebied was Stagefright. De implicaties van deze bug in een Android-library waren enorm: het gat was door Androids op z'n zachtst gezegd matige patchbeleid een langetermijnprobleem, de kwetsbaarheid was gebaseerd op een geheugensaneringsissue van C++ dat zich ongetwijfeld voordoet op meer plekken in subsystemen en het issue zat in een library die door Android wordt gebruikt om mediabestanden af te spelen.

Dat laatste is een probleem dat we vaker hebben gezien: library's die een kwetsbaarheid bevatten hebben hun impact op een groot aantal systemen. Neem de kwetsbaarheid in glibc, wat een impact had op allerlei Linux-distributies en daarmee een groot aantal embedded apparaten en servers. Het grote voordeel van open source - het vrij delen en leren van elkaars code - heeft als nadeel dat kwetsbaarheden zich repliceren in alle code die op de kwetsbare code zijn gebaseerd of daar gebruik van maken.

Criminelen zijn zich van dit laatste ook bewust en richten zich graag op kwetsbaarheden in library's die op grote schaal worden ingezet, omdat ze malware en exploits cross-platform in kunnen zetten.

Beveiliger Mario Vuksan (voorheen van onder meer Bit9 en Microsoft) vertelt op RSAc dat de oplossing ligt in duidelijkere asset-management als het gaat om het gebruik van code en verantwoordelijkheid van de makers. "Het moet worden zoals je op voedselverpakkingen ziet: software moet aangeven wat er allemaal in verwerkt is, zodat specialisten de code kunnen beveiligen."

Volgens Vuksan kunnen we library-ellende in de toekomst voorkomen met drie stappen:

  1. Inventartiseer welke OS-library's of third party-library's je in jouw omgeving gebruikt.
  2. Zet leveranciers onder druk om kwetsbare library's te upgraden wanneer dat nodig is.
  3. Zorg ervoor dat patchability een vereiste is voor code die je inzet.

Veel aandacht gaat voor deze aanvalstechniek trouwens uit naar open source-code, maar propriëtaire code maakt je niet veiliger (daar komen we in punt 5 nog op terug). We hebben in deze discussie vaak te maken hebben met twee uitersten. Aan de ene kant is dat security through obscurity: de broncode is onduidelijk, dus ook voor criminelen onduidelijk en daarmee zou het veiliger moeten zijn. Aan de andere kant van het spectrum is de code volledig inzichtelijk en aanpasbaar, waardoor iedereen de code beter kan beveiligen en daarmee zou het veiliger moeten zijn. Beide aanpakken hebben hun voor- en nadelen.

4. Complexe, sterk geplande aanvallen

De aanval op Oekraïense elektriciteitscentrales was anders dan andere hacks. Niet vanwege de DoS-implementatie, de malware, de betrokken componenten, de afhankelijkheid van automatisering en gebrek aan redundancy, de laterale bewegingen, de VPN-aanval, het flashen van firmware, het uitschakelen van switches bij onderstations, herprogrammeren van de UPS'en, het wissen van MBR's of een van de andere elementen die de aanval bijzonder maken: het was de grondige voorbereiding, gedurfde aanpak en vastberadenheid van de aanvallers.

Securitybedrijven orakelen graag over het gevaar van Advanced Persistent Threats en devalueren de term zodanig dat iedere malware-infectie gezien wordt als een APT. Maar als er ergens één aanval het etiket APT verdient, dan is het deze wel. Mocht je er de tijd voor hebben, kan ik dit artikel van Wireds Kim Zetter aanraden dat gedetailleerd kijkt naar de hack op de Oekraïense elektriciteitscentrale.

Zetter baseert zich grotendeels op onderzoek van SANS, waar de beveiligers over praten op RSAc. De aanval was overcompleet en grondig voorbereid: de hackers kenden het systeem tot in het grootste detail, waren op de hoogte van alle software- en hardwarecomponenten en konden de reactie van IT'ers en beveiligers voorspellen, zodat ze de pas werden afgesneden.

Zo flashten de aanvallers de firmware van switches zodat ICS-systemen niet benaderd konden worden en zorgden ze dat het netwerk op de hoofdlocatie niet meer functioneerde, zodat het energiebedrijf voor elk generatorstation en onderstation fysiek op locatie de switches moest herstellen.

De methode maakte verder om binnen te komen gebruik van het bijna tien jaar oude, maar niet minder effectieve BlackEnergy (PDF), vrij doorsnee malware die ondergronds te huur is om bijvoorbeeld grote botnets te creëren. Inmiddels is de malware populair en stevig geëvolueerd, zie video hieronder.

Het doel was mogelijk vooral politiek: de aanvallers wilden klaarblijkelijk het vertrouwen in Oekraïense nutsbedrijven ondermijnen. Delen van het land zaten nota bene in een van de koudste maanden van het jaar 6 uur lang zonder energie en de aanvallers hadden het telefoniesysteem onklaar gemaakt, zodat klagers geen gehoor kregen en niet werden geïnformeerd. "Het idee was om mensen zodanig te frustreren dat ze minder vertrouwen hebben in [Oekraïense] systemen", zegt SANS' Ed Skoudis.

Ook opvallend: de volledige aanval op het industriële controlesysteem was netwerkgebaseerd. Het vereiste geen fysieke penetratie, social engineering op locatie en/of het toevoegen van malafide hardware, zoals bijvoorbeeld bij de beruchte ICS-aanval via Stuxnet nog wel het geval was. "Gelukkig was het systeem nog niet volledig geautomatiseerd en waren er nog mensen die handmatig bij de switches konden", vertelt Skoudis. "Nu, drie maanden later, wordt er nog steeds gewerkt om het netwerk weer honderd procent in de lucht te krijgen."

BlackEnergy is een oudje, maar een nieuwe versie is flink gegroeid in populariteit, vooral in Oekraïne en Polen. ESET presenteerde twee jaar geleden over de malware en de reden en impact van diens plotselinge groei.

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.