The second Jira website I discovered was surprisingly harder to exploit. It didn’t give me the verbose errors like the one I discussed and showed above.
I ended up discovering that I could assess whether certain ports existed internally based on response time.
For example: Querying Port 22 resulted in a 1,000ms response time. Where as querying Port 21 resulted in a 10,000 ms response time. Additionally I couldn’t figure out any supported protocols due to the lack of verbose errors, though I ended up focusing on the key point of this article, accessing NIPRnet. I also used burp collaborator to see what type of information was being leaked when it requested data from a server I controlled.
What I noticed from the request headers was that they were leaking sensitive information including an ‘X-Forwarded-For’ header that leaked an internal IP. I ended up querying all IP’s that interacted with my ‘Burp Collaborator’ server link as well to see if anything odd happened. Nothing did, however, besides a time out error. At this point I also discovered I wasn’t able to query AWS metadata on this endpoint though I was able to query the intranet IP’s and DoD servers just like I did with the first website.
The severity of both reports were increased to critical after reporting my findings. Later on, I revisited two low severity SSRF vulnerabilities I previously discovered and reported earlier this year, in the hopes of increasing severity with the information I discovered from my previous research.
These two vulnerabilities leveraged a web application filter by abusing an HTTP connect request for querying a specific IP’s. The request was very simple, we submitted CONNECT IP and we could then enumerate services through this method. We could have also abuse the host header to perform an authentication request to a internal IP or external ip, for example: militarywebsite.mil@internal_IP. Upon revisiting them, I discovered I could perform Blind server side request forgery by querying internal IP’s or services which resulted in the page telling me the operation timed out, an SSL error, or some variation of it. The reports were increased to medium severity after the fact.
During my research of these exploits and discovering bug bounty targets using them, I discovered that in certain instances during exploitation, a stack error would occur and leak out various sensitive information. I haven’t really found the source of why it happens in some instances but not others. You can typically trigger it by using an incomplete HTTP Protocol like http:// or how I initially discover it by using, http://[::]. Information that is leaked include the Database IP, version of the database, plugins being used, OS, architecture of the OS, etc.