With a enough time and a little insight, a system that hasn't been properly secured will be exploited.

A few weeks ago, I wrote a piece called "The Internet of Unprotected Things," which touched on the security concerns of twenty billion connected devices in a few short years, otherwise known as the Internet of Things (IoT).

I had a pretty good response to the article. So much so that a number of people asked me to ethically hack their IBM i as an impartial party for intrusion detection purposes. One company was really interested because they were very confident in their abilities in security. To be fair, we all are. There's nothing like giving someone a program you've written and saying, "Try to break it." You learn pretty quickly where the bugs are.

Anyway, this company wanted me to try to break into their system. I would be given only their public IP address and the knowledge of the services they believed to be available on the public Internet. That's a good head start but nothing that couldn't be figured out with a port scan of their public IP. I told this company that I'd be glad to work with them free of charge on the condition that I could write about the results without using any names or screen shots of their system.

Challenge accepted.

This company had their IBM i connected to the public Internet in two ways: Telnet and web traffic via HTTPS. The company network was behind a firewall with network address translation (NAT), which forwards requests to one of their public IP addresses onward to their IBM i IP address. For example, their Telnet requests are handled in this way:

1. Public IP address xxx.xxx.xxx.1 at the company firewall is sent a Telnet request on port 992.

2. The firewall sends the request to IBM i IP address 10.0.32.1 on port 992.

This is pretty standard. Nothing amiss here...yet.

Certificate Strength

The fact that the company had secured their services with encryption is a good start. Every online service, private or public, that allows the transmission of sensitive data requires encryption. To do without is a serious security liability to your business, users, and customers.

The bad news is that the certificate was a self-signed SHA-1 certificate, generated in 2015 and set to expire in 2020. Since it was generated in 2015, they should've known better. Most reputable certificate vendors won't even supply SHA-1 certificates anymore unless you make a special request. Microsoft, Google, and Mozilla will stop supporting SHA-1 certificates in 2017. SHA-1 is broken. Kaput. And it's beem common knowledge in the security world for a good few years now. Since it was self-certified, there are no checks and balances. A vulnerable hash algorithm? Have at it.

The SHA-1 certificate is far less secure than the newer SHA-2 certificates. Sure, it's encrypted. Some would say it's better than plain text, but I disagree wholeheartedly with that assessment. It's actually worse. Why? What a weak certificate does is promote a false sense of security.

How did I find the certificate is weak? Easy. I ran their website through the Qualys SSL Labs website to check the certificate strength. I could've grabbed it directly from the website but Qualys gives us much more information.

Figure 1: Qualys SSL Labs provided surprising results.

This particular IBM i partition supports Transport Layer Security (TLS) 1.0 but TLS 1.2 is the only real secure option. TLS 1.1 and TLS 1.0 are weaker, and their vulnerabilities have been well reported. This IBM i partition also relies on the older and insecure (i.e., useless and broken) SSLv3 and even SSLv2. Those two need to be turned off if at all possible with TLS needing to be at 1.2.

It turns out that both HTTPS and Telnet use this particular certificate.

Telnet and HTTPS

For Telnet, I first tried the regular user id and password combinations for all IBM supplied user profiles. I went to the usual admin/admin and backup/backup profile combinations. It appeared they use the ANZDFTPWD regularly. Nothing worked...except I got lucky by trying QSRV with passwords qsrv. Ouch. By default, profile QSRV has *SERVICE and *JOBCTL special authorities. I could've quite easily ended all subsystems and done an IPL while the IT staff for the target machine sat around scratching their heads. Very harmful mischief could've been had with an informed password guess.

So...I ended the QBATCH subsystem. I had to do something just to prove a point. And yes, I was told to make it known what I could do (within reason) if I managed to get in. I'm assuming they had a sinking feeling when the support staff started getting calls about jobs not completing as expected. No real harm done.

For HTTPS, the real weapon to an attacker is the SSL vulnerabilities I've mentioned above. It's not like I needed to go any further. I mean, I could already do a PWRDWNSYS RESTART(*NO). The Qualys website essentially told me exactly what protocols were and weren't supported, what cipher suites were being used, and what protocol vulnerabilities the server had in case an attacker wanted to launch a man-in-the-middle attack. This is not just a check on the SSL certificate strength. It's a check on how a server is vulnerable through HTTPS and also gives some great insight on what that server supports. For instance, if TLS hasn't been enabled on one service, then TLS hasn't been enabled on any of them. If SSLv2 is being used on the web, then it's almost a guarantee SSLv2 is used everywhere else.

What Are the Lessons Learned Here?

First, if you have Telnet on the public Internet, make sure you have watertight control on user passwords. A good idea is to also set up exit points for Telnet to limit the scope of IP addresses that can connect to the Telnet server. Or put Telnet behind a VPN if you need remote access. I wonder if the fact that it was "protected" by SSL had something to do with the false sense of security. Encryption just prevents the contents of the traffic en route. PWRDWNSYS has the same effect if the packets carrying the command across a wire are readable in plain text or not.

Second, we need to be locking down services with strong encryption. We need to alter the QSSLPCL system value on IBM i 7.1 to take advantage of TLS 1.2, which comes disabled by default. It lies dormant until you enable it. Enabling TLS 1.2 will disable SSLv2! We need to alter the QSSLCSL system value to allow for strong TLS 1.2 ciphers *RSA_AES_128_CBC_SHA256 and *RSA_AES_256_CBC_SHA256. If you can't go to TLS 1.2 because of your applications, then you can remove SSLv2 manually as well as remove old ciphers *RSA_RC2_CBC_128_MD5, *RSA_3DES_EDE_CBC_MD5, and *RSA_DES_CBC_MD5. We have to remove RC2 and RC4 ciphers, which are now insecure. And we need to get off SHA-1 because the rest of world is quickly leaving it behind.

It's not like someone needs a website like Shodan to discover IBM i partitions on the Internet either. If you use that type of website, then your search results are tracked to the profile you set up. It's very difficult to be anonymous on that site. But there are plenty of bots available that can gather information anonymously. IBM i is the most securable system in the world. With enough time and a little insight, a system that hasn't been properly secured will be exploited.

And if you have a partition on the live Internet, it can be found.

Steve Pitcher

• Email
• Site

Steve Pitcher works with iTech Solutions, an IBM Premier Business Partner. He is a specialist in IBM i and IBM Power Systems solutions since 2001. Feel free to contact him directly atspitcher@itechsol.com.