Sicherheitsproblem "Kennwort knacken"

[loeweadolf]

Ein Mitarbeiter eines Kunden hat ein Auswertungsprogramm erstellt (PC), mit dem der Netzwerk-Datenstrom (netzwerklogger) ausgewertet werden kann.
Alle Anmeldungen über Client Access an der AS/400 werden ausgefiltert und in Klarschrift sind alle Anmeldungen und Kennwörter zu erkennen.

Ist dieses ein bekanntes Sicherheitsproblem ? Was kann dagegen unternommen werden ?

mfg. Ludger

[Fuerchau]

Das ist ein allgemeines Problem, wenn ohne Verschlüsselung gearbeitet wird, da ja die Eingabe des Kennwortes auf dem 5250-Schirm keine Autentifizierung (wie Windows) ist.
Stelle im Sitzungsprofil "Anmeldung umgehen" ein, dann wird die CA-Anmeldung für die Sitzung verwendet.

Ansonsten:

Stelle CA auf SSL-Verbindung um, und schon wird der gesamte CA-Verkehr verschlüsselt (nicht nur der 5250-Strom sondern auch ODBC/OLEDB).

[loeweadolf]

Könntest Du mir einen Tipp geben, wie CA auf SSL-Verbindung umgestellt werden könnte ?

[Fuerchau]

Das habe ich noch nicht gemacht, aber schau mal unter http://www-1.ibm.com/servers/eserver/iseries/access/

[loeweadolf]

Ganz einfach scheint die Angelegenheit wohl nicht zu lösen zu sein. Aufgrund der obigen Antworten hat der Mitarbeiter des Kunden Stellung bezogen. Dieser Mitarbeiter ist kein AS/400-Spezi, kennt sich aber ganz gut aus mit Netzwerken, Windows + PC. Vielleicht könnte jemand zur Lösung zu diesem Thema noch was beitragen ?

mfg. Ludger

Hallo,

Einstellen in Client Access, dass die Netzwerkanmeldung direkt für die AS/400 übernommen wird und keine gesonderte AS/400-Anmeldung erforderlich ist
Stimmt so nicht, mit der Windows-Netzwerk-Anmeldung meldet man sich erstmal nur am Windows-Netzwerk an, sonst nichts (d.h. man authentifiziert gegenüber dem eigenen PC bzw. NT-DomainControllern). AS400, was zufälligerweise auch im Netzwerk steht, bekommt davon gar nichts mit. Mit dieser Anmeldung kann man dann auf die Windows-Netzwerk-Dienste zugegriffen werden, z.B. freigegebene Verzeichnisse, Drucker usw., viel mehr erstmal nicht.
Nicht zu den Windows-Netzwerk-Diensten gehören allgemeine Netzwerk-Dienste wie Mail (pop3/smtp), FTP, SSH, Telnet usw., hier muss man sich für jede Sitzung separat am Mail/FTP/SSH/Telnet-Server anmelden. Es ist z.B. klar, daß man beim Abholen der Mail vom Provider auch ein Kennwort im Mail-Client eingeben muss, obwohl die Anmeldung am Windows-Netzwerk durchgeführt wurde. Das gleiche gilt auch für FTP, SSH usw. und eben eben auch für Telnet-Sitzungen, die die Basis von ClientAccess-AS400-Sitzungen sind.

Nun könnte man sicher Programme basteln (die gibt's wohl auch), mit denen bei der Anmeldung am Windows-Netzwerk auch gleich eine Telnet-Sitzung (oder Mail/FTP...) zu einem beliebigen weitern Server hergestellt wird, die dann unsichtbar im Hintergrund "schlummert". Bei einer folgenden AS400-Sitzung verbindet man sich dann statt mit AS400 mit dieser "schlummernden" Sitzung und es wäre keine erneute Anmeldung erforderlich. Leider hat die Sache zwei Nachteile:

- auf AS400 läuft nach wie vor der gleiche Telnet-Server, der Name und Kennwort unverschlüsselt erwartet.
- da man Name/Kennwort immer noch mitlesen kann, hat man auch gleich das Windows-Kennwort geknackt :-((
und/oder

Client Access ist auf SSL-Verbindung umzustellen.
Ist für ClientAccess V3R2Mx wohl nicht möglich, ich hab's jedenfalls nicht gefunden. Anscheinend geht das erst ab CA400 in Version "Express"? Weiß ich nicht genau... Aber das wird bei unserer Firma wohl auch damit nicht funktionieren, denn

- auch der Telnet-Server auf AS400 muss die SSL-Verschlüsselung akzeptieren.

Soweit ich gelesen&verstanden habe, machen das erst aktuelle OS400-Versionen. Bei uns ist V5R1 installiert)
<...>
Über PC-Verbindung
Stimmt nicht (nur, damit nicht in der falschen Richtung nach Lösungen gesucht wird)! Auch wenn die Sitzung von einer anderen AS400 gestartet würde (z.B. telnet 100.1.1.1), wäre das Name/Kennwort-Paar im Klartext auf dem Netzwerk. Problem ist der Telnet-Server auf AS400, der Name/Kennwort unverschlüsselt erwartet.

Noch ein Problem ist daher sicherlich auch die IBM-Software CA400, die Name und Kennwort schön mit Markierungen versieht und in EINEM Datenpaket über's Netzwerk schickt. Auch bei normalem FTP u. Telnet wird das Kennwort (m.W.) unverschlüsselt übertragen, aber eben weder mit Markierungen versehen und auch nicht in einem Datenpaket. Um zum Beispiel FTP oder "normales" Telnet zu knacken, braucht man schon mindestens ein Programm, das mehrere Datenpakete zusammensetzt um dann das Kennwort Buchstabe für Buchstabe zusammen zu suchen, bei CA400 reicht es, wenn nur das erste Datenpaket untersucht wird - hier sind alle interessanten Daten enthalten.

M.a.W.: IBM macht's sowohl auf Server-Seite wie auch auf der Client-Seite besonders einfach.

Im Detail (so habe ich das jedenfalls herausgefunden und kann damit die Kennwörter ausfiltern):
-
über IBM-ClientAccess wird AS400 im Prinzip über eine modifizierte Telnet-Sitzung bedient
-
im Gegensatz zu der Annahme, daß der Datenstrom auf dem Netzwerk verschlüsselt ist, werden Daten zwischen Client <-> AS400 offensichtlich unverschlüsselt übertragen (lediglich EBCDIC-ASCII-Umsetzung erforderlich)
-
der Datenstrom zwischen ClientAccess <-> AS400 enthält u.a. die Hex-Sequenzen [11h, 06h, 35h] und [11h, 07h, 35h].
-
im ersten Datenpaket, daß zwischen ClientAccess <-> AS400 ausgetauscht wird (Anmeldung), haben die Sequenzen folgende Bedeutung:
- auf [11h, 06h, 35h] folgt der Anmeldename
- auf [11h, 07h, 35h] folgt das Kennwort
bei falsch eingegebenen Kennwort wird im zweiten Paket
- auf [11h, 07h, 35h] nur nochmal das neu eingegebene Kennwort übertragen
bei falsch eingegebenem Anmeldenamen zurück zum ersten Paket.

..eintragen in CA: im Sitzungsprofil "Anmeldung umgehen" ein, dann wird die CA-Anmeldung für die Sitzung verwendet.
Habe ich ausprobiert (CA V3R2M0): da ändert sich gar nichts. Es kommt nach wie vor der kleine graue Bildschirm mit Name/Kennwort-Abfrage, dann der grüne Bildschirm mit Name/Kennwort-Abfrage und Name/Kennwort gehen wie immer im Klartext über das Netz. Welche Anmeldung wurde umgangen???
Ansonsten:

Stelle CA auf SSL-Verbindung um, und schon wird der gesamte CA-Verkehr verschlüsselt (nicht nur der 5250-Strom sondern auch ODBC/OLEDB).
Wie gesagt: wohl kaum mit CA-V3R2M0 und auch nicht mit dem z.Zt. vorhandenen Server-OS400.

Schönen Abend noch!
I. K.

[Frank.Sobanek]

Guten Morgen,
es gibt bei Client Access jede Menge Sicherheitsprobleme.
zB. wird mit der Emulation von Client Acces die so genannte Datenübertragungfunktion installiert.
Sie ermöglicht, Daten von der AS/400 auf den PC zu übertragen und umgekehrt Daten vom RC auf die AS/400 zu übertragen.
Mann könnte, wenn man den will ZB. Daten in Microsoft Editor (Notepad) laden, diese Manipulieren und zurück auf die AS/400 laden.
Weit schlimmer aber ist die Tatsache das mit Client Access
die Funktion Remote Command mitgeliefert wird.
Hier handelt es sich um eine 15 KB große EXE-Datei, die auch anderweitig beschafft werden kann.
Mit diesem Programm ist es möglich, alle OS/400 Befehle auszuführen, für die der jeweilige Benutzer laut seiner Benutzerklasse berechtigt ist.
Einschränkungen wie zB. der Befehlszeile werden dabei umgangen.
Auch kann man Microsoft Access installieren, um einen enfachen Zugriff mit ODBC zu haben.
Der DB2/400-ODBC-Treiber it im Internet frei verfügbar und ermöglicht es, auf Daten der AS/400 mit der Editier-Funktionenvon Access zuzugreifen.
Damit können alle Daten (fremde und eigene) manipuliert und angesehen werden.
So gibt es noch viele viele Beispiele.
Fazit:
Aufpassen Aufpassen Aufpassen
Gruß und einen schönen Tag

[Fuerchau]

Wie immer: Wer zu allem offen ist, kann nicht ganz dicht sein !

Das "Umgehen der Anmeldung" ist über den Systemwert QSIGNON (o.ä.) wieder abschaltbar (*FRCSIGNON).
SSL-Verschlüsselung für CA gibt es seit mindestens V4R3 sowoh auf OS als auch auf der Client-Seite.

Der Datenstrom, der da analysiert wurde ist der 5250-Datenstrom, der nun mal Bildschirmfelder überträgt.

Zu den Sicherheitsproblemen:
Seit der Einführung von Client-PC's an der AS/400 gibt es diese "Probleme", die eigentlich gar keine sind !!!
Bei konsequenter Umsetzung des Berechtigungssystems der AS/400 lassen sich alle Probleme abschalten, so dass der Benutzer nur noch das darf, wozu er berechtigt ist.

Mittels REXEC kann man auf jedem System (Windows/Linux/OS400/...) Befehle ausführen, wenn man eine gültige Anmeldung hat und für die Befehle berechtigt ist.
Auch auf den Windows-Servern ist das möglich wenn ich weiß wie es geht.

Die AS/400 ist da um keinen Deut besser, wenn man sich nicht darum kümmert.

Für alle, die sich mit der Berechtigung der AS/400 nicht herumschlagen wollen, gibt es dann Tools wie PCSACC/400, die die Kotrolle der Remote-Zugänge übernehmen.

Dies hat also nichts mit der CA-Version oder dem OS/400 zu tun, sondern damit, wie man seine Systeme per Berechtigungssystem schützt.

Im Intranet sollten ja eh nur vertrauenswürdige Personen Zugang habe, die sich nicht mit krimineller Energie um das Ausspionieren von Daten bemühen.
Man sollte auch seine Mitarbeiter anweisen, den PC immer zu sperren, wenn man mal zur Pause oder aufs Klo geht. Es könnte ja sonst ein Mitarbeiter kommen und mit meiner gültigen Anmeldung Unfug treiben.
Was nützt mir da SSL und verschlüsselte Autentifizierung wenn die Mitarbeiter so nachlässig sind und die einfachsten Sicherheitsregeln nicht beherzigen ?

Ich schreib meine Geheimzahl ja auch nicht auf die Rückseite meiner EC-Karte.

[Sven Schneider]

@Frank
Wie im wahren Leben.
Wenn ich meine Haustür (AS/400) offen lasse, ist es egal ob mein Hab und Gut mit 'nem Rucksack (z.B. ODBC, OLE-DB, Filetransfer) oder per LKW (z.B. FTP) mitgenommen wird.

[Frank.Sobanek]

Hallo,
sicher wenn ich meine Haustür offen lasse ect.... ist schon klar !!!
Aber ich habe nicht gewusst, dass selbst ein User mit der kleinsten Sicherheitsstufe (*user ohne Befehszeile) via RemoteCommand den Befehl WRKREGINF absetzen kann,
also den Namen meine Schutzprogramms herausfindet (zB. FTPTOOL) und dann noch DSPPGMREF(Programm-Referenzen anzeigen) aufruft und die für zB. Ftptool zuständigen Dateien anzeigen lässt und damit mein Schutzprogramm evtl. deaktiviert.
In meinem Fall hat so ein Künstler genau das getan.
Zusätzlich hat er dann noch wie beschrieben mit Microsoft Accsess und ODBC sein eigenes Userprofil hinzugefügt,
und schon war BVS FTPTOOL ausgehebelt.
Haben seitdem ein Tool im einsatz und Client Access komplett
gesperrt.

Gruß

Frank

[loeweadolf]

Wie immer: Wer zu allem offen ist, kann nicht ganz dicht sein !

Der Datenstrom, der da analysiert wurde ist der 5250-Datenstrom, der nun mal Bildschirmfelder überträgt.

Zu den Sicherheitsproblemen:
Seit der Einführung von Client-PC's an der AS/400 gibt es diese "Probleme", die eigentlich gar keine sind !!!
Bei konsequenter Umsetzung des Berechtigungssystems der AS/400 lassen sich alle Probleme abschalten, so dass der Benutzer nur noch das darf, wozu er berechtigt ist.

Dies hat also nichts mit der CA-Version oder dem OS/400 zu tun, sondern damit, wie man seine Systeme per Berechtigungssystem schützt.

Hallo Baldur,
in diesem Falle spielen die Berechtigungsvergaben keine Rolle.
Der Datenstrom im Netzwerk wurde ausgelesen und ausgewertet. Alle User und deren Kennwörter sind wie in einer öffentlichen Leihbücherei zu entnehmen.
So kann mit dem User-Name eines berechtigten Benutzers und dessen Kennwort alles gemacht werden. Berechtigungsvergaben auf der AS/400 sind Makulatur.

mfg. Ludger

[Fuerchau]

@Ludger

Ich sag doch, wenn das Intranet besonders geschützt werden muss, dann muss die CA-Kommunikation auf SSL umgestellt werden.

@Frank

"Ohne Befehlszeile" heißt nicht, dass ich keine Kommandos ausführen darf. Das wäre ja ein grosses Problem bei Kommandos in CL-Programmen oder per QCMDEXC.
WRKREGINF ist nicht das Problem.
Wieso hat der Benutzer die Berechtigung an der Lib wo das Programm drinsteht ?
Wieso hat der Benutzer die Berechtigung an den Dateien, um sich dann selbst einzutragen ?
Das, was der User da getrieben hat, kann ich auch mit SQL-Befehlen erreichen. Selbst wenn ich nicht CA verwende, kann ich mir einen ODBC-Treiber "besorgen", im Zweifel halt auch Java, und mach das dann ohne CA !
Per SQL kann ich ja auch CALL QCMDEXC durchführen um genau das zu erreichen.

Also auch hier: Die AS/400 ist viel zu weit offen !!

Übrigens:
Mit PCSACC/400 kann das nicht passieren. Das Programm steht zwar in den REGINF's (ich kann also nachschauen), die Lib ist aber für *PUBLIC auf *EXCLUDE gesetzt !
Solange ich also kein *ALLOBJ besitze (auch das haben leider viele User), komme ich an die Pgm'e und Dateien nicht dran.

Mach deine AS/400 also dicht, aber mit den richtigen Berechtigungen, dann kannst du auch CA nutzen.

Links:
http://www.newsolutions.de/news400/a...lio/sic_ip.php
http://www-1.ibm.com/servers/eserver...telnet/ssl.htm

[loeweadolf]

Vielen Dank für Eure Mühe.

Ich habe den Link zu diesem Thema dem entspr. Mitarbeiter weitergeleitet. Die angegeben Links bzgl. SSL scheinen interessant.

mfg. Ludger