|
Hi ! I hope you are well!
Welcome to the sixth issue of the BBRE Newsletter🔥. This time you received the premium version.
BBRE premium is something that is scheduled to launch in August. Until then, you will receive extended versions of #6, #7 and #8 issues.
What will BBRE Premium include? You will see but it will be definitely even more than those amazing emails!
Here's what I prepared for you today:
- From 0 to TOP7 Hackerone in 2 years
- How XSS experts bypass CSP?
- Finding DOM-XSS with Untrusted Types
- 50 SSRFs found in ColdFusion
- Generating a web application
- Many struggled for hours, he did it in 57 minutes
- Testing iOS apps without physical device
- How to not plan the day?
From 0 to TOP7 Hackerone in 2 years 
Ahmad Halabi was the top 7 hacker on Hackerone in 2020 after starting bug bounties only in June 2019!! It's a huge achievement in my opinion. Add that only in 2016 he received a mobile phone with an internet connection. That's only 5 years ago! It just shows that with a good learning process and attitude you can achieve outstanding results in a really short time.
Are you interested in knowing how did he achieve that? I certainly am. Lucky for us, Ahmad decided to describe his journey in two articles. We can read what worked for him but also what didn't work. Those two articles are really golden because we often see those 5-digit payouts (even on my channel 🙄) and we might feel like every bug hunter is scoring them all the time. But it's not the truth. That's why It's really good to see when someone as successful as Ahmad shows us the big picture.
And since this is a premium mailing, I'm not only giving you links and telling you to spend the next 20 or more minutes reading those articles but I did this myself and here are the main takeaways:
Learning path
First, there was chaos. In June 2019 he was reporting clickjacking and other low-risk stuff what led his Hackerone reputation to decrease from 100 (starting point) to 67.
Then, he started hacking on programs with no bounties. Mainly it was the Department of Defense where he became top 1. He really got to know it and what bugs are typical for DoD. He submitted many reports but received only 2 bounties that year.
In June 2020 he started focusing on making money. It took a whole year of learning and many reports submitted before he started thinking about the money. It's one of the most important lessons - take the time on VDP programs with the focus on learning and not getting monetary rewards first.
Since then he started focusing on paid programs and well-paid bugs.
Learning sources
He mentions a few learning sources that he used:
Also, there are a few writeup sources:
- Pentesterland's List of Bug Bounty Writeups
- Hackerone Hacktivity (https://hackerone.com/hacktivity)
- Bugreader Reports
- BugBountyWriteups (https://medium.com/bugbountywriteup)
A few tips
- Read writeups and never stop learning but since you are still reading this email I can say that you don't stop learning so huge congratulations to you my friend🎉
- Automate what you can but don't rely on it to find vulnerabilities for you. It can only help you make some things faster.
- Put a lot of effort into writing the report. Remember to put steps to remediate in the report.
- Stick to a target when you are finding bugs on it but don't be afraid to change it if you can't find anything
- Don't depend on others' methodologies. Create your own one, create your checklists, your notes etc.
Results
- Ranked 1st Hacker at United States Department Of Defense in 2019.
- Ranked 1st Hacker at IBM in 2020.
- Ranked 3rd Hacker at United States Department Of Defense in 2020.
- Ranked 7th Hacker at HackerOne Leaderboard in 2020.
- Ranked 1st Hacker at U.S. Defense Industrial Base.
- Listed Among Top 50 Hackers WorldWide on HackerOne.
- Scored above 12,700 reputation on HackerOne (Still in Progress).
- Ranked 1st Hacker in Lebanon by HackerOne.
Full-time bug bounty?
Even though these are outstanding results, Ahmad mentions that he does not do bounties full-time because it can burn out quickly. He treats it as a side income which makes it more fun.
I think it's also visible in the community that even the best hackers don't do bounties for full-time. It probably seems very appealing but apparently, for many, this is not the way to go.
If you are interested in more details of his journey, check out these two articles:
https://infosecwriteups.com/my-bug-bounty-journey-ranking-1st-in-u-s-dod-achieving-top-100-hackers-in-1-year-f208c10144fc
https://ahmdhalabi.medium.com/my-experience-for-2-years-in-bug-bounty-hunting-b22d03f98ed3
How XSS experts bypass CSP? Gareth Heyes is one of the best in the world when it comes to XSS. Lately, he found a great XSS in Paypal. Initially, the report was rejected because PayPal requires you to bypass the CSP.
Although he thinks that XSS should be accepted without Content Security Policy bypass, he was able to find one and his approach to that is really worth noting.
Here are steps he took in the process:
- He of course took a look at the CSP to see what are the potential vectors.
- He defined scope in Burp with whitelisted domains and started looking for older JavaScript libraries hosted on those domains. He hoped to find an old AngularJS, Bootstrap or jQuery but with no success.
- The next part was looking for hosted JavaScript code that was not from any known libraries.
- He found a vector that could be used. Inside
youtube.js file the input ../' + $(this).attr("data-id") + '.jpg"... was used in something like innerHTML function.
- It was necessary to embed this script using
<script src=youtube.j>and create a <div> element with youtube-player class and the payload inside the data-id attribute.
- The problem was that script tags won't execute in DOM-XSS normally. What Gareth needed to do was to use
- Then, everything was ready. The last step was to create this malicious div element:
The whole payload looked like this:
There's HTML and double HTML-encoding in some places to not break the context.
Result:
Really cool CSP bypass. I think you and I can follow that steps when we encounter a CSP.
Here's the article if you want more details:
https://portswigger.net/research/finding-dom-polyglot-xss-in-paypal-the-easy-way
Also, Portswigger has created the DOM-invader tool that looks really promising and I will want to cover it once I'm more familiar with it.
PS. If you are wondering why am I using images instead of just pasting the code, see this tweet:
https://twitter.com/gregxsunday/status/1411284347005571075
Finding DOM-XSS with Untrusted Types Speaking of DOM-XSS... It's definitely the hardest XSS type to find. I remember when I was at the presentation by Krzysztof Kotowicz from Google about Trusted Types where he mentioned how many of their bug bounty reports are DOM-XSS.
I was like "DOM-XSS? I don't think I have found many of them really". This opinion was also backed up by my friends from my company of that time. The truth was that applications that we were testing were not as JS-heavy as Google websites but surely there were some DOM-XSS that we must have missed.
Today we have good tools around them. As mentioned before, the tool from Portswigger is fresh and looks good and I will definitely cover it in one of the future newsletters but today I have for you another one that has really helped me to find a few non-obvious DOM-XSS during pentests: Untrusted Types.
The Trusted Types mechanism implemented by Google was supposed to mitigate some of the DOM-XSS. It doesn't seem to be used that commonly but it enabled filedescriptor to create a tool that facilitates that mechanism to discover those sources and sinks that can be used for the DOM-XSS.
It works as a browser extension and it has two modes.
Passive
In passive mode it just prints out every usage of dangerous functions like innerHTML, document.write etc. They are called sinks.
It looks like this. You have a new tab in the developer tools and there are printed all occurrences of such sinks. You can also see what argument was used.
In this case, We see 3 calls to innerHTML. The HTML code you see on the above image is the function's argument. If there would be some user-controlled data inside this argument, it would mean that there can be the XSS there. In this case, I don't see anything outstanding so there are slim chances of an XSS.
In case you find something interesting, you can expand the stack trace and see the code responsible for that. When you want to open this file, I suggest using the Console tab instead of the Untrusted Types tab. The reason is that from the console you have a clickable stack trace which means you can jump to that piece of code much faster.
Then, the next step for me is putting the breakpoint and debugging the code manually from there.
The problem is that usually there are a lot of those innerHTML calls and almost all of them are false-positives. That can be solved by using the active mode of the tool.
Active mode
It works the other way around. Here you find an input that you want to test and put the predefined value there. Then, the tool will tell you if your input was used anywhere. This reduces the huge amount of false-positives that you see while using the passive mode.
You put in the string "d0mxss" (it's a default value that can be changed) and the log in Untrusted Types tab will be red-colored. You can also mark "Only show highlighted" to remove all that noise from passive mode.
Here you can see that string var searchResultsObj = {"results":[],"searchTerm":"d0mxss"} was an argument of eval function. The d0mxss parameter is taken from the URL query. This means that we have a reflected DOM-XSS here.
My usage
How I use this tool? I usually browse through logs from passive mode only if they are not too long... And they often are.
More often I rely on the active mode. I just put the d0mxss in all parameters and see if there's anything in the console. Also, don't forget to put that in random places in
For example
/path/d0mxss
or
/d0mxss/../index.html (just make sure that the browser won't resolve your ../ with proper encoding)
A really, really good one for DOM-XSS. I'm curious how will this compete with the new tool from Portswigger.
You can install Untrusted Types from the Chrome webstore.
https://chrome.google.com/webstore/detail/untrusted-types-for-devto/bpeblffgmddnafmnmdjohcmkbeifdlnb/related
50 SSRFs found in ColdFusion 3 weeks ago on my channel, I published a video about 0-day in Lucee that was exploited on Apple server. The video is doing really well, closing in on 10k views so you probably saw it already and you are familiar with ColdFusion and CFML tags.
Turned out that 50 (!) functions of ColdFusion were vulnerable to SSRF. Even functionalities that were not supposed to open URLs might make the application vulnerable.
I said after that video that it's appealing to find some more vulnerabilities in this ColdFusion framework and this only makes me more willing to do it.
Check out the article for more details:
https://hoyahaxa.blogspot.com/2021/04/ssrf-in-coldfusioncfml-tags-and.html
Many struggled for hours, he did it in 57 minutes What an XSS-themed issue of the BBRE newsletter this is...
This time take a look from yet another side. Intigriti is known for awesome and really hard monthly XSS challenges. The June XSS challenge was completed only by 16 hackers! It's hard to tell how many tried but it was definitely many.
Within these 16 hackers, there's another respected XSS expert, terjanq. The funny thing is that many hackers spent multiple hours on this challenge with no success and then he has started and finished it in... 57 minutes! Insane!
In his writeup, he reconstructs the sequence of events almost like in "Mayday: Air Crash Investigation" TV series. A really good read to see how the experience makes things easy!
https://terjanq.medium.com/how-to-solve-a-challenge-from-intigrity-in-under-60-minutes-6843ba9b9552
Testing iOS apps without physical device Anyone who ever tested iOS applications knows that it's neither an easy nor well-documented process. It's really hard to start and tools change all the time. Partly, the reason for that is that you needed a physical device with the iOS version vulnerable to jailbreak.
I wrote needed because there's now this thing called Corellium that offers iOS visualisation. They didn't accept Apple's offer to buy them and won the battle in court with them so looks like they are here to stay for a while.
In the article Evan Custodio (featured on my channel in $6,5k + $5k HTTP Request Smuggling mass account takeover - Slack + Zomato video) describes the whole process of preparing the device for testing. From jailbreaking, up until capturing the traffic via Burp.
The biggest problem with Corellium at the moment is that you can't download apps from AppStore. If you have a physical jailbroken device you can install the app there and then dump the application and install it on emulated device. That's the path that Evan presents in the article but to be honest - if you already have a jailbroken physical device I don't know if you need the emulator.
I see two use-cases for that at the moment.
One is not for bug bounty but for pentesting. You usually get the .IPA file directly from the project team so then there's no problem. Corellium can be really useful for that.
In my opinion if you want to do bounties find a friend that has a jailbroken device who can install and send you the applications from the AppStore.
Read this article and save it if you ever need to set up the iOS testing.
https://defparam.medium.com/ios-app-testing-through-burp-on-corellium-fe59ed849516
How to not plan the day?
Let's say it's a Saturday and I'm creating the video for Monday. I do have some time because there's still Sunday coming when I can finish it but I'd rather do more on Saturday and have Sunday free. I don't have anything special scheduled - the whole day can be spent on the video. You know what is the worst plan of the day when I need to get something done?
It's planning to spend the whole day on the video.
I know this doesn't make sense yet - let me explain.
When I say to myself that I will dedicate the whole day to this one thing my productivity is usually terrible. I've done this many times and you know how it looked like?
First, I procrastinated with the start. "I have the whole day", I said to myself while catching up with the latest YouTube videos.
Then I started doing something but I got tired after 2 hours. Instead of making a clear break from that, I stayed in front of the monitor, sometimes even making some small changes to the slides. "I started late, now I need to catch up" was in my head then.
At the end of the day, I did the equivalent of maybe 4 hours of work but paid for it by little physical activity, no time to make a proper lunch and generally feeling bad about wasting my day.
I noticed that sometimes during the busy day when I only could squeeze those 4 hours for the video I was able to do more.
So I added 2+2 and it turned out obvious that I must make my day artificially busy.
For example, on a Saturday when I need to work on the video I will schedule my work in ~2 hour blocks with clear breaks where I mustn't do any work.
For example, I work from 7-9AM, then I will take a break for breakfast, read a book and ideally do some stretching or yoga. Next from 11AM-2PM, I will work again. Then, I will go to the gym, get some steel moving etc.
The point is that those scheduled activities create small "deadlines" for me. When I sit to work at 11AM, I know that I won't do this until the sun goes down but I only have 3 hours reserved because later I go the gym. Probably, for some of you, 3 hours seems like too little to do anything but this makes me really get the best out of that period.
So now, whenever I have a free day I do my best to make it a bit more "busy". It makes me more productive and happier as well, because those breaks are something I enjoy like gym, walk, a match or an F1 race.
Generating a web application This is not really a security link but I just wanted to send you this. Imagine.ai is a free service that generates a REST API for you based on the model that you create. Like many new things, it uses artificial intelligence.
It's probably the trend that more and more repetitive code is auto-generated. It will be very interesting to see what mistakes the AI makes and what vulnerabilities will be common - will it make the same mistakes as human devs or different ones? From our perspective, it will be interesting to see how it changes the security of websites.
I will definitely test this tool when creating some vulnerable apps (BBRE Premium will include hands-on labs so maybe then 😏).
Here's the link to the tool:
https://app.imagine.ai/
I hope you find this newsletter helpful. As I've said, this took me much longer time than usual and I will greatly appreciate any feedback from you! You can even, share it on Twitter (don't forget to tag @gregxsunday). Next Monday, there will be a video so we'll meet here in the newsletter in 2 weeks.
Best,
Grzegorz Niedziela
Bug Bounty Reports Explained
PS. Reply to this email with feedback on what you think of this newsletter. Would you like to get such emails from me every time?
|
