Attention, the method works not as well as it should
There is a possibility to find out a vendor of AV installed on a user's PC. Remotely and without detection from the user. This information could be useful for us if we want to attack the user.
The method is based on two main features.
The first feature. The most of modern AVs can detect malware analyzing network traffic. Usually, http and smtp/pop3/imap protocols are analyzed. However, as TLS is used more and more often, then an AV actually has to perform a man in the middle attack against a user application and a remote server. To bypass a certificate chain check, the AV installs its own root CA (root CA's private key is stored too) to the OS and uses it for "on fly" certificate creation for intercepted TLS connections.
The second feature. Flash supports raw TCP sockets. Actually, there is an opportunity to send/receive any tcp packet to any port of a remote server from a swf file in a browser. But as this feature could be an issue in terms of security, Flash supports crossdomain policy for sockets. If a swf file wants to connect a remote server via a raw socket, Flash connects to 843 tcp port on the server and sends a request ("<policy-file-request/>") and gets a crossdomain xml response. The crossdomian file contains information from which ports and from which domains are allowed to connect to the server.
Example of socket crossdomain:
The overall scheme of the method:
0) A user visits to our site. Our malicious swf is loaded by the user's browser.
1) Swf requests a socket crossdomain policy from 843 port of our server and gets required permissions.
2) Swf connects to our server (port 443, 465, etc.) and send a 'Client Hello' TLS packet (in raw bytes)
3) The server replies a 'Server Hello' TLS packets with the server’s certificate.
4) AV intercepts connections, generates a new certificate and signs it using the AV's own root CA
5) SWF receives the TLS packet (with a certificate) from AV and resends it to our server where we can parse it and get the name of root CA.
Actually, the idea of method is based on the research of Facebook - https://www.linshunghuang.com/papers/mitm.pdf. They used a special swf for a "real" MitM detection. But they didn't share the sources of the project.
I've created a PoC to test this method (it's far from real implementation) - https://github.com/GrrrDog/FlashAV. It consists of a special swf file and a python server. The swf sends a raw SSLv3 request and resends a response to the python server. The python server is used for certificate "parsing" and for crossdomain socket policy distribution.
Results:
My initial tests have been made on Avast AV. And it works great. I've got AV's certificates for IE and Chrome when Swf connects to 443 port. Avast has not intercepted connections from Firefox to 443 port of a server. However, in case of Firefox if swf connects to 465(587/995/etc) port (SMTPs), AV intercepts it and we can get a version of AV again.
Here is an example
Then I've tested the PoC on Kaspersky AV, but, unfortunately, unsuccessfully. KAV intercepts traffic from browsers, but it doesn't want to intercept connections from the swf (to any port).
I'm not an AV guru, so I'm sure that I've missed something. So I've decided to share this idea and these weird results to get some feedback from you.
You can play with SWF here https://dbggl.pw/flashav.swf Nginx (443) and ncat (465, 995) are started on the server for testing.
There is a possibility to find out a vendor of AV installed on a user's PC. Remotely and without detection from the user. This information could be useful for us if we want to attack the user.
The method is based on two main features.
The first feature. The most of modern AVs can detect malware analyzing network traffic. Usually, http and smtp/pop3/imap protocols are analyzed. However, as TLS is used more and more often, then an AV actually has to perform a man in the middle attack against a user application and a remote server. To bypass a certificate chain check, the AV installs its own root CA (root CA's private key is stored too) to the OS and uses it for "on fly" certificate creation for intercepted TLS connections.
The second feature. Flash supports raw TCP sockets. Actually, there is an opportunity to send/receive any tcp packet to any port of a remote server from a swf file in a browser. But as this feature could be an issue in terms of security, Flash supports crossdomain policy for sockets. If a swf file wants to connect a remote server via a raw socket, Flash connects to 843 tcp port on the server and sends a request ("<policy-file-request/>") and gets a crossdomain xml response. The crossdomian file contains information from which ports and from which domains are allowed to connect to the server.
Example of socket crossdomain:
<?xml version="1.0"?>The curious thing happens when we use both of these features. If we simulate TLS connection from a swf file to a remote host on a specific port (443,587, etc.), then an AV intercepts it. So, our swf receives a TLS certificate generated by the AV and we detect a vendor of the AV from a root CA name.
<!DOCTYPE cross-domain-policy SYSTEM "/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control permitted-cross-domain-policies="master-only"/>
<allow-access-from domain="*" to-ports="443,995,465,587" />
</cross-domain-policy>
The overall scheme of the method:
0) A user visits to our site. Our malicious swf is loaded by the user's browser.
1) Swf requests a socket crossdomain policy from 843 port of our server and gets required permissions.
2) Swf connects to our server (port 443, 465, etc.) and send a 'Client Hello' TLS packet (in raw bytes)
3) The server replies a 'Server Hello' TLS packets with the server’s certificate.
4) AV intercepts connections, generates a new certificate and signs it using the AV's own root CA
5) SWF receives the TLS packet (with a certificate) from AV and resends it to our server where we can parse it and get the name of root CA.
Actually, the idea of method is based on the research of Facebook - https://www.linshunghuang.com/papers/mitm.pdf. They used a special swf for a "real" MitM detection. But they didn't share the sources of the project.
I've created a PoC to test this method (it's far from real implementation) - https://github.com/GrrrDog/FlashAV. It consists of a special swf file and a python server. The swf sends a raw SSLv3 request and resends a response to the python server. The python server is used for certificate "parsing" and for crossdomain socket policy distribution.
Results:
My initial tests have been made on Avast AV. And it works great. I've got AV's certificates for IE and Chrome when Swf connects to 443 port. Avast has not intercepted connections from Firefox to 443 port of a server. However, in case of Firefox if swf connects to 465(587/995/etc) port (SMTPs), AV intercepts it and we can get a version of AV again.
Here is an example
Then I've tested the PoC on Kaspersky AV, but, unfortunately, unsuccessfully. KAV intercepts traffic from browsers, but it doesn't want to intercept connections from the swf (to any port).
I'm not an AV guru, so I'm sure that I've missed something. So I've decided to share this idea and these weird results to get some feedback from you.
You can play with SWF here https://dbggl.pw/flashav.swf Nginx (443) and ncat (465, 995) are started on the server for testing.