A Simple IBM i Penetration Test Lesson

iTech Solutions has had IBM i penetration testing as a service for a little while now. While not discussing anything confidential, offering a little friendly advice based on some of the generic and even specific things encountered on a penetration test will certainly be to the benefit of IBM i customers such as yourselves.

First, let’s explain the meat of what iTech does on a pen test.

  1. Perimeter Test – attempts to catalog and breach your systems from outside the firewall.
  2. Black Box Test – attempts to find and breach your IBM i partition(s) from inside the firewall. No knowledge of any system specifics (even the IP address) are given in advance.
  3. White Box Test – attempts to elevate authority of an existing user to get around security rules on the system. This is the equivalent of a rogue user attempting to steal data or do some damage.

For each test, the ground rules are agreed upon by both parties. Some customers want you to spend a little extra time on a particular service (i.e., EDI, web servers) which is certainly doable. Others want nobody in the local IT department to know about it in order to test efficacy, alerting and reaction of an attacker tripping a tripwire.

The minority of shops are watertight. Many are not. Some are far more wide open than they thought. So much so that all three aspects of their penetration tests have taken less than 20 minutes combined. That means breaching the system from outside the firewall with a set of working credentials and then either elevating authority to gain more control or simply by having excess rights with the profile used in the very first place.

How does that happen? It’s usually the combination of two things.

Network Address Translation (NAT) rules on a firewall is the first massive problem. A NAT rule will take a port on a firewall public IP address and map it to a corresponding IP address on a local server. For instance, you may have a public IP address of 142.175.10.xxx and a local address of for your IBM i server with an FTP server running on port 21. External FTP clients would connect to your firewall IP address with an FTP request on port 21 and the firewall would route that request to on port 21. It’s simply a traffic cop. So review your firewall rules every quarter and ask questions about new rules that have popped into the list. Limit what you expose.

And if a company thinks they’re clever by using port 2121 for FTP or 10443 for SSH, boy are they in for a rude awakening. Robots catalog these things on the web and develop some handy tools to identify systems based on the service, not necessarily the port. For example, below are 1700 or so IBM i-based FTP servers in the US. In this tool, a simple mouse-over event on any of those dots will give me the IP address of those servers. You can zoom in and zoom out to be more granular about your result set. It’ll also give some DNS information about the company in question or provide an attacker with additional information to dig deeper. It’s a double-sized softball with a big bow on it for an attacker.

So if you provide an attacker a direct connection to a production system on a port that allows a user an interface to log into a service (think FTP, SSH, Telnet), then you can best believe an attacker will attempt to do so too. And you can bet that our penetration test will attempt it as well.

The second major problem is default passwords

(i.e., a user ID and a password that’s the same). I always recommend setting up a job schedule entry that does a daily Analyze Default Password (ANZDFTPWD). No matter the controls you have in place to ensure proper passwords are assigned to user profiles, this is a great simple solution to ensure those controls are being followed because it’ll dump a spooled file with a list of users that have matching user IDs and passwords. The first thing attempted is IBM profiles set with default passwords simply because we KNOW those profiles. The second is commonly used vendor software profiles. Some vendors set a strong password…and some don’t. And some will actually set a default password. The third attempt is on miscellaneous profiles with names FTP, EDI, MYSQL and so on. The fourth is to socially engineer user profile and password educated guesses. And if you’ve got a pattern for your user names (ABCJOHN, ABCJANE, etc.) that just makes it all the easier for an attacker to guess once the pattern is determined. It’s incredibly easy to socially engineer a user name. We start with LinkedIn to enumerate a list of employee names both past and present. Then you test the most common patterns (first initial + last name, last name + first initial, first name only, etc.), and most often than not you get matches. Arbitrary user names are the way to go in my humble opinion.

And almost every time we’ve breached a system during a penetration test (which has been every single time except one), there’s usually a comment about how previous penetration tests were unsuccessful. That’s because companies often have Windows consultants doing them. They’re spotting an Apache track and trace vulnerability with a tool instead of IBM i professionals doing a proper IBM i penetration test. It’s kind of like ordering clams at a pizzeria. Sure, you could. But it’s not their specialty and the results are likely not what you’re hoping for.

So that’s two very rudimentary things to do to protect yourself against attackers. Of course, IBM i security needs to be layered. If you lock a door you can bet an attacker is going to try a window. This is but two doors to review, but they will help slow an attacker down.

More from this month:

Leave a Comment

Your email address will not be published. Required fields are marked *