Pentesting Report: Attack Narrative Series Part 1: Recon

#security #pentesting #codenewbie #hack

During my time at Flatiron School I created a password manager for my final project. Though a seemingly simple task, this threw me for a fun loop into authentication and cryptography; and now it is time to test it.
This is part 1 in an ongoing series as I complete the pentest report of the application I built. This series is meant to supplement the actual report that doesn't need the step-by-step breakdown that this will cover.

Part 1: Reconnaissance

There are two types of reconnaissance that take place during a penetration test, passive and active recon. For the purposes of this assessment, I will be acting as if I am being provided minimal information outside of the organizational domain name: https://flatiron-passwordmanager.netlify.app with the intent to closely simulate an adversary without any internal information. This is also referred to as a "black box" pentest.

Tools may include: Burp Suite, ZAP, Browser Developer Tools, sqlmap, Nmap, Shodan, and Nikto.

Passive Reconnaissance

Passive reconnaissance on the target involves gathering information that is already available on the internet and doing so without directly interacting with the target system.
Methods of passive reconnaissance involve search engine spidering, viewing public DNS records, enumerating website subdomains and links, viewing domain registration information, and services like the WayBack Machine.

As this is a new application that is being hosted through a hosting company, Netlify, no results were found through passive reconnaissance; Google, WayBack Machine, Bing, Duck Duck Go, or binsearch.info.
Shodan produced no results related to the application.

Active Reconnaissance

Active reconnaissance on the target involved directly probing the target system and retrieving an output.
Methods of active reconnaissance involve fingerprinting the web application, using the Shodan network scanner, performing a DNS forward and reverse lookup, and examining the source code; to name a few.

Nmap produced a few open ports but they were all related specifically to Netlify and is not included in the scope.
When Running Nikto the Following was found:
Upon inspecting the request header, the following information was retrieved:
- The server for the main app is called "Netlify". As this is the hosting company, this makes since.
- The server from the api is called "Cowboy".
- (HTTP Strict Transport Security) HSTS is enforced as the site will not load from http.
- Web Server header weaknesses were found and will be discussed later in this document.
When using ZAP to perform an "active scan" on the site nothing new was produced.
When using ZAP to preform a fuzz for common directory paths, none presented.
robots.txt file does not exist and the site doesn't have any other pages so nothing else populates.
While reviewing technologies used via Wappalyzer the following was round:
- PaaS and CDN of Netlifly
- The module bundler webpack
Upon signup and login attempt it can be seen that there is traffic to the api at "https://the-trapper-keeper.herokuapp.com/api/v1/users"
While walking through the application the following was observed.
- An error message of Please log in is displayed if you try to access the api directly.
- Signup and login without parameters cause the site to fail.
- Login with wrong credentials does not show which part was incorrect. On the site an error message populates saying "unknown username or password" and from the API an error message of {"error":"ivalid credentials"} is returned. [oops... i spelled 'invalid' wrong...]
- When trying to create an account that is already taken a header of Authorization: Bearer undefined is returned.
- When a valid user is created {"user":{"username":"admin1","password":"admining","email":"admin@admin.com"}} a lot of information is returned. It should be noted that headers Access-Control-Allow-Origin: * and Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS, HEAD are returned.
- No cookie is set but there is Session Storage of a JWT. If we decode the JWT it gives information about the user ID and the algorithm used to encrypt it.
- On refresh the session tokens are deleted and the user must login again. The same happens if a logged in user and tried to directly access a page through the URL the page will again delete the session tokens and the user must login again.
- Multiple users can sign up with the same password or email.