​​How much one can earn on Bug Bounty

#money

In the beginning, I suggest looking at the statistics of HackerOne itself. It's not the most recent, but it gives a good general idea.

According to her, by 2019:
⁃ more than 1 million researchers have registered on the platform;
⁃ more than 9,000 of them earned at least something;
⁃ more than 200 people have earned more than $100,000;
⁃ 9 people earned more than $1 million.

I also know that now there is at least 1 person who has earned more than $2 million.

I would like to separately mention Sergey Toshin (bagipro) from Moscow, he became one of those who were able to earn more than $1 million on H1. In addition to the fact that I'm just glad that he is from Russia, I want to note his unusual approach to finding vulnerabilities.

As far as I know (I don't know him personally, I just read a few interviews and saw his disclosed reports) - all this time he was researching exclusively mobile applications. As a result, he even launched his own startup for analyzing the security of mobile applications, which he financed from his income in a bug bounty.

As for me, my income for 3 years of full-time work was:
⁃ $91 thousand for 2019;
⁃ $229 thousand for 2020;
⁃ $252 thousand for 2021.

And in total, for the entire time of my work, I managed to earn $ 588 thousand.

I want to immediately note that going into this area solely for money, having no interest, is a disastrous approach. My opinion is that here, as in any profession, only a person who sincerely enjoys work can achieve significant success.

P.S.: A big request is not to write to me in a personal, ask all your questions in the comments to the posts.

​​What can jQuery selector injection do?

#technical #think_different

There is a post with a lot of code today so please read using the button below

Today is my daughter first birthday and she has already found a few vulnerabilities

Do you need to be a programmer?

Disclaimer: we are talking about the research of web applications only.

Let's single out 4 types of vulnerabilities.

1. Recon vulnerabilities
Here I will include everything that does not require direct interaction with the application. For example, you can find the ssh key from the company's server in a github commit. Or, say, scan the server's ports and find some outdated service with a publicly known exploit available. This also includes the hijacking of a subdomain or an admin panel open to all without a password on company.com/admin.

Does it need programming? No.

And what you need? Here you need to have a broad outlook in computer science, let's say so. That is, to understand how the web works, what is HTTP, ports, DNS, GIT, SSH keys, and more. It would also be nice to figure out how to use specialized software, such as port and subdomain scanners.

Can programming be useful? Yes, sure. The search for such vulnerabilities can be automated, for example. For these purposes, I would choose some kind of interpreted language, such as python (I use it myself).

2. Application logic bugs
For example, you found that when you buy a product on the server, along with its ID, the price that you see in the application also sent to the server. And it turned out that if you modify this price, then the purchase will be made at a lower cost.

This was found, for example, in OK.ru - it was possible to buy either stickers or music almost for free. And I would include IDOR here - there is a request to change the password of a user with a specific ID. And what happens if you substitute someone else's instead of your own?

Maybe it needs some programming? Well, actually no.

And what you need? First of all, you need to understand how the client communicates with the server via HTTP and master any HTTP / WebSocket request interceptor. The leader here is Burp Suite. There are others, but when I tested them (long ago) they were poor.

And the logic is very necessary. You need to think that the developers could not have foreseen. Or how can you trick the application to get some extra privileges?

Can programming be useful here? Hardly. There is just logic and working with requests from the client to the server.

3. Attacks on the client
XSS, CSRF, CSS-exfiltration, clickjacking, JS-hijacking, I forgot something else.

Do you need to know programming? At the very least, you need to know a little. You need to understand and be able to read HTML and JS. For more complex types of XSS, like DOM-XSS, you will need to know JS fairly well.

What else is needed? You need to understand how the browser works. It is most important. Understand what SOP, CORS, CSP are. Know what security headers are and what they affect. How cookies work and what is the SameSite policy, how can it be bypassed.

4. Attacks on the server
SQLi and other injections, SSRF, race condition, stuff like that.

Do you need to know programming here? Well, I would say that first of all you need to know the theory of programming. That is, what are threads, how queries are made to databases in general (and how injections into these queries work), how an application works and is structured in general, what components it consists of, how they interact with each other. It is absolutely not necessary to be able to create the same application yourself.

Moreover, it is absolutely not necessary to know all the languages ​​in which these applications are made. It is enough to simply understand the general principles and concepts. Of course, if you are a good programmer, it will be useful, you will be able to find some bugs that others cannot find.

So here are my top skills:

1. Not programming, but computer science. How the web, browser, protocols work. Needed everywhere.

2. HTML + JS. For attacks on the client.

3. Python or other simple interpreted language. To automate and understand server programming concepts.

4. Other server languages. Studying their specifics and features to find complex unique bugs.

​​My work schedule

#fulltime #organization

According to the 2020 H1 report:
⁃ 37% of researchers spend on bug hunting from 1 to 9 hours a week;
⁃ 25% - from 10 to 19 hours;
⁃ 14% - from 20 to 29 hours;
⁃ 8% - 30 to 39 hours;
⁃ and 16% - more than 40 hours.

When I was still working in the office, I did this randomly, for several hours a week, when there was time and desire. Before work or after. More for the sake of interest than hoping to earn something.

But when I switched to full time, the question of organizing working time arose. And I've tried a bunch of different options.

In the first month I worked almost non-stop, every day for 8-10 hours with rare days off, as it was just scary to be out of funds. The problem with this approach (for me personally) is burnout. I really love programming and searching for vulnerabilities, I can stay up for a very long time when there is an interesting task.

But after a few days of such work, sometimes the desire to do this further can disappear for 2-3 weeks. I had this even in the office, when we had a project deadline and sometimes I had to not even sleep at night. Then, it happened, I felt sick from work the whole next month 🙂

I consider bughunting not exactly a technical profession, but rather something in between technical and creative. At least my approach is exactly this - I often look for and find non-standard bugs. That is why I need inspiration, a fresh head and rest. It often happened that I worked a lot and with no success, but then, a week later, with fresh energy and already with a desire, I ran the same parts of the application and found something that I did not notice the first time.

Therefore, I decided that I needed to artificially limit myself to the schedule. I tried different options: to work 5 days for 8 hours (to be like in the office), every day for 3 hours without days off, some more. This always led either to a loss of desire, or to the fact that I could not consistently maintain this schedule for weeks and months.

As a result of trials and errors, I came to a schedule of 3 days a week for 5 hours. It's loose enough to have time to reload, but dense enough to get some kind of significant result every week.

I only count the time at which I look for bugs though. Writing reports, some abstract reading of articles - all this is separate. So in total it still sometimes comes out a lot if I need to write a lot of complex reports, for example.

This year I decided to add another day of work to my week, but knowing that this would not lead to good, I did not add another day of finding bugs. Instead, my friend and I began to write software for automating search, and I allocated this day just for it. Changing activities to programming dilutes the week very cool and somehow it has become even easier.

Well, now I still make this channel in my free time, it takes another 2-3 hours a week approximately.

If someone else hunts full time - tell us what schedule you have, it will be interesting)

If you like this week posts you can buy me a coffee or subscribe me on Patreon (from $1 per month):
https://www.patreon.com/skavans

Why do I need this channel

I've always had an urge to share information. Some colleagues and close people believe that I am good at it. That I can tell complicated things in simple words and find an explanation that everyone will understand.

At various times, I had thoughts about teaching at school, creating my own courses for children or adults, even teaching people separately from the hinterland of the country. Because I have this position: if you find a business that interests you, you will be happy at the same time and you will definitely achieve a certain material success. And it seems to me that at the moment I have found such a thing for myself. And I want to tell other people about it, to tell it in an interesting way so that they can also fall in love with it and at the same time make good money. This is the first reason.

I believe that our century is the time of open information. Everything that I know and can do I owe to open reports on HackerOne, blogs of researchers from different countries, YouTube videos and other public sources. Since I have my own experience, my own achievements and ideas, I also want to share them with other people. Plus, unfortunately, our country is objectively lagging behind in terms of the quantity and quality of such content. And I thought I could at least fix it a little. Here is the second reason.

To be honest, for a few days I just dropped out of work, although I can not afford it, as there are a lot of obligations to my family. But I still wanted to write this post. And somehow it sets you up for work, no matter what. This is probably the third reason - to be able to just sometimes speak out.

Regardless of where you are from and how you feel about Russia now, if you are interested in my posts, if they motivate you, teach you something new, I am very happy about this.

Now while problems with free time, but I will try to write more often.

If you want to support my channel, you can become its sponsor on
https://boosty.to/skavans (minimum subnoscription cost is about $1 per month).

Underrated: ClickJacking

Many programs certainly don't accept clickjacking - they just put it entirely in the Out Of Scope.

In general, it is rather stupid when determining the amount of a payout or in-scope / out-of-scope to operate on the type of vulnerability, and not its impact, it always seemed to me very strange.

For example, a scope might have reflected XSS with a complex user interaction on a domain containing a static page without any user data. And at the same time, clickjacking, which allows, for example, to delete objects from the user account (or the entire account) in one click, will be outside the scope. At the same time, it is obvious that the first vulnerability does not have a real impact, unlike the second.

Have you ever seen clickjacking, which does not affect the integrity of information in any way, but affects its confidentiality? Seems weird, right?

I once found clickjacking in NewRelic on a page that hosted a custom API key, and came up with such a funny exploit (see video).

Generally speaking, sensitive data can be stolen from the user in this way. In my example, I created a malicious registration page on some resource, and in the last step, I pass out the frame with the user key in NewRelic as the key to this site and ask that it be copied into a text field to confirm that the key is stored in a safe place (since it is displayed only once).

Alternatively, such tokens can be presented to the user in the form of captcha, which must be entered on a malicious site. I think that you can even put some CSS distortion on top of the iframe with the token to make it completely believable.

P.S.: the real impact is certainly not high, but I really like to come up with such non-standard PoC and exploitation techniques 🙂

If you want, you always can support my channel on Boosty (any donation starting from about $1):

https://boosty.to/skavans

Sometimes it can be useful to check which browsers support a particular technology. Especially when some newfangled protection is implemented on the site, and we want to understand whether it will work in all browsers.

For example, not so long ago Safari did not know how to use CSP Strict-Dynamic, which could sometimes be used when submitting XSS to a bugbounty.

When I have doubts about the prevalence of some security technology, I always go to caniuse.com.

Interesting:

- at the moment no one except IE supports
X-Frame-Options: ALLOW FROM, while some sites use it for some reason, so you can get a little money by reporting clickjacking to them;

- Trusted Types are only supported by Edge, Chrome and Opera, so this technology is not yet destined to defeat XSS;

- once upon a time, it was decided to abandon the sanitizers built into browsers (X-XSS-Protection), since they were more of a headache than good. But not everyone refused. Safari still supports this header, and what it can lead to - I'll tell you another time 🙂

——
If you want to support:
- https://boosty.to/skavans
- ETH 0x1a90F6ABDD2D29bD7A9b8FE099ff8c7dd0961519
- BTC bc1q9uq96lfekq7ec6slhw72k6kvxntzfk9a4un3vs

Guys, I read an interview with some H1 hacker some years ago where he told that he was on vacation with gf and she wasn't glad he was searching for bugs and so he hunted using his mobile and found some bugs. Do anybody know who is this guy? I forgot 🙁 It was one of tops.

If I'm not mistaken, he was hunting in PayPal.

We have a chat here folks so you can join and discuss whatever you want (about bug bounty 🙂)

https://news.1rj.ru/str/+orgiucS0SEQ0Njcy

https://youtu.be/oHYC1-CgrRk?t=243

LOOK IN COMMENTS, there are tools!

For those who has no laptop.
Frans Rosen is telling how he used his iPhone to search for bugs.

It was a long time ago but I think it's possbile now too.

Also, if you find some intercepting proxy tool for your smartphone – you'll be able to do almost the same as we're doing using a laptop.

If anybody know some tools like this, please refer them in comments – it would be way helpful for many people.

Obscure: CSP, SOP, CORS

#technical

Some of you ask me which of them is better and more useful in our bugbounty business. In honor of the anniversary 1631th subscriber, I am making a post-answer for newbies.

Most importantly, you need to understand that although these abbreviations sound similar, they are generally about different things, although 2 of them are still related.

Usually, when such questions arise, you just need to go to Google and read. But okay, let me google this for you.

CSP – Content Security Policy

In short: this is the header of the server's response, in which it defines the content security rules on a given page that the browser should follow. It includes rules from the category:
- noscripts from which domains are allowed to be executed on this page (noscript-src);
- which domains are allowed to embed this page in an iframe (frame-ancestors);
- whether the use of base tags (base-uri) is allowed.

More details: https://developer.mozilla.org/en/docs/Web/HTTP/CSP

When we need it: if some attack (usually XSS or Clickjacking) does not work where it should, we need to look at the CSP header and look at these very rules to understand if they are the reason.

I also sometimes look at the CSP ahead of time if I'm going to tinker with some complex XSS sanitizer. Because there have been cases when you bypass it for a day, and then it turns out that on the CSP page, and XSS still cannot be achieved.

There is a cool CSP security check service from Google - https://csp-evaluator.withgoogle.com. Here you can check if there is a chance to bypass the CSP or if there is nothing to catch.

SOP – Same Origin Policy

In short: this is the basic security principle that keeps our web as we know it secure, and by which all browsers operate. The basic idea is very simple: one site should not have access to another site. By "site" the browser understands origin, which consists of a scheme, a host, and a port.

That is, a noscript located on the site https://google.com will not receive user data from the site https://yandex.ru in any way. Even the requests from https://yandex.ru to http://yandex.ru will not go through, since all three components of origin must be the same in order for the browser to allow such access.

The same works for frames, so if you frame someone else's page on your site, you will not be able to read its content in any way.

Of course, we can send a request from one origin to another, but the browser will not send the user's cookie along with it, which means that at most we can see the version of the page for an unauthenticated user, which is useless.

More details: https://developer.mozilla.org/en/docs/Web/Security/Same-origin_policy

When we need it: only when we don’t understand this basic principle yet and are trying to do things that are simply impossible in 2022. And so once remembered - and forever.

CORS – Cross-Origin Resource Sharing

In short: this is a mechanism that allows you to legally bypass the SOP. Sometimes (often) you still need the ability to send requests from one origin to another. For this, CORS was invented. The owner of a site whose data is to be made available for other sites must send, along with the response, allowing headers like
Access-Control-Allow-Origin: https://google.com

In the case above, a request from https://google.com will be able to retrieve data from that site. Well, not everything is so primitive, of course.

More details: https://developer.mozilla.org/en/docs/Web/HTTP/CORS

When we need it: to search for vulnerabilities like CORS misconfiguration. Sometimes (again often) the list of origins that are allowed to receive data from the target site is not fixed, but, for example, defined using a mask

For example, the owner wants any Google domain to be able to read the data from his site. And he writes code that looks at the origin, which makes a request, and if this origin matches *.google.* - allows access. From time to time it happens that this code is written crookedly and we can also request this data, for example, from the malicious domain google.hacker.ru

If anybody wants to support the channel

💳 https://boosty.to/skavans

🪙 ETH, BNB, MATIC 0x1a90F6ABDD2D29bD7A9b8FE099ff8c7dd0961519

🪙 BTC bc1q9uq96lfekq7ec6slhw72k6kvxntzfk9a4un3vs
🪙 TRX THeRubKK1cNzVRD9JTTQYR7ApK8wCao8Fm
🪙 LTC ltc1q9k2lhuzfg7k482qkcswgqmn0vwsp32suf7yvr3
🪙 BCH bitcoincash:qqypg65vd2cmy54kevdu0ae4jp0229xddycx3xgsg5