This is a call to action! Please see my experiment below — and agree with my assertion that as a global digital culture, we must care more about security. Starting now.

Maybe you noticed a few days ago that a ransomware campaign targeted a remote management system called iLO by HP. Perhaps you feel that you hear about ransomware attacks too often these days, so why bother worrying about another?

Well, I’d like to make it a potent example of the problem we have with today’s security. iLO makes it possible to remotely perform activities on an HP server. If bad actors hack the system, they can basically access servers, lock down data, and ask for ransom. It’s an all-too-common story: internet-connected servers with remote management capabilities have a vulnerability that allows almost any script kiddie to access them. Nothing new.

But I’m the kind of person who likes get his hands dirty every time I see a vulnerability. So to stay consistent with my habits, I conducted an experiment — what if I was a script kiddie? How easy would it be for ME to hack into iLO? Join me on this journey...

Step 1: Exploring the minefield

First, I need to find the devices with iLO service connected to the internet. I used Shodan.io (a very useful tool for those of us who wear white hats) to search for all iLO devices, and received these results:

After filtering this data, I landed on 11,000 unique server IP addresses running iLO. Alright, ready to have some fun.

Step  2: Finding the way in

As a script kiddie, I’m now browsing through all known vulnerabilities. Yes, there are multiple  vulnerabilities reported for iLO management services. After a while, I found one called “CVE-2017-12542.” I choose it because of its high “score” of 10, indicating that it’s as serious as a vulnerability can get.  

The “2017” in the file name tells me the year in which the vulnerability ID was allocated. This particular one was published on February 15th this year. Here are some other details:

Step 3: Exploitation time

Anyone can write an exploit or find an existing one that can be used. As a script kiddie and newbie hacker, I start searching for some ready-made scripts to use. And in less than 10 seconds, look at that — I find a Python implementation.

Here’s how this vulnerability works: simply by issuing an HTTP request, I can get a list of all iLO management system users. No authentication is required. It’s so easy that you can almost do it using your browser; you only need to change one field in the request header so the server thinks you’re already logged in. I did this, and was greeted with the following data in response.

This is just a partial dump of data, but you can see the Password field, followed by the word “null.” It turns out that the password is not in fact “null,” but gives us that word because we are restricted from seeing the real password. It is most likely being stored properly through hashing. So this looks like a dead end. No easy access.

Step 4: Finding a way around

Ok, so I'll try a different route. If I cannot log in as an existing user, why don’t I try to become a new user? Because the server gave me such a detailed list of users without any authentication, perhaps it will allow me to create my own account.

So I construct this request for the server:

Just for fun, I chose UserName=’hyperadmin’ and Password=’12345.’ The response was funny:

You might notice the server’s main concern here is not that I'm trying to create a new user without being authorized to do so, but that the password is too short. Okay, one more time, this time with Password=’12345678.’ The result is:

I am in!

Step 5: Trying to log in

It’s time to test if it works. I try to log in using my newly created credentials:

And voilá:

Step 6: Taking full control of the server

As you can see, I now have full control of the server. I can even mount my own .iso image with installation and boot from it, which is exactly what the ransomware mentioned at the beginning of this article did.

What does this all mean?

It’s been almost three months since this vulnerability has been published, and it’s a CRITICAL vulnerability. Does no one care?

Given how easy it was for me to infiltrate the vulnerable server, I decided to check and see how many of thee 11,000 servers around the world are still vulnerable. The startling truth is 2,500 of them are still publicly available and vulnerable to this kind of threat. Is that a small number or a large number? I would say it doesn’t matter. What matters here is that for three long months nobody has moved to resolve the issue. Patches ARE available, so we can’t blame the vendor.

Which brings us to the point that really needs to be stressed here: Security of IT systems are the joint responsibility of all of us.  

There are several takeaways:

• If you are running or managing any servers, routers, or other devices that are publicly available on the internet, it is your responsibility to regularly patch them. Don’t rely on someone else — you are responsible for the data that is stored there.
  
  
• Avoid exposing any management services to the internet directly, always use and require management through VPN access.  
  
  
• From time to time, consider using services such a shodan.io or censys.io to check your public IPs. These services are here for you to do an audit and penetration tests. It’s always better to be a script kiddie attacking your own device than for the cybercriminal to get in there first.