IntroductionIn this article, we would be looking at some of the essential tools and techniques that form the baseline for information gathering and attacking phases in the traffic analysis. We would be going through some of the very basic tools available for free and using them for achieving some of the basic reconnaissance and vulnerability detection. Understanding of HTTP and SSL/TLS would be a must to get started.
Recognizing our TargetsBefore knowing about any tool, we must use a Top-to-Down approach for gathering information about our target. The approach for our current task is explained in the below diagram:
Starting with the very top, we recognize that our main task is the ‘Security of the iOS application’. Coming down, we see that we are currently on the ‘Traffic Analysis’ part of iOS application security. The three basic things which need attention are:
- ‘Service’ which may be HTTP, XMPP or any other protocol on which the application is communicating with the server.
- ‘Server’ which is the remote server with which the iOS application is communicating.
- ‘Channel’ which may be SSL/TLS or any other channel depending on the security imposed by the developers.
Tools required for traffic analysisNow we get that in totality, we need to secure these three things in order to ensure the complete security of iOS application traffic. Let’s move on to some tools which we need to install and make use of for ensuring security of these three components.
1. Directory brute forcersThe first thing that we think of when we get to know the URL of the target application is to get every common file present on it whether hidden or explicitly referred to. While doing such a task we would want to discover the following:
- Admin panels
- Default pages
- Backup files/directories
- Hidden files/directories
- Dirb (written in C)
- Dirbuster (by OWASP)
- Gobuster (written in golang)
- Dirsearch (written in python3)
All of them perform the same task but only differ in their respective implementation. We can use any of them considering our requirements such as speed, stability and other options they provide. The below screenshot shows the use of dirb for directory brute forcing on Twitter's URL.
2. Web Server ScannersWhile we are brute forcing directories, we are also interested in scanning the web server itself for vulnerabilities. Nowadays, we have the tools that can recommend vulnerabilities based on the software being used on the server. The basic idea is to run an automated scan based on some generic or server type checks and analyse the changing response headers and body against publicly available exploits.
Some of the popular web server scanners used are:
A list of vulnerability scanners can be found at https://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools
The below screenshot shows the use of nikto for scanning the Twitter's web server at https://api.twitter.com.
3. Port ScannersThe server on which the backend of the application is hosted needs to be secured from the attacks because if it can be compromised in any manner, the attacker would be able to exploit many vulnerabilities which might include source code exposure, users’ data theft and so on.
For achieving this level of security, we need to scan all the ports on the server for vulnerabilities and ensure that all the vulnerabilities are timely patched. Some of the popular port scanners are:
- netcat (nc)
The below screenshot shows the use of nmap for scanning all the ports (TCP) the Twitter's server at https://api.twitter.com.
4. Channel ScannersThe two main components of communication i.e. the request/response API and the server have been taken care of by now. It is also worth noting that the channel of communication can also be used by attackers to craft an attack against the users of the application. Hence, we need to deploy the relevant patches on the channel in order to make it secure.
For doing this, we first identify the channel or the protocol of communication and then scan the channel of communication for vulnerabilities. Let’s talk about the most popular channels used today i.e. HTTP and HTTPS.
- HTTP by default is an unencrypted protocol. An attacker sniffing the packets on the router can easily watch all the communication unencrypted and hence using HTTP for applications storing any of the user’s data is not recommended.
- HTTPS is the secure version of HTTP and is very widely used these days. It uses transport layer encryption (SSL/TLS) for communication. All the request parameters including the GET and the POST parameters are secure over HTTPS.
But it is not recommended to transmit sensitive information like passwords, PII and so on in the GET or the QUERY parameters as they get logged on the server. Any data breach on the server would compromise user’s data and add to the impact caused.
Taking security into consideration, we must ensure proper configuration of SSL/TLS in order to reduce the chances of attacks on the communication channel. To check this, we have publicly available tools that verify the SSL/TLS configuration. The famous ones are nmap (SSL Cipher Enumeration script), sslscan and Nessus.
The following screenshots show the use of nmap and sslscan for testing the configuration of SSL on the Twitter's web server at https://api.twitter.com.