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

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