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 , , 32 reacties

De organisatie Swift waarschuwt dat er meer incidenten hebben plaatsgevonden, waarbij interne en externe partijen in staat waren om Swift-berichten vanuit financiŽle instellingen te versturen. Aanleiding voor het bericht is de bankroof in Bangladesh, waarbij 81 miljoen dollar is buitgemaakt.

Swift-logoDe waarschuwing van Swift werd vertrouwelijk via het interne netwerk verstuurd, zo weet Reuters te melden. In het bericht zou de organisatie echter niet ingaan op de getroffen instellingen en op de waarde van de uitgevoerde transacties. Swift gaat echter wel in op de methode die is toegepast bij de bankroof in Bangladesh.

Zo noemt de organisatie dat de aanvallers in dat incident in staat waren om geldige inloggegevens van een medewerker te bemachtigen, die was geautoriseerd om Swift-berichten aan te maken en goed te keuren. Op die manier konden de aanvallers zelf berichten versturen en opdracht geven tot het overboeken van grote bedragen. Swift heeft ook een beveiligingsupdate uitgebracht, die klanten voor 12 mei moeten installeren. Het is onduidelijk wat de inhoud van de update precies is.

Beveiligingsonderzoekers laten aan Reuters weten dat de verwachting is dat er meer van dit soort aanvallen aan het licht zullen komen. Aan de ene kant omdat de waarschuwing van Swift ertoe zal leiden dat instellingen een intern onderzoek uitvoeren en aan de andere kant omdat andere criminelen naar aanleiding van de hack en de buitgemaakte bedragen zullen nagaan of zij eenzelfde aanval kunnen uitvoeren. De mogelijke winst zou in verhouding namelijk zeer groot zijn.

Maandag meldde beveiligingsbedrijf BAE Systems dat het bij de bankroof in Bangladesh om een zeer geavanceerde aanval ging, waarbij speciaal aangepaste malware werd ingezet. Deze was geschreven voor de Swift-clientsoftware 'Alliance Access', die bij sommige instellingen in gebruik is. Daarmee waren de aanvallers in staat om zelf betaalopdrachten naar Filipijnse rekeningen uit te voeren, ter hoogte van 81 miljoen dollar. Andere overschrijvingen, die in totaal opliepen tot 951 miljoen dollar, werden tegengehouden doordat een bankmedewerker een spelfout tegenkwam in de naam van de ontvanger.

Moderatie-faq Wijzig weergave

Reacties (32)

Zo noemt de organisatie dat de aanvallers in dat incident in staat waren om geldige inloggegevens van een medewerker te bemachtigen, die was geautoriseerd om Swift-berichten aan te maken en goed te keuren.

Waarom kan hij/zij beide? Dat is niet bepaald de manier om veilig te werken...
Dat is niks nieuws. Zonder namen te noemen; ik heb een tijdje bij een kleine bank gewerkt (gedetacheerd) en zelfs ik had toestemming/toegang tot de SWIFT-omgeving om bepaalde troubleshooting te doen en aanpassingen te maken.

Procedureel gezien moest ik een aanpassing door een vaste medewerker laten controlen en mocht ik 'm daarna pas doorvoeren; maar zoals dat vaker gaat met ICT'ers, is soms de business belangrijker dan het proces en zeker in vakantie-periodes, was er enige vrijheid om een goedkeuring zelf door te voeren.

Daarnaast is/was het volledig niet ondenkbaar dat je een verkeerde overboeking deed; stel dat T.net een SWIFT-account heeft met de opeenvolgende betaalnummers TWEAABN1, TWEAABN2 en TWEAABN3, dan is het relatief simpel/overzichtelijk om bij een tikfout het verkeerde rekeningnummer in te voeren. De betaling wordt daardoor niet geblokkeerd maar kan op de lopende rekeningen van T.net wel een enorme impact hebben.
Rekening nummers zijn bestand tegen tikfouten omdat ze moeten voldoen daan de elfproef. https://nl.m.wikipedia.org/wiki/Elfproef

Je moet dus wel een paar typefoutjes maken ;)
Echter hebben we het hier niet om nederlandse rekening nummers, maar om SWIFT een internationaal betalings systeem, waar deze elfproef niet werkt.
Ahh ok! Dat las ik niet uit zn bericht. Heeft swift dat niet? Dat is vrij onhandig
Je verwart het type rekeningnummers. SWIFT is heel wat anders dan wat je in de Elfproef beschrijft.

Voorbeeld bank: JPMorgen Chase Bank
SWIFT-code: 8-letter swift code: CHASUS33 / Branch code: XXX

Het zijn dus opeenvolgende nummers die geen referentie hebben met een geadresseerde; uiteindelijk is de begunstigde "JPMorgen Chase Bank".

Aangezien de XXX in bovenstaande kan worden gevuld met 36^3 karakters, is een type-fout dus wel ontzettend snel gemaakt.

[Reactie gewijzigd door MAX3400 op 26 april 2016 09:51]

Idd, mijn vrouw kon tot voor kort tot 600 miljoen overschijven omdat ze als project manager de productie omgeving moest helpen rechthouden bij problemen en de (grote) baas haar zijn login had gegeven.

Lekker veilig.
stel dat ze dat doet. Dat wordt dan toch ontdekt mag ik hopen???? En als het ontdekt wordt, kan het toch wel terug komen?? Of is het dan ook echt mogelijk dat zo'n bedrag werkelijk naar een bank 'verdwijnt' op een tropisch eiland gaat en dat je daar dan gaat rentenieren???
Delen van dat bedrag en daders vinden ze af en toe . Crelan in belgie verloor 70miljoen onlangs, weet van fortis van vroeger dat die 120 miljoen kwijt waren.

Iets van 3/4 kon toen teruggevonden worden.

Ik denk dat een wat goed georgansieerde dievenbende een groot deel van zo'n bedrag wel kan houden, alleen zonder enige connecties en handlangers lijkt me dat heel moeilijk.
Voor een bedrag van 600 miljoen loont het de moeite voor een dievenbende om een complex plan te bedenken en uit te voeren om het geld te laten "verdwijnen" nadat het is buitgemaakt.

Met een beetje gezond verstand kun je op je vingers uittellen dat de bank die je besteeld er een keer achter komt wat er is gebeurd en dan zal proberen om het geld terug te krijgen. Dus ligt het voor de hand dat een organisatie die de moeite heeft genomen om een banksysteem te hacken ook de moeite zal nemen om het gestolen geld goed te verbergen. Anders is alle moeite voor niks geweest tenslotte. Je moet wel je investering beschermen he.
In het artikel van Reuters staat:
It said the attackers obtained valid credentials for operators authorized to create and approve SWIFT messages, then submitted fraudulent messages by impersonating those people.
Alsnog niet duidelijk of er medewerkers zijn die beide rechten hebben.
Wellicht wel, maar op zich maakt dat niet uit als je beide profielen hebt gehacked (en al dan niet hebt samengevoegd - hoe de hack is uitgevoerd is bij mijn weten niet bekend).
Zal wel een manager zijn die vindt dat hij boven het veiligheidsgeneuzel verheven is.
Zo noemt de organisatie dat de aanvallers in dat incident in staat waren om geldige inloggegevens van een medewerker te bemachtigen, die was geautoriseerd om Swift-berichten aan te maken en goed te keuren.
Het grote probleem is dat er nauwelijks beveiliging zit in de swift software zelf. Deze is volledig afhankelijk van de beveiliging eromheen.

In dit geval is de aanval waarschijnlijk getriggerd via goedkope '10 dollar' switches welke de bank overal in gebruik had.

Ook de gebruikte methode heeft zich ontwikkeld van een standaard overboeking/diefstal tot een gemaskeerde geautomatiseerde overboeking/diefstal.

Hopelijk wordt het centrale transactieverkeer eens eindelijk beter beveiligd en incidenten niet onder de tapijt geveegd.....

edit: Bloomberg heeft ook nog een mooi stukje:
http://www.bloomberg.com/...wo-weeks-before-big-heist
We benadrukken dat het SWIFT netwerk zelf niet gehacked is....
is de officiele verklaring van SWIFT.
....maar niks over het gemak waarmee de SWIFT software gemanipuleerd kan worden welke de transacties verwerkt.

[Reactie gewijzigd door kwakzalver op 26 april 2016 09:14]

Ik denk dat Swift hun systemen zo moet aanpassen dat ze niet meer vertrouwen op wat een aangesloten bank als beveiliging op hun onderliggende systemen heeft.

Alles over een VPN die vanaf de Swift kant wordt afgedwongen, een hardcoded CA afgedwongen door Swift, etc. etc. Het zal niet alles oplossen maar wel de ergste risico's indammen.

Kennelijk kun je niet van elke aangesloten bank verwachten dat ze zelf hun zaakjes wel op orde hebben.
Hoe ga je dit oplossen ?

Ergens moet je van een intern systeem van een bank interfacen met het SWIFT SAA product.
Bijvoorbeeld via een Messaging infrastructuur (MQ) dat in handen ligt van de bank om dit ook secure te maken. Als een attacker hier geldige logins voor te pakken krijgt kan hij ook berichten laten versturen over het SWIFT netwerk. Je moet hiervoor geen geldige logins hebben op het SWIFT product zelf. Met andere woorden, de gehele ketting is maar het sterkst bij de zwakste schakel. En veel van deze schakels liggen bij de verantwoordelijkheid van de bank.

Als ik een vergelijking maak met het bitcoin network, de infrastructuur zelf is zeer secure (tot nu toe nog geen manier gevonden om het protocol zelf te hacken) maar alle diefstal rond bitcoin komt door het feit dat de private keys konden achterhaald worden die gestockeerd zijn op externe servers/locaties die op zich gehacked zijn. Dus in de peripherie alweer...
Een van de problemen in dit specifieke geval is dat de hackers de integriteitscontrole van de Swift software hebben uitgeschakeld. Dat zijn zaken die Swift zelf beter kan beveiligen, zij maken immers die software. Het is dan ook niet verwonderlijk dat Swift hier op gereageerd heeft met een software update.

Uiteraard kan Swift weinig doen aan gelekte logins bijvoorbeeld. Maar het allerminste is wel dat ze hun eigen infrastructuur op orde hebben.
Ik had toch wel verwacht dat ze twee-factor authenticatie gebruiken voor het inloggen op de SWIFT software. Of is da teen hele rare gedachte?
De hackers wisten erg goed waar ze mee bezig waren. Het moeten haast wel mensen geweest zijn die zelf in IT in de financiele sector gewerkt hebben. Ze hadden gedetailleerde kennis van de Swift system maar ook van compiance afdelingen binnen banken. Ze hebben gebruikt gemaakt van legitieme transacties waar ze de begunstigde hebben veranderd. Ze hebben de transactielogs in de database aangepast zodat het onzichtbaar was voor gewone gebruikers. Ze hebben er zelfs voor gezorgd dat de printer die alle transacties op papier print zodat ze door een audit team gecontroleerd kunnen worden juist de frauduleuze transacties oversloeg.

Dit is wel een aardig artikel wat er wat dieper op in gaat:
http://arstechnica.co.uk/...ladesh-hack-typo-details/

[Reactie gewijzigd door Maurits van Baerle op 26 april 2016 11:16]

Aan de andere kant zijn ze zo dom hebzuchtig geweest om zo idioot veel te willen buitmaken. Was 81 mio echt niet genoeg 8)7 ? Om hoeveel man ging het helemaal? Nu lopen ze het risico dat wordt achterhaald wie het zijn geweest. Anders waren ze gewoon klaar geweest.

Maar dat zie je wel vaak bij criminelen, ze zijn heel gewiekst in hun criminele gedrag maar tegelijk zo dom als het achtereind ve varken. Door de hele buit te verkwisten aan over the top luxe bullshit. Terwijl ze ook gewoon klaar waren geweest.
Maar hoe kan SWIFT op afstand zien of een transactie legaal of illegaal is ingevoerd? Als ie authorisatie van een toegestane sleutel heeft, dan is het in principe legaal. Dat die sleutel niet door de eigenaar gebruikt is, is een probleem waar SWIFT zelf geen invloed op heeft.
Je kunt niet alles afdekken vanuit de Swift kant uiteraard. Als er login gegevens zijn uitgelekt kun je daar weinig tegen doen.
Als IT leek kan ik al meerdere methodes bedenken die het in elk geval moeilijker maken om met gestolen login gegevens illegale transacties uit te voeren, zoals:
  • Two step authoristation
  • Linken van user aan IP adres
  • Linken van user aan hardware security certificaat
Een combinatie van two step authorisation en linken van user aan hardware security certificate (op user computer level, niet op bank server level) lijkt mij een zeer geschikte methode.

Aan de andere kant is dit zo voor de hand liggend dat ik me nauwelijks kan voorstellen dat zoiets niet al standard onderdeel uitmaakt van het betalingsverkeer. Bij internetbankieren is two step authorisation bv al standaard.
[...]
In dit geval is de aanval waarschijnlijk getriggerd via goedkope '10 dollar' switches welke de bank overal in gebruik had.
Dit lees ik overal, maar toch heb ik hier mijn twijfels bij. Een managed switch kost niet echt 10 dollar. Voor 10 dollar heb je een heel simpele switch die bijna hardwarematig switched
Klein destail: 2e hands en Bangladesh, ietwat andere markt dan hier.
Wat ik begrijp is het probleem eerder dat ze niet managed (te goedkoop voor managed) waren. Omdat het simpele huis tuin en keukenswitches waren hadden ze geen VLAN mogelijkheid en ging het Swift verkeer dus over hetzelfde netwerk als ander verkeer.
De vraag is kan je Swift dan verantwoordelijk houden voor de bankroof van 81 miljoen?
Dit is toch onmogelijk te verzekeren lijkt me
Kun je Microsoft verantwoordelijk houden dat je schade lijdt doordat via hun software malware binnenkomt?
Andere overschrijvingen, die in totaal opliepen tot 951 miljoen dollar, werden tegengehouden doordat een bankmedewerker een spelfout tegenkwam in de naam van de ontvanger.
Deze medewerker verdient wel een bonus :P
Op zich verdient de goede man/vrouw zeker een schouderklopje voor goed werk, maar dit is precies waarvoor je fraude-analisten in dienst hebt.
Dit zou toch op te lossen zijn met een extra verificatie via two tier, zoals een telefoon/random reader/tokenizer, of denk ik te simpel? Als ze alleen al met TAN-codes zoals ING zouden werken, dan heb je helemaal niks aan alleen een username en password!

[Reactie gewijzigd door Luuk1983 op 26 april 2016 11:18]

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