Welcome to In Depth Defense. In Depth Defense LLC is a privately owned Information Security Consulting company owned and operated by Mark Baggett. In Depth Defense specializes in Penetration Testing and Incident Response. At this time In Depth Defense is not accepting any new client work, but we are happy to speak to you and point you to other resources in the community.

Mark Baggett has been active in Information Security for 18+ years. I've served in a variety of roles from software developer to CISO. You can find archives of older blog entries below and read my newer posts on http://www.pauldotcom.com, http://isc.sans.edu and http://pen-testing.sans.org

Friday, September 19, 2008

Symantec Detects Symantec as virus

I love incidents caused by false positives in antivirus products. Its frustrating enough that they don't detect legitimate threats, but when they delete legitimate files its just a waste of time and energy.

Today I handled an incident where 10% of an organizations machines detected ESUGRemoteSvc.exe as a Trojan..

2008-09-19 17:13:48;2008-09-19 17:23:42;Real Time Scan;LOGGER_Real_Time;1;Virus found;Trojan Horse;1;"C:/WINDOWS/system32/ESUG/ESUGRemoteSvc.exe";Quarantined;

Fire up the IRT engine. Gather samples, run it in a isolated machine to watch it behavior, submit it to virustotal.com and Normans Sandbox, pull it apart with Immunity Debugger, but the thing looks legit. No machines are scanning the network or making TCP connections to an unusual number of hosts, but it appeared to be spreading. So what is this evil program? ITS SYMANTECS OWN ADMIN TOOL!!! ESUG stands for "Enterprise Support Utilities Group"

A call to Symantec confirmed it was a false positive. Thanks for the friday afternoon excitement.

Tuesday, September 2, 2008

PCI - The gaping hole in your IDS/IPS

I’ve come to learn PCI requires business leave their network unmonitored and open to attack!!!   Specifically  on page 4 item  #13 of this document.  

It reads:
13. Arrangements must be made to configure the intrusion detection  system/intrusion prevention system (IDS/
IPS) to accept the originating IP address of the ASV. If this is not possible, the scan should be originated in a location that prevents IDS/IPS interference.

I understand what the intention of this requirement is.  If your
IPS is blacklisting the scanner IP's then ASVs don't get a full assessment because they are a loud and proud scan rather than a targeted attack.    For example,  Lets say I have 1000 host on my network.   If during the assessment of host 1 of 1000 the IPS blocks the source IP of the scanner, then serious threats will remain undetected on hosts 2-1000 and portions of host 1.   An attacker who is not nearly as noisy as a scanner would not be blocked by the IPS and could exploit those undetected vulnerabilities.    This is a very legitimate problem and the PCI standard needs to be sure that IPS’s do not cause that.  However, blindly accepting the originating IP of the scanner leaves the hosts vulnerable to various attacks.   Attackers can simply reference various public websites to see what IP addresses they need to use to bypass those detective or preventive controls.   For example:


provides attackers with everything they need to launch
UDP based attacks against any site with the “HackerSafe” logo on it.   Those attacks will not be detected by the merchant and will not be blocked even though the IPS could have prevented the attack.   UDP based attacks are now enabled as a result of this requirement.  Various TCP based spoofing attacks may also be possible (such as NMAP IDLE scans).  Again the merchant is now blind to all of these attacks.   IPS/IDS’s are an important of a comprehensive defense strategy.   I am certainly a proponent of eliminating the vulnerabilities on the server and not relying on IPS’s to block the attacks.  However Defense in Depth is a staple of any good security program.

PCI does strongly encourages and in circumstances require the use of a Web Application firewall.   Today the lines between Web App Firewalls and IPS’s is a gray one in many circumstances.   For example, many IPS's such as McAfee IntruShield, TippingPoint and others does not do any IP blocking by default that would produce the undesirable affect I described above.  They do however drop specific attack packets that match a signature in the same way that Web App firewalls do.   IPSes will drop Cross Site Scripting, SQL  and traditional Web App attacks packets in the exact same way that a web app firewall does.   Further more, some web app firewall may do IP list blacklisting and present the undesired scan scenario described above.  For example the product:  http://www.port80software.com/products/serverdefender/artificialintelligence/    Lists the following on its feature list:

  - Block
IP for subsequent HTTP requests

With so much Web App Firewall functionality in boxes that have “
IPS” printed on the Appliance and IP blocking in Web App Firewalls I think the wording on that requirement needs to be addresses.

PCI may say something like "Just exclude the IP of the scanner during the scan and reenable the IPS when the scan isn't running."   The problem with that approach is that the required UDP exhaustive port scans make the scan very slow.   I have personally seen PCI scans for networks with 2000+ hosts take more than a week to complete.  Then add in time to fix any findings and rescan and large organizations end up with SIGNIFICANT windows of exposure.   In my discussions with various PCI scanning vendors I am told that the OVERWHELMING VAST MAJORITY of business simply exclude the IPS from their IDS/IPS and go about their business.   This is very dangerous indeed leaving them completely blind to attackers.

In summary,  I don’t believe that the wording of this requirement accurately reflects the
PCI Council’s intention.   I think that in practice it creates a significant unmonitored exposure for merchants.   I have attempted to contact the PCI counsel and see if they can address the exposure and risk to credit card data they are unintentionally creating with this requirement, but they are not interested in speaking with me.   But there is a beacon of hope.  As I was about to give up I received an email from David Taylor, founder of www.KnowPCI.com.   KnowPCI.com is a great forum to pose PCI questions to knowledgeable PCI professionals and get answers to questions.   Check out the site.  www.knowpci.com