我如何攻破一家新西兰主要的服务提供商
How I pwned a major New Zealand service provider

原始链接: https://mrbruh.com/majorprovider/

2025年2月19日,我在进行渗透测试时,发现了KiwiServices应用的一个漏洞。该应用的用户基数较小,存在一个暴露的端点,允许未授权访问用户数据。最初,在`/users`端点过滤电话号码会导致超时。移除过滤器也导致超时,这暗示可能存在与检索大量用户详细信息相关的漏洞。 通过使用`/users?range=[1,1]`参数,我能够检索到第一个用户的资料,包括敏感信息,例如邮箱、姓名、电话号码和出生日期。这证实了一个重大风险,因为攻击者可以通过迭代不同的范围来潜在地导出整个用户数据库。 我于2月20日向KiwiServices报告了此漏洞,并提供了详细的复现步骤。他们迅速确认了该问题并开始着手修复。该漏洞已于3月11日得到修复,并在30天的负责任披露期后,我现将此报告公开发布。

Hacker News 最新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录 我如何攻破新西兰一家主要服务提供商 (mrbruh.com) 10 分,来自 MrBruh,1 小时前 | 隐藏 | 过去 | 收藏 | 1 评论 girvo 3 分钟前 [–] 这让我想起了我们过去常常归咎于 PHP 的所有 SQL 注入漏洞。随着 PHP 越来越不受欢迎,而相同/类似的漏洞仍然存在,我意识到这更多的是不良实践(尽管大约 2000 年到 2010 年代初的 PHP 在创建这些漏洞方面确实非常粗糙,但这可能只是它流行程度的一个函数!)发现它做得很好:) 回复 加入我们,参加 6 月 16-17 日在旧金山举办的 AI 初创公司学校! 指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系 搜索:

原文

Note: The name of local company asked very politely to have their name redacted so it has been replaced with KiwiServices as suggested by ChatGPT

On the evening of the 19th February 2025 I had an itch, an itch to do good in the world and to continue to polish my pen testing skills.

First I went through a list of trending apps on the Google Play Store, and looked for an “‘semi” popular app in New Zealand. After a bit of scrolling past the most popular apps I found it, KiwiServices. An app with under a 4 star rating (potentially indicating rushed development) and under 100k downloads.

I did some research and found that the app did infact have a responsible disclosure policy which at that point, I was happy to continue forth.

After downloading the App onto my rooted (spare) phone, I connected it to HTTP Toolkit (shout-out to the creator Tim for giving me free pro) and started the process of creating an account so I could test the different functionalities of the app.

When I typed in my phone number to make an account I noticed it make an outgoing HTTP request checking if I already had an account.

https://kiwiservices.example.com/users?filter=["phone":"64123456789"]

Can you spot the potential issue?

Yes, you just had the same thought as me. If I removed the filter, what would happen? Would it return user details unrelated to my account, or would it just error out?

Well it actually turned out, neither. The request timed out after 30 seconds with no data returned. However this is still very odd as the request should have either given an error code or some kind of response.

My next thought was that what if the request was timing out because it was trying to do a computationally heavy task such as gathering multiple users details and send it to me.

After some trial and error I managed to finally make the request work.

https://kiwiservices.example.com/users?range=[1,1] // Requests the first user

This returned a list of user[s] containing the following data (censored) for what seemed to be a testing account.

[

{

"id": 1,

"email": "[email protected]",

"firstName": "John",

"lastName": "Smith",

"phone": "64123456789",

"dateOfBirth": "2000-01-01T00:00:00.000Z",

"firstSeen": "0000-00-00T00:00:00.000Z",

"lastLoggedIn": null,

"Card": null,

"isNew": 0,

"cognitoId": "00000000-0000-0000-0000-000000000000",

"CustomerId": null,

"LoyaltyId": null,

"LoyaltyCard": null,

"RewardsMemberId": null,

"RewardsCard": null,

"isActive": 1,

"referralCode": "",

"fcmToken": null,

"allowTransNotif": 1,

"allowPromoNotif": 1,

"isVip": 0,

"session_id": 0,

"giftcard_id": 0,

"site_id": []

}

]

At this point I was confident that their entire user database was at risk, since a malicious actor could dump the entire user database by iterating through it with a large range. However it was midnight so I decided to report it the next day after I awoke.

Day 2

On day 2 I awoke and began by finding some form of contact details, information was somewhat sparse but I managed to find a phone number. After talking with someone there they said they would talk to one of the big cheeses and get them to call me back.

After maybe 30 minutes a big wig called me back and I ended up sending them a vulnerability report via email including replication steps.

A while after that, I got an email back saying that they managed to replicate the issue and were working on a fix. We also agreed on a 30-day responsible disclosure period.

As of the 22nd of March they have fixed the vulnerability and the 30-day disclosure period has ended.

Timeline

19/02/2025 - Vulnerability Discovered

20/02/2025 - Vulnerability Reported

11/03/2025 - Vulnerability Fixed

22/03/2025 - 30 Day responsible disclosure ends

25/03/2025 - Writeup published

联系我们 contact @ memedata.com