TL;DR LeakLooker has more to offer, now you can hunt for Gitlab, Jenkins, SonarQube, Samba and Rsync. In addition, it supports custom queries, so it’s even easier to narrow your search.
Tool here → https://github.com/woj-ciech/LeakLooker
Previous version of LeakLooker (https://hackernoon.com/leaklooker-find-open-databases-in-a-second-9da4249c8472) showed how easily is to find publicly accessible databases with trove of information, even personal ones. It focused on databases like MongoDb, CouchDB or ElasticSearch but there is much more to discover.
In some cases, when company has hid their assets, you need to dig deeper and look somewhere else, where credentials and URLs, to more valuable services, may be stored. Perfect example of this “hunt” are config files from different projects. That projects/tools/scripts usually connect to external services and have hardcoded passwords and usernames. It’s easy win for further vertical/horizontal privilege escalation.
If you read carefully this blog, you should know something about Rsync and why it might be culprit of a leak. Except my discovery, I stumbled upon couple more —
For the record, it operates on port 873 and is used to synchronize files between machines. Script returns IPs which have anonymous mode enabled and any rsync module.
rsync -az IP:/module ~/ — progress
rsync — list-only IP:/
rsync -avrz /opt/data/filename [email protected]:/opt/data/file
In short words, SMB (Server Message Block) is used for sharing files, printers, devices and other resources over a network. You don’t have to be genius to see that if misconfigured can give total access to anyone. Retrieved documents are usually internal, like salaries, resumes, projects or HR things.
Except IP, hostnames and port, LeakLooker shows you accessible shares. It’s worth to note that if SMB server does not require authentication, it does not mean that you can mount every share from there.
mount -t cifs //IP/SHARE /media/Share -o user=root
mount -t cifs “//IP/SHARE” /media/Share -o user=,password=
SonarQube & Jenkins
Like two friends, SonarQube and Jenkins are used together in most cases. First of them is responsible for analyzing and inspecting code in static way and Jenkins is known for integration and deployment. Together they keep very sensitive information, apart from source code itself, which is IP (Intellectual Property), it’s possible to dig out config files, API tokens, database credentials and lot more. It’s again great example of privilege escalation inside of the company. Additionally, it supports searching, so keywords like “config”, “database”, “admin”, “dbconn” are your friends.
SonarQube keeps every scanned project in organized way and having source code it’s in your hands it is easier to find vulnerability and then exploit it. Unfortunately, it’s not possible to list all the project without directly touching SonarQube server. However, from my calculation it seems that around 80% of servers have no authentication at all and contain at least one project.
Jenkins it’s not very different regarding leak and kept information. You can find there development versions of applications, git files, config files and of course more and more. By default it listens on port 8080 and, if misconfigured, return main page with jobs and executors. Shodan indexes this page, and LeakLooker parse html code and shows you all available assets. Based on this, we can assume if the information kept there is worth to review.
Jenkins 200 ok
One of the most famous Gitlab leaks that come to news headlines was brought by Upguard and involved Cambridge Analytica. Server misconfiguration was based on allowing anyone (from any domain) to register account in theirs Gitlab instance. After that, it was possible to browse the whole source code, clone it or do any damage. Of course it included what I’m highlighting, i.e. credentials to database, ssh keys and other ‘opportunities’ to move deeper.
There are couple ways to detect Gitlab servers in Shodan. I tried first with simple filter with hostname and port — “hostname:gitlab port:443” but it gives only around 2,7 k results. One of the very helpful and not very well known Shodan filter is “http.favicon.hash”. It calculates hash of favicon.ico image and search for exactly this same value, which returns websites running this same software or service.
To display Gitlab servers, LeakLookers uses “http.favicon.hash:1278323681” query. Next, it parses html response and look for word “Register”, if found it means that registration is possible. Last thing is manual check to confirm if registration from any domain is possible.
From now, you can narrow your search with additional keywords or filters. It’s useful for bug bounty hunting, for example — filter “hostname” will give only results from particular hostname, which is in scope of BB program.
If you prefer to narrow your search to specific files or documents, no filter is needed then. You can pass your keyword to LL and it will be included in search. Keywords can be differ depends of your hunt, “backup”, “confidential”, “clients”, “flights” or “tickets” are just examples, what might be leaking and valuable.
Below screenshot presents results from command:
— jenkins –first 1 –last 1 –query “hostname:gov”
Which means, show me all open Jenkins instances only on first page with “gov” in hostname.
Rsync and SMB are services that pose direct risk if not configured properly. Intellectual property leaks can make real damage to company. From the other hand, there are services like SonarQube, Jenkins and Gitlab which might leak IP as well as credentials to other services or servers.
As you could see, getting access to database in OSINT way might consist of couple additional steps. Amazon API key found on Gitlab can be used to dump information from s3 bucket, which might include additional credentials to production database. Companies that have poor server configuration don’t care about credentials being stored securely.