Get Started with Black Box Pen tests: 2 — Vulnerabilities.

HunkyHack3r

Hey there, lovely readers! I hope you’re all doing well and ready for another thrilling installment of our series. No worries if you’re joining us or missed the last post! 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 public-facing and internal applications 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.

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

Check which ones are protected for public applications with subdomains in scope. You can even enumerate subdomains from here, gaining valuable insights into the application’s security posture.
If the Hostname differs from the actual domain name, report it as an ‘SSL Certificate Hostname Mismatch.’
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’.
Verify if a legitimate authority issues the SSL Certificate. Many internal applications have self-signed certificates, which are like low-hanging fruit for attackers — label them as ‘Self-Signed SSL Certificates.’
There are many 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. You can find these easily with the NMAP Scans.
nmap --script ssl-enum-ciphers -p 443 target_domain

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 much to explore here!

One common issue to look for is Default Credentials. Even as an experienced professional, I always prioritize checking for this whenever I encounter a login form. And it’s not just limited to the official login page; you might find it helpful to test other sensitive endpoints or open panels on different ports too. Default credentials refer to username and password combinations pre-configured on specific 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:

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 generate a massive 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 SQLi 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 — 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 indicates that the input is vulnerable to an 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 🙂

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:

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 several 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 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.
Another scenario involves the forgot password action. You can flood the victim’s email address with numerous requests using the Intruder or Repeater. 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.’
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.’

Some of the valuable resources,

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

Now, let’s dive into how we can find those active usernames with a few different techniques, 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, check for documentation — you might find sample usernames there. Look out for 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 checking minor changes like Burp’s content-length variations — they might reveal valuable information beyond just error messages.

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. You’re on the right track 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.

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

Remember, the number of test cases you 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. We’ll dive into various techniques and methodologies in the upcoming posts to uncover directory and header vulnerabilities. WE’LL COVER EVERYTHING from HTTP Methods Override to Directory Bruteforce and even Host Header Injection! We’ll also explore low-hanging fruits like Missing Security Headers and Sensitive Data Disclosure through real-life cases.

So, stay tuned! Happy hacking, folks! 😄