Tag Archives: Emerging Threats

Some Potential DNS Poisoning Scenarios

Posted on by
Reply

We have kind of been breaking down the DNS cache poisoning exploit scenarios and have been dropping them into 3 different “piles”.

1) Massive poisoning attacks that would be used a denial of service style attack to attempt to “cut an organization off from the Internet” or at least key sites – the damage from this one could be low to medium and is obviously likely to be discovered fairly quickly, though tracking down the issue could be difficult for organizations without adequate technical support or on-site IT teams

2) Large scale attacks with malware intent – these would also be largely executed in an attempt to introduce malware into the organization, browser exploits, client-side exploits or forms of social engineering could be used to trick users into activating malware, likely these attempts would introduce bot-net agents into the organization giving attackers remote control of part or all of the environment

3) Surgical poisoning attacks – these attacks would be more focused and much more difficult to identify, in this case, the attackers would poison the cache of sites that they knew could be critical- this could be as obvious as the windows update sites or as focused as the banking sites or stock trade sites of executives, this attack platform is likely to be focused on specific effects and will likely be combined with social engineering to get insight into the specifics of the target

There certainly may be a myriad of additional scenarios or specific focus points for the attacks, but we wanted to give some examples so that folks can be aware of where attackers may go with their new toys and techniques.

Doing incident response and forensics on these attacks could be difficult depending on the levels of the cache time to live and logging that is done on the DNS systems. Now might be a good time to review both of these variables to make sure they will be adequate to examine any attack patterns should they be discovered now, or in the future from this or any other poisoning attack vector.

As we stated earlier, please do not rely on the idea that recursion is only available from internal systems as a defense. That might help protect you from the “click and drool” exploits, but WILL NOT PROTECT YOU from determined, capable attackers!

Myriad of Ways to Trigger Internal DNS Recursion – Please Patch Now!

Posted on by
Reply

For those organizations who have decided not to patch their DNS servers because they feel protected by implemented controls that only allow recursion from internal systems, we just wanted to point out that there a number of ways that an attacker can cause a recursive query to be performed by an “internal” host.

Here is just a short list of things that an attacker could do to cause internal DNS recursion to occur:

Send an email with an embedded graphic from the site that they want to poison your cache for, which will cause your DNS to do a lookup for that domain if it is not already known by your DNS

Send an email to a mail server that does reverse lookups on the sender domain (would moving your reverse lookup rule down in the rule stack of email filters help minimize this possibility???)

Embed web content on pages that your users visit that would trigger a lookup

Trick users through social engineering into visiting a web site or the like

Use a bot-net (or other malware) controlled system in your environment to do the lookup themselves (they could also use this mechanism to perform “internal” cache poisoning attacks)

The key point here is that many organizations believe that the fact that they don’t allow recursion from external hosts makes them invulnerable to the exploits now circulating in the wild for the DNS issue at hand. While they may be resilient to the “click and drool” hacks, they are far more vulnerable than they believe to a knowledgeable, focused, resourced attacker who might be focused on their environment.

The bottom line solution, in case you are not aware, is to PATCH YOUR DNS SYSTEMS NOW IF THEY ARE NOT PATCHED ALREADY.

Please, do not wait, active and wide scale exploitation is very likely in the very near future, if it is not underway right now!

DNS Exploit is in the Wild – Patch NOW!!!

Posted on by
Reply

Unfortunately, the blackout period for the DNS issues has been broken. The exploit details have been made public and have been in the wild for a number of hours. While the security researchers involved have tried to remove the details and analysis, Google had already cached the site and the details are now widely known.

Please patch IMMEDIATELY if you have not already done so!

If you can not patch your existing DNS product, please switch to a patched public DNS (for Internet resolution) or deploy OPENDNS as soon as possible.

Here is a quick and dirty plan of action:

1. Catalog the DHCP Servers you use on the Internet and internally. Be sure you check all branch locations, firewalls and DHCP servers to ensure that you have a complete picture. If you find any Internet facing DNS with recursive enabled, disable it ASAP!

2. Verify that each of these DNS implementations are patched or not vulnerable. You can check vulnerability by using the “Check DNS” tool at Mr. Kaminski’s page, here.

3. Test the patch and get it implemented as quickly as possible.

4. Note that you may have to upgrade firmware and software for firewalls, packet filters and other security controls to enable them to understand the new DNS operations and keep them from interfering with the new way that DNS “acts”.

Please note that the exploit for this cache poisoning attack in now public and exploitation on a wide scale could already be underway. PATCH AS SOON AS POSSIBLE!

Symptoms to look for include:

Vulnerability: unpatched and non-random source ports for DNS query responses.

Exploit: check for a large number of non-existent subdomains in your DNS records (or subdomain requests in your logs) if you are an authoritative DNS for a domain, attackers will be poisoning the cache with subdomain records at least according to some researchers.

If you have questions or concerns, please contact MSI for more information or assistance.
Updates to our DNS paper and other details will be released soon, so check back with stateofsecurity.com for updates.

DNS Patches May Break Some Things…

Posted on by
Reply

I just had a quick conversation with an IT technician who alluded to the idea that more than Zone Alarm may be broken by the new port randomization behaviors of “patched DNS”. These fundamental changes to the ports allocated for DNS traffic may confuse existing firewalls and other filtering devices that are unaware of the changes to DNS behaviors.

For example, if you have filtering devices that specific port ranges defined for egress or ingress of DNS traffic, especially if you are using a non-stateful device, this configuration may need to be changed to allow for the greater port range applied to the “patched DNS” setup. Systems that are also “DNS aware” might not expect the randomization of the ports that the patching is creating. As such, filtering devices, especially at the perimeter may well need to be reconfigured or upgraded as well to allow for continued operation of unimpeded DNS traffic.

There may be SEVERAL other nuances that become evident in some environments as the patch process for the DNS issue continues to evolve. Stay tuned to stateofsecurity.com and other security venues for information and guidance as it becomes available.

More on DNS Security Issue Management – Know & Control DNS + SOHO Issues

Posted on by
Reply

Just added this to Revision 2 of the whitepaper:

Attack Vector Management

Part of mitigating the risk of this security issue is also managing the availability of the attack vector. In this case, it is essential that security teams understand how DNS resolution operates in their environment. DNS resolution must be controlled to the greatest extent possible. That means that all servers and workstations MUST be configured to use a set of known, trusted and approved DNS servers whenever possible. In addition, proper egress filtering should be implemented to prevent external DNS resolution and contact with port 53 on unknown systems. Without control over desktop and server DNS use, the attack vector available for exploitation becomes unmanageably large. Upper management must support the adoption of these controls in order to prevent compromise as this and other DNS vulnerabilities evolve.

Home User and Small Office Vulnerability

Home users and small offices (or enclaves within larger organizations) should pay careful attention to how their DNS resolution takes place. Many home and small business firewall devices such as Linksys, D-Link, Netgear, etc. are likely to be vulnerable to these attacks and are quite UNLIKELY to be patched to current firmware levels. Efforts must be made to educate home and small office users about this issue and to update all of these devices as the patches and upgrades to their firmware becomes available.

DNS Security Issue Overview & Mitigation Whitepaper

Posted on by
Reply

Our engineering team has analyzed the available data on this emerging security issue and the fixes identified. As such, we have prepared the following white paper for our clients and readers.

Please review the paper and feel free to distribute it to your management team, co-workers and others who need to be involved in understanding and remediating the problems emerging with DNS.

You can obtain the white paper here.

If your organization needs any assistance in understanding or managing this vulnerability, please do not hesitate to contact us. We would be happy to assist in any way possible.

Project Pre-Release – Vulnerabilities in Popular Content Management Systems Under Study

Posted on by
Reply

Over the next few weeks you will see more details from us about a project that we have been working on. As a part of our relationship with Syhunt, one of our elite partners for application security work, we have been testing and reviewing their new tool, Sandcat4PHP. The tool is a sophisticated and user friendly source code scanner for performing deep analysis of PHP applications including their surrounding javascript and HTML components.

Stay posted here for a pretty in-depth review of the new tool, its use and capabilities. We will be doing that review as a part of the project as well.

First, let me start with the purpose and the scope of the project. In the last few months we have worked with a number of clients who have had issues with the security of their content management system. More than a few of them are using popular products, but several are using proprietary tools as well. As such, we have worked on a few incidents and application reviews. That led to a pretty in-depth discussion between a couple of clients and ourselves about the state of content management system security, in general. As an off shoot of that discussion, we decided to test 5 of the most popular content managers using the new Syhunt PHP scanner, since we needed to review it anyway.

Next, we obtained a couple of lists of popular content managers. Selecting our five was pretty easy and we settled on the following:

WordPress, Joomla!, Mambo, Drupal and BitWeaver

We then downloaded the current versions of the CMS (as of that day, a couple of weeks ago…) and set up our testing environment.

We assessed the entire package, but only as downloaded from the web site. That means in most cases, that we tested only the core components and not any additional modules, plugins or components. We considered whatever was in the default download to be the basis for our work.

To date, we have begun our assessments and review of the CMS tools. We will be in contact with each of the CMS projects about the findings of the assessments and they will receive the details of the tool’s findings prior to public release of the technical details. Statistical and numeric data will also be forthcoming.

For now just let us say that we are evaluating our findings and that the tool performed very very well.

I look forward to sharing the details with everyone in the coming days.

Let me know if you have any questions about the product, the project or the work.

Increases in PHP Scanning

Posted on by
Reply

We are detecting increasing PHP scans for a series of known PHP vulnerabilities that thus far are originating from Asia.

To date, we see no new attacks, just checks for known bad pages, particularly admin interfaces and a couple of quick URLs to test for command injections. The scans seem to have begun in the last 24 hours and the traffic appears to be related to a possible new PHP scanner. Likely, some new tool has been released that contains a plethora of PHP vulnerabilities.

Organizations should ensure that any systems offering PHP or PHP applications have been properly assessed and patched.

HoneyPoint Security Server users are urged to deploy a web HoneyPoint or HornetPoint and to drop the hosts performing the scans into your firewall or router black hole lists. This should allow you to create a “one strike and you’re out” approach for black holing attacking systems.

Please let us know if you see any new PHP activity. We are currently watching this pattern for any zero-day type activity, but thus far, we have observed only known security issues. being probed.

Snort Issues In Case You Missed Them and Malicious SWF

Posted on by
Reply

In case you missed it last week, Snort seems to be suffering from a problem with odd TTL values, which could allow an attack to get by Snort without detection. 2.8.1 has been released and includes the fix for the issue. Users of Snort should upgrade as soon as possible or apply the following workaround until they can update:

/From iDefense/

In the snort.conf file, set the ttl_limit configuration value to 255 as shown below.

preprocessor frag3_engine: ttl_limit 255

This will set the allowable difference to the maximum possible value, and prevent fragments from being dropped.

/End iDefense Content/

Also, SANS is talking about malicious SWF files that have been found online. Looks like they are using some encoded images that can cause some issues with what may be a previously known flash player vulnerability. Advise your users to be wary of flash enabled sites that they would consider “untrusted”. Of course, your milage may vary with this one, but at least awareness might help….

Lastly, as refresher, if you are a Notes/Domino user, it might be a good idea to check out patches that have been released lately. There have been a number of issues in the last few weeks and we are seeing an increase in Domino fingerprinting on some of our non-US HoneyPoints. Looks like quick scans for names.nsf and a couple of other common Notes files. So far though, we have not seen any attacker activity out of the norm, but it may be the precursor to an attack or other activity. Just an FYI…

Fear Renewed: The Cisco Router Rootkit

Posted on by
Reply

The media is all abuzz about a possible Cisco router rootkit that may be part of a presentation at a near future security conference.

While various issues with Cisco gear have emerged over the years and there has been at least one really public overreaction on the part of Cisco to vulnerability disclosure talks, there is probably little to really get spun up about here for the average corporate manager or infosec person.

The big news is that hostile, difficult to detect code could be introduced to routers at any point in their lifespan if an attacker has access to introduce images onto the router. This is a common problem with almost every type of device. There have been a number of trojan horse loads for everything from home firewalls to other forms of network gear for a number of years. Sure, the Cisco router is almost ubiquitous, and sure, it powers a lot of the Internet at large, but I think we pretty much always assumed that attackers with physical access and opportunity could introduce bad things to a device if they gained opportunity.

So before you give in to the hype or fear mongering, consider how this is different than any other form of software/firmware or the like. Likely, you already have a process in place for blowing new firmware onto all devices you purchase before putting them into use (right???). If not, it might be time to think about writing one…