How i was able to bypass the rate limit using Case sensitive technique

Hello, i’ m back with the another short write up about my recent finding on Account takeover. To all who don’t know me : i am Basant Karki, a Cyber Security Analyst and a part time bug bounty hunter from Nepal.

你好,我又回来了,又是一篇关于我最近发现的接管账户的短文。致所有不认识我的人: 我是 Basant Karki,一名网络安全分析师,来自尼泊尔的兼职漏洞赏金猎人。

Without further a do, lets get started

不要再做了,让我们开始吧

It was a morning of Sep 23rd, i got the private invitation in hackerOne which was started almost 6 years back with more than 300+ reports resolved. I basically love to test ATO and password reset functionalities, So i accept the invitation.

那是9月23日的一个早晨,我收到了《 hackerOne 》杂志的私人邀请,这份邀请开始于近6年前,解决了300多份报告。我基本上喜欢测试 ATO 和密码重置功能,所以我接受邀请。

After then, I create an account and started looking for any password reset flaws. I started with the forgot password, and tried to bypass OTP. But there was already a rate limit implemented in the OTP validation endpoint so i started to check if there’s any IP based blocking mechanisms. Hmm but the endpoint was almost safe.

然后,我创建了一个帐户,并开始寻找任何密码重置漏洞。我从忘记密码开始,试图绕过 OTP。但是在 OTP 验证端点已经实现了速率限制,所以我开始检查是否有任何基于 IP 的阻塞机制。嗯,但是终点几乎是安全的。

Later i tried more than 3–4 rate limit bypass techniques like,

后来我尝试了不止3-4频率限制搭桥技术,比如,

  1. X-Forwarded-Host: evil.com (Password reset poisoning)
  2. X-Forwarded-For: 127.0.0.* (Rate Limit Bypass)
  3. Null byte techniques 空字节技术
  4. And at last, Case sensitiveness 最后,案例敏感性

I hope you all know about these rate limit bypass techniques but for me the case sensitive was almost new and i didn’t exploited rate limit before using this trick. I first came to know about this in our Live Hacking event ( Bugv — Live Hacking 1225 ) where one of the researcher used the same trick and successfully bypassed the blocking mechanism, which was cool.

我希望你们都知道这些速率限制绕过技术,但对我来说,区分大小写几乎是新的,我没有利用速率限制之前使用这个伎俩。我第一次知道这个是在我们的实时黑客活动(Bugv ー Live Hacking 1225)中,其中一位研究人员使用了同样的技巧,成功地绕过了屏蔽机制,这很酷。

So i started looking for case sensitiveness in otp validation endpoint.

所以我开始在 otp 验证终点寻找案例敏感性。

The request was

我的请求是

POST / HTTP/1.1
Host: redected.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://www.redected.com/
Content-Type: application/x-amz-json-1.1
X-Amz-Target: AWSCognitoIdentityProviderService.ConfirmForgotPassword
X-Amz-User-Agent: aws-amplify/0.1.x js
Origin: https://www.redected.com
Content-Length: 140
Connection: close
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site

POST/HTTP/1.1 Host: redected.com User-Agent: Mozilla/5.0(Windows NT 10.0; Win64; x64; rv: 92.0) Gecko/20100101 Firefox/92.0 Accept: */* Accept-Language: en-US,en; q = 0.5 Accept-Encoding: gzip,deflate Referer: https://www.redected.com/内容-type: application/x-amz-json-1.1 X-Amz-Target: awscognitoidentityderservice。ConfirmForgotPassword X-Amz-User-Agent: aws-amplify/0.1. x js Origin: https://www.redected.com 内容-长度: 140 Connection: close Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: cross-site

{“ClientId”:”7ht8udknbugbp4rr4dnvsuh6ch”,”Username”:”basantkarki@gmail.com”,”ConfirmationCode”:”242789″,”Password”:”YOURPASSWORD”}

{“ ClientId”: “7ht8udknbucgbp4rr4dnvsuh6ch”,“ Username”: “ basantkarki@gmail. com”,“ confirmcode”: “242789”,“ Password”: “ YOURPASSWORD”}

I send the request continuously 500 time And blocked for 25min, then i started manipulating lower case email address to upper

我连续发送请求500次,封锁25分钟,然后我开始操作小写的电子邮件地址到大写

Like “Username”:”basantkarki@gmail.com” > ”Username”:”Basantkarki@gmail.com” , Surprisingly the response was

就像“用户名”: “ basantkarki@gmail. com”> “用户名”: “ basantkarki@gmail. com”一样,令人惊讶的反应是

200 OK, which was weird, hmm

200好吧,这很奇怪,嗯

So again i sent 10 more request for the proper verification, and at this time i was blocked for 30min, again i changed the ”Username”:”Basantkarki@gmail.com” > ”Username”:”BAsantkarki@gmail.com”, and got the perfect response, which i was looking for.

所以我又发送了10个正确的验证请求,这时我被屏蔽了30分钟,我又一次更改了“用户名”: “ basantkarki@gmail. com”> “用户名”: “ basantkarki@gmail. com”,得到了我一直在寻找的完美响应。

OTP not matched.

OTP 不匹配。

Every time when the request gets blocked, I changed one more alphabet to upper case and rate limit will bypassed.

每次当请求被阻塞时,我都会将一个字母表更改为大写,并绕过速率限制。

Example

例子

Rate limit in: attacker@gmaii.com email address

Rate limit bypass : Attacker@gmaii.com, and 10 more request

Rate limit bypass : ATtacker@gmaii.com and 10 more request

Rate limit bypass : ATTacker@gmaii.com …..

Rate limit bypass : ATTAcker@gmaii.com ………

Rate limit bypass : ATTACker@gmaii.com …..

Rate limit bypass : aTTACker@gmaii.com and many more

After then i reported this behavior to the company and within 5 hour my report got triaged and severity was changed to the 9.3 Critical because with this i can easily check for the valid OTP and takeover the victim account.

然后我向公司报告了这种行为,在5小时内我的报告得到了分类和严重程度改为9.3重要,因为这样我可以很容易地检查有效的 OTP 和接管受害者帐户。

I was expecting more then $1000 but they only rewarded $250 for this.

我本以为会超过1000美元,但他们只给了250美元。

But they leave the beautiful comment 🙂

但是他们留下了美丽的评论:)

Which was great, After receiving this message i replied them with my email address and still waiting for the reply from Amazon AWS security team.

这是伟大的,在收到这条消息后,我回复他们与我的电子邮件地址,仍然等待从亚马逊 AWS 安全团队的回复。

So this was the write up about my interesting finding, if you want to DM me, please you are always welcome 🙂 Here’s my twitter profile : https://twitter.com/basantkarki007

所以这就是我的一个有趣的发现,如果你想给我发 DM,请随时欢迎:)这是我的 twitter 个人资料: https://twitter.com/basantkarki007

Time Line:

时间:

Sep 23rd : Bug reported

9月23日: 错误报告

Sep 23rd : Got Triaged and severity changed to 9.3

9月23日: 伤情分类和严重程度改为9.3

Oct 7th : Bounty rewarded

10月7日: 赏金回报