The idea for the talk came from an absence of enough resources on the Internet when attempting to pentest resources running on the IBM cloud. Like a lot of cloud providers out there, IBM cloud also has a standard set of services across compute, storage, databases and networking.
These services can be targeted based on their default configurations and customer exposed attack surfaces. Primarily, the objective of the talk was to answer the following questions:
The entire exploration of the IBM cloud and services within was from an attacker perspective to identify any weaknesses that can be documented.
Here are all the slides from the conference presented virtually on 14th September 2021
This slide and the content generated is also on the GitHub repo at https://github.com/Kloudle/pentesting-ibm-cloud. This blog post takes you through the slides and expands on the topics covered in the talk along with additional commentary around the content.
Apart from the novelty of attacking a cloud provider that did not happen to have too many hacker friendly resources listed, I also had credits to IBM cloud that I was using to set up a CTF level for the CloudVillage.
While setting up the CTF challenge, I faced difficulties with some of the documentation that led me to poke around the services a bit more to gauge which attacker friendly configurations were in place.
To be able to attack any cloud provider for that matter, you can be placed in one of these 3 locations, obviously barring the cloud provider being the attacker themselves.
Each of these locations provide various services and resources that can be attacked or leveraged to further your access.
I followed a very exploratory approach with IBM cloud. With the free credits that I had I set up an IB cloud account, I set up the CLI and then poked around different services.
In all the cases, I looked at the resources from both a “this is a new technology” as well as “if this was on AWS/GCP what vulnerabilities would it have” approach.
Majorly, I started a service, checked if insecure defaults were at play, what authentication was used, public DNS and IP information and for each of the services, identified what kind of environment they were running.
All work has been released via Github at https://github.com/Kloudle/pentesting-ibm-cloud
This is an ongoing research project and will likely expand with additional inputs from the community and our work.
This section is about what were my most interesting observations during the poking and prodding of IBM cloud.
I started by looking at what public objects are exposed by customers who use IBM cloud or as an extension of different services.
Weirdly, I was unable to find the public IP ranges for the IBM cloud as this would be one of the first things attackers would want to enumerate and scan. AWS, GCP and Azure all publish these ranges within their documentation.
The only documentation I found was not the public range for IBM services. I figured walking backwards might be useful, so I created a Floating IP, looked at the public IP neighbourhood and gathered IP ranges from there using the Hurricane Electric BGP site.
The IP address ranges belong to an ASN called SoftLayer Technologies, Inc, which was incidentally acquired by IBM in 2013
Following this across different regions within IBM Cloud, I created a list of IP ranges that would be useful for additional OSINT.
Censys or Shodan are good services to start with to see what’s running without sending a single packet to the target.
I made a list of things to do so that all IP ranges can be uncovered for IBM.
The first service I started poking around was the IBM Cloud Storage service. Very similar to the AWS S3, IBM Cloud storage also uses similar terminologies.
A cool feature of IBM Cloud storage is the integration it provides with IBM Cloud SQL Query. You can run SQL queries on uploaded data if it is JSON or CSV for example.
Looking at the HTTP response headers and body when accessing an IBM storage bucket, shows that the implementation is of Cleversafe, a storage company that IBM acquired in November 2015. Searching for “Server: Cleversafe” on Shodan shows promising results.
I documented the steps needed for CLI access to interact with Object Storage. The steps were far too many considering that AWS or similar storage services require minimal access steps.
Using the information we have so far, we can search the Internet for public IBM buckets.
Both Google searches using the DNS naming convention and subdomain enumeration tools work well and I was able to get a decent size list of bucket names.
For future work, made a note of access policies for IBM buckets and to enumerate other storage type services namely disk snapshots and compute volumes.
IBM Cloud shell is an interactive shell environment that gives you a quick terminal to work with your IBM account on the CLI
The IBM Cloud Shell environment is a Bluemix container based on Kubernetes as seen by the output of cat /proc/1/cgroup and mount commands.
The Bluemix config json contains an IAM Token that can be used with IBM REST APIs.
I was able to make requests to IBM API endpoints with the IAM token to fetch a list of storage buckets within the account.
Additional investigation is required to identify if the IBM Cloud shell has internal IBM network access and if container escape is possible.
From an attacker perspective, knowing what the CLI configures on the client is very useful in terms of a wider attack surface.
The IBM Cloud CLI offers multiple ways of logging in. I used the “One Time Passcode” method as this was the most convenient.
Just like in AWS we have the aws sts get-caller-identity, we have ibmcloud account show on IBM
After you have logged in, the CLI token is saved in the ~/.bluemix/config.json as IAMToken. This is the same token that the IBM Cloud shell container uses when a cloud shell is invoked.
The IBM Cloud CLI can also be logged in via API key on the cli or REST API using the API Key to obtain the IAM token.
IBM Cloud functions are based on OpenWhisk. A simple python function was set up that would give me reverse shell access to the OpenWhisk container.
The reverse shell can be kept alive for 600 seconds as that is the maximum time of execution to wait for the container before it is killed.
Previously disclosed security weaknesses like CVE-2018-11756 and CVE-2018-11757 were allowed for overwriting of the function code. These have been fixed now.
Future work with IBM Cloud functions is to get container capabilities and see if OpenWhisk has other security flaws.
IBM Cloud Virtual Server for Classic is the previous generation of virtual machines service. This has support for End of Life operating systems including Ubuntu 16.04 LTS.
While setting up the machine, I noticed that the service stores the login password for root and allows a user to retrieve the password in plain text. No private key required to decrypt.
The interface is like a password manager and you can use this to store other passwords as well, none of them requiring any additional keys to decrypt them.
IBM Cloud Databases include about 21 different types of managed DB services. I started poking around the first in the list - Cloudant JSON.
Cloudant JSON is a JSON document DB and provides a HTTPS endpoint post creation which has no authentication by default!
Using the unique headers that the HTTPS endpoint has, it was trivial to find Cloudant JSON databases exposed to the Internet using Shodan.
Future work will be to see how other database services are configured within IBM and what information they leak. We will also be able to tell how IAM fits into authentication for these database services.
This presentation was a means to get started with documenting offensive insights into how IBM Cloud can be set up by devs, what misconfigurations can exist and how attackers can abuse these.
Future work will be around updating the documentation and maintaining it, continuing documentation around misconfigurations and insecure defaults, building reliable tooling to automate some of the misconfiguration detection work and to explore the services that I did not see during the creation of this presentation.
Community support is important to keep this project alive! Pull requests are welcome at https://github.com/Kloudle/pentesting-ibm-cloud.
Thank you.
This article is brought to you by Kloudle Academy, a free e-resource compilation, created and curated by Kloudle. Kloudle is a cloud security management platform that uses the power of automation and simplifies human requirements in cloud security. If you wish to give your feedback on this article, you can write to us here.
