Updated: May 10, 2022
Another long (hacker) story of mine! Once upon a time contracted to do a penetration test on a bank… I spent the better part of a week assessing every nook and cranny of the main web application. I mapped every function, and every web path, but the main website was very hardened.
After spending a lot of time understanding it, most of the makeup of the transfer system was API based and the infrastructure was AWS. I decided to open up the mobile application to see if it was any different and if its functions were on the same domain.
I proxied the iOS app through a proxy to see its web traffic. I also was running the app on a jailbroken phone to see what files were created when installing and using the app. Nowadays you can proxy your mobile apps like this. The 1st issue I found was because of a new feature many banks were launching at that time:
depositing checks by taking an image of them
I was so obsessed with this vulnerability, I almost missed the most simple vulnerability: The server where the check images were eventually uploaded to had insecure AWS permissions. I could just use AWS tools to retrieve all the checks of clients. For this you can use tools like:
The “checks” feature had one more vulnerability. The app was renaming the images to a predictable name, like:
Even if AWS permissions had been not wide open you could have requested: IMG2758974.png or IMG2758972.png To get someone else’s check image. So let's review, I had:
Written a worm that could have taken the check images from people's phones
Found that I could have just taken all 2 million check images from AWS
I had XSS on their main domain because of a misconfiguration in the mobile API
When being able to see all the files a mobile app creates, you can review its data stores. Hardcoded in a plist file was a credential for user. I had no idea for what login though. I wrote it down for later. During all this app analysis I was running my recon scripts in the background. Tools like
One interesting thing you can do with Amass is specify an Autonomous System Number to retrieve domains inside of that IP space.
Amass intel -asn bigbanksASN
This came back with a domain that I had never seen before. The regular domain was something like:
The new one found was something like:
Scanning this domain for subdomains and hosts revealed even more surface area to hack. Eventually, I ended up finding several blank page websites in this set of hosts.
Some were asking for basic authentication. So I supplied the username and password from the mobile app plist file. It worked!
The web app was so sensitive in nature I can’t really even describe the contents, but it was a big find by itself.
In addition, on that web server, I ended up having access to
Which is a server-level administration endpoint for Tomcat. The credentials I had once again worked. I followed my normal Tomcat hacking methodology and was able to get a reverse shell on the box. For security testers, something like this is the normal process for hacking Tomcat endpoints like that.
(example, not a real IP)
At this point, I was out of time but I was confident I could have moved laterally into the bank's network and gotten more. It was a fun test. If you want more hacker story threads like this; like, follow, and retweet here !