Introduction:

Greetings to my professional colleagues and readers. This blog post delves into my enriching experience at the OWASP Global AppSec Washington D.C. 2023, where I had the honor of contributing as a speaker. This international cybersecurity conference, held in October 2023, was not only a platform for professional exchange but also a significant milestone in my career journey. Here, I share detailed insights into the conference, my presentation, and the invaluable experiences I gathered.

Conference Overview:

The OWASP Global AppSec conference was a convergence of pioneering ideas and cutting-edge practices in cybersecurity. The event brought together a diverse group of professionals, including industry leaders, researchers, and practitioners. The exchange of ideas and collaborative discussions over these few weeks provided a unique learning opportunity and a chance to understand the latest trends and challenges facing the cybersecurity world.

Presentation Analysis:

Source on Academia.edu:

My presentation on October 30 was a defining moment. I showcased my project, the OWASP Top 25 Parameters, which I began developing in my mid-teens and eventually transferred to OWASP in 2023, thereby stepping into the role of an OWASP Project Leader. The presentation covered the intricate details of the project, its evolution over the years, and its impact on the field. The project’s focus on the most frequently detected parameters in security vulnerabilities offers a comprehensive look at current cybersecurity challenges.

Project Synopsis and Significance:

GitHub Repo:

In September of last year, I found a Race Condition vulnerability at an Online Services company located in the Netherlands. They had a private Zerocopter program and that’s why I was doing bug hunting based on web applications, on their systems. And I reported the vulnerability to them. Then, they fixed this vulnerability and rewarded me with a €€€ bounty.

Firstly, what is a Race Condition?

What Is a Race Condition?
In any computing system, there are some tasks that need to be completed in a specific order. For example, before allowing someone to log in, a security system first receives their username and password and then checks it against a database before allowing access. Attackers can exploit this fact by interfering with processes to access secure areas and content in what's known as a race condition attack.

What Is a Race Condition Vulnerability?
Race condition attacks (also called Time of Check to Time of Use, or TOCTTOU attacks) take advantage of the need that computing systems must execute some tasks in a specific sequence. In any such sequence, there is a small period of time when the system has carried out the first task but not started on the second. If this period is long enough or the attacker is lucky and knowledgeable, a race condition vulnerability exists where an attacker can trick the system into carrying out unauthorized actions in addition to its normal processes.
There are two main ways this attack is carried out:

Interference by an untrusted process - The attacker inserts a piece of code in between the steps of a secure process.

Interference by a trusted process - The attacker exploits two different processes that share some state in common.

-Veracode

Recon

When I was doing my pre-research normally for system recognition, I had already determined that they did not have a Rate Limit and I had reported it before. Of course, as you know, we cannot talk about the existence of Race Condition vulnerability without No Rate Limit. Because these two are related vulnerabilities.

The Race Condition vulnerability can exist thanks to a base formed by the No Rate Limit vulnerability. Later, I realized that this vulnerability is not only in a single function, but in every function. And I researched for the riskiest place to amplify the impact.

There is something..

I was trying to prove the existence of a Race Condition vulnerability in a function with no impact. For this I use Turbo Intruder, which is a plugin of Burp Suite. If you want to get it, you can find it on the BApp Store.

I was also detecting the vulnerability with this code snippet.

You can go to this tweet to access this code snippet: a Python Snippet to try Race Condition weakness in Turbo Intruder

And yes, this system had a Race Condition vulnerability.

Eureka!

I had already grasped how the system works in pre-research. A premium membership(worth ~500€) was required to add multiple users to the test group. So a free membership could only add 1 user to the group. I found the Add User function and executed the code snippet here with the Turbo Intruder.

And yeah! Like other functions, the Add User function also had a Race Condition vulnerability. And I was able to add as many users as I wanted to my test group. So I was able to do things on a free account that only a premium account can do.

As you can see in the screenshot, my limit to add 1 user as a free membership has decreased to -22. So we broke the limit counter.

The end :

13 September 2020 - Report sent
15 September 2020 - Confirmed by triager
22 September 2020 - Internal team denied impact of report
25 September 2020 - Zerocopter discuss with Internal team
05 October 2020 - Internal team also accept the impact of the vulnerability
05 October 2020 - I was awarded a €€€ bounty

Firstly, it’s nice to publish my last write-up this year. In June of this year, I found a Reflected XSS vulnerability in a video-game company. Then, I realized that this server is caching the weak parameter’s value. In this way, I incresead the probability of triggering this vulnerability and escalated to Account Takeover weakness. Later, I reported the vulnerability and they fixed this vulnerability. Also, they rewarded me with a €€€ bounty. I can’t say the company, because I have no permission to disclose them.

Recon

I discovered a Reflected XSS with a basic payload execution
(1</script><svg/onload=confirm("document.cookie")>) in the “language” input. I thought this vuln was a normal Reflected XSS. As usual, the vulnerability was triggered when going to the vulnerable URL and user session was stolen with a suitable payload. Because, the session cookie did not have any httponly or secure flags.

For those who don’t know what httponly and secure flag is:

HttpOnly: An HttpOnly Cookie is a tag added to a browser cookie that prevents client-side scripts from accessing data. [from CookiePro]

secure: When a secure flag is used, then the cookie will only be sent over HTTPS, which is HTTP over SSL/TLS. When this is the case, the attacker eavesdropping on the communication channel from the browser to the server will not be able to read the cookie (HTTPS provides authentication, data integrity and confidentiality). [from infosecinstitute]

Impact Escalation with Web Cache Poisoning!

But then, I saw that each page also contains language parameter. And I realized that the value of this parameter is put in the web cache. So this means:

Even if the vulnerability was triggered just once, the payload would be embedded in all pages of this site.

Actually, this does not cached entire page like standart Web Cache Poisoning weaknesses, only the part where the payload is embedded is cached. But of course, this is still a web cache poisoning. This scheme prepared by Detectify may be useful for you.

Also, you can read Dedectify’s article: https://blog.detectify.com/2020/07/28/do-you-trust-your-cache-web-cache-poisoning-explained/

And a simple Account Takeover

As we mentioned at the beginning, there was no httponly and secure flag or a Content-Security-Policy (CSP) that can block payload on the site.

So admittedly, the system was already very weak.

Attack scenario with Web Cache Poisoning

With Web Cache Poisoing, we can create a simple attack scenario. For example, if the victim sends a request in the background from an external page to the vulnerable URL in several ways(like embedding the vulnerable url in a picture), The payload is cached in the web, and the payload is triggered each time the victim goes the target site.

I reported the vulnerability, and they agreed that it should be fixed.

If you want to learn Web Cache Poisoning:
https://portswigger.net/web-security/web-cache-poisoning

The end and results :

17 June 2020 - Report sent
18 June 2020 - Confirmed
24 June 2020 - I was awarded a €€€ bounty

In August of this year, I found a Clickjacking vulnerability in a dutch company. Later I realized that this vulnerability could be upgraded to Account Takeover. Then, I coded a PoC template with CSS and reported the vulnerability. And they fixed this vulnerability and rewarded me with a €€€ bounty. I don’t say the company, because they want to remain confidential.

Recon

I was reviewing the responses by sending requests to the system. When I looked at response header, I saw that the X-Frame-Options attribute was not set. This was causing the Clickjacking vulnerability.

Impact Escalation

I saw there was a control panel page for users. Also, due to the system, when the e-mail address was changed, user accounts could be taken over.

Template Source: https://pastebin.ubuntu.com/p/WKtVKBBd4F/

I coded a template using the drag&drop feature with CSS and HTML.

Reported

I can hear what you think. Yes, Since the drag & drop feature is used, the impact of the vulnerability is reduced. However, it is still a weakness that is likely to cause serious damage. I reported the vulnerability, and we agreed with the company that it should be fixed.

The end :

7 August 2020 - Report sent
8 August 2020 - Confirmed
11 August 2020 - I was awarded a €€€ bounty

In July of this year, I found a Content Spoofing vulnerability in a Bitcoin Exchange company. The system was very simple, an encrypted text in a GET parameter was decrypted and reflected on the homepage in an alertbox. I know it’s very simple and its impact is very low. In my philosophy, every finding is worth reporting. Then, I reported this weakness and the company rewarded me with a $$$ bounty.

Recon

I was doing research on page of the website that do not require authentication, and I started researching the login page. While trying to login with some default credentials, I saw it execute “wrong username or password” warning on an GET parameter named “?e=”. I saw the parameter’s value is encrypted with Base64 and tried printing something else. The website did not fail and reflected what I wrote on the screen as a warning.

Mechanism

I placed the text in the picture below, which I encrypted with Base64, into the parameter. The system also executed this message.

Weakness is weakness…

I know that this vulnerability is simply and very low impact. Personally, I am careful to report every findings I find.

The end :

17 June 2020 - Report sent
18 June 2020 - Confirmed
27 June 2020 - I was awarded a $100 bounty

In June of this year, I found a CORS Misconfiguration vulnerability in a datacenter company. The system was very simple, a PUT command sent to the API Server both changed the account email and showed all the data of the account in JSON format as Response. Then, I reported this weakness and the company rewarded me with a $$$ bounty. Also, I would like to thank Bugra Eskici , who helped me a lot to detect this vulnerability.

Recon

I was reviewing the responses by sending requests to the system. When I looked at request header, I saw that the “Origin” attribute was defined. The vulnerable site was defined in the “Origin” attribute as a value, and this value was also defined in the “Access-Control-Allow-Origin” attribute in the Response. Also, the “Access-Control-Allow-Credentials” value was “true”.

Is it vulnerable?

I write evil.com as the value to Origin. And Bingo! The response status was “200 OK” and evil.com was also included in the Access-Control-Allow-Origin attribute.

That is, there was a CORS Misconfiguration vulnerability.

Double Shot!!

I can change the account email with a simple PUT request. Moreover, the server was showing the sensitive data of the account as Response. Then, I have created a simple script for both changing email and stealing sensitive data.

You can find the script I created in my tweet:

A script you can use for Sensitive Data Leakage via CORS Misconfiguration 🕵️🧙‍♂️

Source Code: https://t.co/TroWuo34cJ#bugbountytips #bugbountytip #bugbounty #cybersecurity #infosec #ethicalhacking pic.twitter.com/e0hId2BKmG

— Lütfü Mert Ceylan (@lutfumertceylan) June 21, 2020

With the script, I changed the e-mail address by sending a PUT request. (Account Takeover)

Then, I sent the Response containing sensitive data to a request-bin service with this script.

And, sensitive data sent the attacker’s site.

So I was able to both change the e-mail address of the victim account and steal sensitive data. Both vulnerabilities were caused by CORS Misconfiguration. As I have explained, it is possible to exploit these vulnerabilities with a simple script.

The end :

10 June 2020 - Report sent
10 June 2020 - Confirmed
11 June 2020 - I was awarded a $$$ bounty

In June of this year, I found a CORS Misconfiguration vulnerability in a datacenter company. The system was very simple, a PUT command sent to the API Server both changed the account email and showed all the data of the account in JSON format as Response. Then, I reported this weakness and the company rewarded me with a $$$ bounty. Also, I would like to thank Bugra Eskici , who helped me a lot to detect this vulnerability.

Recon

I was reviewing the responses by sending requests to the system. When I looked at request header, I saw that the “Origin” attribute was defined. The vulnerable site was defined in the “Origin” attribute as a value, and this value was also defined in the “Access-Control-Allow-Origin” attribute in the Response. Also, the “Access-Control-Allow-Credentials” value was “true”.

Is it vulnerable?

I write evil.com as the value to Origin. And Bingo! The response status was “200 OK” and evil.com was also included in the Access-Control-Allow-Origin attribute.

That is, there was a CORS Misconfiguration vulnerability.

Double Shot!!

I can change the account email with a simple PUT request. Moreover, the server was showing the sensitive data of the account as Response. Then, I have created a simple script for both changing email and stealing sensitive data.

You can find the script I created in my tweet:

A script you can use for Sensitive Data Leakage via CORS Misconfiguration 🕵️🧙‍♂️

Source Code: https://t.co/TroWuo34cJ#bugbountytips #bugbountytip #bugbounty #cybersecurity #infosec #ethicalhacking pic.twitter.com/e0hId2BKmG

— Lütfü Mert Ceylan (@lutfumertceylan) June 21, 2020

With the script, I changed the e-mail address by sending a PUT request. (Account Takeover)

Then, I sent the Response containing sensitive data to a request-bin service with this script.

And, sensitive data sent the attacker’s site.

So I was able to both change the e-mail address of the victim account and steal sensitive data. Both vulnerabilities were caused by CORS Misconfiguration. As I have explained, it is possible to exploit these vulnerabilities with a simple script.

The end :

10 June 2020 - Report sent
10 June 2020 - Confirmed
11 June 2020 - I was awarded a $$$ bounty

In April of this year, I found a Stored Xss vulnerability at University of Utwente. However, I later realized that there was a vendor of the vulnerable system, and I contacted them. Then they fixed this vuln. and rewarded me with a $$$ bounty. Also this was my first bounty. I don’t say the company that produced the system because they want to remain confidential.

Recon

I discovered XSS with a simple payload execution in the “First Name” input. But I thought this vuln was a Self XSS. Because all pages were private for every user (except for one page). Then I saw that the password recovery page also contains user First Name value.

First Try

I type a payload in the “first_name” input

but the system always encodes the payloads on Profile Page.

Profile Page was not public anyway. Not bad luck!

Catch You!!

I believed XSS was no longer possible. But there is one last place, “Password Recovery Page”, Moreover, it reflects the user’s “first_name” value to the page.

I just created the page with the request to create a Password Recovery Page. The system not encode the payload on this page. So payload was executed!

The end :

9 April 2020 - Report sent
10 April 2020 - Scenario requested
13 April 2020 - Report’s scenario sent
14 April 2020 - I was awarded a $$$ bounty