Re: AS/400 Vulnerabilities
Hello Bugtraq, On Fri, 13 Jun 2008, security curmudgeon wrote: I would guess there is little research being done on them. The odds of a box falling over due to a few malformed TCP packets, but being resistant or not vulnerable to more complex attacks seems pretty far fetched. While this vendor and technology is widely deployed, it isn't a sexy target for research. Speaking of AS/400 security research, I'd like to point out the following resources: http://seclists.org/pen-test/2008/Feb/0083.html http://www.venera.com/downloads.htm http://www.venera.com/order.htm http://www.security-database.com/toolswatch/AS-400-Auditing-Framework-Beta.html Cheers, -- Marco Ivaldi, OPST Red Team Coordinator Data Security Division @ Mediaservice.net Srlhttp://mediaservice.net/
Re: AS/400 Vulnerabilities
: Have you ever nmap-ed a network with AS/400s? If you have, you probably : know that doing so will, in at least half the cases, either crash the : box, hang up one or more services, or really confuse the IP stack to the : point that the box almost screeches to a halt. This is frequently observed by pen-testers for sure but just as frequently anecdotal. I have personally run into it at least once, where a standard nmap SYN scan crashed a few AS/400 boxes. Each time it ends there, the client freaks and little to no more information can be obtained as it is dropped from the scope. I'd be curious to see how many bug reports IBM has received on the port scan DoS. Given the lack of information about what versions or conditions are required for it to happen is why I said it is mostly anecdotal. : However, if you search for AS/400 vulnerabilities, you find only about a : dozen, and most are years old. Nessus only checks for one. Search your favorite VDB for "OS/400" and you will see more current issues. Either way, given the distribution of the platform, there are relatively few vulnerabilities publicly disclosed. OSVDB Disc Date CVE Vuln - - --- 46082 2008-06-06 IBM OS/400 BrSmRcvAndCheck Boundary Error Local Overflow 41518 2008-02-04 2008-0694 IBM OS/400 V5R3M0 / V5R4M0 HTTP Server Expect HTTP Header XSS 37792 2007-06-28 2007-3537 IBM OS/400 on iSeries TCP SYN-FIN Packet Handling Security Bypass 32812 2007-01-13 2007-0442 IBM OS/400 Unspecified Connection Reset DoS 30743 2006-11-17 2006-6836 IBM OS/400 osp-cert ASN.1 Certificate Version Handling Weakness 30744 2006-11-17 2006-6836 IBM OS/400 osp-cert ASN.1 X.509 Certificate Version Weakness [..] 16606 2005-04-20 2005-1238 AS/400 FTP Server for iSeries Traversal File Restriction Bypass 15300 2005-04-04 2005-1025 AS/400 iSeries FTP IFS Mode ADDLNK User Account Disclosure 15079 2005-03-26 2005-0899 AS/400 LDAP User Account Name Disclosure 15074 2005-03-23 2005-0868 AS/400 Multiple Emulator STRPCO / STRPCCMD Command Execution [..] : This raises a couple of questions: : 1) Is anyone really doing any vulnerability research in this area? : : 2) Are the boxes really just unstable to malformed network data, but : not exploitable? I would guess there is little research being done on them. The odds of a box falling over due to a few malformed TCP packets, but being resistant or not vulnerable to more complex attacks seems pretty far fetched. While this vendor and technology is widely deployed, it isn't a sexy target for research. Brian OSVDB.org
RE: AS/400 Vulnerabilities
> From: Jon Kibler [mailto:[EMAIL PROTECTED] > Sent: Thursday, 12 June, 2008 14:54 > To: bugtraq@securityfocus.com > > 2) Are the boxes really just unstable to malformed network > data, but not exploitable? Exploiting data-handling vulnerabilities (as opposed to design vulnerabilities, like missing access checks) is difficult on the AS/400 (aka iSeries, and various other names), because it's a capability architecture. Attacks like stack overflows don't apply to the '400 the way they do to more common virtual-address-space systems. Of course that doesn't mean that they're not exploitable, just that the exploits will take different forms. (In most cases - processes running in the PASE enviroment are an exception, though I couldn't say just what access you might get by breaking one.) I think it's an area that's definitely worth investigation, but few researchers (whatever their hat color) seem to have done much with capability architectures in general or the '400 in particular. And it doesn't look like many are motivated to acquire the necessary knowledge to do so. That is a bit of a shame, as capability architectures are interesting in themselves, and have interesting security implications, and the '400 has shown that they're commercially viable. Intel's early effort at a capability architecture (the 432) died because it couldn't compete on performance, but the long life of the '400 suggests that perhaps the time is right to try again. -- Michael Wojcik Principal Software Systems Developer, Micro Focus
AS/400 Vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Have you ever nmap-ed a network with AS/400s? If you have, you probably know that doing so will, in at least half the cases, either crash the box, hang up one or more services, or really confuse the IP stack to the point that the box almost screeches to a halt. Given that those boxes are so brittle to even simple network scans, it would seem that they would have to be full of exploitable vulnerabilities. If nothing else, a few custom packets should be able to DoS a box. However, if you search for AS/400 vulnerabilities, you find only about a dozen, and most are years old. Nessus only checks for one. Since these boxes are a common part of small to medium size business infrastructure (especially in manufacturing or organizations that have used computers for over 25 years), it looks like they would be ripe for exploitation. This raises a couple of questions: 1) Is anyone really doing any vulnerability research in this area? 2) Are the boxes really just unstable to malformed network data, but not exploitable? THANKS! Jon Kibler - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-224-2494 s: 843-564-4224 My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhRcLIACgkQUVxQRc85QlNhrACfdG7tlp2HbDmnnIAiQS0ROZF0 CakAn0J0VdEQBhICnxXK5MV/nmiGQGhQ =FuL1 -END PGP SIGNATURE- == Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email.
