🎯
dmdhrumilmistry's gitbook
  • dmdhrumilmistry's gitbook
  • Blog
    • TryHackMe WriteUps
      • PickleRick
      • StartUp
      • Basic Malware RE
      • Bounty Hacker
      • Lazy Admin
      • Crack The Hash
      • Cyborg
      • OverPass
      • OverPass2
      • Agent T
      • Vulnerable API App
      • Git-Happens
      • Kiba
    • Vulnerabilities in Wild
      • Hiring Platform Exposing Thousands of User's Data
      • Security Analysis of the Indian Government's Student Assessment Platform
      • Exploiting S3 bucket misconfiguration to dump users emails
      • Getting Shell Access to ADB Exposed Smart Devices πŸ“²πŸ“ΊβŒš
      • Hacking Mumbai's Metro ChatBot and APIs for FUN πŸ€ΈπŸ»β€β™‚οΈ
      • Random Object Referencing IDs Still Aren't Safe in APIs πŸ’₯
      • Exploring Weird Account TakeOver (ATO) Vulnerabilities in APIs
    • Secure Software Development
      • Validating File Content Types to avoid Malicious File Hosting using ML Model
      • Securing Containers Supply Chain using Secure Base Layer Image
      • Automated API Tests in SDLC are Boon
Powered by GitBook
On this page
  • BackStory
  • What Can Go Wrong?
  • Web Application Bad Practices
  • Want to avoid such attacks in your apps?
  • How to avoid such mistakes?
  • Conclusion

Was this helpful?

  1. Blog
  2. Vulnerabilities in Wild

Hacking Mumbai's Metro ChatBot and APIs for FUN πŸ€ΈπŸ»β€β™‚οΈ

This blog post is regarding the time when I hacked into Mumbai's Metro Booking System from ChatBot to SQLi and breaking encryption.

PreviousGetting Shell Access to ADB Exposed Smart Devices πŸ“²πŸ“ΊβŒšNextRandom Object Referencing IDs Still Aren't Safe in APIs πŸ’₯

Last updated 1 year ago

Was this helpful?

BackStory

A few months ago, me and my friends were going for an event in Mumbai. While reaching to the metro station, I noticed one of my friend was using Mumbai's metro WhatsApp ChatBot which provided functionality to generate session codes and OTP for booking metro ticket.

I was curious how secure it was! So I tried to book a ticket myself and understand its flow. Flow goes this way:

  • Traveler can use the link to book ticket or OTP at the ticketing counter.

  • When traveler clicks on the link they're asked about their source, destination, journey type, number of individuals, etc.

  • Once traveler has filled the required details, they can proceed with payment. They'll be redirected to payment gateway where they can pay using their desired payment option (Debit Card/Credit Card/UPI)

  • After payment they'll be assigned a QR Code which can be used to enter and exit metro stations.

What Can Go Wrong?

Web Application Bad Practices

No Obfuscation on Client/Browser Side Source Code

Redirecting user to web application provided me an opportunity to reverse engineer their web application by reading their client side source code. It helped me to understand how their web application works what user inputs are needed to which endpoint.

The Browser side code wasn't obfuscated so I was able to break their client side encryption which provided me to forge checksum.

Application Running in Debug Mode

Since, Source code was readily available, I used jsluice to extract API endpoints and other urls.

I started fuzzing endpoints manually to in hope to generate tracebacks. I found out that the application was running in debug mode using laravel in the backend.

Now I was able to read few parts of the backend source code. During which I found that there was no input validation and sanitization in the API. Most of the API endpoints are crashed were vulnerable to SQL Injection attack vector due to missing sanitization and input validation.

In Laravel, the where() method is a helper method that constructs a simple where clause for an Eloquent query. When you use the where() method with a string argument, Laravel will automatically escape the string to prevent SQL injection attacks. However, when you use the where() method with a Closure argument, Laravel will not escape the Closure, which means that any unescaped user input passed to the Closure will be included in the SQL query as-is.

In above example code, the where() method is used with a Closure argument to construct a where clause that compares the sale_or_no column to the order_id variable. If the order_id variable is not properly sanitized and validated, an attacker can inject malicious SQL code into the variable, which can then be executed by the database server.

Want to avoid such attacks in your apps?

How to avoid such mistakes?

  • Never run any of your app in debug mode for production environments. It can leak so much information about the production environment.

  • Never ever trust user input data, always validate and sanitize their inputs.

  • Always obfuscate/uglify code for client side applications.

Conclusion

We usually learn from our mistakes but let's learn from others mistakes as well. Let's sanitize user inputs each and every time, which will help us take one step towards creating robust and secure applications.

Ping to generate OTP/Link with session code.

PoC Code Link: (This might not work now)

Checkout my project which automatically pentests your APIs using and fix security issues before they're deployed to production environment.

whatsapp bot
https://github.com/dmdhrumilmistry/hacking-mumbai-metro/
OWASP OFFAT
Mumbai Metro One WhatApp ChatBot
Web Booking System Interface
Payment Gateway
Metro Web Application running in debug mode
Backend Source Code Example 1
Laravel Code in which `where` clause is used along with closure argument leading to SQLi
Laravel Queries from Debug Mode
Metro Booking Web App Meme