Get Started with Black Box Pen tests — Part 2 — Vulnerabilities

Hey there, lovely readers! I hope you’re all doing well and ready for another thrilling installment of our series. If you’re just joining us or missed the last post, no worries! You can catch up by following this link.

Today, we’re diving deep into the exciting world of internet and intranet application testing for vulnerabilities. But fear not, I won’t bore you with the basics. Instead, we’ll explore various scenarios to check for potential vulnerabilities in both public-facing and internal applications, all while maintaining a black-box approach.

So, get ready! Let’s jump right in!

When it comes to web applications, one of the first things we notice is their protocol. If there’s no HTTPS, that’s a red flag, and the application might be vulnerable. You can make a count as ‘SSL/TLS Not Implemented’ or ‘Unencrypted Communication’. But there’s more to it than that — the SSL Certificate requires careful examination. Let’s break it down step by step.

To start, you can easily perform an SSL check online using tools like https://www.ssllabs.com/ssltest/ or do it manually. Here are some important scenarios to consider:

1. For public applications with subdomains in scope, check which ones are protected. You can even enumerate subdomains from here, gaining valuable insights into the application’s security posture.
2. If the Hostname is different from the actual domain name, then report it as ‘SSL Certificate Hostname Mismatch’.
3. No matter what the application is, always check the expiry date of its SSL Certificate. If it’s already expired, mark it as ‘Expired SSL Certificate’, or if it’s close to expiry, report it as ‘SSL Certificate about to expire’.
4. Verify if the SSL Certificate is issued by a legitimate authority. Many internal applications have self-signed certificates, which are like low-hanging fruit for attackers — label them as ‘Self-Signed SSL Certificates’.
5. There’re lot more attacks like TLS SSL LOGJAM Attack, Sweet32 attack, POODLE attack etc., and version related vulnerabilities like TLS Version 1.0 Protocol Detection, SSL Version 2 and 3 Protocol Detection so on. You can find these easily with the NMAP Scans.

nmap --script ssl-enum-ciphers -p 443 target_domain

Sample Scan Results.

You should now have a bunch of vulnerabilities to work with, and even some test cases to experiment on upcoming projects. Now, let’s move on to the login page — there’s a lot to explore here!

One common issue to be on the lookout for is default credentials. Even as an experienced professional, I always make it a priority to check for this whenever I encounter a login form. And it’s not just limited to the official login page; you might find it useful to test other sensitive endpoints or open panels on different ports too. Default credentials refer to common username and password combinations that come pre-configured on certain devices and software.

It’s surprising how often developers leave default credentials in place, assuming no one will access them. Give it a try on your own with some sample inputs like “root:root,” “admin:admin,” or “admin:password” — you’d be surprised how often these work!

But if you really want to step up your game, use Burpsuite’s Intruder to perform a brute force attack. (We’ll discuss this one later) This powerful tool can help you try out different combinations and crack those login credentials. To make your task easier, here are some valuable resources you can check out:

1. https://github.com/jeanphorn/wordlist
2. https://github.com/many-passwords/many-passwords/blob/main/passwords.csv

You can also prepare your own wordlist (I’ll try to cover it on a separate blog) for optimal solutions. Keep in mind, if the application is publicly faced, then get the appropriate teams’ approval to proceed as it may generates huge volume of traffic. So go ahead, give it a shot!

Imagine stumbling upon a vulnerability that grants you access to higher privileges bypassing the usual authentication process. Sounds thrilling, right? Well, that’s SQL Authentication bypass comes into play.

A SQL injection (SQLi) attack targets vulnerabilities in SQL databases to execute malicious SQL code and gain access. One method is an authentication bypass, where the attacker enters SQL code in a login form to gain access without credentials.

The concept is straightforward — simply try entering ‘or 1=1 — ‘ into the input fields of a login form and hit that submit button. The — denotes a comment in SQL, ignoring the rest of the query. If the attempt succeeds, you’ll find yourself logged in without needing any valid credentials. This outcome is a clear indication that the input is vulnerable to a SQLi attack.

Feeling curious and want to experiment with it yourself? Go ahead! Try entering variations like admin’ or ‘1’=’1 or user@gmail.com’ or ‘1’=’1 into the username field. The possibilities for testing are numerous!

Remember, we have a savior to automate this. Yes, again the intruder :)

SQLi Authentication Bypass Wordlist

Do you notice any similarity between the vulnerabilities mentioned above? Both of them relate to the Brute-Force attack, which occurs when there’s no Rate-Limiting on a form. This vulnerability can be found in various actions within an application, and its impact may vary depending on the nature and functionality of the application.

Rate limiting is a mechanism to restrict the number of requests allowed, preventing excessive traffic. The absence of rate limits in an API call / Request can lead to potential vulnerabilities, allowing unlimited attempts for data extraction.

Let’s explore some examples to understand it better:

1. Consider a login page where you can attempt to brute-force the credentials without any limitations. In this case, if the account doesn’t get locked out after a certain number of invalid attempts (usually, banking and payment applications should have this mechanism), you can report it as a ‘No Rate-Limit on form leads to Bruteforce Attack’. If the application doesn’t even have an account lockout mechanism, you can report it as an ‘Insufficient Account Lockout Mechanism’. Combining this vulnerability with ‘Username Enumeration’ can escalate its severity.
2. Another scenario involves the ‘forgot password’ action. Using the Intruder or Repeater, you can flood the victim’s email address with numerous requests. This can also apply to actions like OTP login or any other action that triggers email notifications to the victim. In such cases, you can report it as a ‘No Rate-Limit on form leads to Email Flooding/ Triggering of Mass Emails’.
3. It’s also essential to analyze the admin modules and check for similar vulnerabilities. For instance, you can explore actions like Account creation, User updates, and Transactions Initiation. The possibilities are extensive, and when these actions lack Rate-Limiting, you can report them as ‘Workflow Flooding’.

Source: Infosec Writeups — Jaydev Ahire

Some of the useful resources,
1. No Rate Limit — 2K$ Bounty. Summary : | by Jerry Shah (Jerry) | Medium
2. Bounty Tip !! Easiest way to bypass API’s Rate Limit. | by Shaurya Sharma | InfoSec Write-ups (infosecwriteups.com)
3. Ability to bruteforce Instagram account’s password due to lack of rate limitation protection — Youssef Sammouda (ysamm.com)
4. Yelp | Report #774050 — No rate limiting for confirmation email lead to email flooding | HackerOne

Last but certainly not least, let’s talk about Username Enumeration. It involves gathering valid usernames for a target system, and it serves as a pivotal starting point in black box pentesting. Why are usernames so important? Well, they are required to launch password cracking attempts and other potential exploits.

Now, let’s dive into how we can go about finding those active usernames with a few different techniques, all depending on the nature of the application. Take the login page, for example. When you provide incorrect login credentials, you might encounter a common error message like ‘Username and/or password is incorrect.’ But here’s the exciting part: if you try a valid username with an incorrect password, you may receive a different error message like ‘Password is incorrect’ or ‘Invalid Credentials’. When you spot this variation, congratulations — you’ve just discovered a potential case of ‘username enumeration.’

Let’s explore a few sample scenarios to make things even clearer:

1. The Login Page: If you’re faced with a simple login page, try using guessable usernames like ‘admin,’ ‘testuser,’ ‘guest,’ and ‘root.’ But if that doesn’t work, don’t lose hope. If it’s a public application, then check for documentation — you might find sample usernames there. Additionally, look out for any leaks in repositories like Git or online Pastebin sites. If the application is private, consider using AD Credentials or common usernames that might be used in other projects. Don’t miss to check minor changes like content-length variations in Burp — they might reveal valuable information beyond just error messages.

Source: Rapid7

2. Forgot Password Feature: When dealing with the “Forgot Password” functionality, try using email addresses as usernames. Like before, you can check for common email addresses used by application developers, which might be embedded in JS files or on the ‘contact us’ page. If you get an error message like ‘User not registered’ or ‘Invalid Email address’ for an invalid email and ‘Email sent to registered mail address’ for a valid one, you’re on the right track.

Source: Rhino Security

3. Signup Page: During the registration process, observe the responses you receive. Phrases like ‘User already registered!’ or ‘Mail address already in use’ could be valuable indicators of username enumeration possibilities.

Source: Shippo

Remember, the number of test cases you might encounter can vary greatly based on the application’s functionalities.

And that’s a wrap for this blog post! But hold on tight, we’re not done yet! We’ve got a lot more exciting content coming your way as part of this series. In the upcoming posts, we’ll be diving into various techniques and methodologies to uncover directory and header vulnerabilities. From HTTP Methods Override to Directory Bruteforce, and even Host Header Injection, we’ll cover it all! Not to mention, we’ll be exploring some low-hanging fruits like Missing Security Headers and Sensitive Data Disclosure through real-life cases.

So, stay tuned! Happy hacking, folks! 😄