If you happen to be in the security field or if you deal with a large number of computers, you probably have heard of the new vulnerability in the Microsoft Windows operating system. This latest vulnerability leaves systems susceptible to running code by loading a malicious LNK or PIF files, aka shortcuts. Since it is feasible that a malicious website could be built to deliver these files, I decided to put together procedures to block these from being downloaded through a Cisco ASA using deep packet inspection.
If you can see the two images below, your environment permits the downloading of PIF and LNK files. These are simply renamed “png” files that, in this case are harmless. The ability to view these files does not conclusively prove that someone has not taken other measures to protect the corporate assets, just that the download of these files is permitted.
It had been about three months since I had done much with deep packet inspection on the ASA. When I started putting together my rules, I looked at some samples from the Cisco website. I was quite frustrated when I could not seem to get them to work. Ultimately, I found that the regular expressions did not seem to work with version 8 (didn’t try in 7x though). However the real issue seemed to be what the ASA considered to be a “URI” differed from the examples on the web site. So what does the ASA consider a URI and is thus compared against the Regular Expression?
As one can see in the above image, a “URI” might look like “/directory/file.ext”. Some examples I found seem to indicate that the URI might contain the “Request Version”, for example HTTP/1.1. Once I figured this out, building the appropriate class-maps and policy-maps was fairly straightforward.
The first step is to create a regular expression that matches URI’s that we wish to block. From a simplified standpoint, I wanted to block something like “/*.lnk” and “/*.pif” (where * could be a filename or directory/filename and the extension case insensitive). The easiest way to accomplish this is as follows.
regex badext "/.*\.([Ll][Nn][Kk]|[Pp][Ii][Ff])"
Next I built a class-map to pull our regular expressions (in this case only one regular expression) together.
class-map type regex match-any BADEXT match regex badext
A deep packet inspection http policy map can then be built that defines how http traffic should be handled. In this case, I dropped and log the traffic matched by the above class-map.
policy-map type inspect http http_inspection_policy parameters match request uri regex class BADEXT drop-connection log
Then all I had to do was to tie this into the http inspection for the traffic. This may vary from configuration to configuration. Generally, it can just be attached to a global http inspection.
policy-map global_policy class inspection_default inspect http http_inspection_policy
The final and complete configuration is as follows.
regex badext "/.*\.([Ll][Nn][Kk]|[Pp][Ii][Ff])" class-map type regex match-any BADEXT match regex badext policy-map type inspect http http_inspection_policy parameters match request uri regex class BADEXT drop-connection log policy-map global_policy class inspection_default inspect http http_inspection_policy
I do not want to overstate this solution. With vulnerability as pervasive as this one, there are many attack vectors. I just think blocking these file types in http requests is a good thing in most cases. I guess there is the possibility that someone is using one of these extensions for some non-standard file type and this could break something. However, that should be a rare occurrence and this could do a lot more good than harm.