|
Hi ! I hope you are well!
Welcome in the new issue of the BBRE Newsletter🔥. It's the last one where you get the premium version for free. With the next issue I will release the details about the BBRE Premium where you will be able to subscribe for more content (these emails and more...). And I have a good information for you. My mailing list will receive the best deal possible - the information will not be published YouTube, Twitter or any other social media. So make sure to check your inbox in about two weeks.
Usually these emails are sent on Tuesday but I am back from vacations and I had the holiday hangover😏
Here's what I prepared for you today:
- Unicode Normalization Vulnerabilities
- How zseano approaches a new target?
- Is bug bounty good as a full-time job?
- AWS security labs
- Thoughts about a triage
- Salesforce Lightning Components Security
- Do you allow yourself to rest?
Unicode Normalization Vulnerabilities Unicode normalization. It sounds awesome, doesn't it? Imagine finding a high-risk Unicode normalization bug and sharing it with your fellow pentesters or with your Twitter followers. They probably won't even know what this is and your respect will go over the roof.
The sad truth is with such sophisticated vulnerabilities that they don't occur that often. If they would, then they would be more commonly known. However, for me, it's one of the things that differentiate mediocre hackers from the great ones. And, as you are writing this newsletter, it's what separates you from the mediocre hackers.
With that overlong introduction, let's jump to what Unicode and normalization are and when it's exploitable by reading the research from AppCheck company.
Unicode
Unicode is a way to map characters to numerical values. In English, it would be sufficient to have 128 characters from 0x00 to 0xff but in other languages, for example, polish, we have ą, ć, ę, ł, ń, ó, ś, ż and ź that don't fit in there. Unicode solves this problem by allowing us to use more than 1 byte to encode the character.
The most common type is UTF-8. There, quite popular $ character will be encoded as U+0024 so in hex you can just use one-byte: 24.
Much less popular ¢ character is encoded as U+00A2 which in hex is C2 A2.
The number of bytes per one character can go up to 4.
Normalization
Turns out that it's possible to encode the same thing in different ways. For example, you can write the name chloé as:
These two look the same even though the encoding is different. In case you would like to have the same binary representation, you can normalize them. It's a process of assuring that equivalent strings will have the same binary representation. There are 4 normalization algorithms: NFC, NFD, NFKD and NFKD. Luckily, we do not need to dive deep into their inner workings.
Exploitation
If you are thinking right now "okay Greg, that's cool but can we finally get to something interesting??", I fully understand you. Now it's time to see how can we exploit the Unicode normalization.
We can do it when it occurs after some filtering.
Let's say you are spending your lovely Wednesday afternoon hacking on a new target.
you want to execute XSS and you see that the < is removed from your input, making the XSS impossible
you go to the Unicode normalization reference table: https://appcheck-ng.com/wp-content/uploads/unicode_normalization.html
you see that the < sign might be encoded as %3c but also as %ef%b9%a4 or %ef%bc%9c
you try %ef%b9%a4 instead of %3c
It will work in a situation where the developers filter < characters BEFORE the normalization (in this case using NFKD or NFKC algorithms).
Just like in this snippet of code:
The same can be done with other classes of vulnerabilities where other characters are filtered or blocked.
Confirming there's a normalization in place
It's always good to make the smallest steps possible before getting to the final exploit.
First, confirm there's normalization and only then try to find if it's before or after the filtering.
For that, use a character that will not be filtered and is encoded the same way for all 4 normalization algorithms: the Kelvin symbol.
It looks just like a K and is encoded as %e2%84%aa
You can put it in your profile name or other field and if then you see your name with a K-looking character, it means there's a normalization present.
From there, find out if and how can you use that to bypass some filters.
source article: https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/#
Unicode Normalization Reference Table https://appcheck-ng.com/wp-content/uploads/unicode_normalization.html
How zseano approaches a new target? There are many tips on the Internet about specific types of vulnerabilities. However, before actually exploiting anything you must first pick a target, discover the specific asset and then a specific functionality. There's little information about how to actually do these steps. Thankfully, zseano did his best to fill in that gap with an hour-long video presenting how he approaches a new target. Not only what he does but more importantly what he thinks.
But since you likely don't have an hour right now to watch it, I did it for you and wrote some notes. Here they are.
zseano's style of hacking
zseano doesn't rely on recon. He tells that he just visits the main page and goes from there. He doesn't need many subdomains but tons of functionalities instead. He doesn't use many tools - in Burp he told in the video that he has never run a scan - he only uses target, proxy and repeater tabs.
What's available to me?
The first stage of approaching a new target is seeing what's available in the application.
He notices:
can he log in? Can he register?
what roles are in the application? What he can do with his account and what not?
every functionality that might be juicy like file upload or image import via URL
everything that might be impactful for the application
Of course, all those information are noted.
How do things work?
How does the signup work? What roles are there? How do requests look?
Then, zseano put an <h2> tag in his profile name and description to see how the application deals with HTML tags.
Is it blocked? filtered? encoded?
This is crucial information. He noted all parameters - those vulnerable and those not. The next step for them is to see if they are treated differently when opening the application from a mobile or when seeing his profile in other places of the app.
He noticed that there are inconsistencies so he started looking further. He told he would now look for XSS everywhere seeing that developers have problems here. At this point, he would not check for other vulnerability types.
Common patterns
The next step is seeking patterns.
If he sees that XSS is encoded in one place but not in the other, it means that the problem is not completely solved and will likely occur in other endpoints.
He notes the parameters names and checks if parameters from one endpoint will work on another. For example, there was a returnUrl used on one login panel, he checked if the same parameter can be used on another login panel.
He also checks different connected applications, mobile version of the site - what's the same as in the web version, what's different, etc.
Deciding what to test
When thinking about what part of the application to test, he asks himself a question - what would the real criminals do? What data is stored in the application? What sensitive would they want to steal? So basically, it's his way of thinking about the impact.
And the last tip I noted is to take your time. Don't be overwhelmed by the application and have the plan. If you notice yourself jumping from feature to feature, you will get burnt out quickly. It might be a good indicator to change the target.
That's it for my notes but you can watch the whole video here if you want: https://www.youtube.com/watch?v=T6BROEozJOk&ab_channel=OWASPNagpur
Is bug bounty good as a full-time job? Bug bounty can be considered by many a dream job - you have no boss, you hack whenever you want and wherever you want and, of course, you make tons of money. This is a reality for some, but for many, it's not that simple. In the article "THE SHOCKING TRUTH YOU MAY NOT KNOW ABOUT BEING A FULL-TIME BUG HUNTER" codingo shed some light on many non-obvious factors of making a decision to go full-time bounty hunting.
Apart from being a great hunter (and YouTuber as well), he was a professional online poker player. Why does that matter? Because just like bug bounty, it's skill-based with a randomness factor. Poker is much older than bug bounty and they have already figured out how to have a calm life even with irregular income.
How many bugs can you find?
Obviously, prior experience is the most important factor. How much do you know? How many bugs you can find? I will leave that part of the article for those who will read the original one. In this summary, I will skip this part.
Instead, I will focus on other aspects that must be considered when thinking about bounties full-time. Ones that may surprise you.
Where are you from?
Different countries have different costs of living. As funny as it seems, the Big Mac index is a good way to present this. It shows how much a Big Mac from McDonald's costs in different countries. It's definitely not the most academic approach but it gives us an idea of how much the same product costs in different countries.
For example, in Poland, the Big Mac costs about PLN14,60 ($3,81) and in the US $5,65 which is about %50 more expensive. When you go to a normal job this is accounted for - a pentester in the US will make more than a pentester in Poland. But a hunter in the US must earn about %50 more in bounties to cover living expenses. No program will pay him out more just because he pays more for food than me or you. This means that bounties are more appealing for those in countries with weak currencies and lower costs of living.
Who relies on your income?
A 19-years old student who can rely on parents with financial help can risk much more than a father with a wife and 2 kids that count on his earnings and potentially put pressure on him when the worse time comes. The question for you is how much risk you can take and what will your closest ones think about it.
Do you diversify your bugs?
Codingo rightly points out that not only how much you made matters. The fact, that you made money in the past doesn't mean you will in the future. This especially matters if you heavily rely on a single class of bugs or a single program.
You can't find yourself in the situation where you make a decision to go full-time bug bounty because you made a lot of money finding only subdomain takeovers, for example. Because when the industry evolves it might be no longer easy to find a sufficient amount of such bugs.
Or you were great at finding bugs in one program. You knew it all the way, even better than most developers. But finally, they improved their development practices instead of only fixing a single bug and you are no longer finding that much.
Those are risks but the more diversified bugs you can find the safer you are to perform well in the long run.
How long can you live without earnings?
Another important factor is how much can you live without earning. Codingo calls the amount of your spending a burn rate. If you have $10000 and your burn rate is $2500, you can live 4 months without earning anything before potentially needing to find a stable job. Make sure to calculate some time for the recruitment process here because it's never instant.
So you know how many months you can live without earnings. From that, you can start evaluating if your financial situation is good enough and how many bugs you need to be finding.
When factoring in costs, don't forget about taxes and tools like Burp Suite.
When calculating the weekly time you can spend on hunting, make sure to account some time for:
learning
conferences
unpaid leave
family time
illness
Why?
Finally, think about why do you want to do bounties full-time. If you analyse it deeply, maybe it will turn out that all you need is a stable pentesting job but in a greater company than you work at the moment.
If you are really considering doing bounties full-time right now, please read the whole article on codingo's blog
https://www.bugcrowd.com/blog/the-shocking-truth-you-may-not-know-about-being-a-full-time-bug-hunter/
or watch the video version:
https://www.youtube.com/watch?v=vypKVlPEyMs&ab_channel=codingo
AWS security labs For anyone interested in cloud security, these labs from KONTRA are a must-do. They are free and at the moment there are 13 labs available, covering different aspects of AWS security.
The best thing about them is that they really make you understand the bug and see the faulty source code. It will be equally good for us, hackers, as for AWS developers. So maybe, you want to forward this email to your friend?
https://application.security/free/kontra-aws-clould-top-10
Thoughts about a triage There has been a lot of talk about triagers lately on Twitter. As much as I like Twitter, I don't think it's a good place to form out an idea about this situation. In my opinion, it's better to see a blogpost of a respected hacker to see what are his thoughts on the matter.
Such an article was published recently by shubs and I think it presents the subject in a non-judgemental way.
I will not summarise the article here, but one thing that surprised me greatly is that:
When you have reported a vulnerability to a security team, you are giving up the intellectual property for that vulnerability and you no longer have the right to disclose it, as technically, it is no longer yours.
which means that even if the security team marks your report as an informational or a N/A you don't have the right to disclose it.
https://shubs.io/a-hackers-perspective-on-bug-bounty-triage/
Salesforce Lightning Components Security In my previous job, we had quite a lot of Salesforce applications for testing. A big part of them used Lightning Components and I will tell you that the bodies of those requests were a complete mess! There were tons of parameters but only a few were actually relevant.
The big problem for me was that there were not many resources about the topic, especially from the security perspective.
Now, Aaron Costello from AppOmni created a whitepaper that guides you step by step what is Lightning Component, Aura, Apex, etc. so that all this makes sense now. There are even free practical labs where you can test your newly possessed knowledge.
If you are not interested in this technology now, save this link for later, when you encounter such an application, this will save you lots of time!
https://go.appomni.com/hubfs/Collateral/AppOmni_Labs_White_Paper_Apex_Security.pdf
Do you allow yourself to rest? As mentioned in the intro to the email, I just came back from the holidays. I had a lot of free time to think and I realised a sad fact about myself. I can't rest properly unless I'm on holiday 🙃.
I always was very strict regarding my employment - no overtime, no checking emails at home and I were out of the office exactly at 5PM.
But with youtube, newsletter and other things that I have now it's different. There are always things to be done. If I made one video, I'm already thinking about the newsletter to then think about another video.
Sometimes I subconsciously know that I have a lot of time because it's Tuesday. Instead of allowing myself to rest, I'm telling myself that I will start the video earlier this week. My subconscious mind wins by making me not do the work because there's still a lot of time. The problem with that is that I then neither rest nor work. I'm feeling guilty for not working which is also tiring.
Lately, I'm starting to notice that and stop that bullshit cycle. I just allow myself to have a free afternoon. However, it would still be much better if I planned for it earlier and allowed myself to chill. Resting is very different from procrastinating for me.
But making the decision to rest is just so hard for me.
During holidays I realised that I pretty much never genuinely allow myself to have a day completely off, without a good reason for it.
Now I know I need to work on it and allow myself to rest more often. Deep down I know that in the long run, it will be much better and healthier for me.
How is it for you? Do you sometimes tell yourself you will work when you need a rest and you end up neither working nor resting?
That's it for this one. I know that many of you actually read the last, non-technical section of the email because, surprisingly, this is the one appreciated by you the most. I wrote surprisingly because I wasn't sure if I should even put this part here. I'd like you to know that we all struggle with some aspects. I don't want you to see me as some quantum-effective productive person just because I experiment a lot with my time management and I write about in these emails. I'm just like you with better and worse days.
I hope you find this newsletter helpful. If you did, share it on Twitter (don't forget to tag @gregxsunday) or among your friends. Next Monday, there will be a video so we'll meet here in the newsletter in 2 weeks when I will give you the best deal for BBRE Premium so make sure to check your inbox.
Best,
Grzegorz Niedziela
Bug Bounty Reports Explained
PS. You can reply to this email with feedback on what you think of this newsletter.
|
