• Xerocole’s link: Xerocole Partners with Damballa for Botnet Detection on Carrier Networks
• Damballa’s link: Damballa Enhances Cyber Threat Protection for Telecommunications and Internet Service Providers

The Xerocole-Damballa partnership is another evolution of a security technique where the DNS recursive resolver is used as a “DNS Firewall” – keeping devices from going to known “bad sites.” Why is a DNS Firewall important for all network enterprises? Let look at a typical story …..

A typical story …..

Imaging walking in to work the first thing in the morning. Your staff comes into the office. They get their coffee, fire up their computer, and check out the morning industry news. Your staff is alert, applies all the patches sent to keep the computers up to date, insures the anti-virus updates are installed, and follows all the “safe browsing” recommendation. In essence, an ideal “security mindful” workforce. Yet, later that day you receive an E-mail report from one of the third party malware systems you use to keep an “outside in” view of your network. This third party reports 25 systems in your network communicating with a BOTNET command and control system. These are new infections. You take this information, match it against the firewall/NAT logs, and then trace back the DHCP leases to the people who have been violated with malware. All the systems are pulled from the network and examined.  This is what your INFOSEC Team finds:

• All the systems were infected with the same malware.
• All the systems were up to date with all the relevant system patches.
• All the systems were using the latest anti-virus patch.
• All the users of the systems were reading a popular tech site – catching up with the latest news.
• Further research shows that a “malvertisement” was uses on this popular tech site. This malvertisement would have the computer do a DNS lookup to a drive-by malware site, pull down the graphic, and start a “conversation.” That “conversation” would not be noticed by the user.  The only thing they would notice is the “advertisement” graphic. They would not see the “drive-by” site infecting the computer with malware through a zero-day exploit unknown to the community.
• Continued investigation uncovered all the domain names used for the exploit. All of the domain names were black listed at SPAMHAUS, SURBL, and other core black list providers. They were in the black list for over a month.

Bottom-Line: Your staff took every security precaution and still got infected! The infection was quickly caught (thanks to public benefit “outside in” – 3rd party monitoring). Yet, the lost time, productivity, and cost (hard drives being replaced) is not what your organization needs.

The situation described above is based on a true story. It is a very common story encountered by network throughout the world – with one modification. Most organizations do not monitor their network with 3rd party security tools – meaning their users get infected and the organization does not know it. Organizations are getting hit with malware for which there is no effective defense. Yet, the techniques used to get this malware onto your team’s computer all depend on the Domain Name System (DNS).

What if there was a way to us the DNS infrastructure for something more that an address to name translation tool? What if there was a way to use your DNS infrastructure to keep your staff’s computers from being pulled to malware-metasploit sites – returning an alarm to let everyone know you have some cyber-criminal trying “phish,” spam, or malvertize into your network?

DNS as a Security Tool – DNS Firewalls

The vast majority of DNS Resolvers perform its one core function – taking a unique domain name and resolved queries for these names into IPv4/IPv6 addresses for the purpose of locating computer services and devices worldwide. This is why DNS is Internet critical. Every device is dependent on a DNS Resolver for normal Internet functioning – creating a critical dependency and choke point. This choke point is one of the reasons why DNS is an attractive policy enforcement point – preventing the resolution to domains which have been identified with miscreant activity.

Imagine your network’s DNS recursive resolver checking on a list of bad/suspect domain names before it completes the resolution. If the domain name is in that “black list,” it would return a response that warns the user – preventing the computer from going to a site that might try to “drive-by exploit” without the user’s knowledge. This would prevent devices from getting IP addresses to suspect sites – minimizing the chance of infection. The DNS servers would become a “DNS Firewall,” protecting customers before there was a chance of infection.

Now, the industry has been using DNS lookups as a tool to check black list for anti-spam activities.  The principle of using DNS as a security enhancement tool is not novel or new. In fact, one of the first organizations to put serious effort into using the “DNS Firewall” principle as a tool to protect customers was Simplicita (now Xerocole) in 2005 (Xerocole – www.xerocole.com was originally Simplicita – which got bought by Sandvine, then spun back out in 2011 as Xerocole).  They developed a system that would take in multiple black list feeds from sources as diverse as Spamhaus, Team CYMRU, and Shadowserver. These black lists would be pulled into their Reputation Knowledge System (RKS). This list would then be used by the DNS Recursive Resolver (Xerocole’s eXtensible DNS Resolver (XDR)) to check if a domain is good or bad. When a device asked the XDR for a DNS resolution, it would check the black list and if there is a match to respond with the appropriate action.

In 2005, the new innovation was the use of the DNS Resolver as the enforcement point – checking to see if a domain was in the black list first – and if it was in the black list, taking policy action to protect the user. But, once Simplicita was acquired, the solution “disappeared” from common view. Only a few in the industry knew of their DNS Firewall capabilities. OpenDNS – who in 2006 started anti-phishing capabilities to protect their customers. But OpenDNS’s solution would have a network “outsource” the resolver functionality to the “Cloud.” Depending on the Cloud DNS works well as long as  the connection to the Internet keeps working. If the connection goes down, all DNS resolution capability stops – including resolution to local resources inside the enterprise.  Other DNS vendors explored DNS Firewll capabilities. For example, Nomimum created something similar in 2010 with their Network Protection Service (NPS). Endgame System – a small start up also created a “DNS Firewall” capabilities in 2010. Neither of these solutions gain market traction. It wasn’t until 2011 that two events resuscitated the function of a DNS Firewall – Xerocole spinning out of Sandvines and ISC’s create of the DNS Response Policy Zone (RPZ).

DNS Response Policy Zone

In 2010, the Internet Systems Consortium (ISC) added a new code to BIND’s resolver to allow it to be used as a DNS Firewall. Vernon Schryver and Paul Vixie created a technique that would use the existing Authoritative Transfer (AXFR) and Incremental Zone Transfer (IXFR) zone transfer techniques to push a “DNS Black List” zone into the DNS Resolver. This Response Policy Zone (RPZ) solves a fundamental problem with distributing DNS Black list . It is a open specification and capable of being used in any DNS implementation (or other security devices which will use the list).  DNS RPZ enables DNS reputation data producers and consumers to cooperate in in real time – coupling the new abilities to track cyber-criminal activity via DNS and then push that updated list to DNS Firewalls spread throughout the Internet. In essence, DNS RPZ turns the recursive DNS server into a security hammer … provide the same capabilities of an anti-spam DNSBL (DNS Block List, ne RBL) and RHSBL (Right Hand Side Block List)…. … with greater degrees of scaling and speed.

The following figures provide a walk through for how DNS RPZ works to rapidly push out standard and updated black list to devices who have their DNS resolvers configured for DNS RPZ:

Integrated DNS RPZ as open source in BIND 9.8.1. This provides all DNS implementations a reference to see how they would integrate RPZ into their code. ISC is posting a collection of Knowledge Base articles here: Building DNS Firewalls with Response Policy Zones (RPZ).

There are currently three known RPZ black list providers: SPAMHAUS, SURBL, and Internet Identity. Work continues to encourage more organizations to use DNS RPZ to distribute their black list.

• http://www.spamhaus.org/news/article/669/spamhaus-dbl-as-a-response-policy-zone
• http://www.surbl.org/
• http://www.internetidentity.com

What is needed to push this DNS Firewall deployment forward?

Today, network operators have an open source solution (BIND), a commercial solution (Xerocole), and over the top DNS solutions (OpenDNS). DNS Firewalls do work. They prevent users from getting infected. If the solution works, why are there poor adoption? First, the vast majority of CIOs and CISOs do not view their DNS resolvers are “security tools.” So the concept is new and not top of mind. Second, there are many firewall and deep packet inspection (DPI) companies who get top of mind influence with these CIOs/CISOs – drowning out the small marketing effort to advertise the capabilities of DNS Firewalling. Finally, the persistent and loud marketing to push out the capabilities of DNS Firewall capabilities have been weak. OpenDNS has had the most successful outreach over the past year. Over all, DNS Firewall – using the existing DNS infrastructure as part of comprehensive security defense – needs more effective outreach (hence this article).

What can you do to help the effort? Start using a DNS Firewall – Start with BIND

Step 1 – Pull down the papers and materials on DNS Firewalls.

Step 2 – Deploy a BIND Based DNS RPZ Resolver instance in your network. You can select which computers use the DNS RPZ configured resolver. All three DNS RPZ providers provide trial RPZ feeds to test the technology.

Step 3 – Select the DNS Firewall solution that best fits for your organization. Be it a commercial solution like Xerocole, an open source solution like BIND, or a Cloud solution like OpenDNS, DNS Firewall is a tool that will protect your users while “taking back DNS” from the criminals.

15 Aug 2012 — ripe ncc

As reported in previous announcements, the RIPE NCC will go to court in the Netherlands on 29 November 2012 to seek clarification on the procedure taken by the Dutch police on 8 November 2011 when it presented the RIPE NCC with a police order to “lock” registrations in the RIPE Database.

For background on this story, see: Summons of the RIPE NCC Against the State of the Netherlands.



After receiving independent legal advice that the police order had no sufficient legal grounds to force the RIPE NCC to execute the order, the RIPE NCC unlocked the blocks of IPv4 address space on 10 January 2012. We’d like to give you an update on the current situation.

Two of the four address blocks included in the police order (93.188.160.0/21 and 85.255.112/20) were reallocated after the contractual relationship with the member holding the address space was terminated. The member’s account was closed and the space was deregistered according to ripe-541, “Closure of LIR and Deregistration of Internet Number Resources”. The address space was quarantined for six weeks before being returned to the RIPE NCC’s available pool of IPv4 address space. It was then randomly reallocated to a new resource holder according to normal allocation procedures.

As the RIPE NCC nears IPv4 exhaustion, it will reduce the quarantine period of returned address space accordingly to ensure that there is no more IPv4 address space available before the last /8 is reached. The  RIPE NCC recognises that this shortened quarantine could lead to routability problems and offers its members assistance to reduce this.

As mentioned in my previous blog, the general behind the scenes reaction is surprise. This statement by RIPE has not helped the situation. In fact, it might have made it worse given what RIPE has communicated in this statement.

First, we understand RIPE’s leadership has issues with the court order – a court order RIPE specifically requested from the law enforcement agencies involved with the Rove Digital/DNS Changer operation. RIPE needed a court order through the Dutch courts to take action. RIPE’s issue is reflected on this page: Summons of the RIPE NCC Against the State of the Netherlands. RIPE does have legitimate issues with the use of “seizure” and how the court order was phased. This is no surprise and expected. Legal dialog of this nature is how the world legal system progresses.

Second, everyone involved with the DNS Changer Working Group failed to read between the lines of RIPE’s announcement on 10 Jan 2012 where they would unlock the prefixed used for this criminal operation and then “reallocated the resources.” The people who missed this ranges from law enforcement in several countries, to some of the worlds best National CSIRT Teams (see www.first.org for a list), to the top security vendors, to key security researchers, to network vendors, and to many of the largest service providers in the industry (most of whom are RIPE members).  The details of the “unlocking” is here: RIPE NCC Unlocks Registration in RIPE Registry.  This “miss” was bad news for everyone working to protect the people victimized by DNS Changer. The community “should have noticed” the RIPE announcement and then understand the dangers of reallocation (which includes myself – as one of the active DCWG members).

Finally, where is RIPE’s accountability? The fact that RIPE took NO ACTION to notify anyone in the DCWG community that “unlocking” really means RIPE is activating the “deregistration” policies in document RIPE-541, “Closure of LIR and Deregistration of Internet Number Resources.” RIPE’s leadership and staff knows many of the people in DCWG. Many of the DCWG participants are RIPE members. It would have been simple for RIPE to communicate officially or un-officially that they were moving beyond unlocking to using RIPE 541 to re-allocated.

Given the number of organizations within the RIPE community who participated in the DNS Changer clean up, it can only be assumed that RIPE intentionally decided to NOT communicate. There was on-going dialog between members of the DCWG and ARIN/RIPE leadership to find ways to responsibly mange all IPv4 blocked involved with the Rove Digital/DNS Changer activity. At no time was it communicated from RIPE to their membership who were part of DCWG that contractual relationship for 93.188.160.0/21 and 85.255.112/20 ended and that these would then be put back into the allocation pool. RIPE could have clued in the community when the contract ended. RIPE could have clued in the community when the addresses went back into the allocation pool’s quarantine period. RIPE could have communicated when the addresses were live in the allocation pool.

The surprise expressed by the community was that RIPE’s actions indicate mindful intent to not communicate.

What should you do?

If you are a operator in the RIPE community, and LIR, or a National CSIRT in the RIPE Community, please ask RIPE why they mindfully choose the path of non-cooperation. This choice will have an impact on future work against cyber-crime. Many of the DCWG participants know about RIR policies and procedures. They understand checks, balances, and limitations crafted in those policies and procedures to protect the interest of the Internet and the RIR constituents. Everyone would understand if RIPE’s leadership communicated “hey, contract is over, our hands are tied, RIPE doc 541 says we need to reallocate.” This is not what happened.

The fact that RIPE’s leadership mindfully choose a path of non-cooperation with their peers and members is a worry all RIPE constituents should take note.

Individuals and RIPE members can contact RIPE at https://www.ripe.net/contact.

http://www.ris.ripe.net/cgi-bin/lg/index.cgi?rrc=RRC001&query=1&arg=85.255.112.0%2F20

http://www.ris.ripe.net/dashboard/85.255.112.0/20

As a reminder, the Rove Digital/DNS Changer Crew used the following IP address blocks for their nefarious activities:

85.255.112.0/20

67.210.0.0/20

93.188.160.0/21

77.67.83.0/24

213.109.64.0/20

64.28.176.0/20

From November 9^th, 2011  until July 9^th, 2012, the DNS Changer Working Group with the FBI hosted clean DNS servers to help victims clean up their systems. On July 9^th, 2012, these servers were shut down and the IP blocks were removed from the global routing table.

It was assumed that these blocks would remain in limbo until all the court proceedings were completed. The “assumption” was not correct. Alarms that many service providers and security professionals put in place to watch for miscreant “hijacking” of these IP address block were triggered early on Friday. What was a surprise was that these blocks were not “hijacked,” but re-allocated.

85.255.112.0/20 was previously Promnet Ltd but has now been reallocated to INEVO-NET (see http://bgp.he.net/AS56831)

93.188.160.0/21 was was previously Promnet Ltd but has now been reallocated to LT-HOSTING

Of course this could be a false alarm. When you take the existing INEVO-Net block and look for miscreant activities, we find the following:

• Google Safe Browsing Check for AS56831
• ZeuS Tracker :: AS56831 (INEVO Inevo Labs SRL)
• SpyEye Tracker :: AS56831 (INEVO Inevo Labs SRL)

While not a detailed analysis of AS 56831’s cleanliness, the quick check calms some fears. Still until all the details are in, operators should treat the network with suspicion.

Why is this a problem?

DNS Changer was not the only malicious activities inside these Netfblocks. Who ever controls these netblocks can hijack computers that are still infected with DNS Changer and other malware. The way these netblocks are reallocated and surprise at the speed of the reallocation exacerbates the concern. This move by RIPE surprised many in the security industry, law enforcement, and participants of the DCWG. Given the surprise, network operators should be very cautious with any traffic to/from these netblocks.

What should you do to protect your network and your customers?

First, monitor traffic to and from these netblocks. If you do not have the resources, then consider filtering all traffic to and from these netblocks until you receive the all clear.

How would you filter

• Access – List on your gateway router is perhaps the quickest and most effective way to block traffic.
• “Default Free” Multi-homed Networks can filter incoming prefixes so that traffic from your network cannot reach these netblocks.
• Multi-homed Networks can insert a black hole BGP prefix to insure traffic from your network cannot reach these netblocks.
• The Emerging Threat Open Source Firewall filters still work: http://doc.emergingthreats.net/bin/view/Main/WebSearch?search=DNSChanger
• DNS Resolvers can be set up to block DNS request going to these netblocks. ISC has a Knowledge Bulletin (KB) to explain how to use BIND to create a DNS Firewall: https://kb.isc.org/article/AA-00525/0/Building-DNS-Firewalls-with-Response-Policy-Zones-RPZ.html
• Check with your Firewall vendor. They might have a filter reach to load.

Complements and Kudos to my peers in several security groups who had the alarms set up and watching for any chances to the DNS Changer netblocks. It is hard to hide on the Internet.

 “We are aware of the media reports on security vulnerabilities in some small Huawei routers and are verifying these claims. Huawei adopts rigorous security strategies and policies to protect the network security of our customers and abides by industry standards and best practices in security risk and incident management. Huawei has established a robust response system to address product security gaps and vulnerabilities, working with our customers to immediately develop contingency plans for all identified security risks, and to resolve any incidents in the shortest possible time. In the interests of customer security, Huawei also calls on the industry to promptly report all product security risks to the solutions provider so that the vendor’s CERT team can work with the relevant parties to develop a solution and roll-out schedule.” – Huawei’s US PR Statement

Major Note: A Press statement is NOT an effective vehicle to restore confidence when someone finds a vulnerability with the product. Especially when the press release provides contradictory information. The press statement says to use psirt@huawei.com vs the NSIRT@huawei.com.

Who’s responsible for Huawei’s handling of the vulnerabilities disclosed at DEFCON? All would agree Huawei is the accountable party for vulnerabilities discovered in their products. Huawei has to have clear and effective vulnerability disclosure processes that allows for any organizations to know the following:

• Who to contact if you find a vulnerability in the product? (E-mails, phone numbers, and PGP keys)
• What will be done once the vulnerability is reported? (saying we’ll investigate is not enough in this environment of rampant cyber-crime and open cyber-warfare)
• How will information about the vulnerability be disclosed? (Public pages or private customer only pages work – but the policy needs to be public.)

The normal practice is for organization to have a “/security page” that contains this information. For example, www.microsoft.com/security, www.cisco.com/security, and www.yahoo.com/security point to pages that list the basic three requirements plus more specifics that apply to the organization’s unique characteristics. If Felix Lindner (also known as “FX”) and Gregor Kopf found a vulnerability on Microsoft, Cisco, or Yahoo resources, they would know who to contact, what to expect when they contact the security teams, and be able to point to the organization’s vulnerability disclosure process. With Huawei, none of this existed. It is an issue with Huawei, but it is also an issue with every service provider who buys equipment from Huawei.

I would assert that Huawei’s customers shares accountability for Huawei’s laze-fare vulnerability management. The service providers who evaluate, select, and deploy vendor’s equipment in their network are accountable for their network. These SPs depend on their vendors to do their part to assure resiliency and security in their network. But, these same SPs are the accountable to their customers – customers who depend on critical communications. The SPs cannot afford lame security approaches from their vendors. It is incumbent for the security team of a SPs to insure a major vendor (Huawei in this case) has the processes and procedures they require to safe guard their network. Vendor non-compliance means that many SPs are ignoring security in their network.

This is an easy problem to fix. Economics and purchasing power are the most powerful drivers for security improvements in the private industry. Huawei’s customers have a unique relationship – requiring Huawei provide the essentials of security vulnerability management which match the SP’s satisfaction.

As mentioned in the SP Security Workshops, every service provider must have the following information from each of their vendors:

• Public “Security” Page that list the 7*24 hour security contact for the vendor that includes their vulnerability process and disclosure procedures
• Clear and rational policy to update your software which is deemed vulnerable.
• Commitment from the vendor to actively participate in the industry wide security practices and organizations. For example, is the vendor part of www.first.org?
• Does the vendor use the Common Vulnerability Scoring System (CVSS) in their Security Advisories?
• Does the vendor use the Common Vulnerability Enumeration (CVE) in their vulnerability processes?
• Does the vendor write their security advisories in format that are useable by the service provider?

Network Operators – please add these to the requirement for purchase (RFP). Imaging the impact if every service provider includes these and other “vendor expectations for vulnerability management” to their RFPs.  If you like this “RFP” approach, please review the International Organization for Standardization (ISO) work on responsible vulnerability disclosure. FIRST is working with the ISO working groups and has a good summary page here: http://www.first.org/vendor-sig/iso_activities

Recommended Service Provider Action:  Pull from the FIRST, ISO, and other work to build your own RFP vulnerability disclosure requirements. All owners of network infrastructure have a role to pressure the industry to do their best to deliver secure code. The RFP power does impact behavior – setting expectations that produce results.

Their updated presentation is posted here: http://www.phenoelit.org/stuff/Huawei_DEFCON_XX.pdf (please download & review the findings)

Their methodology and approach to finding vulnerabilities is not new. The approach has effectively work to influence other router vendors, with their findings useful to building more resilient code (based on my personal experience working @ a couple of vendors for whom FX has done previous investigations). Service Providers and Equipment Vendors should have ways to work with this segment of the industry – commissioning vulnerability research and then responding to their findings. The fact that Huawei does not is a concern for everyone in the industry (more in the next blog).

The “Real” Direct Risk: The real direct risk has been overlooked since the FX & Gregor’s DEFCON talk. Namely the Huawei AR18 and AR28 routers are exploitable. These exploits pose two major threats. First, companies that use these routers are vulnerable to having these routers violated and then used as a launch pad for further penetration (think the first step in a Advanced Persistent Threat – APT attack). Second, violated routers are extremely valuable to cyber-criminals who use them as part of their SPAM, Phishing, DDOS for hire, and other criminal operations. These groups constantly scan the Internet looking for routers that could be easily hacked. It is logical for these miscreants to add the Huawei AR18 and AR28 routers to their scans.

Recommended Action to the Direct Risk:

1. Contact your Huawei reseller or Huawei directly if your organization has Huawei AR18 and AR28 routers in their network. Ask for the security advisory with the work arounds, risk assessment (preferably with the CVSS base score), and status when the updates will be distributed. Huawei Network Security Incident Response Team (Huawei NSIRT ) can be contacted through the information provided at FIRST – http://www.first.org/members/teams/huawei_nsirt.
2. Monitor for increase scans on routers, switches, and other network devices. This can be done with access-list on routers sending “deny” hits to syslog then processing all of the syslog to get a reading of “the volume of scanning interest.” Monitoring scans is a best common practice for network security. For examples, check out Shadowserver’s reports: http://www.shadowserver.org/wiki/pmwiki.php/Stats/ScanCharts and Dshield’s system – http://www.dshield.org/. Medium to large networks who do not have the time to set up their own “scan log processing” can use Dshield’s services. They will anonymize details, process the logs, and display the details in a portal.

The Real In-Direst Risk: The facts presented by FX and Gregor on the quality of the code added to Huawei’s response can lead people to believe similar problems exist in other Huawei products. Lazy coding is never an isolated incident. The engineering environment that allows for poor code quality will span different product teams. If there are problems in AR18 and AR28 routers, then there might be problems in all of the other routers. This ambiguity is normally mitigated with aggressive communications between the vendor (Huawei in this case) and the network operator. Security advisories, special briefings, and updates are used to communicate action, concern, and commitment – that are all required to maintain confidence. Huawei is not doing any of this, increasing the concerns and destroying confidence.

The service provider and network operator have limited options to regain confidence. Most cannot afford to pull out Huawei gear from their network. So they can try the following:

1. Contact the local Huawei account manager – ask for the updated Security Advisory.
2. Request a briefing on Huawei’s vulnerability disclosure processes. For reference, other major vendors provide these briefings. Cisco, Microsoft, Juniper, Oracle, and others all provide updates to their customers. There will always be vulnerabilities – the question is what will be done to mitigate the threat and restore confidence.
3. Commission Testing of Huawei equipment. This can range from having engineers in the network’s lab to do their own testing to paying for teams to “break into” the router. If/when vulnerabilities are found; they should be reported to Huawei or a local CSIRT Team.

Bottom Line – This should not be a big issue! FX and Gregor should have done their work, contacted the security team at Huawei, Huawei would then validate the findings and prepare their response plan. When FX and Gregor presented at DEFCON, Huawei would have then posted their security advisory. In fact, FX and Gregor would most likely have provided the pointer to the security advisory in their presentation. None of this happened. In fact, FX reached out to the operational security community of network operators to try to contact Huawei at the last minute before the DEFCON talk. What was amazing was that service providers with Huawei gear in their network did not know the product security contact.

During last week’s FCC CSRIC III meeting, several people called on operators to deploy “BCP 38.” This IETF best common practice (BCP) is packet filter placed on the edge of networks to insure that the IP source cannot pretend to be some other network (i.e. spoofing some other network). The general assumption is that IP spoofing is use for bad activities on the Internet. It is common to have someone speak at a security meeting and state that the lack of BCP 38 deployment is a big problem. The common assertion is that most providers do not deploy BCP 38 in their network. That perception is not correct any more. It now appears that most providers do deploy some type of BCP 38 packet filtering.

The MIT ANA Spoofer Project has updated their stats (see figure). The updated data illustrates what some have suspected – over 80% of the Internet cannot be used to send spoofed IP packets. In other words, we have now reached the infamous 80/20 ratio!

What does this mean? First, the Spoofer Project’s data illustrates measurable results. 80% deployment is a tremendous success that cannot be over looked. Second, the 80% deployment eliminates the hope that there is an easy solution to spoofed DDOS attacks. The mantra that we hear at many security meetings which says “we would not have these security problems if people deploy BCP 38” cannot be used anymore. Finally, the last 20% of the Internet not doing BCP 38 will prove to be the most difficult. While the efforts to deploy BCP 38 will continue, no one can count on success. In fact, we’ll need new solutions to mitigate spoofed attached that use this last 20%.

Will the last 20% be used for Spoofed Attacks?

The last 20% of the spoofable Internet is used daily to attack networks. Most of these attacks are in the form of DNS Applications attacks. Malware writers can the same techniques seen in the MIT ANA Spoofer Project to have their BOTNETs test if a network is “spoofable.” The BOT Herder infecting the computers can use this “spoof check” to groom the BOTNET into one that is specialized for sending spoofed packets. While it is not know if this specific capabilities exist today, coding it in malware is a logical next step in malware evolution. Given this, we can conclude that spoofed IP attacks are going to be around for the foreseeable future.

How did the Internet reach the 80% BCP 38 deployment?

RFC 2827/ BCP 38 – “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing – has one core principle – people cannot pretend to be from someone else’s IP address. The industry enforces this packet filter policy four major approaches:

• Static Packet Filters. These are manually maintained and/or configured from the SP’s provisioning system. The packet filter insures the only source packets allowed are from those IP addresses allocated by the upstream network. The vast majority of network gear supports this capability.
• Dynamic Packet Filters. Technology from the Broadband Forum, Cable Labs, and plan old RADUS enables a large network to dynamically provision source address packet filters. Over time, the filters will change as the customer’s network allocation changes.
• Forwarding Based Validation. The router’s forwarding table can be used to validate the source of a packet and then filter if it does not match the forwarding information. Unicast Reverse Path Forwarding (uRPF) was the first of several technologies that provide BCP 38 capabilities.
• Network Address Translation (NAT). Many people don’t think of NAT as a tool for BCP 38 enforcement. In reality, residential broadband, enterprises, and other networks behind NAT benefit from the inherent “source validation side effect.”

It is easy to see how the industry reached a 80% BCP 38 deployment. The source validation side effect of NAT, the automated approaches with uRPF, and the dynamic provisioning capabilities are all examples of how network “just filters.”

Does your network prevent Spoof IP addresses?

If you have the time, go to the MIT ANA Spoofer Project page, download the software, and run the test. You can see for yourself if the network you reside allows for spoofed IP packets while providing the project with another data point.

If you find the network allows spoofed IP packets, ask them why.

Update!

Kasperski Labs has an alternative page to check to see if you are one of the 500K – http://flashbackcheck.com/. The

How does Dr. Web’s and the Kasperski Lab’s tool Work?

Go to the Dr Web Page:

If you are someone who really knows the MAC, you can follow the instructions to get the UUID from the system report tool. If not, some screen shots are attached below.

Step by Step on a Macbook Pro

Step 1: Select the “Apple” at the top left. The drop down menu will appear. Select “About this Mac.” This will open the information application.

Step 2: Select “More Information”

Step 3: Select “System Report”

Step 4: Select and copy the UUID from the hardware section.

Step 5: You can now past the UUID into Dr Web’s tool to  see if you are in their list.

NOTE: Not being in their list does not mean you are clean. You might be violated and Dr Web not having your computer in the list. Malware data becomes fragmented as more “good guys” set up their own Sink Holes.

It is still worth checking manually (see Topher Kessler‘s article on How to remove the Flashback malware from OS X)

This voluntary code of conduct is a milestone for the industry – placing new expectations on the eco-system required to safe guard our telecommunications system.

The core of the code is as follows (please down load and read the whole document):

Voluntary Code of Conduct Participation Requirements

To participate in this Code, an ISP will engage in at least one activity (i.e., take meaningful action) in each of the following general areas:

• Education – an activity intended to help increase end-user education and awareness of botnet issues and how to help prevent bot infections;

• Detection – an activity intended to identify botnet activity in the ISP’s network, obtain information on botnet activity in the ISP’s network, or enable end-users to self-determine potential bot infections on their end-user devices;

• Notification – an activity intended to notify customers of suspected bot infections or enable customers to determine if they may be infected by a bot;

• Remediation – an activity intended to provide information to end-users about how they can remediate bot infections, or to assist end-users in remediating bot infections.

• Collaboration – an activity to share with other ISPs feedback and experience learned from the participating ISP’s Code activities.

DNS Changer (see http://www.dcwg.org/) has been a “thick” piece of malware to remediate. At the start of the take down we have ~600K violated computers. Today we’re at ~400K computers. Not an impressive clean-up record. Why? The operational security community has no effective tools that an average user can use to start cleaning up their system. The typical advice has been to back up your data, do a complete re-format of the the hard drive, and rebuild the system. I could see many see this advice as a shock. They would ask for other options. the problem is that we’ve not had any other options. Until now.

Anti-malware vendor’s work is starting to pay off. McAfee’s Stinger has just added DNS Changer to it’s detection list:

Stinger Release Notes

Build Number: 10.2.0.529
Build Date: 02-Mar-2012

MD5:    275AD47EAB8B1919753846D1D7BBFF98
SHA1:   753070FBA328E598FE87DE059A8E6280A51EEC21

Enhanced detections are those that have been modified for this release. Detections are enhanced to cover new variants, optimize performance, and correct incorrect identifications.

New Detections:
•	BackDoor-EXI.gen.aj
•	DNSChanger.dj
•	FakeAlert-Rena.cj
•	FakeAlert-Rena.ck
•	Generic FakeAlert.jn

Stinger is one of those tools in our tool kit that we use to clean a violated computer (see the Malware Removal Guide as an example). The approach is use a series of tools clear as much of malware off the system to get it to a point to run an effective backup and not have the back up reinfect the repaired system. Stinger is one of the key tools used in this approach.  We hope to see a few more of the tools with “DNS Changer” updates.

Are you worried about DNS Changer? If yes, please go to www.dcwg.org and read through how you can check to see if you computer has been violated.