Hacking the AS/400

Hacking the AS/400

by Mel Beckman


And there’s the rub. How do you know whether a particular platform is truly secure? The Computer Emergency Response Team (CERT), a nonprofit organization that catalogs and disburses operating system exposure alerts, issues several bulletins a month on newly discovered holes in such popular operating systems as Unix and Windows NT (but so far, not in OS/400). So it’s not a foregone conclusion that you can buy a name-brand off-the-shelf server and expect it to be Internet safe.

To determine the safety of OS/400 as a Web server platform — compared to Windows NT, another popular Web serving operating system — we staged an "ethical hack" exercise at NEWS/400’s offices in Loveland, Colorado. Our objective was to see whether we could break into a server configured with normal care and due diligence using known, published hacker attack methods.

We assembled two teams, one expert in Unix and Windows — the skill set commonly found among hackers — and one expert in OS/400. The attackers’ goal was a single piece of sensitive information on the target machines. Any attack that obtained this information would show the subject system as vulnerable.

To save you from jumping to the end of the article, we’ll tell you that both the AS/400 and Windows NT systems acquitted themselves well — neither team managed to sneak in and snatch the holy grail from either. But the value of this story is not in the ending, but in the telling, so read on to find out how the contest played out. There are morals to this story that can help you better protect your system.

The Rules of Engagement
The contest ran under strict rules to ensure an even playing field. IBM provided an AS/400 preconfigured as a Web server and containing a valuable piece of information (we were told it was Lou Gerstner’s credit card number) stored in a presumably safe yet obvious location on the AS/400’s disk. A valuable tidbit also was stored on the NT server. NEWS/400 Senior Technical Editor and Windows NT Magazine Lab Manager John Enck moderated the tests, scheduling each attacker’s time and ensuring that nobody violated the rules.
IBM shipped the server — an AS/400e model S50 running OS/400 V4R1 — to NEWS/400’s lab under lock and key, accompanied by a small team of IBMers led by AS/400 Security Architect Carol Woodbury. Only Woodbury’s team was allowed to perform final configuration steps and complete the connection to the lab’s Internet LAN, making the AS/400 visible to the world. Once connected to the Internet, the AS/400 console was under the exclusive control of the IBMers. Security consultant and Windows NT Magazine Contributing Editor Mark Joseph Edwards configured the Windows NT server.

After IBM pronounced the server ready for battle, two teams of attackers took turns chipping away at the system from remote locations on the Internet. The Midwestern Commerce team, composed of Unix and NT security consultants in Columbus, Ohio, ran through attacks they commonly use when performing security audits, including techniques widely published by hackers on the Internet. The NEWS/400 team, led by me and including Steve Glanstein, a consultant with Management Information Consultants in Honolulu, made the usual hacker gambits but also used knowledge of AS/400 internals to try and sneak in where typical hackers might not recognize an opening.

At any given time, only one team was actively attacking the AS/400 to ensure that the attackers wouldn’t interfere with each other and to easily identify who was responsible in the event of a successful penetration. The lab ran an Ethernet sniffer on the Internet LAN to record the attacks and document any successful break-ins.

The contest guidelines permitted any kind of attack aimed at breaking through a server’s protection to obtain the target information. This ruled out denial of service (DoS) attacks, which seek to prevent legitimate users from using a system — by crashing it or consuming all its networking resources — rather than to gain entry to the system.

DoS attacks were disallowed for two reasons. First, some well-known, easily instigated DoS attacks have no practical defense — all servers are vulnerable to them (see "Smurfs to Take Seriously" There’s little point in testing when you already know the outcome.

Second, although you can protect against some DoS attacks, the server isn’t the best place to count on such protection. New DoS attacks are discovered and publicized several times a year, but operating system vendors often require months — due to the complexity of updating an entire installed base of systems — to develop and distribute protective fixes.

A better place for DoS protection is in a firewall positioned between the Internet and Web server. Firewalls can be easily updated without affecting application systems. Thus, firewall vendors generally release fixes for new DoS attacks, when practical, within weeks or days of their discovery. Firewall vendors have only one service to sell — protection — so they’re highly motivated to get a fix to market quickly. (Next month, look for an article describing DoS-attack prevention using firewalls, including IBM’s Integrated PC Server, or IPCS, firewall.)

The Setup
Because the objective of the exercise was to determine whether a system configured as a Web server could withstand attack, the only TCP/IP services enabled on the AS/400 and NT machines were those necessary for Web serving. IBM ran its Internet Connection Secure Server (ICSS) and simulated an online store that accepted credit card payments for merchandise orders. ICSS uses Secure Sockets Layer (SSL) to encrypt traffic between client browsers and the server, ensuring security of sensitive payment information. NT ran Microsoft’s Internet Information Server (IIS), with a similar storefront application written by John Enck.

Incoming services such as Telnet, File Transfer Protocol (FTP), and e-mail were disabled during the test. Although many people setting up Web servers leave these services enabled, the practice isn’t considered safe by Internet security experts, who recommend running ancillary services, such as e-mail and Domain Name System (DNS), on a different server to minimize the number of avenues a hacker can exploit.

You might wonder how real-life data files could be updated on such a disabled server and how merchandise orders could be extracted from it. Although not implemented in IBM’s simulated storefront, the safe way to do this is via separately authenticated administrative Web pages that can trigger file send and receive events from inside the Web server. Despite having incoming FTP disabled, the AS/400 could still originate FTP connections triggered by appropriately programmed Web pages.

IBM’s AS/400 Web application was written in Hypertext Markup Language (HTML) and C by IBMer John Nielsen. Carol Woodbury’s team installed the software and configured the AS/400 using the guidelines in IBM’s "Tips and Tools for Securing Your AS/400" (SC41-5400) — just as any security-savvy IBM customer would be expected to do. In addition to recommending lockout of unnecessary TCP/IP services, these tips detail default passwords that must be changed, AS/400 user authorities required for safe Web serving, and techniques for preventing abuse of Common Gateway Interface (CGI) applications that maintain sensitive database files.

The Attacks
Each team kept a detailed log of every attempted attack and the results. One group of attacks was intended to simulate an inexperienced hacker using an off-the-shelf "hacking toolkit" to probe the server for weak spots. This is the most common kind of attack — an opportunistic hacker with no particular objective attempts to break into a system just to see what it contains. A second group of attacks focused on getting to the target objective by using specialized techniques for circumventing database and Web program protections. An attacker using these methods would benefit from knowledge of OS/400 internals. Figure 1 lists the types of attacks in each group.

Not all the attacks were applicable to the AS/400. Some were precluded by the server configuration. For example, because the AS/400 application used SSL to encrypt all sensitive data, packet sniffing wasn’t a workable technique. Similarly, because unnecessary services that normally require a user ID and password, such as Telnet, were disabled, password cracking was not an option. Other attacks, such as CGI subversion, depend on specific operating system features, such as an interpreted shell language. The AS/400 server was coded in compiled C, with no interpreted scripts, defeating this kind of attack by design.

An AS/400 with more services enabled may well be vulnerable to such hacker techniques as password cracking or packet sniffing. Unless you take precautions to block such attacks by limiting the services available on your AS/400, you can’t be sure that an attacker won’t gain entry through one of these methods. A good rule of thumb on any public server is to block access to everything — TCP/IP services, commands, and data files — except those required to run your application.

The Results
Following 48 hours of continuous attack, during which the lab’s sniffer recorded megabytes of traffic probing and picking at the server’s front door, the official test ended. Both teams reviewed their results and filed final reports. Neither team managed to gain a foothold in the AS/400, leaving Lou Gerstner’s credit card number safe and the teams’ plans for a shopping spree foiled. NT also beat back the barbarians.

During the test, the teams noted some interesting behavior on the part of IBM’s ICSS and NT’s IIS. Buffer overflow attacks — often successful on other systems — resulted in ICSS simply closing down the attackers’ connection. This is a good response, but perhaps not the best one. The server did nothing to stop the same attacker from returning and trying additional buffer overflows without limit. A better way to handle persistent attackers is to temporarily block all connections from the source IP address, limiting the number of buffer size permutations the hacker can try. This is the approach NT took.

In another test attempting to hijack SQL statements by modifying embedded parameters, the teams found that the AS/400 Web application limited parameters to eight characters. This confounded attempts to insert SQL parameters that might give a hacker free run of the database, a good result. NT had no such restriction, but its scripts were also inviolate. And finally, although IBM’s application did create a "cookie" in client Web browsers — to hold the current order number — the code was smart enough to not use the cookie’s order number in the SQL statement that accessed the AS/400 database. Thus, a hacker couldn’t modify the cookie value to look at orders for other users.

The moral here is that simply configuring a server to be secure is not enough — you must pay close attention to your application code as well, constantly considering how an interloper might try to subvert generated Universal Resource Locators (URLs) and cookie values. IBM’s application was written in a noninterpreted language, but OS/400 also runs interpreted, or scripting, languages, such as Perl, for CGI programming. These languages require special attention to input-data handling, to filter out escape characters that could let a hacker execute ad hoc script commands.

The two teams exchanged progress reports and useful information during the course of the exercise. For example, one team ran the time-consuming port scan searching for available services and passed the results on to the other team. This mimics the behavior of real hackers, who often share information about their targets through underground discussion groups and e-mail lists. In an actual penetration attack, system administrators often find they’re being hit from several remote locations simultaneously. The odds are definitely in favor of the invaders once an attack is in progress, making prevention all the more important.

Is It Safe?
Did this exercise prove the AS/400 is safe on the Internet? Our conclusion is that an AS/400 can be made safe by careful configuration to remove unnecessary services, preemptive protection against packet sniffing using encryption, and diligent review of Web application code to prevent its subversion.

The truth is that it’s impossible to prove any server is secure, just as it’s impossible to prove that a program has no bugs. You can only perform reasonable testing to try and discover the most obvious problems and correct them.

The best protection comes from minimizing your exposure — by keeping a minimal amount of sensitive data on publicly accessible servers. Given these precautions, the AS/400 is the equal of any other system on the Internet at keeping your data safe.

Mel Beckman is a senior technical editor for NEWS/400. You can reach him at mbeckman@news400.com.

Smurfs to Take Seriously
Denial of service (DoS) attacks are a kind of Internet vandalism. A hacker might initiate a DoS attack to prevent legitimate users from using a particular server or even an entire network. DoS attacks work by crashing machines, tying up their resources, or flooding the target network with so much traffic that legitimate traffic is excluded.

Although there are preventive measures for many DoS attacks, some can’t be defended against. Perhaps the most insidious is the Smurf attack, discovered in October 1997 and named after the first program found to implement the attack (the name appears to be arbitrary).

In any DoS attack, the attacker wants two things: anonymity and simplicity. If an attack can be traced back to the attacker, he or she may well face criminal prosecution. And a complex attack might be beyond the means of the attacker, either in terms of bandwidth or computing resources. The Smurf attack is elegant in its simplicity and completely untraceable, making it a favorite of hackers. And there is no known defense.

The Smurf attack uses a vestigial feature of the Internet Control Message Protocol (ICMP) called a broadcast ping. Unlike a regular ping packet, which is transmitted to a single host and returns a single echo to the originator, a broadcast ping is sent to an entire network, asking that all the machines on the network respond. Broadcast pings have little value on the Internet today because many hosts don’t respond to them. But enough still do to make this ICMP castaway a powerful weapon.

The hacker first locates a few large networks on the Internet having many devices responsive to broadcast pings. He might find, for example, a dozen sites with 50 or 60 hosts each willing to reply to a broadcast. The hacker then sends these sites repeated broadcast pings but forges the IP address of the intended victim network as the source address of the pings. The hacker sends out one broadcast ping, and the unwitting accomplice sites send responses — not to the hacker, but to the victim site, for that’s where they believe the broadcast originated.
The Smurf attack lets someone with only a modem connection completely saturate the bandwidth of a 1.5 Mbps T1 line in seconds. An attack prosecuted through an Integrated Services Digital Network (ISDN) or other digital connection can generate more than 50 Mbps — enough to overflow the connections of even a large corporation. To keep the attack going, the offender need send out only a few broadcast pings every second, confident that the patsy networks will amplify his traffic a hundred- or thousandfold. Ping packets are virtually untraceable, and the attacker may well be using a stolen account as a base of operations anyway, so he need not fear discovery.

Blocking ping packets is no defense, because by the time the packets reach the victim’s router, they’ve already consumed the bandwidth between the victim and the victim’s Internet service provider (ISP). In fact, the ISP likely becomes a victim, too. The only way to prevent Smurf attacks is by encouraging everyone with a dedicated connection to block broadcast pings at their Internet routers so they can’t involuntarily become intermediate sites in an attack. This onerous task is underway right now, but it will be months, or years, before most Internet routers have been upgraded.

The thought of being completely defenseless against a particular DoS attack may make you want to throw up your hands in despair and avoid the Internet altogether. That would be an overreaction because Smurf attacks are rare and growing rarer still. Only a tiny fraction of Internet sites have been Smurfed. And the frequency of Smurf attacks today is half what it was when this type of attack was first identified. This is partly due to the gradual deployment of protection against becoming an attack intermediary.

The real lesson to learn from the Smurf attack is that protection is sometimes a cooperative effort. You should be willing to fix your network connection so it can’t be part of a particular security problem, even if you’re not currently a victim of the problem.

— M.B.







--------------------------------------------------------------------------------


Figure 1
Types of hacker attacks
Type of attack Description
Hacker toolkit attacks
Buffer overflow Tries to cause application crashes with unexpectedly large data packets in the hope that the crashed application will leave the server in a vulnerable state.
Common Gateway Interface (CGI) subversion Attempts to use existing Web CGI programs to execute general system commands that can open new system entry points by creating user accounts or turning on disabled services.
Directory map disclosure Forces error messages to see whether message text includes information about a server’s directory structure.
E-mail culling Using a compromised host on the target LAN or an Internet backbone provider, scans e-mail entering and leaving the target network, searching for key phrases such as "password." The hacker also watches for evidence that he has been discovered.
Hypertext Markup Language (HTML) directory discovery Attempts to force display of directory lists for nonpublic directories on the Web server.
IP address spoofing Attempts to gain privileged access by simulating a local, trusted host.
Log obscuration Destroys the evidence of a hacker’s entry and actions by deleting system access and job log entries tracking the hacker’s actions.
Log-in spoofing Leaves what appears to be a log-in screen visible to incoming users, who then enter their user ID and password for capture by the log-in spoofing program.
Masquerading Redirects legitimate user sessions to a server impersonating the target server to try to trick the user into divulging access information, such as passwords.
Packet sniffing Uses access gained on another computer between the target system and clients to eavesdrop on sensitive traffic, hoping to capture passwords or other valuable data.
Password cracking Uses common user-ID and password combinations, including manufacturer’s default passwords, to gain access to a legitimate user account.
Port scan Locates all available TCP/IP and User Datagram Protocol (UDP) ports as possible avenues of entry.
Server crashing Uses techniques that can also be used for denial of service, such as Ping of Death, to try and crash the server, hoping to find it in a vulnerable state.
Session hijacking Attempts to take over a legitimate user session in progress to capture any valuable information the user has entered so far.

Specialized attacks
Command language invocation Attempts to force the server to execute individual operating system (OS) command language statements by using escape characters or override parameters in default CGI programs included with a particular system.
Cookie modification Detects any cookies created by the target server and modifies them to alter the behavior of the server, possibly crashing it to obtain privileged access.
Embedded SQL hijacking Modifies embedded SQL statements in Universal Resource Locators (URLs) and HTML to try to retrieve or modify sensitive data, such as payment information for orders placed by other users.
Form field overload Inserts unexpectedly large strings in HTML form fields returned to the server to try to crash the server or gain access to privileged CGI programs.
Form field substitution characters Uses OS–dependent special characters in form field data to try to cause unexpected command language substitutions that may provide access to privileged CGI programs.
Server-side include (SSI) interception Feeds known SSI HTML commands back into the server in Hypertext Transport Protocol (HTTP) responses in an attempt to get the server to execute the SSI commands, either by replacing existing SSI HTML files or by using command substitution to output them through the SSI server.
URL forgery Forges internal URL strings normally generated by a Web application, hoping that such strings will be trusted by the Web server and be given special privileges.
URL mapping circumvention Tries to discover URL mapping rules by using various permutations of internally generated URLs. Knowing mapping rules lets the attacker discover possible security holes to gain access to nonpublic directories and programs.




--------------------------------------------------------------------------------

Has been stolen from the excellent news400.com.