Rapport från en provtryckning av AS/400

Den tänkta IBM Business partnern som skulle leverera den IBM iSeries som vi skulle provtrycka drog sig ur. Med mycket kortvarsel lyckades arbetsgruppen för Expeditionen i Marienlyst att få fram en ny IBM Business partner som kunde ställa up.

För att genomföra denna aktivitet, var det inte på något sätt viktigt att namnge den IBM business partner som ställde upp, men eftersom Systeam själva marknadsförde sig inom ramen för denna aktivitet, så vill jag passa på att rikta ett stort tack till dem.

Den maskin som vi fick levererad var en AS/400 modell 170 (proc #2159, 700Mb RAM & 12 Gb DASD) med OS/400 V4R4M0 PTF-nivå 00252 och WebSphere V3R5. Vi hade inte vetskap om detta under provtryckningen. Under resans gång fick vi vetskap om att Systeam hade ett egentillverkat program för att "låsa till" maskinen ytterliggare, något som vi anade eftersom maskinen var förvånansvärt tät.

Maskinen anslöts till ett 10 Mb/s Ethernet som fanns draget i utställningen på Expeditionen i Marienlyst. Till det nätet anslöt vi (Certezza & Vigilante) fyra egna datorer med diverse verktyg.

Inledningsvis körde vi portscanningar för att se vilka tjänster (portar) som maskinen svarade på. Vi kunde identifiera standardportarna för http (TCP80) och DNS (UDP53 & TCP53). Dessutom hittade vi en några statiska portar såsom TCP900, TCP9000 och TCP9001 samt en rad dynamiska portar såsom TCP5140 TCP5142 TCP5148 TCP5156 TCP5158 och TCP5168. Det "luktade" WebSphere. Under portscanningen noterade vid scanntider för scanning av samtliga portar (65.535 st) och 10.000 st. Tiderna var låga, ca 2 min för att scanna samtliga TCP-portar. En orsak till detta är att maskinen skickar RST-paket på de SYN-paket som skickas till okända portar. Om detta hade varit en brandvägg, så hade detta varit negativt. Man brukar frångå standarden, och därmed inte besvara anrop till okända portar. Något som gör portscanning betydligt svårare.

Nästa steg var givetvis att penetrera de upptäckta tjänsterna för att se om dessa hade några sårbarheter. Följande sårbarheter kunde vi identifiera:

WebSphere kraschade vid Denial of Service-attack (data flood) - hög risk
- Verkar kräva en IPL för "komma på fötter" igen
TCP Sequence Number Predictable - medium risk
- Sekvensnumren slumpas i liten variation (nmap ~150)
DNS Zone Transfer - medium risk
- Begränsad till en början (?), fungerade utan begränsningar efter ett tag
Access till DNS programmets stack - medium risk
- Namnservern svarar på den felaktiga förfrågan, men svaret "verkar" ofarligt
IBM http-server ger mycket information - låg risk
- 5769-DG1 Version 4 Release 3 (?!?!?)
- Originalhosten är troligen web.solna.systeam.se 10.0.16.111
Svarar på traceroute - låg risk - Både ICMP och UDP
ICMP timestamp - låg risk

Våra spontana kommentarer efter provtryckningen var följande:

Den testade datorn är tätad

• ex "http put" är otillåtet
• Den använder en felaktig DNS (10.0.1.4)
• Långsam reverse lookup
• Den öppnades upp för att kunna genomföra pass 27B
• Bland annat för SNMP, Telnet & NetBios
• Det hade varit intressant att testa den med dessa förändringar
• Vad hade en ny version av OS och WebSphere inneburit?

För att avrunda och summera denna aktivitet så kan vi konstatera att den testade datorn var oväntat stabil. Vi lyckades inte med någon form av intrång under de 10 timmar vi provtryckte datorn. Däremot lyckades vi som sagt får WebSphere att krascha så totalt att det krävdes en IPL för att kunna använda WebSphere igen. Enbart en omstart av WebSphere räckte inte. Om den testade datorn hade frontats med en korrekt konfigurerad brandvägg, så hade denna attack inte lyckats.
Har ni frågor eller funderingar kring denna aktivitet, tveka inte att kontakta mig. Enklast via thomas@certezza.net.

©2001 Thomas Nilsson, Certezza AB