That One Meeting Every Founder Has

Every founder I’ve spoken to has had that one meeting; the one that shakes the foundation of what you’re doing and makes you take a few steps back to re-check the ground you’re standing on.

I’ve had a several such meetings, each one at different phases of growth and each one opening up a new direction of thought and improvement.

Having started Security Brigade way back in the day before “start-ups” were the fad, we were very fortunate and got to meet a lot of very interesting and knowledgeable people with great amounts of industry experience.

The earliest such meeting I can recall was on 21st June 2008. It had been a little over a year since we started the company and I had the opportunity to meet with Sumit Chowdhury, who was at that time the CIO at Reliance Communications.

I walked into that meeting an over-confident hacker who thought he understood security, business and everything in the middle. I walked out of that meeting a broken founder who realized he had a lot to learn and a lot to do.

At this point in the business – I was 20 and we really hadn’t given much thought to the business plan. It was all about vulnerabilities, audits and hacking.

Getting back to the meeting – we walked into the room and did our basic pitch. Followed by the pitch were a whole series of questions from Sumit.

What’s your USP? Why should we go with Security Brigade as opposed to the range of other vendors out there?

You’re a small company today and you’ll be personally involved in each audit. What happens when you grow? How will you continue to deliver great audits when you have 20-30 auditors working for you?

It was naïve, but honestly we had never thought of these things at that stage.

I walked out of that meeting promising to come back better prepared with these details. I walked out of the office complex, hopped into a black-and-yellow and found my way straight into the business section at Crossword (Yes, we bought books in physical stores back then :P).

I picked up a copy of Differentiate or Die by Jack Trout and read it cover-to-cover several times in the next week.  Over the next several weeks we began to reevaluate our business, understand our competition, understand our customers and started formulating the direction we should go in as a company.

We came up with a USP – In a market filled with automated scan vendors, let’s be a vendor that focuses on business logic and manual testing. We elaborated on this with specific features –

• Beautiful in-depth reports with descriptions that actually mean something
• Step-by-step POCs so developers learn as they fix
• Recommendations that are specific to a customer’s development language and platform as opposed to a generic “apply patch and do input validation”.
• And most importantly we formalized our audit process to focus on business Logic flaws. These are flaws that are impossible to detect with the scanner and can have the most incredible and high-value business impact when exploited. 

We revamped all our documentation; we changed our audit processes and really ingrained these points into the DNA of the company.

The second point Sumit raised was a more challenging question and definitely more difficult to address:

How do you build a quality focused, expert driven, service oriented company that can scale?

Strong business processes, enforced workflows, accountability and metrics. That was our answer and that’s how we started building Lemon – our In-house audit workflow management system. Today, 7 years later Lemon is an “Everything management integrated system” for us.

Slowly, over the years, we dedicated more and more resources to Lemon, adding more and more capabilities. It started with Project Management ,Task Management, Reporting and grew into Vulnerability Management, Test Case Management, Workflow Enforcement, Approval Tracking, Quality Checks, Automation Management, Intelligence and Business Reporting, Sales, Marketing, Billing, Accounts, and so much more.

The idea was – literally – For Lemon to be an ‘exoskeleton’ that would allow our auditors to focus on the real intelligent portion of audits, while everything else would be automated. By building a lot of checks-and-balances, metrics and a lot of self-learning into Lemon, we were able to ensure that with each audit, we improved as a company. Every mistake or missed vulnerability was addresses with a code-push as opposed to a discussion. All in all, Lemon has successfully allowed us to grow over the last 7 years without impacting our quality in any way.

I’ve said this time and again: As a company, we would have died if we hadn’t built Lemon. There is no way an audit company with more than 5-10 consultants can sustain quality or delivery consistent audits without such a platform in place.

I’ve always found it interesting how such seemingly random meetings have had such a huge impact on the direction and success of this company. I’ve never had a chance to speak to Sumit about this, and its strange that after all this, he probably has no idea on how much his questions influence the direction of this company.

I’ve had a few other such meetings since – the most recent one focusing on business growth metrics, company health tracking and 5 year planning. But that’s a post for another day.

Cheers - Yash

Inherent Lack of Privacy in India

Over the last few weeks, I came across multiple scenarios where there was an absolute lack of concern over privacy or user data. This got me thinking about how there was an inherent lack of concern for privacy in India and what we in our capacity as security professionals, regulators / law makers and end-users could do about it.

Scenario 1: The Election Mail
The Backstory: I am a member of the N.S.C.I club and as such receive the occasional paper mail communication from them about various events, activities etc. Around sometime last year, as part of the transition to RFID access cards - I also provided them with alternate contact details such as my phone number, e-mail address etc. However, I don't believe I have received any official communication from them over any alternate medium since.

At some point in the afternoon last monday, my phone beeped and the nagging red light ensured that I checked it right away. It seemed to be an unsigned message asking me to "Vote for Progressive Group" - which at the point didn't make much sense to me. Over the next couple of days, I received about three different e-mails from a Mr. Nasir Amlani asking me to vote for him in the upcoming NSCI board elections. I have a couple different concerns with this whole mess:

1. Who gave Mr. Amlani my mobile number and e-mail address?
2. If it was NSCI - Under whose authority was my personal information shared with a third party.
3. Mr. Amlani used CC to send one of the e-mails and therefore has now shared the entire e-mail list with everyone marked on it.

Scenario 2: The Airline Trying to Survive

The Backstory: I tend to use unique e-mail addresses for various account registrations, which allows me to efficiently manage e-mail, spam, etc. For e.g. if I was registering for an account on the website of ABC Pizza, I would probably use [email protected]. 

So when I registered my account on the Fly Kingfisher website - I ensured that I used a unique e-mail address that would only be used for that particular purpose. Now earlier today, I received an e-mail from someone called "HighOnTravel" offering me some travel packages on that particular e-mail address. There was no mention of Kingfisher in the e-mail and the e-mail even suggested that I received it as I must have signed up for it on their website. Again, this raises a couple different concerns for me:

1. Who gave Kingfisher the right to sell my information?
2. If the information was sold officially and legally - shouldn't appropriate bulk mail practices have been used?

Scenario 3: The Anti-Corruption Corruption

The Backstory: I am a supporter of the Anna Hazare movement for the implementation of the Jan Lokpal bill. As such, I had signed up for newsletter on their website which had promised to keep me up-to-date with future events, etc.

Once again, I used an e-mail address that was unique to the particular organization and was not used anywhere else. A few weeks after signing up for the newsletter, I started receiving random e-mails about various social causes, mails where I was marked as part of petitions for unrelated issues, random marketing mails - even an e-mail from Think Digit offering me some special subscriptions. My concerns here are the same as above.

In all of the above scenarios, there are a few different common trends or root causes if you will.

• Organizations seem to find it amazingly easy to sell / distribute personal information.
• There is a level of negligence when it comes to CC'ing people on such mass e-mails and therefore making a bad situation worse.
• Otherwise reputable organizations seem to completely ignore privacy regulations and spam regulations in-order to adhere to bulk mail regulations.

Based on all of the above - we as an industry really need to look at how we handle, manage and ration personal information. Although there are certain laws in place, we need to look at re-evaluation of said laws and their effectiveness. As end-users the only way we can protect ourselves is by using such random e-mail addresses for different registrations. For e.g. Gmail supports a wildcard functionality in e-mails. [email protected], [email protected], [email protected] will all come back to the same inbox. By using this sort of functionality while registering accounts, we can at-least start identifying organizations that are selling our information out there. Only when there is a certain amount of awareness and outcry will organizations as well as the government take such privacy concerns much more seriously.

Building security into business processes

Earlier today after months of avoiding it, I finally decided to go a few days without my faithful Blackberry and get the camera repaired. As I handed over my Blackberry, the technician returned a zip-lock bag with the battery, back cover and sim card.

This made me wonder, what about the hundreds of stored e-mails, thousands of accessible e-mails via imap, work documents, personal photos, phone records, contact information, etc that still remained on the device.

Of-course, I had the phone wiped clean several times and took my memory card home with me and disabled e-mail delivery from the online blackberry portal. But what was more concerning was the pile of Blackberry and other pda devices lying around the shop for repair or re-sale, most that previously belonged to Executives, IT professionals or Consultants.

This made me think about the need for businesses to build security into their day-to-day processes. Would it be so difficult for the shop to include an additional step / process for their customer's security? Not really.

Formatting a phone or implementing encryption on PDAs takes nothing more than a few minutes these days. Some may argue that not all users maintain regular backups of their phone data. There are several simple solutions:

1. If the user has a memory card, simply create a in-store backup of their device on their memory card and format the phone a few times. This can be done from within the phone it-self. It would take about 3 minutes and would allow the user to walk away knowing that there is no chance of any data loss.
2. If the user does not have a memory card, simply enable the phone encryption / access password option for the device and have the user type in a password.

Implementing any of the options would not take more than a few minutes and would provide an additional and much appreciated level of concern for their customer's data-security.

The point of this post isn't about a particular instance or a particular store or even a particular type of business. The point is, about the concept of implementing security into day-to-day processes that we take for granted. Many of these secure processes would require minimal modification, negligible time differences and minimal investment. Consider the following examples of some day-to-day processes where security could be implemented easily.

1. At petrol pumps, most attendants generally walk away with your credit card for several minutes while you're sitting in your car. Are mobile credit card readers really that difficult to implement? No.
2. Same as point number 1, but for restaurants, coffee shops, etc.
3. Almost 90% of hotel/resort reservations in India involve you giving your credit card details over the phone/e-mail. Implementing an online registration system, or even an automated phone system is not very expensive or difficult.
4. Most people/shops throw away credit card or ATM receipts that contain your name, dob, cc number, expiry etc. Investing in a shredder should definitely be a must for businesses and most importantly, they must definitely be available at most ATMs/Banks for customer's to use.

Day-to-day examples apart, lets think a bit more on the enterprise front:

1. Data security on mobile devices: Almost all organizations have executives that carry around laptops, tablets, pdas etc that contain sensitive information. Would it really be so inconvenient to add a step into their day-to-day processes to implement encryption? No. Full disk encryption would simply add one password prompt to their start-up and a fairly negligible performance difference. Passwords and encryption on Blackberry's and PDAs is also fairly easy to implement. A few clicks and your data's safe.
2. Whiteboards: I cannot count the number of offices I have walked into and found whiteboards filled with username/password information for SSH/RDP/FTP/DB etc. Again, implementing an open-source application like keepsafe will allow your employees to have access to complex username/password details with minimal fuss or interruption.

I could go on with examples for several pages, but the point to be made is: In most cases security is not so difficult. All it needs is for someone to sit down, make a step by step list of their various processes and how they could make them more secure with minimal interruption or problems to the end-user.

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.

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.

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.

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."

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".

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.