Juniper SRX/IDP custom attack signature to block .EXE file download
HTTP transfer can take place either by requesting the direct file (example:
http://somedomain.com/virus.exe), which is very easy for IDS systems or by serving the file from a dynamic server script (php) using the "attachment" content disposition mime type.
Example of http request of url direct file request using tcpdump:Code:
.UL.....GET /nginx/download.exe HTTP/1.1
Host: 82.78.227.176
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Connection: keep-alive
...a.UL.HTTP/1.1 404 Not Found
Server: nginx/1.2.0
Date: Mon, 11 Jun 2012 21:16:12 GMT
Content-Type: text/html
Content-Length: 168
Connection: keep-alive
Example of http request via server script using tcpdump:Code:
.U.T.a.kGET /nginx/download.php HTTP/1.1
Host: 82.78.227.176
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Connection: keep-alive
.a...U.THTTP/1.1 200 OK
Server: nginx/1.2.0
Date: Mon, 11 Jun 2012 21:18:58 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/5.3.11
Content-Disposition: attachment; filename=filenamehere.eXe
0
Why first example is easier to match for Deep Packet Inspection systems is that the matching occurs in a very specific protocol context and it's direction is client to server (usually smaller quantity of traffic than the other direction).
A custom IDP signature can match both .exe file download cases, using a "chained" attack-type:
Code:
[edit security idp custom-attack CUSTOM:HTTP:URL:Exe]
# show
recommended-action close-client;
severity minor;
attack-type {
chain {
scope transaction;
expression "m01 or m02";
member m01 {
attack-type {
signature {
context http-header;
pattern "\[Content-Disposition\]: \[attachment\]; \[filename\]=.*\.\[exe\]";
direction server-to-client;
}
}
}
member m02 {
attack-type {
signature {
context http-get-url-parsed;
pattern ".*\.\[exe\]";
direction client-to-server;
}
}
}
}
}
Since first member implies that server-to-client traffic is inspected, make sure this feature is not disabled in the sensor config.
Adding the signature in a test policy:
Code:
# top show security idp active-policy | display set
set security idp active-policy test-download-exe
# top show security idp idp-policy test-download-exe
rulebase-ips {
rule 0 {
match {
source-address any;
destination-address any;
attacks {
custom-attacks CUSTOM:HTTP:URL:Exe;
}
}
then {
action {
close-client-and-server;
}
}
}
}
Checking if this signature matches the two exe file download methods:
Code:
# run show security idp attack table
IDP attack statistics:
Attack name #Hits
CUSTOM:HTTP:URL:Exe 2
In both cases, my browser receives an RST packet and displays "The connection to the server was reset while the page was loading."
Exe file download request variations:Signature will catch most, if not all, of the variations and shouldn't produce false positives, matching all fields case-insensitive.
Code:
.UL.....GET /nginx/download.exe HTTP/1.1
Code:
.UL.....GET /nginx/download.eXe HTTP/1.1
Code:
Content-Disposition: attachment; filename=filenamehere.exe
Code:
Content-Disposition: attachment; filename=filenamehere.EXe
Code:
Content-Disposition: attachment; filename="filenamehere.EXe"
Some servers can enclose the exe filename in single/double quotes that the signature covers.