iSeries aka AS/400 servers are used by manufacturers, banks, insurance companies, casinos and governments. Odds are that wherever there is an iSeries based application, the money is as well. With over 300,000 customers worldwide and millions of users, some people are bound to be rogue hackers looking for a way to exploit it for their own means. We present what should be done to avoid such practise.

iSeries aka AS/400 servers are used by manufacturers, banks, insurance companies, casinos and governments. Odds are that wherever there is an iSeries based application, the money is as well. With over 300,000 customers worldwide and millions of users, some people are bound to be rogue hackers looking for a way to exploit it for their own means.

The iSeries aka AS/400 server belongs to the midrange server family. It is used for multi-user, multi-tasking OLTP and data-processing applications. iSeries servers have a built in DB2 database. They can be used to run legacy applications (written mostly in the COBOL or RPG languages), as well as more modern ones (C, C++, and Java). Other scripting languages available on this platform that are limited to the IBM world are CLP and REXX.

In the old days, in order to work on an AS/400 server, one had to have a special terminal connected by Twinax cable. Today the most basic way to connect to the iSeries is by using a telnet client, that works as a terminal emulator. Twinax terminals are rarely used, except as the system console. Besides telnet, a modern iSeries has a built-in set of TCP/IP servers, including FTP, TFTP, SMTP, POP3, DNS, LDAP, DHCP, CIFS, and ODBC, as well as other proprietary protocols. iSeries machines are also used as application servers, with Tomcat, WebSphere, Apache and Domino available for the platform. Used servers can be found on eBay for a price between $4,000 and $5,000.

iSeries security issues

When we use an Oracle database, Microsoft SQL, or even DB2 on *NIX or Windows, the list of users who can login to the server is different from the list of users who can login to the database. On our platform, there is no separation between different types of users. A user and password combination used for logging in via telnet can also be used to login via FTP, ODBC, and all other resources that require user authentication. The difference is in their authority to iSeries objects: commands, programs, files and libraries (there are a lot more esoteric types of objects, but this is irrelevant to us at this point). Authority is managed in the ACL (Access Control List) model, and is granted to a user, a group, or a role.

For many TCP/IP services, IBM provided APIs, or programmable hooks, into the authentication and authorization process. If you want to allow user X to login via telnet to an interactive OLTP application, but you want to block the same user X from using FTP, you have to either write your own program or buy third party tools.

iSeries servers used to be shipped from IBM with most of the TCP/IP services enabled and turned on by default. The iSeries administrator is more likely to be a COBOL programmer than a system administrator who knows the difference between pop3 and ftp. These services are usually left running in the background even if there is no business reason for them to be there.

Too often, an OLTP application's security model is based on limiting the users to a predefined set of screens and menus, without taking proper care of ACL security. Such a security model, combined with lack of full TCP/IP services security management, is a recipe for disaster.

The scenario background

The Trupex Inc. Corporation manufactures and sells casket widgets. Some of their applications, including the order entry and accounts receivable applications, reside on a state of the art IBM iSeries server. The reason this platform was chosen over other options is its availability, stability and security, as experienced by the IT manager during his 15 years of IT experience.

Julius Krupp used to be an IT helpdesk representative in another place, but his overly curious and inquisitive character caused endless clashes with his superiors and eventually ended his IT career. He did apply for a similar position in Trupex, but when he was offered a job as a customer support technician he accepted it. Today he is not satisfied from his position. He feels that he was passed over in promotion. He thinks that he deserves some compensation from his employer, and after doing some internal research decides to go for the jackpot, and to get the credit card information saved inside the iSeries DB2 database.

Balthasar Ogus is the BOFH responsible for the smooth operation of the iSeries, Windows and Email Servers. He has inherited the current configuration from the previous system admin a couple of years ago, and so far he is content to log into the iSeries a couple of times a day to see the system status. Occasionally he does so when he receives a call regarding stuck jobs, locked out users and other unplanned problems. He is far too busy doing his other, more important stuff.

User enumeration

Julius has a workstation installed from a standard image, that includes iSeries Client Access with an emulation for the iSeries (see Inset iSeries clients), but unfortunately has no user account on the server. Julius sets out to find out what users exist on the iSeries server, to use their accounts in the exploit. He assumes that some user accounts on the iSeries server may be similar to existing user accounts in the company's Active Directory. Of course, being an employee, Julius has a valid account on Trupex's Active Directory server. He installs an LDAP client (see Inset LDAP clients) and after one hour of work he is able to retrieve the user list to his PC.

Figure 1. iSeries Telnet login screen

sum:

0 €