http://Yaklang.io anti-connection technology three axe
Anti-connection service
Multi-protocol port multiplexing
Intranet penetration
What is anti-connection? Why do it
Many times, when we perform vulnerability detection, we cannot determine whether a vulnerability exists through the information returned by the application. But if the command/special operation is indeed executed, how do we prove that the command or special operation is executed?
We habitually call this vulnerability detection technology: echo-free vulnerability detection technology.
Generally speaking, echoless vulnerability detection technology can be divided into two types:
- sleep/benchmark time-consuming operation detection.
- dnslog / http-reverse / tcp / tls / rmi and other service external connection detection.
Strictly speaking, I don’t think sleep / benchmark does not count as echo, and time-consuming operations can be regarded as directly observable indicators. In addition, sleep/benchmark will cause various minor problems on the server side:
- If the server is single-threaded, sleep will cause blocking,
- If the server CPU is not good enough, benchmark will consume resources
- If it occurs in a database, many databases in production environments will impose various restrictions on the execution of SQL statements, such as:
- The timeout SQL statement is considered badsql and the current query process will be cut off directly
- Malicious use of the SQL connection pool may cause other queries to fail, or even bring down the entire machine
4. If sleep is executed in a for/while branch, the sleep time will be much longer than expected, or directly 0.
In contrast, service external connection detection is a more “safe” method.
DNS reverse connection detection principle
For example, when the service is connected externally, we execute the curl http://abc.example.com command:
- At this time, http://abc.example.com will be parsed, and the NS records and A records of http://abc.example.com will be queried.
- If the NS record exists (http://ns1.example.com), http://ns1.example.com will be queried for the A record of http://abc.example.com.
- If NS does not exist, A record query is enabled directly to the public server.
During the process described above, if we can control http://ns1.example.com, any user query process will be recorded.
Of course, we can artificially set a subdomain name, and any requests to this subdomain name will be aggregated and displayed. This is the core principle of http://dnslog.cn.
RMI/HTTP/TLS
Of course, in the above example, we curl http://abc.example.com and if the corresponding IP can be found, an HTTP request will be made to the IP.
The original packet and any content of this request can be recorded by the anti-connect server we control.
- If we implement the HTTP protocol, HTTP related details will be logged
- If we implement RMI/LDAP/TLS, etc., we can record the information carried when reconnecting
This information is useful to determine whether a vulnerability exists, or to collect some sensitive information, such as AWS_SECRET_KEY / ACCESS_KEY / SECRET_KEY, etc.
Multi-protocol port reuse: Facade technology
You may have noticed an interesting phenomenon in the picture above. Whether RMI or HTTP/HTTPS, we are all listening on the same port.
Some students asked, is there really no problem with this?
This technology is not a sophisticated one. Port multiplexing is actually a very simple operation. The protocol headers of different protocols are different:
For example:
- The TLS protocol requires a TLS handshake operation first. During the TLS handshake, we will recognize that this is a TLS handshake operation. The client will judge the server as a TLS service, and the server will automatically return what TLS should receive.
- The protocol header of RMI is JRMI. When we receive these bytes from the client, we should reply with the content that RMI should recognize.
- Surely HTTP is simpler, right?
Of course, we have assembled these common protocols and opened them on one port at the same time. Some time ago, everyone called this technology mimicry. In fact, it can also be said that http://yaklang.io has implemented mimicry anti-connection server.
We named this server Facade
If the headers of the two protocols are exactly the same, it will cause the Facade server to confuse the protocols.
Of course, this situation is actually relatively rare. If it occurs, it can also be handled by setting the Facade recognition protocol cache size. You don’t have to worry about protocol errors.
In addition to convenience, are there any other benefits to protocol reuse?
In actual combat, many users found that although some of our protocols cannot be recognized, TCP connections can always be recognized. This is done to “cover the bottom”.
An invisible protocol was encountered, but the reverse connection was indeed connected back. Although it was only TCP, the user at least knew that the target had a reverse connection problem, right?
Intranet penetration: benchmarking ngrok penetration
Many times, when we scan, we may not be able to match up a public network server in time to enable the anti-connection server. Even if the public network server has the reverse connection service enabled, when our vulnerability payload is sent out, we may not know in time that our server has received the corresponding reverse connection.
So how to solve this problem? Of course, for the http://yaklang.io project, the simplest thing is to deploy a yak engine on the public network. Apart from this, are there any other solutions?
Students who are familiar with ngrok will say that we can deploy an ngrok to let the local server go online remotely.
Many students do this when using CS to go online.
Therefore, we implemented a mechanism in yak called cybertunnel, and used grpc to build a set of port penetration technology. We can map a local tcp/udp protocol port to the remote end. We can even map a local dnslog server to the remote end (the remote end requires the domain name provider to configure resolution records)
Yak engine penetration service
server configuration
Of course, penetration service requires the cooperation of a remote server.
If the yak core engine is installed on the server, you can use yak bridge to solve this problem
yak bridge –secret [your-password]
If you only have a docker environment, you can use the solution in https://github.com/yaklang/yak-bridge-docker/
docker run -d --rm --net=host v1ll4n/yak-bridge yak bridge --secret [your-awesome-password-for-u-bridge]
Start a Yak bridge server with one command
Yak intranet penetration client
When Yak is used to penetrate the local port to the yak bridge, it is actually very simple. We execute Yak tunnel -h to see the following help information
?yak-engine yak tunnel -h NAME: yak tunnel - USAGE: yak tunnel [command options] [arguments...] OPTIONS: --server value (default: "cybertunnel.run:64333") --local-port value (default: 53) --remote-port value (default: 53) --secret value --network value, --proto value (default: "tcp")
In fact, the configuration is very simple
- –server content is the public network address of the yak bridge we started, [host/ip]:[port] is enough
- –local-port is the local port we want to penetrate
- –remote-port is the remote port we want to penetrate to the yak bridge
- –secret is the password we set when starting yak bridge
- –network refers to the protocol of the local port we want to map. It supports both udp and tcp, so we can map the local dnslog.
We can use yak tunnel to map any local port, including yak grpc. Therefore, when we penetrate the intranet, we only need to run a yak grpc, and then penetrate through yak tunnel, and then we can use yakit to connect!
yakit anti-connection support
Of course, in addition to the mapping of any port supported by yak, we can also support yakit to map the anti-connection server to the remote end. For yakit, reducing the user’s operational burden is actually the core appeal.
After we configure a successful connection, all content will be saved to yakit’s local ~/yakit-projects/base/yakit-local.json folder.
Every time you start yakit in the future, it will automatically connect to the yak bridge. No need to manually configure again. .
yak bridge only has two functions: port mapping and obtaining the current public network IP. It has no other functions, so the version does not need to be too high. As long as it supports the yak bridge subcommand, it can be run.
Integration: The perfect fusion of Yakit plug-in and anti-connection technology
When we execute any yakit executable plugin
url := risk.NewPublicReverseHTTPUrl(risk.title("Reverse connection server test"), risk.type("Test reverse connection"))
println(url)
rsp, err := http.Get(url)
die(err)
http.show(rsp)
We found that we got the following results
The code is actually very simple. Whenever we need to detect vulnerabilities, we need to obtain the anti-connection URL, especially the URL accessible from the public network.
We use risk.NewPublicReverseHTTPUrl / risk.NewPublicReverseRMIUrl / … etc. to obtain an available reverse URL with Token.
Pass it into vulnerability detection as payload to realize anti-connection detection vulnerability.
All specific APIs can be found here: https://www.yaklang.io/docs/api/ris
Yak official resources
Yak language official tutorial:
https://yaklang.com/docs/intro/
Yakit video tutorial:
https://space.bilibili.com/437503777
Github download address:
https://github.com/yaklang/yakit
Yakit official website download address:
https://yaklang.com/
Yakit installation documentation:
https://yaklang.com/products/download_and_install
Yakit usage documentation:
https://yaklang.com/products/intro/
Quick FAQ:
https://yaklang.com/products/FAQ