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.

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.

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.

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.

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.

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

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.

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.

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.

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.

Physical Security: The Lost Art

I had to visit my local bank today to take care of some papers. As I was sitting across the table talking about how they spelled something wrong on of my documents; I notice that right next to the Manager's office is a small but well packed Server Room.

I immediately started assessing the physical security of that server room and was disappointed by the fact that there was absolutely no access control mechanism; Just a door with a shoe rack outside. A few minutes later and a bit scared about my money, I walked out of the bank and headed back.

As I walked away from the bank, I noticed a LAN wire coming out of a window. This window was positioned exactly where the Server Room had been. Imagine my surprise, a Bank's Server Room has its information transmitted through a exposed LAN wire that is lying on public property?!


This sounds like a bad combination and a easy opportunity to cut, crimp and sniff. I decided to explore this further and see where the LAN wire led me. I walked around the bank and found an Enclosure that the wire was entering. This was of course exposed behind the bank and not monitored by anyone at anytime. Inside this unlocked box were routers, switches, and other devices up for grabs and sniffing.

As a security professional, I am not only appalled by this but might be forced to give them a complimentary penetration testing service for the safety of my own money.

SNMP Hacking

I've spent a lot of time exploring alternative attacking
methods other than the traditional flaws. One of the routes I've really enjoyed exploring has been SNMP attacks. I thought I'd give an overview for those who are not very familiar with the subject.

Simple Network Management Protocol (SNMP) is an application-layer protocol for managing TCP/IP based networks. SNMP runs over UDP (which runs over IP). Most administrators/security guys fail to understand SNMP and its security impacts.

What is SNMP Used For?
SNMP is a protocol that is simply used to manage multiple devices on enterprise networks; i.e. where the administrative software can contact each device via SNMP and retrieve its status and diagnostic information. This way an administrator can keep an eye on all of his/her devices without much effort. Also with the "write string" mentioned below they can use it to change configuration information over a large number of devices.

Does SNMP Use Authentication?
SNMP uses community strings as a key or password. Provide the right string and gain a different level of access.

By default there is the "public" string that is enabled on most servers and "private" string that is enabled on some servers. It is possible however, to brute-force SNMP community strings.

"public" and "private" strings will generally give you read-only access, however this can be fairly dangerous also (as seen in one of the examples below). Brute-forcing the write access strings is easy as SNMP is over the UDP protocol. The speed of attack can be improved significantly then one that is done over TCP and the Source IP can be easily spoofed.

OID: Is a string (series of numbers, seperated by ".") that is used to tell the device what information you want. Different devices have different OIDs.

The ThreatSNMP "walking" is very dangerous even with read-only access. Windows servers disclosed full list of user-names via SNMP walking the oid "1.3.6.1.4.1.77.1.2.25". There exist many tools intended for the purpose of bruteforcing and identifying OIDs once a weak SNMP Server is found. This can be used to identify and modify a lot of sensitive information on the device.

There are many tools that are included in the SNMPWalk kit for different purposes. I will walk through SNScan from Foundstone and SNMPWalk.

SNScanSNMP Scanner that can be used to scan IP ranges for SNMP Servers with weak strings, including a brute-force feature.

SNMPWalk
The snmpwalk command is designed to perform a sequence of chained GETNEXT requests automatically, rather than having to issue the necessary snmpgetnext requests by hand.

Simply: It is able to identify the various OID strings and retrieve their content.

Example:
D:\snmp>snmpwalk test.yash-home public
.iso.3.6.1.2.1.1.1.0 = "Linux test.yash-home 2.6.9-023stab046.2 #1 Mon Dec 10 14:51
:29 MSK 2007 i686"
.iso.3.6.1.2.1.1.2.0 = OID: .iso.3.6.1.4.1.8072.3.2.10
.iso.3.6.1.2.1.1.3.0 = Timeticks: (248307958) 28 days, 17:44:39.58
.iso.3.6.1.2.1.1.4.0 = "Root (configure /etc/snmp/snmp.local.co
nf)"
.iso.3.6.1.2.1.1.5.0 = "test.yash-home"
.iso.3.6.1.2.1.1.6.0 = "Unknown (edit /etc/snmp/snmpd.conf)"
.iso.3.6.1.2.1.1.8.0 = Timeticks: (11) 0:00:00.11
.iso.3.6.1.2.1.1.9.1.2.1 = OID: .iso.3.6.1.6.3.1
.iso.3.6.1.2.1.1.9.1.2.2 = OID: .iso.3.6.1.2.1.49
.iso.3.6.1.2.1.1.9.1.2.3 = OID: .iso.3.6.1.2.1.4
.iso.3.6.1.2.1.1.9.1.2.4 = OID: .iso.3.6.1.2.1.50
.iso.3.6.1.2.1.1.9.1.2.5 = OID: .iso.3.6.1.6.3.16.2.2.1
.iso.3.6.1.2.1.1.9.1.2.6 = OID: .iso.3.6.1.6.3.10.3.1.1
.iso.3.6.1.2.1.1.9.1.2.7 = OID: .iso.3.6.1.6.3.11.3.1.1
.iso.3.6.1.2.1.1.9.1.2.8 = OID: .iso.3.6.1.6.3.15.2.1.1
.iso.3.6.1.2.1.1.9.1.3.1 = "The MIB module for SNMPv2 entities"
.iso.3.6.1.2.1.1.9.1.3.2 = "The MIB module for managing TCP implementations"
.iso.3.6.1.2.1.1.9.1.3.3 = "The MIB module for managing IP and ICMP implementati
ons"
.iso.3.6.1.2.1.1.9.1.3.4 = "The MIB module for managing UDP implementations"
.iso.3.6.1.2.1.1.9.1.3.5 = "View-based Access Control Model for SNMP."
.iso.3.6.1.2.1.1.9.1.3.6 = "The SNMP Management Architecture MIB."
.iso.3.6.1.2.1.1.9.1.3.7 = "The MIB for Message Processing and Dispatching."
.iso.3.6.1.2.1.1.9.1.3.8 = "The management information definitions for the SNMP
User-based Security Model."
.iso.3.6.1.2.1.1.9.1.4.1 = Timeticks: (11) 0:00:00.11
.iso.3.6.1.2.1.1.9.1.4.2 = Timeticks: (11) 0:00:00.11
.iso.3.6.1.2.1.1.9.1.4.3 = Timeticks: (11) 0:00:00.11
.iso.3.6.1.2.1.1.9.1.4.4 = Timeticks: (11) 0:00:00.11
.iso.3.6.1.2.1.1.9.1.4.5 = Timeticks: (11) 0:00:00.11
.iso.3.6.1.2.1.1.9.1.4.6 = Timeticks: (11) 0:00:00.11
.iso.3.6.1.2.1.1.9.1.4.7 = Timeticks: (11) 0:00:00.11
.iso.3.6.1.2.1.1.9.1.4.8 = Timeticks: (11) 0:00:00.11
.iso.3.6.1.2.1.25.1.1.0 = Timeticks: (248309155) 28 days, 17:44:51.55
End of MIB

D:\snmp>snmpwalk testios.yash public
.iso.3.6.1.2.1.1.1.0 = "Cisco Internetwork Operating System Software ..IOS (tm)
7200 Software (C7200-IK9O3S-M), Version 12.3(9b), RELEASE SOFTWARE (fc1)..Copyri
ght (c) 1986-2004 by cisco Systems, Inc...Compiled Wed 18-Aug-04 15:31 by dchih"

...... followed by a long list of information such as processes, users, modules, ports, etc.

D:\snmp>snmpwalk hp.yash public
.iso.3.6.1.2.1.1.1.0 = "HP-UX gedis1 B.10.20 A 9000/803 2013446997"
.iso.3.6.1.2.1.1.2.0 = OID: .iso.3.6.1.4.1.11.2.3.2.3
.iso.3.6.1.2.1.1.3.0 = Timeticks: (2955823000) 342 days, 2:37:10.00

D:\snmp>snmpwalk snmp.yash public
.iso.3.6.1.2.1.1.1.0 = "Sun SNMP Agent, Sun-Fire-480R"
.iso.3.6.1.2.1.1.2.0 = OID: .iso.3.6.1.4.1.42.2.1.1
.iso.3.6.1.2.1.1.3.0 = Timeticks: (422632606) 48 days, 21:58:46.06
.iso.3.6.1.2.1.1.4.0 = "System administrator"
.iso.3.6.1.2.1.1.5.0 = "mu-me01-ns-ctm001"
.iso.3.6.1.2.1.1.6.0 = "System administrators office"

D:\snmp>snmpwalk win.yash public
.iso.3.6.1.2.1.1.1.0 = "Hardware: x86 Family 15 Model 4 Stepping 1 AT/A
T COMPATI
BLE - Software: Windows 2000 Version 5.0 (Build 2195 Uniprocessor Free)"
.iso.3.6.1.2.1.1.2.0 = OID: .iso.3.6.1.4.1.311.1.1.3.1.2
.iso.3.6.1.2.1.1.3.0 = Timeticks: (466602853) 54 days, 0:07:08.53

Anyway as you can see a LOT of information was revealed via SNMPWalking; and in the case of many other devices much more sensitive information can be disclosed.

For e.g:
Windows servers return the full list of user names by snmwalking the OID 1.3.6.1.4.1.77.1.2.25.

BT Voyager 2000 router leaking the ISP credentials including the password.

HP JetDirect printers leaking the admin password via SNMP read access (using OIDs .iso.3.6.1.4.1.11.2.3.9.4.2.1.3.9.1.1.0 and .1.3.6.1.4.1.11.2.3.9.1.1.13.0).

Dynamic DNS credentials disclosure on ZyXEL Prestige routers via the OID 1.3.6.1.4.1.890.1.2.1.2.6.0.

SNMP servers contain a lot of information, in many cases revealing passwords and other sensitive information. However most security consultants are unaware of what SNMP Security is and how it can be used by hackers to manipulate your networks and systems.

I am working on a paper on SNMP Security that will be published soon on Security Brigade's Website.

Security In The Education Process

I recently read a couple of Blog posts about Security in the education process.

Catching them early ... build security in to the psyche - Dinesh O'Bareja
Can Security be incorporated in the Computer Science & IT courses? - Dharmesh M Mehta

Both Dinesh and Dharmesh have a similar idea, i.e. integrating IT Security practices into the education process. However as much as I would like to see this happen, I think it would be an impractical idea in the current education system for India.

Most engineers and information technology professionals that are employed by the vast IT industry have a weak hold on programming languages and methodologies as they walk out of college. Most of what they know is learned on the job or in the pre-placement trainings. A lot of those brought into Systems Engineer or Developer positions are those that even lack an IT background.

Further to make this an even harder task to achieve; the syllabus is already lacking and outdated. Its hard to teach security in the education process; when we are teaching students to use Visual C++ 6.0 and Visual Basic 6.0 instead of .NET.


In my opinion, the first step to introducing Security in the education process is to educate the educators. To ensure that the teaching staff is well educated with Security Best Practices. When this happens; security practices will start trickling into their teaching methods and automatically show up in the students.

I believe that instead of teaching security practices to students, we eliminate the insecure practices being taught to them. This way when students walk out with an engineer degree, they have only been taught secure coding for the last 4 years.

At Security Brigade, we are working on many training solutions, from implementing entire Security courses to Security for the educators. We will also be holding a few ethical hacking trainings in the next few months, possibly one in Mumbai in the last week of May.

Trust you plugins? Think again

Over the last weekend, Armando Romeo and I spent some time discussing the attack vectors possible by inserting "backdoor" code into the Firefox (Mozilla) browser through Extensions, Themes and Language Packs.


Romeo has the proof-of-concepts ready for two scenarios - In-browser keylogger and Download and save executable. Two very dangerous scenarios for your "Mac OS X for FF Theme" to be playing with. It would be possible for this vulnerability to be used to map the network and carry out many other dangerous attacks on the intranet.

Just as we went about playing with the fact that the same POCs worked well with Thunderbird and other Mozilla products, we found this. Turns out there were others in the wild who had already explored this concept and put it to work to compromise 10000s of people.

This whole Mozilla incident brings me to a larger point: Do you trust your plugins?

Not just Mozilla; with a few minutes of Googling I was able to identify the following applications that allow plugins:

1. Internet Explorer
2. Miranda IM
3. Wordpress
4. Total Commander
5. Joomla
6. Ad-aware
7. Virtual-DJ
8. ........
   

There are 1000s of applications out there that blindly trust third party plugins/addons.

The concerning part of such attacks that can occur from plugins is that in most cases they would be missed by traditional control mechanisms such as Anti-viruses, Firewalls etc.

I havn't had the time to play with each of these scenarios as of yet, but would definitely like to sometime soon. As for now, disabling javascript on your browser is no longer enough. You will need a source code audit on every extension/theme/language pack you install in Firefox or any other application. Until Mozilla fixes the issue, I recommend running Firefox from Sandboxie.