Wappalyzer SSRF Write up

Preface

             Awhile back I noticed @Random_Robbie and @Spam404Online reported XSS vulnerabilities in Wappalyzer 's website that were fixed, and seeing that they accepted bug reports for kudo's, I wanted to find some vulnerabilities to report to them.

Recon

             We first check their website's robot.txt for any sensitive files or end points, which is everyone should do, one of end points was named console which looked interesting. When I visited it, it said "waiting for input followed" and " stop", this looked familiar since on their main page they have a feature called "Analyse a website in real-time" which shows the same dark screen and same message as before. How this end points functions is that you submit a url and it'll  crawl that website, showing the directories. The one of the vulnerabilities that was uncovered was being that if the website had several directories then it would put the input into a script block. This end point didn't strip input which allowed me to find a trivial xss involving </script><svg/onload=confirm()>, but this isn't what the post is about. I checked if the end point made a request to any other pages when you submitted url and it made a request to the console end point as I mentioned before. The end point looked like this, wappalyzer.com/console?url=  and as most people would of guessed when greeted with this type of parameter is to try to pass the local host address to the end point. First I tried 127.0.0.1, then http://127.0.0.1, both resulted in errors but remembering the site was https, I tried https://127.0.0.1  which resulted in it crawling the directories of the website.  Nothing severe yet since it just showed know directories and nothing sensitive, I moved forward to attempting to check ports and protocols of the website.  Additionally I tried to check for any form of XSPA vulnerabilities but that resulted in nothing. I checked the common ports and protocols which resulted in the following results,

• https://wappalyzer.com/console?url=https://127.0.0.1:22
  Which returned a Connection reset by peer error. This an indication that there was an SSH service listening which didn’t like the request.
• https://wappalyzer.com/console?url=ftp://my_box:12346/
  Connection from [88.99.*.*] port 12346 [tcp/*] accepted (family 2, sport 34480)
  Confirming that we can get ftp connections going form the website.
• https://wappalyzer.com/console?url=tftp://test.com:12346/testudppacket

   I used https://hackerone.com/reports/115748 as reference for different protocols to test out during my testing of this website and we could draw several conclusions from this. We could send spam requests from wappalyzer's server due to gopher protocols, we could create DOS due to FTP (of course I didn't opt to test this), crafted udp connection, etc. These vulnerabilities where patched quickly. It's good practice to check any url= parameters or any parameter that uses urls in it for ssrf. On a closing note, wappalyzer is by numerous pen testers and bug hunters due to the wealth of information it can provide, compromising this website could of lead to a watering hole attack.

Gofundme.com Stored XSS

Gofundme Stored XSS #1 - Dashboard Stored XSS Through Campaign Name
Note/overview : A problem that came up was they restricted campaign names to 35 characters. So we have to check what's being allowed and disallowed,  what and where input is being reflected, escape and then trigger an alert using 35 characters or less.

When I was checking gofundme.com I created a campaign and named it using something easy to find, in this example I used Tera. I went to the the dash board then to my campaigns to view how it reflects.

Then I started to probe the campaign feature using common symbols to see if they have any form of black listing, or filters in place. I used <x>"xss"

We see that <  and > were stripped yet quotation marks were left in place and they also affected the source code. Using this information I decided to inject the following vector

"onmouseover="alert()"

 This inline xss vector,  would basically include the event handler as a segment of the website's code. Essentially, we're injecting into the title="campaign name here" 

When we visit my campaigns again, and view the source, we can see it's been reflected into the website. Then we mouse over the campaign to trigger it as seen below

Normally most people will stop here, but what if we go deeper and try to have this work on a public facing page.

Gofundme Stored XSS #2 - Public Facing campaign Page


I decided to humor myself and go to the public facing webpage to see if it works. When I viewed the page nothing happened then I noticed I got an error in the console menu.

Apparently they don't sanitize here either so we know what to do now. We wouldn't need to include an event handler since we're inside a script tag, don't reinvent the wheel when we can have it execute our alert by including it.
We use "+prompt(document.domain)+"  this is only 28 characters and will work as a campaign title then we go check the public facing page to see if it works. Which is does as seen below, I tested it on chrome and on a different computer which confirms the fact that anyone who visited my campaign would receive it.

XSS stored or reflective doesn't need to be a complete segment of code or use conventional means to trigger XSS. You can always use pre existing code to inject and trigger an alert through including it. Inline xss is much forgotten about.  As of this time now the vulnerability is patched thanks to the gofundme team, I was rewarded 450$ for this vulnerability. 
*note:first write up, forgive me if it's not clear or doesn't make sense

\My List of Recognitions - Hall of fame, Acknowledgements, Recommendations, Etc

As of  July 2017 I have been recognized by several websites written below.
*Microsoft Online Services
*Groupon
*Adobe
*Zendesk
*Zopim
*AOL
*Avira
*Yandex
*DuckDuckGo
*Expedia
*French Defense
*Italian Defense
*CitiGroup 
*BuiltWith
*Fitbit
*Dutch National Cyber Security-35 submissions
*Urban Dictionary
*Gitbook
*Twitter
*Zaption
*Cisco - 3 submissions
*Invision
*Informatica
*Ubiquiti Networks
*Gofundme
*SoundCloud
*Eset
*Sony
*Att
*Europa.eu (European Union )
*Department of Defense -30 submissions
*Hack the Pentagon
*Hack the Airforce
*Bandcamp
*Gifs.com
*Gyfcat
*Amara.org
https://about.amara.org/2016/03/05/amara-release-notes-2016-03-04/
https://www.gitbook.com/security (under old name)
https://bugbounty.att.com/hof.php
https://contact.security.aol.com/hof/
https://hackerone.com/alyssa_herrera
https://secure.sony.net/hallofthanks
https://www.openbugbounty.org/researchers/Alyssa_Herrera/
Eset Acknowledgement 
https://vid.me/Alyssa_Herrera
https://cert.europa.eu/cert/newsletter/en/latest_HallOfFame_.html
https://technet.microsoft.com/en-us/security/cc308575#1014 (under old First name)

Exploit Galore: A tale of a private Bug bounty Program and how information disclosure lead to RCE.

I was recently invited to a private bug bounty program through twitter for a website that hosted videos of product demonstration and was a sister site to the company's vendor page.
Reconnaissance

An important thing about finding vulnerabilities is finding out as much information as you can about the website. What's being used on the site, any type of cms, old plugins,etc. During my initial check I noticed at the bottom of the page it said it was powered by Vshare. Vshare is a now defunct CMS for hosting videos and basically a clone of youtube in functionality. I read the documentation on the CMS from google then checked for common directories or sensitive files that were outlined in the  documentation and any other key information I could use to exploit the site  through google dorking. One of the files I noticed was phpinfo.php, which if you don't know what it is, it's basically commonly used to check configuration settings.  

Onto the fun stuff, I found that it supported Exif and decided to test out an idea.  What I found was that the User avatar uploaded allowed .jpg and .png, and did very basic check for malformed files or php disguised as an image file. Using an old and known trick, which involved manual tampering the upload post I was able to upload a php file through Exif data.  This page and this page,  showed me how to take advantage of the exif support.  I achieved arbitrary file upload and RCE but I decided to dig further into the website. Later I discovered Image Tragick also affected the website much to my dismay.
During my reconnaissance for subdomains that might be hosting staging, defunct  or unclaimed apps, beta environments, testing pages, etc using sublist3r.  I found a subdomain named videos.website.com and it was running the same CMS albeit lack of user submitted content and seemed more like testing subdomain, though I was planning to looking for any form of SQL injection due to the existence of mysql db being needed for the cms to work. From the documentation the search bar  used the Database to search for videos, and I checked using Time based commands such as 'sleep(), etc but came up with nothing then checked for XSS but much to my surprise I managed to get an SQL error  using  videos.website.com/search/'*/ 

Through the help of a fellow security researcher who didn't want to be named I was able to craft a payload that demonstrated capability to load the etc/passwd file, and yes it's totally possible to achieve RCE through sqli. This made two RCE vulnerabilities on one website, both were reported quickly. Most people would stop here but seeing how the site was handled and setup, it wouldn't be a surprised there were other vulnerabilities lurking around, and I did eventually find more.

Any further vulnerabilities on this website? 

 

 The website allows a user to make a publicly available playlist of their favorite videos. I used basic xss vectors, <svg/onload=alert()>,infamous <script>alert()</script>, but came up empty but I  was escaping  just not executing. I  checked a blog post and used an inline vector to trigger this xss, similar to the gofundme but this one using "autofocus/onfocus="[1].find(alert)" which worked as intended and viewing it as a random person also gave me the pop up confirming it's persistence.  There were also three reflective cross site scripting  as well but didn't qualify for a bounty. To close this bl log off by saying make sure you fully look through company assets. This private company opted to fully rebuild the entire website and remove the offending subdomain. 

Scope reconnaissance and using Shodan to discover vulnerable host used in a private bug bounty.

Normally for bug bounties, I check shodan.io using hostname:website.com and check for any hosts being used by them. One of their hosts stood out,  it lead to a default phpinfo page which listed out information about the  host. An attacker can obtain information such as:
•Exact PHP version.
•Exact OS and its version.
•Details of the PHP configuration.
•Internal IP addresses.
•Server environment variables.
•Loaded PHP extensions and their configurations.
This information can help an attacker gain more information on the system. After gaining detailed information, the attacker can research known vulnerabilities for that system under review. The attacker can also use this information during the exploitation of other vulnerabilities.  This lead me to discovering it's using Memcache and after reading Zephrfish's post,  about the issue I was able to  understand the issue more clearly. I connected using telnet to verify that i was able to easily access it and found that I was.

 Additionally I found that version of memcache was vulnerable to multiple integer overflow vulnerabilities exist within Memcached that could be exploited to achieve remote code execution on the targeted system.   From  http://www.talosintelligence.com/reports/TALOS-2016-0219/ and
http://www.talosintelligence.com/reports/TALOS-2016-0220/

 Short blog post, but it goes to show how shodan can reveal more vulnerabilities that you wouldn't normally find that use vulnerable services.