I'll tell you a little about myself.

My name is Anton (skavans), I'm from Moscow, Russia. Here is my h1 profile:
https://hackerone.com/skavans

I wrote above that I have quite a lot of experience in bug hunting. What can I be proud of as a result?

At the moment I have about 6500 reputation on h1, in the overall ranking I am now in 170th place.

I am a top 1 researcher at NewRelic and also a top 5 researcher at two large private programs that I have been working with for the last two years.

I also believe that I am somewhere at the very beginning of the h1 top in Russia, at least in terms of the amount of rewards :)

I have found over 300 bugs and received over 175 bounties for them.

🇷🇺 Русская версия – @BugBountyPLZ

Hi! I am Anton (skavans).

For three years now, my main job has been Bug Bounty Hunting.
And I'm pretty good at it.

I am sharing my experience and knowledge here. I talk about how I organize my work, how I studied, and how you can learn.

And sometimes I just write stories from life related to bug bounty.

------------------------------

💵 I don't want to post an ad here. If you want to support my channel, you can subscribe me on Patreon (from $1 per month):
https://www.patreon.com/skavans

What is the Bug Bounty?

Actually, I'm not going to post common truths. But I have a hope that not only experienced people, but also beginners will subscribe here. And maybe those who do not understand either the noscript of this post or the name of the channel at all. This post is for you.

Bug Bounty is a legal hack that companies pay you for. Many companies want hackers to look for vulnerabilities in their services or applications and are willing to pay rewards for them.

Of course, most of them have their own safety officers on staff and they also research the safety of the products. At the same time, they have much more opportunities, because they can always look at the source code, consult with the developers and stuff like that. But they do not find all vulnerabilities.

Why? I think it's all about motivation. The overwhelming majority of full-time specialists receive a salary that does not depend on their success, diligence and thoroughness.

We, third-party researchers, are motivated solely by the result. If you don't find a vulnerability, you won't earn anything. This is the difference.

As a result, the company receives "free" security research from thousands of people, and it only needs to pay for valid vulnerabilities found.

Researchers, on the other hand, receive motivation that is simply impossible when working in the state. They get a free schedule, the ability to choose any goal from hundreds of different companies according to their preferences, skills and fee.

Win-win.

My first five figure payout

#stories #analysis #technical #money

I received my first five-figure payout ($10,000) from Gitlab.

This happened a month after I quit my job and started full-time looking for bugs. Prior to that, I had done bug hunting only occasionally, in the morning before work, or at night after.

Immediately after the dismissal, I realized that everything was serious, and I needed to at least maintain my previous level of income. I decided to choose a program whose product I like (because I wanted to not only earn money, but also improve my favorite product). But also one that pays well. In general, I settled on gitlab.

And everything didn't go according to plan. I worked a lot - on adrenaline, and because of the fear of being left without money, of course. I worked 10 hours a day with few days off. As a result, by the end of the month, I found a couple of minor bugs: Content Spoofing and a very poor Information Disclosure. Thus, I didn’t hope for a good income, in general. And I remember how it was now: in the evening I had to go with a friend to drink beer, there was a little time left before leaving the house, and I was sitting and, as always, researching the application.

Below is the technical 👨‍💻

Signed in under the administrator and came across the function of impersonalization. This is when the admin can select any user and log in under him simply by pressing one button. Apparently, to debug bugs or help with settings. Tried to do something with this function this way and that, but there was nothing.

It worked like this. When an admin clicks impersonate, a new session cookie is given to him (on behalf of the impersonated user). Then he has a stop impersonating button, after clicking on which, his admin session cookie is returned back.

While I was researching how it works, I also logged in under the impersonated user himself. And I noticed that at the moment when the admin pretends to be him, in the user's personal account, in the list of active sessions (well, where you can often click "terminate all other sessions"), this very session appears, under which the admin sits.

I began to look at what info about this session is available to the user. It turned out that almost nothing but some ID, which is visible when trying to terminate this session. It dawns on me that the format of this ID is somehow very familiar. And then I understand that this is nothing more than the very value of the session cookie.

Thus, for instance, when logging in, the user is set a session cookie
sess=12345
and if he wants to terminate this session in the list of open sessions, a request is sent
/stop_session?id=12345

And the same thing worked for the session under which the admin sits. Therefore, I know this cookie of him and I can log in under this particular session.

Remember, I said that the admin under such a session has a button “log out back to admin”? So I was very interested in whether I will have the same in this case :) Well, the earned bounty hints that yes, it has appeared.

Accordingly, when the admin impersonates any user, this user can himself log in under this tricky admin session, and then go back to the admin. Such is the escalation of privileges.

I rated the bug in Critical when submitting it and thought:
“Wow, they’ll probably pay me 5 thousand, 2 times more than ever.” I still remember my feeling when I saw my first five-figure payout in the mail :)

Report open:
https://hackerone.com/reports/493324

#blacklist

Dissatisfied so far with the Yandex program. We sent a couple of reports with a friend a month ago - zero response. No response to follow-up emails either.

If suddenly something changes, I will write, but for now it’s blacklisted. Don't waste time.

Onmouse* XSS PoC

#technical #tips #PoC

I will write more about how I do PoC in the future. But with special care, I work out scenarios for vulnerabilities that need user interaction.

For example, if I find XSS via the onmousemove or onmouseclick event, I always try to style the vulnerable element in such a way as to stretch that element to the maximum possible area of ​​the page.

I usually use something like
{
position: fixed;
top: 0;
left: 0;
width: 100%
height: 100%;
background color: red
opacity: 0.5
}

Then in the report, instead of "the user enters the page, scrolls it down, finds such and such an image and points the pointer at it," you can write "the user enters the page, and moves the mouse anywhere on the page."

This shows that the attack can be implemented in real life, and not only if you think like an attacker.

Mindmaps

#tips #organization

I usually work with one program for a very long time. It may take up to a year. It's just more profitable, because good bugs always lie somewhere in the depths, and in order to get to them, you need to study the goal well, understand how different components work and what are the relationships between them.

In the past, I've had trouble not getting confused about which features I've already explored and which ones are yet to come. Especially when another idea comes to mind and you run to try it on old, already researched components. Here you can always think: "So, have I already checked this function on CSRF?".

To avoid doing the same job multiple times, I started using mindmaps. It seemed to me that they are much better suited for this than, for example, just text files. Because it is convenient to store tree-like data in them, and when you explore the site, you actually walk across the tree of all its features.

The structure looks like this:

domain ➡️ section ➡️ function ➡️ sub-function ➡️ specific vulnerability

If I have already checked this vulnerability, I paint the node with it in a different color. So even after a year I can easily understand that I did check this function on CSRF 🙂

In the same way, I mark sections or functions that I found, but want to return to them later - with a separate color. Conveniently, you can also write a comment for each node to remind yourself in the future what I wanted to try to do.

https://o1.su/tg_images/1.png

CSS Gadgets

#technical #tips

A couple of posts ago, I wrote about my way to increase the impact of XSS, tied to mouse events - by stretching the vulnerable element to the maximum page area using styles. But what if the style attribute is blocked by WAF, and the vulnerable element is in such a non-obvious place that there is a chance to get informative?

For example, some tiny link in the footer of a view page
<a href="INJECTION">
turned out to be vulnerable and we were able to turn it into
<a href="" onclick=alert() a="">
but we cannot make a beautiful PoC through the style attribute.

In this case, I'm using the so-called (by me) CSS Gadgets. Maybe someone else uses them, but I have not heard.

The bottom line is that you can "craft" the desired style using the application's native styles. For example, it's a good idea to add the properties width: 100% and top: 0 to the affected element.

We open the developer tools on the vulnerable page and look through all the styles. It is convenient to do this in Firefox, where they are all collected in one tab.

We find, for example
.test {
display:block;
color: blue;
width: 100%
}
and
#someid {
top: 0;
font-family: Tahoma;
}

Now we can modify our link and bring it to the form
<a href="" id=someid class=test onclick=alert() a="">

Thus, without using the forbidden style attribute, we will give it the properties necessary for a normal payout.

And even if the WAF is completely evil, and it didn’t work out at all to execute the JS, but there is still an injection into the element, you can try to perform something like a deface in this way. If this element is important for the functioning of the application, you can hide it by applying a class to it with the property display: none or something like that.

Not an impact of the year, but there is a chance for at least Availability Impact: Low.

​​How did it all start?

#stories

Since school, I have been reading Hacker (the Russian offensive security magazine) when I had the opportunity to buy it (then it was still paper, with a disk, and it costs huge money - almost $30). I read mainly research on hacking the web and understood just a few percents.

I remember there was an article where at some store, quite large, they found SQLi right in the login form. I then sat down at my grandmother's computer and tried to reproduce everything step by step right on this site. I didn't know anything about responsible disclosure then, of course.

The funny thing is that the bug was never closed, apparently the author of the article did not know about it either :)

Several years passed, and my colleagues and I at work were offered to go to PhDays (the Russian largest offsec event) at the expense of the company. At that time, we were already studying at MEPhI, just at the Faculty of Information Security. But we had practically no offensive there, with some very small exceptions, and we worked as programmers.

The idea seemed interesting and we agreed, especially since the tickets cost too much money for us, and it was a sin to miss this opportunity.

I didn't particularly remember the reports, there seemed to be some interesting ones. But what I remember forever is how the guys from Qiwi said that they launched a bounty bug on H1. At that time, it was just a revelation for me. That you can hack sites legally and also make money on it.

I went home with a firm conviction to start doing this. You can see the results in the screenshot below :)

It took a long time before I received my first payout. But I'll tell you more about that some other time.

Low-hanging fruit

I was asked here if I could share noscripts for finding low-hanging fruit. Of course, there will be many such comments - that's why I am writing this post.

Low-hanging fruit are bugs that are very easy to find. I would divide them into 2 more types:

1. Bugs that don't have a meaningful impact. For example: lack of any security header, open redirect, content spoofing. I do not look for such bugs and do not advise you.

Firstly, no one will pay you for them in 99% of cases. Secondly, the searching for such “bugs” does not improve you in any way. It is much better to spend time studying at least one more serious vulnerability and you will already be better than many others who can only look in headers without understanding what is happening.

Sometimes I still look for them, but only targeted, if I have some kind of bug, but for exploitation I need, for example, an open redirect. This is called chaining - linking several bugs (sometimes simple ones with low impact) to get a high impact as a result. I'll tell you later with examples.

2. Normal bugs with an impact, but which are in a super-visible place. For example: XSS in the search form on the main page or IDOR in the password change request.

It's more difficult here. Definitely not worth trying to find something similar in old public programs. Thousands of people like you have already long trying to deal with the main page. You will spend a lot of time, find nothing, and just burn out. If you were invited to a fresh private meeting, you can try.

I myself periodically find something similar, but they make up a meager percentage, both in quantity and in earnings.

The deeper the function is hidden, the more complex (and maybe even boring) it is, the less people have researched it. Such functions are your chance to find a vulnerability.

So no, I don't have such noscripts. And I advise you to move in a different direction at all.

Routine

#fulltime #cons

Routine is a big enough issue of the full-time bug bounty (for me).

Well, some part of it is perceived normally. This is writing reports, communicating with companies, even checking fixes. It's just there, it's part of the job, you can't get money without it. Sometimes it can even be fun, especially making some tricky PoC.

But there is another routine that sucks all the juices. Now I have to work another 2 hours to be on schedule, and I sat down to write a post, because it’s fricking impossible :)

This is a routine of two kinds. The first is when you sit researching the application, and nothing is found for hours. Not even something to grab on to. But this is not the worst, because I think like this: the longer I find nothing, the closer I am to a new bug. After all, I have been doing this for a long time and there is always something new to be found. So now it will be the same (although it is still sometimes scary).

But the second kind of such a vile routine is the opposite, when there is a potential vulnerability and it needs to be researched deeply. And it doesn't give up. Well, for example, you need to bypass the filter or WAF. And you sit for hours over it, and think: maybe you need to stop, maybe you just can’t get around it? But you don’t want to stop, because you can miss a bug (especially if it is potentially expensive).

And every hour, on the contrary, reinforces the feeling that time is being wasted. And it’s just a vicious circle – you’ve been sitting there for so long, how can you stop it now (and just loose these hours)?! Here you need to be able to understand your limit, assess the possibilities, accept defeat, and stop in time.

The Unobvious About XSS and HTML Encoding

#technical #xss

Many people know that before getting the value of a tag attribute, the browser decodes the HTML entities inside. Let's say if you try to read the test property of a tag like this:
<tag test="&amp;">
then we get the decoded value: "&".

Some workarounds for simple XSS filters are built on this.

For example, if you need to embed a javanoscript link, and javanoscript: is blocked by WAF, then you can try to do this:
<a href="javanoscript&colon;alert()">
When the browser reads the href of this link, it will decode the value and it will be just javanoscript:alert(). Such a link will bypass the filter (if it is weak), but will be working.

Not only named entities work, but also numerical ones in different forms. That is, you can make attributes like javanoscript:
61 is "a" in hexadecimal, 97 is in decimal. They can be combined and the link will still work.

There's also some extra stuff like a or that you don't have to use the semicolon if the HTML entity isn't followed by a letter. This is known to many who googled about XSS and bypassing filters.

Here is what was not clear to me.

Often an application encodes an input in an HTML entity to prevent XSS. Well, let's say it replaces your quote with ". You have seen it all.

Let's imagine that the page has a tag with an event handler, and the INJ parameter is reflected inside it:
<button onclick="someFunction('test', 'INJ')">
and if we try to insert a quote into this parameter, it is also encoded into an HTML entity, and we get
<button onclick="someFunction('test', '&amp;')">

Looks safe, doesn't it?

Just go back and read a couple of paragraphs above. The browser decodes these entities. And it actually sees:
<button onclick="someFunction('test', ''')">
That is, in fact, we have XSS here, since we broke the string context!

Moreover. Let's say the developers of the application are smart and did not do this. And they decided to encode this quote in "% 27". Then, probably, everything is gone, and the tag is invulnerable?

I would not be in a hurry to think so and tried to pass the HTML entity itself into the parameter:
INJ=&

Have they thought of such an option, or such a value will not be escaped in any way and we will again get XSS in the form
<button onclick="someFunction('test', '&amp;')">
is a question that I would be puzzled 🙂

Should I switch to full time?

#fulltime

In the comments, I was asked what turned out to be more profitable in terms of money as a result - my previous job as a developer or fulltime bugbounty? I answer.

In the first year of full time bug hunting, I earned twice as much as in the last year in the office. And in each of the next two years - already 5 times more.

Does this mean that it will be the same in your case? Of course not. Many researchers do not manage to earn anything, others earn literally a penny. And some are even several times bigger than me. If you would like to do a full time bug bounty, my advice is simple.

Try to look for bugs in different programs, after or before your work, especially in public ones. It is important to look in different ones in order to exclude the fact that one program suits you, and you succeed in it, but it will not work in all others. And it is advisable to look for it in public ones, since there is much higher competition. If it works out there, it will definitely work out in private.

And count the time. Once you find at least a dozen bugs and get paid for them - look at how much time you spent searching for them. This way you can at least roughly calculate how much you could earn in a full working month.

My first bell rang a long time ago. I then earned much less, somehow I found 3 bugs for $2500 in just a few hours and realized that this was my salary for six months. From that moment on, I began to keep track of time, and as a result, I realized that bug hunting would be more profitable for me.

But most importantly, I enjoyed doing it. And this is very important! Because if you decide to quit and do it full time, you will no longer have a fixed salary, you will have to work constantly, and this is hard if you don’t love it.

Folks if any of you have the Medium account, I would appreciate if you subscribe me
https://medium.com/@skavans_

I want to apply the Partner Program to monetize my posts a bit and I need 100 followers for this 🙂

​​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