My name is Jude, I’m a Security Analyst working with a Security Operations Center (SOC) team based in Australia. Outside of the usual SOC tasks (alert management, detection use cases), I work on specialist engagements around analyzing and understanding the external attack surface of companies using OSINT investigation and Dark Web Monitoring. One of the tools I use most is SpiderFoot, because it allows us to integrate a number of sources into one easy platform to work from and protect clients from vulnerabilities and data exposure on the web.
In the last blog we started down a path of seeing how effective SpiderFoot is in the early stages of investigating a public bug bounty program for low hanging fruit exploits. In this blog, we’ll go into detail on some of the things we found and validate them to see if they’re current, and of course feasible with the current infrastructure.
Feasible Exploitation
The first two CVEs we discovered were CVE-2013-3587 and CVE-2011-3389, HTML and SSL vulnerabilities respectively. These vulnerabilities are largely based on cryptography, and aren’t really feasible to exploit without quite a bit of work. That being said, the former vulnerability does have some proof-of-concept (POC) exploits available on Github, mostly known is a .sh script ‘testssl.sh’ that runs against the vulnerable web server to ‘exploit’ the vulnerability. This exploitation gives the attacker an anti-csrf token value that proves the validity of the vulnerability so to speak, but doesn’t actually exploit the vulnerability completely – an interesting finding, nonetheless.
The SSL vulnerability we mentioned in Part I refers to an encryption error, where the encryption method uses CBC mode with chained initialization vectors (IV) which again allows MITM attacks by obtaining plaintext HTTP headers via a blockwise chosen-boundary attack (BCBA) on a HTTPS session. Also known as a ‘BEAST’ attack, a BCBA is essentially controlling the data with which an encrypted secret is encrypted, in order to determine what the secret is through having the first byte of the encrypted secret be the last part of a block of encrypted data that we know the content of. This is a very complex exploit relying on cryptography, which also interestingly has a few POC exploits out there that you can find by looking for ‘BEAST’ attack POCs if you want to learn a bit more about how this works.
SpiderFoot is a powerful tool in finding these vulnerabilities, as it doesn’t just use SHODAN to find ones that have already been disclosed against the web server IP or the website domain, but it employs a number of tools – including that ‘testssl.sh’ script we mentioned for CVE-2013-3587 – to find vulnerabilities that may be of interest. All of this information we’re working with and validating was collated in one place and has made this process a lot smoother than doing all of this manually.
OpenSSH Bugs and Port Enumeration
Let’s talk in depth about those OpenSSH vulnerabilities we found. The first, CVE-2018-15473 was detected on the subdomain mail.theendlessweb.com and as we discussed in part 1, is a user enumeration bug with a CVSS score of 5.0. The vulnerability relates to OpenSSH version 7.7, whereby the software is prone to user enumeration due to not delaying SSH bailout for an invalid authenticating user until after the packet has been parsed completely. This is a blind enumeration attempt as it doesn’t allow the attacker to see what usernames are in place unless they correctly guess.
The two other OpenSSH vulnerabilities detected were CVE-2017-15906, another user enumeration bug, and CVE-2018-15919, the read-only filesystem bug. The latter vulnerability specifically is a user enumeration issue in ‘auth-gss2.c’ that remote attackers can use to detect the existence of users on the target system, and the former is a fault in the process_open function in ‘sftp-server.c’ that does not properly prevent write operations in read-only mode, allowing attackers to create zero-length files on the system. These are relatively minor, and in this instance were found outside of the specified CIDR range so we can’t do a lot here.
It’s important to validate against your scope of work when investigating this way, as SpiderFoot is a powerful and comprehensive OSINT tool that will find just about anything related to what you’re working on, and in quite a bit of detail. For our first vulnerability however, this one is right in scope and while it’s also a relatively minor bug compared to some that you can find commonly on web servers, it’s worth validating if it’s even present on the server and/or if the port has been locked down so it’s not accessible to the regular internet (and of course me).
Trying ‘ssh [email protected]’, it looks like users can be enumerated and I picked a good username. Of course, I don’t know the password so I’m not in just yet. I’ll leave this and move onto the other things we found, but we’ve validated the vulnerability and know it to be working:
I couldn’t help but try admin:admin at least.
Validating the XSS Vulnerabilities
SpiderFoot found a few more Medium CVEs that looked to allow XSS and untrusted code execution, including CVE-2018-14040 through to CVE-2018-14042 that allow XSS via the data-container property of the tooltip feature. Looking at them in more depth, we’d need a way to execute code within a data-container if the site had an applicable one, through some mechanism that allows us to upload something in the first place. In the instance of this detection as you can see in the image, the domain and the location mentioned are hardly locations that would normally expect inputs from users. In any case, a pretty interesting find, and you can check out here how this XSS vulnerability works practically.
Finally, in part 1 we looked at vulnerability CVE-2019-8331 which describes a similar bug to the two above, and CVE-2020-11023 which describes a vulnerability in jQuery. This vulnerability allows attackers to run untrusted code that can be executed using HTML <option> elements even if sanitized. This method is done through jQuery’s DOM manipulation methods. There are some POC exploits and examples that work with this method, and you can check out how it works here. This CVE was part of the same detection as the other vulnerabilities, and as a result may or may not have the same issue with potential exploitation. Like the others however, there are a million ways to work with this kind of vulnerability and XSS is always worth investigating when working from a bug bounty program.
An Effective Strategy?
SpiderFoot found these vulnerabilities using the Retire.js tool that SpiderFoot integrates with, and this is just one of the many built-in tools that can aid us in finding vulnerabilities, exploits, and exposed assets that can be helpful context when beginning an exercise in bug hunting. Having this arsenal of tools available means that even without every API plugged into SpiderFoot, a lot of useful information can still be enumerated from your target hosts and put to good use.
Does this use of SpiderFoot make for an effective way to begin on a bug bounty program? In this case, we didn’t find any critical low-hanging fruit that might have given us an edge, but we know a lot more about the target and found a few interesting pieces of information that give us indications as to the state of some of the hosts, how well maintained they are, and the software in use on a number of them. As someone who is hoping to find bugs in the organization’s attack surface, these details give us a clear idea of where to start looking. SpiderFoot has given a quick and easy way to uncover this information with minimal effort.
