olle.nxs.se

Thoughts on the future of Anti-Virus

olle@nxs.se — Tue, 27 Sep 2011 12:00:00 +0200

One of the reasons I haven't been updating this blog much is that I have been doing less technical work of interest and spent more of my time thinking about building defenses. One of the issues that pop up when evaluating defensive technologies is where Anti-Virus products fit in.

Not to piss off my friends in the AV industry but, until recently, I have been extremely sceptical about the value of AV products.

Lately I have stepped down from my fundamentalist stance and must admit that blacklist AV technology has a place in the market, but certainly not as big a place as it occupies today.

I would still never recommend AV as your only means of defense against malware, as enumerating badness will always fail, but it does provide a nice benefit that I like to call the "hygiene factor". Like washing your hands doesn't protect you from disease, it does get rid of some of the crap so that your immune system doesn't have to deal with it.

The recent announcement from Microsoft that they will include technology from their Security Essentials product in the upcoming Windows 8 release has caused some debate.

One thing that most people conclude is that this move will bring down prices in what is already a commodities market and I hope they are right. Not because I hate Anti-Virus companies and want them to fail, but because the data security market today is grossly inefficient. Let me explain why.

AV is not about technology, it is about intelligence. The best AV-engine can be useless if it isn't fed with good, up-to-date intelligence about threats. Conversely, the worst AV-engine can still be effective if it has access to good intelligence. What you buy isn't the AV software you install, it's access to the AV companies' analysts. What AV companies compete on isn't technology, it's who has better and more up-to-date intelligence on current threats.

Imagine then the ammount of analyst manpower, not to mention computing power, that the world's 40+ AV companies spend keeping up with current threats and it is easy to see what I mean by inefficiency. Today the increasing commoditisation of blacklist AV technology has driven the larger players to integrate other products into their product offering because licensing fees for traditional blacklist AV products are dropping. What this means for users is that the cost of hygiene is approaching zero. Just like with cheap soap in the "washing your hands" analogy, it would then be silly not to use it.

If the market is driven towards a few large vendors servicing all our AV needs at a lower cost, then smaller players will be forced to innovate and find other uses for all that analyst manpower. One example that I have advocated for a long time is to provide intelligence about "goodware", effectively turning the AV business model on its head and providing updated lists of known good software that is continously AV-scanned and vulnerability tested by their analyst staff. That is only one idea, I imagine there are countless others.

I could write pages on this topic but choose to limit myself to conveying these three ideas, in summary:

Existing Anti-Virus products are not security controls, but they are good hygiene
Anti-Virus products are not about technology, they are about intelligence on current threats
Increased commoditisation of Anti-Virus products will drive innovation in the security market

/olle

Striking gold in DNS reply packets

olle@nxs.se — Wed, 04 Nov 2009 17:09:00 +0100

When probing a client's Internet-facing network I saw some strange replies to DNS queries. Their setup was pretty simple, a classic three-legged firewall with som public services on the DMZ. I managed to find the RFC 1918 addresses used on the DMZ segment through a misconfigured IIS and shot off a PTR query to their public DNS server:

$ dig -x 10.10.10.10 @212.212.212.21

; <<>> DiG 9.3.4 <<>> -x 10.10.10.10 @212.212.212.21
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 2283
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;21.212.212.212.in-addr.arpa.    IN      PTR

;; Query time: 6 msec
;; SERVER: 212.212.212.21#53(212.212.212.21)
;; WHEN: Wed Nov  4 15:55:06 2009
;; MSG SIZE  rcvd: 45

$

Wait a minute, what's that in the "query section" of the dig output? Let's try that again using a different IP address:

$ dig -x 10.10.10.1 @212.212.212.21

; <<>> DiG 9.3.4 <<>> -x 10.10.10.1 @212.212.212.21
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 7347
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;1.10.10.10.in-addr.arpa.       IN      PTR

;; Query time: 15 msec
;; SERVER: 212.212.212.21#53(212.212.212.21)
;; WHEN: Wed Nov  4 15:59:56 2009
;; MSG SIZE  rcvd: 41

$

That's more what I expected to see, the query I sent repeated back in the reply. So what happened to the earlier DNS query? Time to bust out some ad-hoc shellscripting:

$ for i in `seq 255` ; do dig in ptr ${i}.10.10.10.in-addr.arpa. @212.212.212.21 | grep PTR; done
;1.10.10.10.in-addr.arpa.       IN      PTR
;2.10.10.10.in-addr.arpa.       IN      PTR
;3.10.10.10.in-addr.arpa.       IN      PTR
;4.10.10.10.in-addr.arpa.       IN      PTR
;5.10.10.10.in-addr.arpa.       IN      PTR
;6.10.10.10.in-addr.arpa.       IN      PTR
;7.10.10.10.in-addr.arpa.       IN      PTR
;8.10.10.10.in-addr.arpa.       IN      PTR
;9.10.10.10.in-addr.arpa.       IN      PTR
;21.212.212.212.in-addr.arpa.       IN      PTR
;11.10.10.10.in-addr.arpa.      IN      PTR
;12.10.10.10.in-addr.arpa.      IN      PTR
;56.171.171.82.in-addr.arpa.        IN      PTR
;14.10.10.10.in-addr.arpa.      IN      PTR
;15.10.10.10.in-addr.arpa.      IN      PTR
;35.212.212.212.in-addr.arpa.       IN      PTR
;17.10.10.10.in-addr.arpa.      IN      PTR
...

Wow, we even found another public IP range, how about that!

But why do we see these strange replies? It's almost as if someone were rewriting DNS replies for certain addresses. Turns out, that's exactly what's happening. The Cisco PIX/ASA static NAT rules have an optional keyword 'dns' that, when appended to the rule rewrites DNS packets according to the address translation scheme. There isn't too much documentation available (from a cursory google search) about this feature and so people might be using it even when not strictly necessary. The primary motivation for using it seems to be when you want internal users to access the public servers on the DMZ-segment using the RFC 1918 addresses of the DMZ segment and not the actuall publicly routable addresses. Check out this Cisco article explaining when to use DNS rewriting.

In my humble opinion this is probably just a bug in the PIX/ASA DNS rewriting module, it's being a bit too frivolous and rewriting something it really shouldn't touch. I could be wrong, of course, there might be some weird use case where you would want to change even the query portion of DNS reply packets... Comments?

So, what did we learn today? Well, I learned that both this client's public IP address ranges were being mapped to services on the DMZ of a Cisco PIX firewall and I could enumerate all the static NAT rules of that firewall == all publicly available servers.

More general lessons:

Defenders; know what features you are configuring/enabling when writing rulesets, don't just fiddle with it until "it works". Adding a feature that you don't need can get you in trouble sometimes!
Attackers; pay close attention to the reply packets when scanning DNS servers, they SHOULD contain a copy of your query. If they don't you might have something interesting there!

/olle

All client IP-addresses have been doctored, obviously...

Automatic Visio network map generation

olle@nxs.se — Tue, 20 Oct 2009 22:14:00 +0200

So I got a request from a customer recently to have his three datacentres scanned to discover what devices were actually on the different network segments and then proceed with vulnerability assessment scans of the managed hosts. So far nothing I hadn't encountered before, but this particular CISO was a wizened old guy recently appointed to "shape up" this customers IT-security operations and in a no-nonsense way described exactly how he wanted the results presented.

In addition to the normal asset listings, he wanted the results of the discovery scans presented in a map layout where he could get a "big picture" overview and drill down on specific segments and hosts to get more details. I could see right away how this would be useful to him and that it would certainly benefit other customers if added to my standard documentation procedure for these types of assignements, so I agreed after asking a few follow-up questions to make sure we had our expectations in sync.

Back at the office I started by evaluating the existing "network map generating" scanners I could find. Since Microsoft axed the "network discovery" features of Visio after aquiring it, the current favourite (judging by google results) seems to be SolarWinds' LANsurveyor product that neatly fills the gap, being integrated as a Visio Add-On. The drawback was the legacy of SolarWinds as a network management software vendor heavily into SNMP. Without SNMP-access to routers and switches, the discovery options of LANsurveyor are severely limited. Also, the information gathered on servers was less than impressive and the device icons and network layout looked really crappy. All other options were just as bad or priced out of my range.

Back to basics, I figured, and set upon searching for Visio scripting options. This looked promising, so I dived in, not knowing the horrors that lie in wait under the slick facade of Visio. Bacically, the Visio backend is a huge spredsheet or collection of spreadsheets. Each item in Visio (Document, Page, Shape, etc.) is described by a "Property Sheet" that looks similar to a simple database or spreadsheet comprised of "Sections" (tables with untyped columns) and "Rows" containing "Cells". To spare you the gory details I'll just say that the loose typing of the cells (due to the API's VBA roots) doesn't jive with C# too well and so it was a bit of a pain to figure out how to get and set the property values.

After a couple of days of bashing away at this (and learning a bit of XPath along the way), I had something that actually drew a "map" of a subnet by connecting an Ethernet shape with Server, Switch, Router, etc. shapes nicely layed out in rows of n shapes. After figuring out how to bypass the VB vs. C# typing issues, getting the properties of each device (Hostname, MACAddress, OStype, Vendor, identified services, etc.) into the "Custom Properties" of each shape was a snap! I still need to figure out how to programmatically add overlay graphics ("Data Graphics") onto the device shapes, but with these manually added it's looking promising.

I'm running this post a bit long so I'll wrap up for now by publishing the first version of the thing to solicit comments, ideas and criticism.

I hope to someday refactor this into something that might be useful in the real world, but that will have to wait until I have a few days of downtime to spend again. 'Til then, the more feedback I get, the more inclined I'll be to actually make somthing of it. "I look forward to your letters..."

Cheers,

/olle