Ghost St Badmus
@commando_skiipz • 14,794 subscribers
Just a random guy, tweeting in front of the world. Sr. Application Security Engineer (API, Mobile, Web, Cloud, AI/ML) 💼. Creator (@vulnbank & https://t.co/pgYmTW2JVL)
Videos
This is a standard practice for almost all Tier-1 banking applications in Nigeria, and for some fintech applications I’ve previously performed pentests on. Client-side encryption isn’t a total waste, or a waste of compute, as some people have claimed, but rather a measure to protect against API tampering or API request/response manipulation between the client and the server when implemented properly. Even with HTTPS, attackers can capture a decrypted version of web or mobile API data in transit because the browser and the server establish a level of trust during the TLS handshake. Attackers can leverage this trust to capture & proxy already-decrypted traffic, tamper with it, and then forward it to the server. This allows them to override what the user interface or client is originally supposed to send and replace it with data of their choosing. That is why validation needs to be performed on both the client and the server side. To wrap up, encrypting API requests and responses makes it significantly harder for attackers to tamper with data, even if they capture the traffic, unless they have access to the encryption details (algorithm, encryption mode, key size, secret key, and initialization vector), assuming asymmetric encryption is used. In the demo below, you can see how I discovered additional parameters (balance, is_admin) in the API response, captured the registration API request, despite it being sent over HTTPS from the interface, added the discovered parameters, and successfully inflated my balance to 50 billion and also escalated my privileges to admin, and ultimately deleted the accounts of two live users/customers. In the second slide, I captured an API traffic of a bank app, and you can see how difficult the payloads are to read.
Ghost St Badmus217,051 views • 6 months ago
This is how the lack of atomic operations and proper database locks can allow an attacker to withdraw more funds than they actually have, all through a race-condition exploit. How to prevent vulnerabilities like this one: - Use atomic DB transactions - Enable row-level or advisory locks - Implement idempotency keys - Re-validate state just before final commit - Limit concurrency per user - Use queues for critical operations - Add rate limiting with strict thresholds You're welcome.
Ghost St Badmus133,297 views • 7 months ago
You see this SSRF attack yeah? Big companies with strong engineering teams like Capital One, GitHub, Microsoft, Alibaba, and others, have all suffered from it in the past. Once an attacker successfully exploits SSRF, they can pivot from the application into the underlying infrastructure, using credentials (keys, tokens, metadata secrets, etc.) that the server is tricked into returning. From there, cloud-level access becomes possible, depending on the permissions of the exposed credentials. If your environment is poorly isolated, this can escalate into full infrastructure compromise. This is how real incidents happen, and in worst-case scenarios, companies end up dealing with ransom demands or catastrophic data and infra loss, like what happened to Code Spaces. I gave a talk on this vulnerability about 2 months ago at APIsec|CON (I’ll attach the video in the replies), & I’ve also decided to show how attackers exploit SSRF in this video for anyone willing to learn. You can see how I tricked the server into making a request to its internal resource, saving the response in a static folder and serving me these cloud config data.
Ghost St Badmus91,265 views • 6 months ago
I believe in showing rather than talking. The first video shows how an attacker could escalate their privileges and perform administrative functions on your API using Xjwt. The second video shows how you can protect App and your company from such embarrassment by scanning your token on the tool to assess its security strength. Share this with your technical team, it’s free and open-source.
Ghost St Badmus42,827 views • 7 months ago
I’m really happy to have met amazing people at the Lagos Cybersecurity Meetup event and to have shown them how bad actors can exploit application vulnerabilities to take over accounts and the servers hosting the application. A big thank you to the organizers of this event!
Ghost St Badmus14,380 views • 1 year ago
No more content to load