- ‘sup, today I’ll talk about my main domain since it is concerning penetration testing and I am currently a professional penetration tester. I won’t be able to show you most of what I do, except if I don’t get lazy and setup a lab to be able to screenshots without showing any client information. This category will speak mostly about web, infrastructure, mobile and everything you can encounter during a penetration test assessment.
Android vs iOS
Generally when you have to audit a mobile application, they’ll provide two version, one for Android and another for iOS as they are the most common mobile OS on the market. The general choice for your starting point should be Android, since it is easily reverse engineered using tools such as apktool and dex2jar and jd-gui. On iOS, the language is generally objective-c and it can be reverse engineered as well but it will need a little bit more tools to do that.
Static vs Dynamic
As a general approach you should have in mind that most applications could be easily dynamically tested since a lot of application will interact with a web service, so you could setup a proxy between the app and the webservice with tools such as burp while setting an access point easily with create_ap. There are a few other tools to do dynamic analysis, on android you can run your application and do some dynamic tests with adb, while on iOS you’ll have to try tools such as frida, that could wrap around some functions to be able to debug them dynamically.
I already talked about static analysis on the previous title but I think checking an application statically should be your priority since you’ll be able to recover all of the route an application will have access to.
General approach on web services
Most of general web application vulnerabilities can be tested on web services, but the current tendency on applications will make it so that modern web services will either use a framework or it is some REST web services. It would be pretty rare to find a simple vulnerability inside a framework without spending a little bit of time to find a 0day, and you’ll generally search for logical vulnerabilities, bad implementations (cryptographically, permissions-wise and so on)
Alright, I’m still on that since I didn’t finish my test and that is the part I never really worked on but there’s a lot of things to verify client-side, in the case of a program being able to alter the output of a webserver for example, it could lead to arbitrary code execution on the client. You’ll have to check general permissions asked by the program as well and verify that the application doesn’t store sensitive information.
What did I learn today?
- I learned about the existence of androtickle, mobsf and create_ap
- Some general methodology about client-side testing