Psychology in Security - Impact of Bad Banking Processes

Quite a few of my recent posts have had to do with visits to the local bank. This morning I made a quick trip to the local branch to carry out some wire transfers. So I sat down at the Foreign Transaction counter and was asked for the following:

• Form providing details of wire transfer, amount etc. (no problem)
  
• A proof of transaction, i.e. an invoice etc. (ok)
  
• A blank cheque, with nothing but my signature/stamp on it. Nothing in the to field, nothing in the amount field. (WHAT!)

At this point, I couldn't help stare the bank employee in the face with the most ridiculous look and inquire about whether they also encourage customers to fund Nigerian officials in need.

Eventually after realizing that I didn't have much of a choice and adding a "Not above RS. xx" statement, I conceded and started to leave the bank. At this point, the bank employee left my blank signed cheque on top of her desk while she walked away for a cup of tea!

Sure, this might not be the most dangerous scenario since there are security cameras all around and the bank's employees have undergone background checks and are well trusted. However, Banks need to realize the security has as much to do with process audits and security cameras as it has to do with customer's psychology. It is important that as responsible organizations, we send the correct message to customers about what is acceptable and what is not in-terms of security. Banks need to realize that if you encourage customers to give blank signed cheques, you are telling them that it is acceptable practice.

It is processes like this one that let users believe that this sort of behavior is acceptable or safe. No wonder hotels and other organizations ask you to provide credit-card details over the phone/email, while the person on the other end writes them down.

This particular incident reminded me of another instance where I have seen something similar.

Another Bank where I have an account constantly sends me e-mails with new offers that have links like "offer_name.bank.com". I think it is a horrible idea to tell you users that it is OK to click links with "xyz.bank.com" as many phishing scams provide links like, "xyz.bank.malicious.com/bank.com" etc which might not look very different to a non-tech user.

Banks need to realize and carefully analyze the psychological impact of their processes on what their customers deem to be acceptable or not. Proper and well thought out processes and policies could in the long-term be the difference between whether a user clicks a malicious phishing link or reports it.

Read more...

Airtel Injecting Ads into User's Browsers

Most businesses have one aim, maximize profits. However, while doing so there must be a balance between risk management, customer security and most importantly - FAIR-PLAY.

Indian ISP and mobile communications provider Airtel seems to have forgotten this exact rule. For almost a week now, Airtel has been "hi-jacking" user's HTTP requests and injecting them with full-page ads of their own DTH service (Screenshot).



To add even further security risk to this mess, I am fairly certain that the page used to display Advertisements is vulnerable to a Cross-Site Scripting attack. This means that an attacker can steal the cookies of an Airtel user even if the web-site in question has no obvious flaws.

Besides for the obvious risks faced by the XSS flaw, there is also the matter of how they handle:

• SSL connections.
• Client-side certificates.
• Sensitive user data sent via web-forms only to be interrupted by Airtel ads.
• Users carrying out Banking or other sensitive activities which when interrupted can result in multiple payments being processed.
• and most importantly, what guarantee is Airtel providing in-regards to user requests and information being maliciously redirected and stored on the Airtel ad-server.
  

Also, what about the fact that they are further affecting web-publishers advertising revenues by placing ads on content they did not write or develop. This is an extremely grim move on the part of Airtel and I sincerely hope that no-other ISPs continue in its footsteps.

Airtel may have made a few extra bucks from these ads, but I for one will never be using an Airtel service as far as I can help it.

Read more...

Indian Information Security Incidents Gallery

I was recently on the phone with Dinesh O'Bareja and he mentioned a blog he started sometime back to document Indian Information Security Incidents. I think its a great initiative on his part and one that we definitely require in the Indian IT Security space.

As anyone who has been involved in the Indian IT industry can tell you, for most organizations security is always a low priority. One of the reasons for this is the lack of corporate liability for the loss of customer data.

Most companies that are faced with a breach use the hush-hush approach and sweep the incident under the rug. This causes consumers who have had their personal information compromised to be left in the dark until their next statement shows up with fraudulent transactions.

In other countries, there are Security Breach Notifications Laws in place to ensure that the consumer is well informed and the responsible company either compensates the victim or subscribes them to an identity monitoring service.

Coming back to the India InfoSec: Incidents Hall of Shame / Fame Gallery Blog, I think Dinesh has definitely taken the right step. Only when we have more attention given to Security Incidents will we see companies dealing with them in a more responsible/liable manner.

So if anyone out there has witnessed any security incidents, go ahead drop Dinesh an e-mail.

Read more...

Budgeting for Web Application Security

Great post on Budgeting for Web Application Security by Jeremiah Grossman.

Some key approaches are:

1. Risk Mitigation - "If we spend $X on Y, we’ll reduce of risk of loss of $A by B%."
2. Due Diligence - "We must spend $X on Y because it’s an industry best-practice."
3. Incident Response - "We must spend $X on Y so that Z never happens again."
4. Regulatory Compliance - "We must spend $X on Y because PCI-DSS says so."
5. Competitive Advantage - "We must spend $X on Y to make the customer happy."

Read more...

Police Backdoors

I ran across this article titled "Police set to step up hacking of home PCs" the other day. It details a new law approved by the UK government allowing police to hack into suspected home computers. In-order to carry out these Hacks, they will be sending E-mails with virus attachments or breaking into homes and installing keystroke loggers.


This kind of behavior is displayed by most governments these days. However, what did surprise me is that they asked security product/service providers to stop detecting/blocking their keystroke loggers and other malicious tools.

I was glad to read that a few security vendors have taken issue and denied cooperation with this matter. As per ZDNet, security vendors Kaspersky Labs and Sophos told ZDNet UK that they would not make any concession in their protective software for the police hack.

Symantec declined to comment on whether it would block a police hack, saying the matter was "politically sensitive". However, the security vendor has said in the past that it would not scan for the FBI's Magic Lantern keystroke-logging software.

I personally think the entire concept is ridiculous, especially the part where security vendors are expected to turn a blind eye to these police hacks. I feel that an AV that would voluntarily miss malicious code used for these police hacks would probably as a direct result miss other malicious code also.

Also, If any malicious users or malware authors were to get their hands on this malicious police code (which is fairly likely since they are installing it on suspect PCs), it would be fairly easy to reverse engineer the code and create malware to mimic its behavior and bypass security software.

Security through obfuscation, i.e. with the hope that no-one will look there, or look deep enough is always a bad idea. The entire concept of asking Vendors to create police backdoors sounds to me like a malformed version of "Security through obfuscation".

Read more...

AVID - Antivirus is Dead!

Late last night I was surfing some forums looking at interesting posts and I noticed one about an MD5 Cracker that utilized various Free Online Services.

Intrigued I downloaded this utility, However suspecting a virus or trojan of some kind, I ran this utility through 37 Anti-Virus Scanners via VirusTotal - Free Online Virus and Malware Scan. Nothing!!. Every scanner on the market gave it a clean-chit including every single heuristic feature these scanners boast.

Being as paranoid as I am, I finally ran this utility through Sandboxie. A few seconds later, Comodo Firewall Pro came up with an alert: The utility was trying to connect to an FTP Server. Instantly I ran Wireshark and sniffed the Username/Password credentials for the FTP Server.

I put these details into Filezilla and in a few seconds I was connect to the server. The server was filled with log files from hundreds of users. The malware had dumped Saved Passwords from IE, Chrome, Firefox etc and uploaded these log files onto the server. After downloading a few of these files for deeper investigation, I deleted every file on the server to ensure that the compromised users would not have their information hi-jacked.

On further investigation of the log files, the virus seemed to be one from mutX.org. I was thoroughly disappointed that a known virus-strain could evade every single Anti-Virus scanner on the market even though it had such obvious heuristic traits such as: dumping information from browsers, msn messenger and uploading it to a rogue ftp server.

This entire episode reminded me about a Podcast I heard last week where Robin Bloor was a guest discussing AVID (Antivirus is Dead). After this particular incident, I couldn't agree more with Robin. If this particular incident had targeted an Organization as opposed to some Security Forums, it could have cause massive damage and probable financial loss to these organizations.

I have always been a fan of Layering Security and in this particular instance layering Avira Antivir, Comodo Firewall Pro, Sandboxie etc together really paid off.

Read more...

Fuzzing 101 - Introduction to Fuzzing

I've spent most of today running Security Brigade's Proprietary Fuzzing Application under a variety of situations and conditions to find some very interesting vulnerabilities in a wide-range of products.

Some of the products I've run it against yet are: Rediff's Toolbar for Internet Explorer, Microsoft Outlook 2007 and Mozilla Thunderbird; All of which have some very interesting vulnerabilities ranging from Denial-of-service to Buffer Overflows.

I will not be going into detail about these vulnerabilities in this posts as I will wait for vendor responses and patch releases before I do so. However, I do want to talk about Fuzzing in general.

What is a Fuzzer?
A Security fuzzer is a tool used by security professionals to test the parameters of an application. Typical fuzzers test an application for buffer overflows, format string vulnerabilities, and error handling. More advanced fuzzers incorporate functionality to test for directory traversal attacks, command execution vulnerabilities, SQL Injection and Cross Site Scripting vulnerabilities.

Common Fuzzing Tools
There are many publicly available and open-source fuzzing applications that are designed for various purposes. Some of these are:

antiparser -Written in Python, simple and limited fuzzing framework.
Autodafe - Can be perceived as a more powerful version of SPIKE. It’s main contribution is the introduction of a UNIX-based debugging agent capable of weighting the possibility of a crash on any given fuzz input.
AxMan - A web-based ActiveX fuzzing engine written by HD Moore.
bugger - A Linux in-process fuzzer written by Michal Zalewski.
COMRaider - A Windows GUI fuzzer written by David Zimmer, designed to fuzz COM Object Interfaces.
Dfuz -sWritten in C, exposes a custom and easy to use scripting language for fuzzer development.
DOM-Hanoi - Written by H D Moore and Aviv Raff, it is designed to identify common DHTML implementation flaws by adding/removing DOM elements
eFuzz - A generic TCP/IP protocol fuzzer. Easy to use, but maybe not as full featured as some others on this list.
Evolutionary Fuzzing System (EFS) -A fuzzer which attempts to dynamically learn a protocol using code coverage and other feedback mechanisms.
FileH-A haskell-based file fuzzer that generates mutated files from a list of source files and feeds them to an external program in batches.
FileFuzz - A file format fuzzer for PE (Windows) binaries from iDefense.
FileP-A python-based file fuzzer that generates mutated files from a list of source files and feeds them to an external program in batches.
Fuzzled -A Perl based generic fuzzing framework.
Fuzz - The ORIGINAL fuzzer developed by Dr. Barton Miller.
General Purpose Fuzzer (GPF) - Written in C, GPF has a number of modes ranging from simple pure random fuzzing to more complex protocol tokenization.
hamachi -Written by H D Moore and Aviv Raff, Hamachi will look for common DHTML implementation flaws by specifying common “bad” values for method arguments and property values.
(L)ibrary (E)xploit API - lxapi - A collection of python scripts for fuzzing.
mangleme -An automated broken HTML generator and browser tester, originally used to find dozens of security and reliability problems in all major Web browsers.
notSPIKFile - A ELF fuzzer closely related to FileFuzz, instead of using SPIKE as a starting point.
Peach -Written in Python, an advanced and robust fuzzing framework which successfully separates and abstracts relevant concepts. Learning curve is a bit overwhelming.
Protocol Informatics - Slides, whitepaper and code from the last publicly seen snapshot from Marshall Beddoe’s work.
PROTOS WAP - A fuzzer from the PROTOS project for fuzzing WAP.
PROTOS HTTP-reply - Another fuzzer from the PROTOS dudes for attack HTTP responses, useful for broswer vulns.
PROTOS LDAP - For fuzzing LDAP, not as successful as the others from the PROTOS project
PROTOS SNMP - Classic SNMP fuzzer, found a vuln in almost every networking gear available at the time (2002).
PROTOS SIP - For fuzzing all those new VOIP SIP devices you see everywhere.
PROTOS ISAKMP - For attacking IPSec implementations
RIOT & faultmon - For attacking plain text protocols (Telnet, HTTP, SMTP). Used by Riley Hassell when he worked at eEye to discover the IIS .printer overflow and included in The Shellcoder's Handbook.
QueFuzz - Small fuzzer that uses libnetfilter queue to take in packets from iptables. It’s fuzzing engine either randomly fuzzes binary or ASCII protocols or uses a basic fuzzing template to search and replace packet data.
Schemer - XML driven generic file and protocol fuzzer.
Screaming Cobra - Name makes the fuzzer sound better than it really is, but is good for finding CGI bugs. Also, its a perl scrpt so easy to modify or extend.
SMUDGE - Pure Python network protocol fuzzer from nd@felincemenace.
SPIKE - Written in C, exposes a custom API for fuzzer development.
SPIKEFile - Another file format fuzzer for attacking ELF (Linux) binaries from iDefense.
Tag Brute Forcer - Awesome fuzzer from Drew Copley at eEye for attacking all of those custom ActiveX applications.
TAOF (The Art of Fuzzing) - Written in Python, a cross-platform GUI driven network protocol fuzzing environment for both UNIX and Windows systems.
WebFuzzer - A fuzzer for web application vulnerabilities.

My personal favourite Fuzzing utilities are SPIKE, Axman and Peach.

Read more...

Hackers Compromise the World Bank - Reflections on Indian IT Security

According to this article from the USA Today, Hackers broke into 18 Servers at the World Bank and had access to and possibly stole sensitive information from at-least 5 of the servers. Indian Banks have been relatively lucky, facing a majority of phishing/scam attacks rather then out-right "Hack" attempts from skilled organized criminals such as these.

Throughout my time as a Security Professional whenever discussing Financial Fraud, Phishing and other attacks faced by Banks & Financial Institutions, I have always been of the opinion that they will soon face much more devastating attacks that will make the current attempts pale in comparison.

Why the pessimistic view? Well its simple.

Attackers have always been "creative" coming up with new and complicated schemes in-order to get access to Credit-Card details and Banking Information. The reason they have the time and ability to do so is: Economics. Bottom-line is that most of these attackers are walking away with fistfuls of money at the expense of Banks and their Customers.

If we consider a typical phishing scam, an attacker would send out a million e-mails (approximation) with a success rate at best of 1% (a very generous number considering that a good percent would be picked up by Anti-Spam, Anti-phishing, Mistargeted Users, Smart Users etc) they will walk away with 10000 working banking details.

Instead if the attacker starts targeting servers belonging to Banks, systems belonging to Bank Employees and more importantly any of the thousands of Indian Shopping web-sites with Exposed Customer Information, SQL Injection vulnerabilities etc they could walk away with 100K - 200K Credit-Card details or Banking Information.

As a matter of fact, last week, a colleague of mine ordered for a product from one of the most popular Indian Shopping Portals. When the product was delivered; the label was a print-out invoice at the bottom of which was the URL: http://shopping-website/ecommerce/admin/vieworders.php. After typing this into the browser we were shown WITHOUT AUTHENTICATION plain-text Credit Card details, Order Information, Banking Details etc.

This for sure is one reason, why I do-not personally carry out Online Banking or Shopping besides for maybe on Amazon.com or my Bank Account with Free Fraud Insurance.

Read more...

ClickJacking Explained

What is ClickJacking?
ClickJacking is a relatively old vulnerabilitiy that has been around since 2003-2004, however it has been recently brought back to life by Robert Hansen and Jeremiah Grossman. ClickJacking is a little bit difficult to explain however try to imagine any button that you see in your browser from the Wire Transfer Button on your Bank, Post Blog button on your blog, Add user button on your web-site etc. ClickJacking gives the attacker to ability to invisibly float these buttons on-top of other innocent looking objects in your browser. So when you try to click on the innocent object, you are actually clicking on the malicious button that is floating on top invisibly.

So while you are simply trying to close the javascript pop-up on your screen, play a flash game or interact with some ajax web-site -- you might really be clicking on the button to wire-transfer money to a russian bank account.

A slightly more technical description would be: A malicious page in domain A may create an IFRAME pointing to an application in domain B, to which the user is currently authenticated with cookies. The top-level page may then cover portions of the IFRAME with other visual elements to seamlessly hide everything but a single UI button in domain B, such as 'delete all items,' 'click to add Bob as a admin,' etc. It may then provide its own, misleading UI that implies that the button serves a different purpose and is a part of site A, inviting the user to click it.

In other words, the hacker would dupe users into visiting a malicious page -- through the usual methods -- but then hide the nasty bits under what appears to be the real-deal content from a legitimate site.

How Serious is ClickJacking?
On its own ClickJacking doesn't sound to be a very serious vulnerability, since user interaction is required. However as I have always said, in the world of vulnerabilities 1+1 does not always equal to 2, and might just equal to 10^2. By this I simply mean, that ClickJacking in combination with other vulnerabilities could become a very serious issue.

Example - ClickJacking can Spy on your Webcam and Microphone
Just as I wrote this blogpost a new use for ClickJacking has been disclosed where it can be used to spy on your Microphone and Webcam. This is based on a new vulnerability discovered in Adobe's Flash Software and published about on Guya.net, Rsnake's Blog and Jerremiah Grossman's Blog.

A particular vulnerability exists in Adobe's Flash Software, which allows the malicious attacker to use ClickJacking to gain access to the user's web-cam and microphone.

The vulnerability works as follows:
1) You visit a web-page with a flash application/game embedded in it.
2) You click on the flash button.
3) Your click is "click-jacked" into allowing the server to access your web-cam and microphone.

Whatis really happening:
1) You visit the web-page, in the back the target application (in this case Adobe's Settings Panel) is loaded and made invisible. The Allow button is made to float invisibly.
2) While you click on the flash button, the invisible Allow button is floating on top of the flash button and actually receives your click.
3) The Flash application now has full permission to access your web-cam, microphone etc and even have it stream to a server where it is recorded for future viewing.

You can see a video of this in action at: Youtube and Vimeo.

Read more...

OWASP Mumbai Chapter Meeting - 22nd September 2008

I will be attending the OWASP Mumbai Chapter Meeting on the 22nd of September 2008. The details are as follows:

Date: 22nd September, 2008 - Monday
Timing: 2:30 PM to 5:30 PM
Venue: Hotel Heavens India, Seepz, Andheri (e)

To Register
Kindly drop a mail to dharmeshmm at owasp dot org with following details to register for the event.

Your Name:
Your Organization/Institution:
Your Designation:
Your Contact No.:

To Sponsor
Send a mail to dharmeshmm at owasp dot org to understand the sponsorship details.

Read more...

Securing Your Home Wireless Network

As most of us in India have noticed, Wireless Networks have been in the news these days for all the wrong reasons. These open networks have always been used by tech-savvy users however lately they have been utilized by malicious organizations to carry out their nefarious purposes (e.g. the recent bomb blasts).

The home user, small businesses that often cannot implement complex security solutions are the ones who primarily suffer the consequences which range from large broadband bills to authorities knocking on your door at 3 AM.

I've put down a quick article with 10 Steps for Securing Your Home Wireless Network:

1. Change Default Administrator Usernames and Passwords
Most routers or access points come enabled with a default set of username/password combinations. These combinations are well documented and available online for hackers to use. If a hacker can access your device’s administrative pages they can modify the configuration and control all aspects of your device. These username/password combinations can be changed from the administrative panel and should be set to something difficult to guess.

2. Turn on WPA / WEP Encryption
All Wireless devices support some form of encryption. Encryption technology scrambles messages sent over the air and ensures that they cannot be intercepted by hackers. Several encryption technologies exist for Wireless communication today. WPA is the strongest commonly available encryption technology for home devices however WEP can also be used.

3. Change the Default SSID
Access points and routers all use a network name called the SSID. Manufacturers normally ship their products with the same SSID set for all routers. For example, the SSID for Netgear devices is normally "NETGEAR". The Default SSID can be changed from the administrative panel and should be set to something unique.

4. Enable MAC Address Filtering
Each wireless device possesses a unique identifier called the physical address or MAC address. Access points and routers keep track of the MAC addresses for all devices that connect to them. Wireless routers offer the option to key in the MAC addresses of your home equipment so as to restrict the network to only allow connections from those devices. It ensures that rogue users cannot connect to the wireless router without using advanced MAC spoofing techniques.

5. Disable SSID Broadcast
The wireless access point or router typically broadcasts the network name (SSID) over the air at regular intervals. This feature was designed for businesses and mobile hotspots where wireless clients may roam in and out of range. For the home user, this roaming feature is unnecessary, and it increases the likelihood someone will try to log in to your home network. Fortunately, most wireless access points allow the SSID broadcast feature to be disabled by the network administrator. Your SSID name can be manually inputted into your devices to prevent the need for SSID Broadcasts to be enabled.

6. Do Not Auto-Connect to Open Wireless Networks
Connecting to an open wireless network such as a free wireless hotspot or your neighbor's router exposes your computer to security risks and attacks. Although not normally enabled, most computers have a setting available allowing these connections to happen automatically without notifying the user. This setting should not be enabled except in temporary situations.

7. Assign Static IP Addresses to Devices
Most home wireless devices use dynamic IP addresses. DHCP technology is indeed easy to set up. Unfortunately, this convenience also works to the advantage of network attackers, who can easily obtain valid IP addresses from your network's DHCP pool. Turn off DHCP on the router or access point, set a fixed IP address range instead and then configure each connected device to match. Using a private IP address range (like 10.0.0.x) prevents computers from being directly reached from the Internet.

8. Enable Firewalls On Each Computer and Router
Modern network routers contain built-in firewall capability, but the option also exists to disable them. Ensure that your router's firewall is turned on. For extra protection, consider installing and running personal firewall software on each computer connected to the router.

9. Position the Router or Access Point Safely
Wireless signals normally reach to the exterior of a home. A small amount of signal leakage outdoors is not a problem, but the further this signal reaches, the easier it is for others to detect and exploit. Wireless signals often reach through neighboring houses and into streets. When installing a wireless home network, the position of the access point or router determines its reach. Try to position these devices near the center of the home rather than near windows to minimize leakage. Many routers allow you to reduce the range of your router from the administrative panel to prevent the signal leakage.

10. Turn Off Network During Extended Periods of Non-Use
The ultimate in wireless security measures, shutting down your network will most certainly prevent outside hackers from breaking in! While impractical to turn off and on the devices frequently, at least consider doing so during travel or extended periods of downtime.

Article Referenced By:
http://www.dailypioneer.com/126829/High5-the-Wi-Fi.html
http://www.rediff.com/getahead/2008/oct/10wifi.htm
http://www.ibnlive.com/news/top-10-tips-for-home-users-to-secure-wifi-networks/73852-11.html?from=search

Read more...

Confusion between Vulnerability Assessment and Penetration Testing

There has always been a fair amount of confusion between Penetration Testing and Vulnerability Assessments. In India however the problem takes a new turn with vendors confusing between the two.

I was recently in a meeting with a potential customer and we were discussing their current vendors and what they provide in their Penetration Test. As I glanced over the reports I noticed that the service provided was purely a Vulnerability Assessment masquerading as a Penetration Test. The particular vendor in question had only conducted a port scan followed by listing possible vulnerabilities that exist for the service and operating system versions identified.

In my opinion I would barely even classify this as a Vulnerability Assessment. A Vulnerability Assessment Engagement from Security Brigade goes through the following phases:

• Pre-Assessment Analysis
• Information Gathering
• Port Scanning
• Enumeration
• Threat Profiling & Risk Identification
• Network Vulnerability Assessment
• Application Vulnerability Assessment
• Engagement Analysis
• Mitigation Strategies
• Report Generation
• Support

A Penetration Testing Service however goes many steps further with the following phases:

• Pre-Assessment Analysis
• Information Gathering
• Port Scanning
• Enumeration
• Social Engineering
• Threat Profiling & Risk Identification
• Network Vulnerability Assessment
• Application Vulnerability Assessment
• Exploit Research & Development
• Exploitation
• Privilege Escalation
• Retaining Access
• Network Propagation
• Engagement Analysis
• Mitigation Strategies
• Report Generation
• Support

The difference can be clearly seen in the fact that a Penetration Testing goes further after analyzing the vulnerabilities into exploitation, privilege escalation, retaining access, network prorogation etc. Simply put a Vulnerability Assessment provides an overview of the flaws that exist on the system while a Penetration Testing goes on to provide an impact analysis of the flaws identified, the possible impact of the flaw on the underlying network, operating system, database etc.

I believe it is fairly important for Clients and especially Vendors in India to understand the difference and represent the two services in their traditionally accepted form. I believe this is a crucial step for Indian IT Security to take a step forward and providing real security to customers.

One of the white papers that I am currently working on specifically looks at the difference between Vulnerability Assessments and Penetration Tests with a focus on:

• What is covered by each service
• What factors should be considered while determining their requirements
  
• How a Client can determine their requirements
• Comparison of the benefits and draw-backs of both the services
• etc.

The paper should be released sometime this month and can be found on Security Brigade's website.

Read more...

Dan Kaminsky's DNS Cache Poisoning Vulnerability Explained

There has been a lot of talk recently about Dan Kaminsky's DNS Cache Poisoning Vulnerability. Simply put there are an extremely large amount of publicly accessible DNS servers that can fairly easily be tricked into storing and serving up malicious DNS Information. The impact of this malicious DNS Information is that users can be unknowingly tricked into accessing malicious sites and possibly compromise sensitive information such as: username, passwords etc.

DNS Cache Poisoning attacks have been around for years now. However this vulnerability is far more exploitable and dangerous than its predecessors. Luckily for the world and all of its administrators, Dan Kaminsky of DoxPara Research raised awareness about the criticality of this vulnerability and coordinated a massive effort with vendors to issue patches. He gave vendors time to make patches and the public time to apply them before releasing all the details.

In regards to the exploitability of this vulnerability, there are a few challenges that need to be overcome by the attackers.

• Knowing when a DNS Server will issue a particular DNS Lookup: If the server doesn't already have the name cached, you can try to spoof the response right then, but you only get one shot.
  
• Guessing the DNS query's transaction ID: it should be possible to blast the server with 65,536 spoofed responses (one for each transaction ID). The fact that this ID is only 16 bit is generally accepted as being too weak.
  
• Creating a proper spoofed packet with poisoned information in it: Vulnerable DNS servers reuse the same source port for every outgoing request, which makes crafting the spoofed return UDP packets trivial (DNS servers that already randomized the source port are generally seen as being practically immune to this exploit, since attackers would have to guess nearly 2^32 combinations instead of only 65,536).
  
• Getting the spoofed response to the DNS Server before the real response: Latency may work against an attacker. But an attacker attacking his own ISP might not face either of these problems.
  

Overall, an attacker would need an insane amount of patience and luck to pull this off.

The steps an attacker would take to exploit this vulnerability would be something like:

1. Attacker asks Victim DNS Server: Who is gmail.google.com?
2. Victim DNS server asks the authority for google.com, Who is gmail.google.com?
3. Attacker blasts Victim with spoofed responses, each containing a different transaction ID. The packet contains a response with an IP for gmail.google.com, as well as an additional RR stating www.google.com is an IP address of the Attacker's choosing.
4. (Exploit) If a valid, spoofed response is received before the real response comes back, the Victim updates its cache with both the requested info as well as the poisonous IP information contained in the RR. The subsequent response from the authority for google.com is discarded.

This is repeated as necessary with new sub-domain requests, until one of the spoofed responses takes. When it takes, the attacker has circumvented the TTL problem and outsmarted the same-domain defense. Reports are this can happen in less than 10 minutes. i.e. 10 minutes to replace cnn.com, or youtube.com, or any other popular site with a site of your own choosing. This means for a certain period of time and for the users of your victim DNS Server you control where these popular websites point. You will be able to deface the website, show them information of your choice, or try to phish for their personal information.

An exploit is currently available from the Computer Academic Underground. It provides a good technical summary on the vulnerability and how exploitation works.

This exploit attacks a fairly ubiquitous flaw in DNS implementations which Dan Kaminsky found and disclosed ~Jul 2008. It caches a single malicious host entry into the target nameserver by sending random sub-domain queries to the target DNS server coupled with spoofed replies to those queries from the authoritative nameservers for the domain which contain a malicious host entry for the hostname to be poisoned in the authority and additional records sections. Eventually, a guessed ID will match and the spoofed packet will get accepted, and due to the additional hostname entry being within constraints of the original request the malicious host entry will get cached.

So what's the fix? There really is no fix, short of using DNSSEC, or moving to some other cryptographic method of trust. Using TCP instead of UDP has come up (this would add the additional, now nearly impossible challenge of guessing sequence numbers), but was shot down as being too resource intensive. So the accepted workaround is what was already mentioned above: DNS servers should randomize their source ports. Then attackers would have a much, much harder time spoofing the return packets.

For those of us out of India, I don't see much hope in waiting for your respective ISPs to patch. In the meanwhile I recommend switching to the DNS Servers from OpenDNS as a precautionary measure.

Read more...

Wireless In-Security Used by Terrorists

Most of you reading this, will have heard about the bomb-blasts that have rocked Bangalore and Ahmedabad. Five minutes before each of the blasts the terrorists "Indian Mujahedin" sent out e-mails to the media warning about the threats and provoking the authorities to stop them in time.

Through the investigation the authorities have identified a wireless router belonging to an American Family in New Bombay as the source of the e-mails. Unfortunately for the family, their wireless router had no form of security or logging enabled.

Now not only is the family in a legal mess trying to prove their innocence without logs but also the terrorists will be able to easily get away without much hope of their identity being tracked. What concerns me most is that even if the family had enabled WEP encryption on their router, it would have taken nothing more then a few minutes to crack the password.

If you want to protect your wireless router from external threats, I would recommend implementing a combination of WEP or WPA encryption and MAC Address Filtering. For instructions, you can refer to this article from PC Magazine.

Update: Since I have last heard, the family is still being made to run around trying to prove their innocence. The wireless-router had no logging mechanism enabled, so its not possible to confirm whether the e-mail was sent by the family or a random passerby.

Read more...

Browser Based Malware

For some time now, I have been interested in browser based malware attacks and even more so after reading Armando Romeo's Posts about Backdoors in Firefox Extensions.

I've spent some time researching the topic and the various attack vectors and opportunities that are available through browser based malware. Consequently, I submitted a paper for the Avar 2008 Conference on Browser Based Malware Attacks which will detail the research I've conducted.

Avar is the largest Asia-Pacific conference for anti-malware technologies that is being brought to Delhi, India by QuickHeal in December 08.

I have been exploring the various attack vectors through which browser based malware could exist and analyzing their impact as compared to traditional malware.

Browser-based malware use the user’s browser to disrupt computer functions. This type of malware is typically unleashed when someone visits a web page that appears harmless, but actually contains hidden malicious code intended to sabotage a computer or compromise the user's privacy. The result of the attack may be as simple as a crashed browser; or as serious as the theft of personal information or the loss of confidential proprietary data.

Before the days of Web 2.0, browser based malware was fairly limited to drive-by-downloads, however since the discovery of JavaScript Attacks, CSS attacks etc the field has opened up. Some of the currently seen browser-based malware techniques are as follows:

• Drive-By Downloads
• JavaScript Worms and Viruses
• CSS Attacks
• Browser Add-ons Viruses and Worms

In the current state of the internet, much of a user’s life runs through their browser. With browser-based technologies such as: OSs, Storage/Backup systems, E-mails, Social Networking Web-sites, CRMs, Intranets etc. For an attacker, controlling a user's browser has suddenly become as fruitful as gaining access to their system.

Also considering that System based viruses and worms have are being comparitively well covered by Anti-Virus, Anti-Malware and Internet Security Products, it leaves the door wide-open for Browser Based Malware Attacks.

Through this research paper I intend to carry out a detailed analysis of browser-based malware threats and hope to dissect each threat and determine the following:

• How they work?
• What is the threat posed and possible impact?
• How they can be remediated?
• Will any current security products thwart this attack?

Also: If anyone is going to be attending AVAR 08, drop me an e-mail or leave a comment.

Read more...