4. De communicatie met de bank
4.1 Zend- en ontvangstqueues
In de directories HNWIN\EXE\SEND en HNWIN\EXE\RECEIVE worden elke communicatiesessie een aantal bestanden geschreven: in SEND voordat de communicatie gestart wordt, in RECEIVE de bestanden die van de bankcomputer worden ontvangen.
Het formaat van deze bestanden is over het algemeen UN/EDIFACT. UN/EDIFACT is een door de Verenigde Naties ontwikkelde standaard voor electronische uitwisseling van handelsdocumenten. EDIFACT staat voor Electronic Data Interchange For Administration, Commerce, and Transport. De syntax van UN/EDIFACT wordt gedetailleerd beschreven in de standaard ISO-9735.
Hieronder zullen enkele voorbeeldbestanden nader worden geanalyseerd.
Sommige bestanden hebben de extensie ~tx terwijl het hier gewoon tekstbestanden betreft. De reden hiervan is niet geheel duidelijk. Mogelijk is geprobeerd te voorkomen dat Windows gebruikers deze bestanden kunnen openen door er op te dubbelklikken (zoals dat met bestanden met de extensie txt mogelijk is).
Sowieso is het niet geheel duidelijk waarom deze bestanden - die puur bedoeld zijn voor gegevens die verzonden moeten worden of gegevens die in de database worden geïmporteerd - eerst op de harde schijf worden opgeslagen, met alle risico's van dien.
4.1.1 De zendqueue
connect.txt
connect.txt is een ASCII bestand wat met nullen opgevuld wordt tot 24 bytes.
Het bestand bevat altijd de volgende data:
A;VIAEBT-10KZ;SET1:0+
login.txt
login.txt is een binair bestand van 82 bytes. Twee voorbeelden staan hieronder. Het betreffende contractnummer was 1023062379, hetgeen duidelijk is terug te zien.
00000000 4C4F 4E31 3032 3330 3632 3337 3930 3141 LON102306237901A
00000010 5A4D 0DB3 47A8 0F25 CD65 9A07 4910 A4E8 ZM..G..%.e..I...
00000020 698A 9249 C688 B2B1 3632 E3F1 12AF 3074 i..I....62....0t
00000030 CF04 7423 50F2 365E 7CC9 1867 9E33 31D1 ..t#P.6^|..g.31.
00000040 B9F4 114D AFFA AFDD A27D 22DC D30F 9237 ...M.....}"....7
00000050 9496 ..
00000000 4C4F 4E31 3032 3330 3632 3337 3930 3141 LON102306237901A
00000010 5A4D 04C2 FC65 87B3 EAE0 AB8F 9EE3 E257 ZM...e.........W
00000020 0C31 44AF 0746 8ECD 843D D91E CE1F 90C7 .1D..F...=......
00000030 4746 4900 0A42 EB5E 3C0F 16FD 137F 9577 GFI..B.^<......w
00000040 C9AF 7A68 E8A8 79CB 5D17 981F 9FB7 5698 ..zh..y.].....V.
00000050 2A83 *.
opd.~tx en opd.zip
opd.txt is een ASCII EDI bestand. Vreemd genoeg bevat opd.zip dezelfde data als het opd.~tx bestand, behalve dat op de eerste regel, na de tekst 'OPD', nog een achttal bytes is tussengevoegd. Byte 5 en 6 hiervan bevatten de lengte van het bestand (minus deze 8 bytes, minus 3 bytes voor 'OPD').
OPD
UNB+UNOA:2+102306237901:ZZ+000000000102:55+000716:192331+01010027'
UNH+1+PAYAAB:2:912:UN:171002'
SEC+AUT++HEX+AS8'
NAD+MS+01'
RFF+SSN:1'
DTM+STS:000716192331:202'
ALG+OSY:0+IVC:0000000000000000'
SLK+S+1'
BGM+451+01010027000270'
BUS+DO+++BGI+0'
FII+OR+0460379119'
FII+BF+0006006851:ODEKERKEN:CAPELLE AD IJSSEL+PCGDNL2A:25:5'
DTM+203:20000716:102'
MOA+7+9:2,50:NLG'
FTX+PMD+++JA'
SLK+T+1'
RST+000000000000'
UNT+17+1'
UNZ+1+01010027'
sre.cnt
sre.cnt is een ASCII bestand van 8 bytes, wat een teller lijkt te bevatten. De inhoud lijkt gelijk aan het aantal te versturen betalingsopdrachten, bijvoorbeeld
00000001
sre.in
sre.in is eveneens een ASCII bestand wat louter cijfers bevat. Het wordt alleen aangemaakt wanneer sre.cnt ongelijk aan nul is. Het bestand is 64 bytes groot en bevatte bijvoorbeeld
4867348623870036325451783510230623790100071619233100000000000000
of
4858265416587573104491167810230623790100071619584100000000000000
Wanneer goed naar deze reeksen wordt gekeken valt op dat alleen de eerste 26 cijfers niet iets voorspelbaars bevatten. Daarna volgt namelijk het contractnummer (1023062379), het zogenaamde postbusnummer (01), de datum als yymmdd (000716, 16 juli 2000), en het tijdstip als hhmmss (192331 respectivelijk 195841).
4.1.2 De ontvangstqueue
asb.zip
Dit bestand lijkt altijd de tekst ASB te bevatten, gevolgd door 8 nul-bytes.
ab.~cm en rab.~tx
Vermoedelijk wordt rab.~tx gegeneerd aan de hand van rab.~cm. Deze laatste bevat binaire data en is (in dit geval) 6125 bytes groot, terwijl tab.~tx (in dit geval) 7389 bytes groot is en ASCII EDI data bevat. Dit bestand bevat de mutaties die op de rekening zijn gedaan.
rab.~tx begint met de tekst 'RAB', onmiddellijk gevolgd door blokken EDI (één per mutatie) die er als volgt uitzien:
UNB+UNOA:2+000000000229:ZZ+102306237901:ZZ+000621002518+6721'
UNH++SWIAAB'
SWI+MT940:001:ABNANL2A ::20:8632658/0023498
:25:460379119
:28:17201/1
:60F:C000619NLG2221,81
:61:0006200620D300,00N361NONREF
:86:GELDAUTOMAAT 20.06.00/18.37UUR
PICASSOPAS CAPELLE AD IJ,PAS013
:62F:C000620NLG1921,81
:86:/EUROX/NLG2,20371
-XXX
'
UNT'
UNZ+1+6721'
4.1.3 Manipulatie van de gequeuede bestanden
Zoals vermeld worden de te verzenden bestanden al bij aanvang van de communicatiesessie ongecrypt op disk klaargezet. Dit geeft een programma wat verborgen op de PC van de gebruiker zou kunnen draaien ruimschoots de gelegenheid om deze bestanden te manipuleren: zodra een nieuwe opd.zip wordt geschreven zou een dergelijk programma dit kunnen detecteren en een gewijzigde versie neerzetten, waarin bijvoorbeeld een extra betalingsopdracht is toegevoegd. Deze opdracht wordt vervolgens ongemerkt door de gebruiker verzonden.
Bovenstaand scenario is in de praktijk getest door handmatig wijzigingen in opd.zip aan te brengen terwijl HomeNet stond te wachten tot de response van de calculator werd ingetoetst. Helaas was dit niet succesvol. De opdracht werd door de bank geweigerd met de boodschap 'De handtekening van de interchange is foutief', met foutcode 0406. Hoogstwaarschijnlijk wordt er een signature meegezonden in het bestand sre.in, waardoor de bankserver heeft ontdekt dat er met de inhoud van opd.zip gerommeld was. Doordat de opbouw van dit bestand ons niet geheel duidelijk is geworden, was het niet mogelijk de inhoud van dit bestand te manipuleren.
4.2 Het FTP protocol
De communicatie tussen HomeNet pakket en de bankcomputer verloopt via het FTP protocol, met als verschil dat TCP poorten 41 en 42 worden gebruikt in plaats van de standaard poorten 20 en 21. Dit detail leidt er wel toe dat veel mensen met een PC achter een firewall HomeNet niet kunnen gebruiken. Volgens de HomeNet helpdesk zijn de alternatieve poorten gekozen om beveiligingsredenen, welke redenen dit precies waren werd echter niet duidelijk.
4.2.1 Opslag van IP adressen
Het bestand telecom.ini bevat onder meer een lijstje van addressen waaronder de bankserver op Internet te bereiken is:
NUMBEROFHOSTNAME=4
HOSTNAME1=viaebt.eb.abnamro.nl
HOSTNAME2=viaebt1.eb.abnamro.nl
HOSTNAME3=193.172.44.45
HOSTNAME4=194.151.107.44
HomeNet zal dit lijstje bij elke communicatiesessie sequentieel afgaan; wanneer de bankserver onder een bepaalde entry niet bereikbaar blijkt, zal de volgende entry in de lijst worden geprobeerd.
Zoals te zien is wordt er gebruik gemaakt van zowel hostnames als IP adressen. Het probleem met het gedecentraliseerd opslaan van IP adressen is dat het onder sommige omstandigheden noodzakelijk kan zijn deze IP adressen te wijzigen. Vanuit het oogpunt van flexibiliteit verdient het daarom aanbeveling om hostnames te gebruiken - deze worden op een centrale plaats (de DNS server op Internet) vertaald naar IP adressen. Wanneer het IP adres wijzigt, zal de hostname eenvoudigweg naar het nieuwe IP adres verwijzen.
Veiligheid en flexibiliteit gaan vaak niet hand in hand. In de praktijk is gebleken dat DNS servers niet altijd vertrouwd kunnen worden; wanneer een DNS server gecompromitteerd wordt is het mogelijk om valse informatie terug te sturen waardoor de client geen contact opneemt met de bedoelde machine, maar met de machine van de aanvaller. Deze kan zich dan voor bankserver uitgeven en de datastream (al dan niet gewijzigd) doorsturen naar de echte bankserver. Een dergelijke aanval wordt een man-in-the-middle attack genoemd.
Het op deze manier opslaan van de adressen van de bankserver brengt dus twee risico's met zich mee:
- Omdat de hostnames vóór de IP adressen opgeslagen worden, zal een valse DNS entry altijd werken. Wanneer de IP adressen eerst in de lijst zouden staan, zou een valse DNS entry alleen dan werken, wanneer beide IP adressen gewijzigd zouden zijn. (Dit is in de geschiedenis van HomeNet nog nooit gebeurd).
- Door het opslaan van deze gegevens in een plain text bestand is het zeer eenvoudig om deze gegevens ongemerkt te wijzigen (bijvoorbeeld door middel van een virus of trojan horse).
4.2.2 Man-in-the-middle attack
Het is mogelijk om de communicatie tussen bank en PC om te leiden door een derde machine. Het dataverkeer blijkt gecrypt, waardoor het niet eenvoudig mogelijk is om gegevens te wijzigen. Wel heeft dit ons in staat gesteld om op simpele wijze het FTP-verkeer tussen HomeNet en de bankserver af te kunnen luisteren.
De HOSTNAME1-entry in het INI-bestand is hiertoe gewijzigd in het IP-adres van een machine die een (zelfgemaakte) transparante FTP proxy server met logfaciliteiten draaide op poort 42. Alle data van de client wordt naar de bankserver doorgezonden, en alle data die van de bankserver wordt ontvangen, wordt doorgestuurd naar de client. Hiertoe dient de proxy de FTP PORT commando's, die het IP-adres van de client bevatten, te wijzigen, zodat het dataverkeer ook via de proxy verloopt.
Overduidelijk bevat het in de applicatielaag gebruikte protocol geen beveiliging tegen dit soort attacks, terwijl ze toch op vrij simpele wijze te voorkomen zijn. Zo zou HomeNet in de ge-encrypte data het IP-adres van de bankserver kunnen meesturen (of zelfs de data aan de hand van onder meer het IP-adres van de bankserver kunnen encrypten), zodat het snel duidelijk zou worden dat HomeNet met een heel ander IP-adres communiceert dan dat van de bankserver. Wanneer het protocol over dergelijke eigenschappen zou beschikken, zouden man-in-the-middle attacks slechts mogelijk zijn met behulp van IP-spoofing - een veel moeilijker te realiseren aanval.
