Category: Other vulnerabilities

Hello, aspiring Ethical Hackers. In this blogpost, you will learn about Heartbleed vulnerability. If you’re learning cybersecurity or ethical hacking, you’ll often hear about famous vulnerabilities that changed how the internet works.

One of the most important and dangerous was the Heartbleed vulnerability. Don’t worry if it sounds complicated. In this beginner-friendly guide, you’ll learn:

• What Heartbleed is
• How it works
• Why it was so serious
• What should we learn from it

What is the Heartbleed Vulnerability?

The Heartbleed vulnerability was a major security flaw discovered in 2014 in a widely used software called OpenSSL. OpenSSL is responsible for securing internet communications using encryption (like HTTPS). Heartbleed allowed attackers to read sensitive data from a server’s memory.

Why Was Heartbleed So Dangerous?

Heartbleed was not just another bug. It was a critical vulnerability. Here’s why:

It Exposed Sensitive Data:

Using this vulnerability, attackers could steal:

• Passwords
• Private keys
• User data
• Session cookies

It Left No Trace:

One of the scariest parts:

Attacks didn’t leave logs or evidence.

It Affected Millions of Websites:

Since OpenSSL was widely used, many major websites were vulnerable.

It Could Be Repeated:

Attackers could exploit it multiple times to gather more data.

How Heartbleed Works?

Let’s break HeartBleed down in a way that’s easy to understand.

The Idea Behind “Heartbeat”:

OpenSSL has a feature called heartbeat. It works like this:

• A client sends a small message
• The server replies with the same message

This is used to check if the connection is still alive.

The Bug:

The problem was that the server trusted the size of the message sent by the client.

So if an attacker:

• Sent a small message
• But claimed it was larger

The server would respond with:

• The message
• PLUS extra data from memory

The Result:

This extra memory could include:

• Private keys
• Passwords
• Sensitive information

In simple terms, the server accidentally leaked its own secrets.

Practical Walkthrough

Let’s see how this works practically. For demonstrating this, I will be using a Vulhub lab shown in our Hacking Labs to setup a vulnerable instance of Heartbleed as shown below.

Once the vulnerable instance is ready, I start Metasploit & load the Heartbleed module.

I set the IP address and execute the module.

The module is by default set to scan for the vulnerability and it does exactly that. Apart from this action, this module has other actions.

For example, the “dump” action dumps the content of the memory.

When we set the action to “key”, the private key of the SSL server gets dumped as shown below.

Real-World Analogy

If that was too technical for you to understand, let me give you a non -technical example. Imagine this scenario: You ask a shopkeeper:

“Give me this 5-page document.”

But the document only has 1 page.

Due to a mistake, the shopkeeper gives:

• That 1 page
• PLUS 4 random pages from confidential files

That’s exactly how Heartbleed worked.

Real-world Exploitation Examples

At the time of public disclosure of this vulnerability, almost 17% of total web servers were found vulnerable to heartbleed, including those belonging to Google, Yahoo, DropBox, Facebook etc. Here are some Real-world explaoitation examples of the heartbleed bug.

Mumsnet:

Mumsnet is a parenting site in United Kingdom. Cyber thieves have obtained passwords and personal messages from Mumsnet by exploiting heatbleed in 2014. Mumsnet has over 1.5 million registered members and there is no idea how many details got hacked.

Canada Revenue Agency:

Social Insurance members of over 900 taxpayers were stolen from Canada Revenue Agency by exploiting heartbleed bug within a 6 hours period on 8 April 2014.

What Systems Were Affected?

Any system using vulnerable versions of OpenSSL are vulnerable to this bug. This included:

• Websites
• Email servers
• VPNs
• APIs

That’s why the impact was massive.

What Data Could Be Stolen?

Heartbleed exposed:

• Private encryption keys
• User passwords
• Session cookies
• Emails
• Confidential data

With private keys, attackers could:

• Impersonate servers
• Decrypt secure communications

Why It Was Hard to Detect?

Unlike many attacks, Heartbleed didn’t:

• Modify files
• Leave logs
• Trigger alerts

This made it:

• Silent
• Stealthy
• Extremely dangerous

How Was It Fixed?

Once discovered, developers:

1. Released Patches:

Updated versions of OpenSSL fixed the bug.

2. Replaced Keys:

Organizations had to:

• Generate new SSL certificates
• Revoke old ones

3. Forced Password Resets:

Users were advised to:

• Change passwords

Fixing Heartbleed required major global effort.

Lessons from Heartbleed (Very Important)

Heartbleed taught the cybersecurity world valuable lessons. They are

1. Even Trusted Software Can be vulnerable:

OpenSSL was widely trusted but still had a critical flaw.

2. Code Auditing is Essential:

Small bugs can cause huge damage.

3. Patch Quickly:

Delays increase risk.

4. Encryption Alone is Not Enough:

If keys are exposed, encryption fails.

5. Security is Continuous:

You must:

• Monitor
• Update
• Improve

Can Beginners Practice Heartbleed?

Yes, but safely.

Use Lab Environments:

Practice on:

• Vulnerable virtual machines
• Training platforms

Never Test on Live Systems:

Without permission, this is illegal. Always stay ethical.

Common Beginner Mistakes

Here are some common mistakes beginners make about HeartBleed vulnerability.

Thinking it’s “Just an Old Bug”:

Even though being an old vulnerability, Heartbleed still teaches important concepts.

Ignoring Memory-Based Attacks:

Not all attacks target websites directly.

Skipping Fundamentals:

Understanding how protocols work is key.

Why You Should Learn About Heartbleed?

Even though it’s old, it helps you understand:

• How vulnerabilities work
• Why validation is important
• How attackers think

It builds your security mindset.

Conclusion

The Heartbleed vulnerability is one of the most important lessons in cybersecurity history. It shows that a small mistake in code can expose millions of systems.

Hello aspiring ethical hackers. In this article, you will learn about the ProxyLogon, a critical vulnerability that affected the Microsoft Exchange Server.  Back when it was discovered late 2020, there were over 2,50,000 vulnerable Microsoft Exchange Servers.

About the vulnerabilit(ies)y

ProxyLogon is a name given to four zero day vulnerabilities that were detected in the Exchange Server in December 2020. On December 10, 2020, Orange Tsai, security researcher working in DEVCORE, discovered that attackers can combine some vulnerabilities in the Exchange Server to achieve remote code execution on the target and upload a webshell to it. The four vulnerabilities are,

1. CVE-2021-26885:

This is a Server-Side Request Forgery (SSRF) vulnerability in the Exchange Server that allows remote attackers to gain admin access once exploited. This can be exploited by sending a specially crafted web request to a vulnerable Exchange Server. The web request contains an XML SOAP payload directed at the Exchange Web Services (EWS) API endpoint.  This request bypasses authentication using specially crafted cookies. This vulnerability, combined with the knowledge of a victim’s email address, means the attacker can exfiltrate all emails from the target’s Exchange mailbox.

2. CVE-2021-26857:

This is a POST-authentication insecure deserialization vulnerability in the Unified Messaging service of an Exchange Server that allows commands to be run with SYSTEM privileges. The SYSTEM account is used by the operating system and services that run under Windows. A SYSTEM account in Windows has full permissions by default. A hacker can either steal credentials or use the above mentioned vulnerability to execute arbitrary commands on a vulnerable Exchange Server in the security context of SYSTEM.

3. CVE-2021-26858 and CVE-2021-27065

These two vulnerabilities are POST-authentication arbitrary file write vulnerabilities that allow attackers to write files to any path on a vulnerable Exchange Server. A malicious hacker can also exploit the previously mentioned SSRF vulnerability to achieve admin access and then exploit this vulnerability to write web shells to virtual directories (VDirs). These virtual directories are published to the internet by the server’s Internet Information Server (IIS).
IIS is Microsoft’s web server and a dependency that is installed with Exchange Server and provides services for Outlook on the web, previously known as Outlook Web Access (OWA), Outlook Anywhere, ActiveSync, Exchange Web Services, Exchange Control Panel (ECP), the Offline Address Book (OAB) and AutoDiscover.
According to Microsoft, these vulnerabilities were first exploited by HAFNIUM, a Chinese government sponsored APT (Advanced Persistent Threat) but operating out of China. This group is known to install the web shell named China Chopper. As of 12th March 2021, at least 9 other hacker groups exploited these vulnerabilities apart from HAFNIUM.  The versions of Exchange Servers vulnerable to these vulnerabilities are,                   

Exchange Server 2019 < 15.02.0792.010                   
Exchange Server 2019 < 15.02.0721.013                   
Exchange Server 2016 < 15.01.2106.013                   
Exchange Server 2013 < 15.00.1497.012

The exploit is named Proxy Logon as it exploits the proxy architecture and login mechanism in the Exchange Server.

Mitigation and Patches

Microsoft has released a security update on March 2021 to patch these vulnerabilities in Exchange Server versions mentioned above. Applying these patches will fix these vulnerabilities. As soon as Microsoft released these security updates, hacker groups around the world went on a scanning spree to hunt for unpatched Exchange Servers.

As there was a delay in applying patches, Microsoft also released a one-click mitigation tool that fixed these vulnerabilities in Exchange Servers. Microsoft has also noted that this tool named Microsoft Exchange On-Premises Mitigation Tool (EOMT) is helpful for those organizations that don’t have a dedicated IT security staff. This tool also includes the Microsoft Safety Scanner and an URL Rewrite mitigation for CVE-2021-26855. However, it stressed that this tool was not an alternative for applying the released security patches.

Proof Of Concept

Metasploit has some modules related to these vulnerabilities. Let’s have a look at these modules.

The auxiliary/gather/exchange_proxylogon_collector module exploits the CVE-2021-26855 vulnerability and dumps all the contents of the mailboxes.

The exploit/windows/http/exchange_proxylogon_rce module exploits the CVE-2021-26855 vulnerability to bypass authentication and gain admin access and then writes a arbitrary file to the target using CVE-2021-27065 to achieve remote code execution.  All the above mentioned versions are vulnerable by default.

The auxiliary/scanner/http/exchange_proxylogon module checks for the CVE-2021-26855 vulnerability that makes Exchange Servers vulnerable.