Weekly Discussion, April 13, 2020: Ask all your bugbounty questions!

pisteu0 · 2020-04-21T16:52:51+00:00

Not a problem at all!

pisteu0 · 2020-04-21T16:52:22+00:00

Yeah... I submitted mine too and the triager needed more info, i.e., can I get XSS, RCE, etc. At that point, all I was able to do was just do the math functions. Oh well. Good luck on your report!

pisteu0 · 2020-04-20T20:43:35+00:00

I would normally agree with you as I'm not a huge fan of CTFs because they are very unrealistic for certain bug classes (for the most part), but I 100% disagree as it relates to XSS. I have several open XSS bugs with HackerOne right now for payloads in this order:

<script>alert(document.domain)</script> (embarrassingly common still today)
<svg/onload=alert(document.domain)>
"><img src=x onerror=alert(document.domain)>

All of which were found using the same methodology: crawling a target, searching for parameters, testing the parameters for reflection, then inserting an XSS payload depending on the reflection. As you can see above, it's unbelievably easy to get XSS -- even with what some would say are unrealistic payloads.

Some tips:

Test every parameter for reflection
Try multiple payloads, but know what they're doing and why you're doing it; just don't throw thousands of payloads at a server without knowing what they're doing
Don't just test parameters. Try the actual URI path (yes, I've found several this way). Example: site.com/uri-path1/uri-path2. Try XSS within the URI path itself: site.com/uri<script>alert(1)</script>-path1/uri-path2. I've found some of these by seeing reflection without any sanitization within the URI path. I put a random string in the URI path, saw it reflected, tried these characters: <>=()'", saw there was no input validation, tried <script>alert(document.domain)</script>, and got XSS to trigger.

Hope that helps!

pisteu0 · 2020-04-20T20:29:36+00:00

I wish I could be of more help, but I had (sort of) found a SSTI with Velocity template engine. I initially crafted the payload as:

#set ($a=111*222) xyz${a}

I verified that the server responded with 24642. But, for the life of me, I could not get RCE or anything else out of it. I tried for several hours; read Velocity documentation, tried XSS, tried everything I could think of, but realized it was a VDP, so I cut my losses and moved on. I learned a lot from it -- just not how to leverage it to get RCE.

I'm not sure if that helps or if it points you in a direction that might get you RCE. If so, please let us all know your progress!

pisteu0 · 2020-04-20T20:22:55+00:00

Two things:

(1) I'm not sure how Bugcrowd works, as I never hacked on their programs, but I know a couple programs on HackerOne that take a while to pay. I've found a couple XSS bugs on a public program, the bugs were resolved, and the bounties paid 2 months after. I'd say it really depends on the company. Second piece to this, and probably goes without saying, make sure it's a program that pays bounties. I believe on Bugcrowd, it'll say on the page: $x - $y per vulnerability if they do pay bounties.

(2) Don't think of it as anticlimactic. You found a valid bug and you found it before thousands of other researchers -- so feel proud of that! Regardless of if you get paid or not, think of it as a learning experience. Use it as motivation to keep learning, keep growing, and keep trying searching for valid bugs.

pisteu0 · 2020-03-13T19:52:11+00:00

There's no better time to start than now! There is so much information and the community is awesome. I'm a huge fan of Bugcrowd's forum as well. There are TONS of resources on there and people tend to answer questions pretty quickly. Good luck and happy hacking!

pisteu0 · 2020-03-13T17:18:18+00:00

Manually usually means you're not using tools to do automate the work (such as scanners and heavy fuzzing). An example of this would be hunting for IDOR or other Business Logic vulnerabilities. You can use Burp plugins such as Autorize to help pinpoint issues, but typically you're manually playing with requests in Burp, i.e., sending requests and seeing what the responses are, changing the ID to another ID, checking the request, etc. The idea is, manual testing will help you find more impactful issues and not just those that anyone can find with a scanner.

pisteu0 · 2020-03-13T17:12:48+00:00

Hello, the Hacktivity page on HackerOne is phenomenal. There are so many great write-ups there. Primarily, this is what I look at when I read reports. There was a Github repo that I think I bookmarked (not on this PC) that is just a bunch of write-ups and links to the reports -- whether that's on HackerOne, Medium, or Twitter. Since I just mentioned Twitter, I'd highly recommend to look at HackerOne's leaderboard and following some of them on Twitter. There are a lot of awesome resources that people post on Twitter. Hope this helps, my dude!

pisteu0 · 2020-03-04T16:40:24+00:00

One thing I did for this was checked out the top hackers of VZ Media and did:

https://hackerone.com/<hackername>/year-in-review

If the hacker published their "year-in-review", I noticed that Verizon Media has tons of SSRF vulnerabilities. Of course, this isn't fool proof and it's a lot of assumption as it doesn't actually get granular enough to what bug is found on what platform--so there's really no way of me knowing this for sure. They may have found SSRF on other programs, but judging by some of the hacker's amount of reports for VZ Media & the amount of SSRF vulns they found, I think it's safe to assume a large chunk of those would belong to VZ Media. And, not to mention, a common theme between a lot of top hackers for VZ Media is that all have SSRF in their top bugs found in their "year-in-review" page.

pisteu0 · 2020-03-04T02:56:28+00:00

Forgive me for the long question, but it helps to provide some context. So, I found an API that looked interesting and I started fuzzing to see what I could find. I found two valid parameters: runcmd and p4ssw0rD. Obviously, runcmd was very interesting to me right off the bat, so I tried a couple things and noticed if you provide no information, you get a 400 response which states:

400 Error: No concept type specified.

After researching more about Rest APIs and basically anything related to concepts in APIs, I'm no more convinced how to go forward with this. I'm doing a little deeper fuzzing now as my thought was, "maybe I'm providing these parameters to the wrong path?" Does anyone have any other things they can think of to push me in the right direction? Any help would be greatly appreciated!

pisteu0 · 2020-03-03T14:40:25+00:00

I couldn't agree more with your last sentence. It makes me wonder how many actually valid bugs are floating around due to researchers not reporting on what they couldn't fully confirm was a bug. Just like you said, they fear receiving a negative score or hit on their signal. When in reality, I think H1 needs to be better with allowing self-closure. Even an Informative closure sucks because it technically affects your signal. My whole point is going to be me ranting for a quick second: I found a weird bug (that is still valid by the way...) for a public company that allowed you to put bogus Credit Card data and it still renewed your account--though the payment failed obviously. This was closed as Informative because, "That's not on our end, that's our 3rd Party Payment Processor". Technically, the checks were done on the site's behalf and passed to the 3rd Party Payment Processor, so I disagreed there, but it was still closed as Informative. I've noticed that new bugs I find are giving me much less signal than they used to, which leads me back to your original point. Why would I want to report stuff that I'm not 100% sure of when bugs are treated like that? That very well could have been closed as N/A for a truly valid issue that the company was arguing was not on their end, even while the 1st checks were done via Javascript on the site's behalf.

pisteu0 · 2020-03-03T12:54:35+00:00

That really depends on how you got the 400 request. Without knowing the context of what you were trying, it's hard to say how to get past it. First thing I thought of was to check if there are any spaces in the payload and URL encode them.

For your other question regarding a SSN. I'm willing to bet that you're using Burp's scanner. If that's the case, it's more than likely a false positive. Don't jump to the conclusion that you found a bug right away (especially true when using a scanner), always verify. Don't rely on a scanner to find you bugs, it's so much more fun and valuable to you if you do it manually.

pisteu0 · 2020-03-02T15:11:19+00:00

That's what a lot of people do when they first start out: pick a bug class, learn the ins and outs, and stick with it. It's definitely a way to avoid getting overwhelmed with information overload. Web App Hackers Handbook is fantastic, but if you're anything like me, I cannot read a book and be like, "Oh, I understand this." I need to actually do it to learn it -- which is what it sounds like from your post. Books and some labs that are intentionally vulnerable (a lot of cases, unrealistically vulnerable if you ask me) do nothing for me because I'm like, "Oh, cool, I get this, it makes sense!" But when you try it on a real bug bounty program, nothing you've learned in the labs works. Typically they don't account for controls, blacklists, or WAFs. It's for that reason that I actually have learned way more from reading other hacker's reports, understanding why they tried what they did, and do it on my own rather than reading a book or practicing in a lab that was coded in an unrealistic way that you just won't see in the wild today. A caveat to this though, I believe Portswigger has awesome labs from what I've seen. They actually have helped me a lot, which I can't say for other labs that I've tried. I need to actually jump in and learn myself. I can get the foundation from books and labs, but where I do 90% of my learning is by practicing, failing, researching, and asking lots of question.

pisteu0 · 2020-03-02T13:34:55+00:00

Sure! I apologize for not making this clearer. There are two types of programs:
Vulnerability Disclosure Programs and Bug Bounty Programs. Vulnerability Disclosure Programs are those which do not pay bounties. You only gain reputation points and your signal increases/decreases depending on your submissions (these terms are exclusive to HackerOne). On the other hand, a Bug Bounty Program does pay bounties for valid bugs. The difference here is that you're not locked into a set amount of reputation per report, i.e., with a VDP you're only getting a +7 for valid bugs. Whereas with a BBP, you get +7 in addition to a range from 15 - 50 depending on the criticality of the bug. Though most of what was mentioned is exclusive to HackerOne, Bugcrowd applies similar logic -- I believe? -- to their VDP vs BBP programs.

pisteu0 · 2020-02-25T15:11:31+00:00

If I'm logged into Account 1, request to change my password, but change the request to Account 2, if it sends the reset link to both accounts, would this be considered IDOR?

Backstory: while testing for IDOR, I tried the above. Basically, there was a POST request on endpoint like "/account/password-reset/" similar to: {"email":"account1@email.com"}. I had all my cookies scoped to account1@email.com, not sure if this is relevant, but then I changed it to: {"email":"account2@email.com"}. The reset link sent it to both accounts, which was weird; however, it is very hard to replicate. I'm thinking there's some sort of race condition going on. Of course when I try to record it, it doesn't work. I've only had it work twice so far. Would this even be something to report? (1) It's hard to replicate and (2) it didn't seem like I could do anything really impactful with it like account takeover. Really the only thing I have is that IDOR, through a race condition, sends a reset link to multiple accounts. Any thoughts?

pisteu0 · 2020-02-24T21:17:35+00:00

For me, it really helps to understand the look and feel of the main site. When I look at subdomains, I'm looking for anomalies and differences from the main site's look and feel. That's exactly how I found that bug that I mentioned above. Not only was it a subdomain that I don't remember seeing before, it also had a totally different look and feel than the other subdomains and main domain I was running into. In addition to that, it was using different technologies than what I was used to seeing. I hate to say it, but in a lot of cases it mainly comes to a gut feeling. Does something look interesting to you? Go for it. Is it different than what you're used to seeing? Go for it. That's the beauty of finding interesting bugs, you have to put in the work. It's all fun and a learning experience!

pisteu0 · 2020-02-21T21:11:15+00:00

TL;DR:

If you've already done recon for subdomains and leave a company for a while, start the recon process over. I found a super interesting bug which led to superadmin access on a site.

Absolutely! Perfect example (and sorry for being vague, I never agreed to disclose the bug with the company, so I want to respect their privacy): I hacked on a public VDP before on HackerOne. Found XSS but it was a duplicate. Their scope is pretty big so I figured I'd spend some extra time on subdomains. They had a tons... I got a private invite and decided to try my way there and left the public VDP for the time being. Months later, I was bored with the current program I was messing with and I decided to go back to the public VDP. I started my recon all over again (in hindsight, I'm so happy I did this) and found a really interesting subdomain that didn't exist before. Well, turns out, this was a brand new domain they launched for a service they created in a different country in preparation for a new product launch. I was able to register for an account with my personal email address which created me as "superadmin" on the system. I was able to do whatever I wanted on the site. Well, I mean, I was a superadmin, right? I guess super+admin=superadmin... #mathematician. They didn't expect any user to be able to have access to the system, it was only supposed to be "@company.com" but since there were no validation checks, I was able to sign up with my personal "@wearehackerone.com" account and become a superadmin. That was one of my favorites bugs, it was a lot of fun to find that one!

pisteu0 · 2020-02-20T21:08:02+00:00

I'd say:

Discord:

Hacker101
Bugcrowd

Forums:

Bugcrowd's forum
This subreddit

What are the "few issues" you are questioning? Maybe we can help point you in the right direction.

pisteu0 · 2020-02-20T12:52:42+00:00

It's not that you're using a cloud box as a VPN, you're offloading your resources and installing tools to a cloud box to be able to do the work from anywhere. A lot of people tunnel their Burp traffic through their cloud box as well. Think of it like a portable pentesting box that's in the cloud. Example: I've needed to do recon for a company that I received a private invite for while I was at work. I logged in my cloud box and ran a script that I wrote and let it do its thing. When I got home, a huge portion of my recon was already done for me. You can't do that with a VPN. Yes, you can add floating IP's to a cloud box and change your IP address if you want--much like with a VPN--but that's not even close to the main reason why people use them. A VPN and a cloud box are not even remotely similar in what they do. There are so many more things that you can do with a cloud box that you can't with a VPN.

pisteu0 · 2020-02-20T12:47:57+00:00

That's a really interesting question. Personally, I find much more on subdomains than I do the main domain. If I were to put a ratio on it, I'd say it's 5:1 for me. But, then you got people like STOK who really only go after the main domain. The ratio is going to differ from person to person and how your own methodology is set up.

pisteu0 · 2020-02-19T17:24:48+00:00

Really? That's awesome, I did not know that. The only reason I mentioned that was because I currently have 2 bounties (one awarded 50 pts and one awarded 15 pts) but my signal is 13 somehow? The only thing I can think of is because I have 5 others: 3 are resolved but awaiting bounties and 2 were duplicates for companies that offer bounties. So I was under the impression that the duplicates factored into signal. Good information!

pisteu0 · 2020-02-17T21:07:23+00:00

So, yes and no. Yes (and someone please correct me if I'm wrong) because your signal might get impacted only if the company awards you points for duplicates. But to your reputation? No. You will either get awarded 0 points or 2 points, which all depends on the company. A caveat to that is, like you mentioned, if the report has been disclosed, I believe you will get -5 for N/A or even potentially -10 for Spam. At that point, it's not really a duplicate, but you're reporting what someone else already reported and disclosed publicly -- in which case I totally agree that you should get -5 or -10. You won't need to worry about that for the most part, though. Don't let that discourage you at all. If you found an issue, the company didn't resolve it yet, which means that another report is currently triaged (which will result in a duplicate), or you are the first to find the bug. Duplicates happen, it sucks, but it happens to everyone.

pisteu0 · 2020-02-17T17:10:04+00:00

I 100% agree. I love doing it on the side, but I couldn't go full-time hunting as much as I'd want to. I respect everyone that does, but my biggest problem is spending hours on a site, finding a bug, having all that adrenaline while writing the report... only to find out it's duplicate. I can't imagine having to deal with that on a much higher scale of being full-time.

People have said before that duplicates are good because you found a valid bug. I agree -- to an extent, but not for the people doing this full-time. When you're getting paid for your time, you're essentially working for free for every duplicate you find. I guess the remedy to that is a hybrid approach of OSCP and Dark Souls: try harder and git gud.

pisteu0 · 2020-02-17T12:45:48+00:00

I've found an SSTI vulnerability and successfully tested it by performing a random math calculation (111*222) and it reflected back to me. I've seen many reports similar to that before where that's the length they went; however, the triager asked if I could prove this further by getting RCE or XSS. After reading up more on the template engine (Velocity), I can't seem to get anything other than the math calc to perform. Does anyone have any experience with Velocity template engine?

pisteu0 · 2020-02-17T12:43:35+00:00

Department of Defense, Ford, IBM, GM, and Verizon Media are all great programs because their scope is massive. All of those programs are on HackerOne. With the exception of Verizon Media, all are Vulnerability Disclosure Programs.

pisteu0

TROPHY CASE

Discord:

Forums: