Tuesday, July 17, 2007

Identifying Phish

Today, I got a Mcafee link which apparently is a phish awareness testing quiz.So, off I went , took the quiz, got 7/10.Great. Now to the point: Somehow, I never expected a security company to offer lame ways of identifying Phish.
If I were to identify Phish, the easiest way is to just take a look at the address bar, and check the site (Yeah, the phisher can put an image on the address bar , but that is easy to figure out).Another precaution is beware of wrong SSL certificates. These 2 prime measures seem to have been conveniently ignored.
Just have a look:

This is the original aol phish page:



This is siteadvisor's explanation:


Bank of America Phish analysis offered by siteadvisor


Capital One Phish analysis


Its surprising how a security company promotes such crude means to identify phish.
The sad part is that these guys seem to imply that a site with correct grammar and graphics is NOT a Phish site.Imagine what such inference does to the grandma class of users. This is unfortunate.

Thursday, July 12, 2007

PhishPhighting

Today, in one of the orkut ( a social networking site ) communities, I read a post on how a guy lost his gmail id on a phish site. He posted the phish url, and warned others to be aware.

True, other than try and steer clear of them ,there is little one can do for a phish attack.Surely, there are tons of advise on how to guard from phish.Whats more, security companies are making money out of identifying and flagging phish sites.

Now that makes me wonder...Is there no other go? Reminded me of the "dont get mad, get even" adage.Lets see how we can do that. Think...what does a phisher do with the information he gleans?He uses it ,of course. From reading other’s emails to emptying bank accounts, they do it all.

From a security perspective however, there is no such thing as foolproof security. Its just a matter of making it more difficult for the bad guy. So, in our attempt to get even with the phisher, that’s what we focus on. We try and make it difficult for him to use phished information. How?? We flood the phisher with junk data. Data that is trash, maybe randomly or dictionary generated. Once we flood the Phisher's database ( or whatever backend he is using) with trash, its like finding the proverbial needle in the haystack for the phish guy. Imagine having one valid victim credentials and ten thousand other garbage credentials.The only possible way for a phisher is to actually use the victim information to find out if its genuine.

Later in the article I demonstrate how such a thing maybe accomplished.

Surely, a more competent phisher will then possibly deploy countermeasures to such flooding.He may implement tracking , session or in extreme cases captchas in his phish site,.Maybe he will filter out the flooding IPs.We will probably think of a solution when they get there. Remember, I am talking about raising the bar. Not about eliminating the problem. Still, its not difficult to defeat such anti - antiphish countermeasures (Captchas would be an exception though)

Also, remember, I am not talking about protecting yourself from phishers, I am talking about making their life miserable enough to wean them away from it.


The inspiration for this comes from the hilarious 419eater.com

Now, as promised earlier lets look at how one may accomplish this.

Before I do that, there are some tools , libraries and utilities that I used, To name a few , Paros , libcurl , perl, gcc , linux…Wow…

The phish site:



Then I fire up my favorite : Paros




Then I set my browser to use this proxy



And then I get victimized




Here is what the phish request looks like:



After trying this with various permutations and combinations of systems and credentials, I found that other than the credentials, everything else remains the same everytime I get phished.This means , I am in luck. All I need to hose the phisher’s inbox is to keep sending him garbage post requests. Great. Now to some actual work.

Now there are many ways I can swamp this guy. I can do a quick and dirty command line ( ahh…isn’t curl great !!!), or , write my own C code using libcurl, or do a plain and simple perl script that uses libcurl binding.

I tried all three. But somehow, doesn’t seem to be a good idea to publish the code. I haven’t actually hosed the guy yet, I am in an ethical dilemma. Gunning down someone ,even if that person is a crook , is still a crime. Let me sleep over it

Monday, July 2, 2007

business emails on 3rd party webmail servers?

The other day, I heard about an individual whose company email account was not functioning. There had been some problems with her account. Instead of getting it fixed by contacting IT and helpdesk , she started using her personal email id on gmail for business communications. Important and confidential information regarding the product she works on , code snippets, developer discussions are all a part of google data centers now.
What bothers me is that this is not an one off isolated case. There are probably countless other instances where people are sending out sensitive business information over 3rd party public email severs.
It's probably a matter of time before someone comes up with a proposal for harvesting and profiting from sensitive data on email data centers.

Friday, June 29, 2007

The penetration tester

As I mentioned in the last post, I was slated to interview a potential penetration tester.
At the appointed time, the guy walks in, with a voluminous stack of printouts of emails from various sources crediting his work.
Boy...was I impressed.A guy with close to 8 years of experience, well versed with both black box and white box, with experience on security focused code reviews, a member of a web app security group, exploits under his belt and what not ...
Still, I need to talk to him , assess his competencies.So, I write a few lines of code that creates an SQL query string on the fly using a fixed sized stack buffer, and ask for a review.
And then the punishment began.
He identified the buffer overflow . I asked him to explain the working of a buffer overflow.I got a "are you stupid" stare, and my candidate went on tangentially about a tool which can detect all "unsafe" function calls, and report it.I prompted him to focus on the question, he goes on again on a remarkable tool that he used ( No, he wasnt the author of the tool, but an user) to discover web app security vulnerabilities. Well done, I said and moved on...

"Explain to me an XSS".He jumped to it. He explained.And I listened.We went to a site which had a blatant "staring you on the face" XSS. He explained to me again that he uses yet another "tool" for detecting XSS, and wont be able to answer my question without access to his tool.

But then, I do look for a possible flash of brilliance from people I interview. You can't expect people to know everything, can you? So, I go back to the code , and ask him how to mitigate the buffer overflow.

The contrived code was something like this

int userExists( const char *name)
{
char buffer[1024];
sprintf(buffer,"select * from users where name='%s'",name);
return runQuery(buffer);
}

Solution...replace sprintf with
memcpy(buffer,name, strlen(name) - 1);

At this stage, I had two options...thank him for his time and interest, or pull my hair out.
I still have hair on my head...

Resume padding can only get you an interview.Beyond that, you gotta know your stuff dude...

Tech Jargon

Two days ago, I was chatting with a lady ( lets call her Mary ) in the HR department.I was about to conclude the conversation
Me : I have to go now , Mary, I am scheduled to interview a guy.
Mary : Why don't you take up some of my work and let me interview the guy ?
Me : You can do an interview on "penetration testing" ??

Mary goes red in the face, looks embarrassed, and returns to her desk without replying.I wonder why.
Later in the day I realized . To the uninitiated, "penetration testing" seems to have a generous helping of sexual connotation.

I emailed her a wikipedia link which explains penetration testing :-)

Moral of the story: Do not use tech jargon in day to day life

Sunday, June 17, 2007

To hell with privacy

I am in an important discussion at office , and my cell rings.

Caller: Good evening Sir, This is **** from citibank. You have a "first citizen" card with Shoppers stop , right.
Me : Yeah , I do
Caller: Sir , we are offering life time free credit card to "First Citizen" card holders.
Me : No I am not interested , thank you.(Disconnects)

I have been getting 2 calls a day now , one on my fixed line ,and one on my cell, wanting me to signup for a citibank credit card. Its a different person each day , with the same story. shopper's stop, citibank ...
All this , because I signed up with SHOPPER'S STOP 's loyalty program,a store that doesn't care 2 hoots for your privacy , and goes on to share your personal information with every tom dick and harry


The bottom line : Unless your life depends on it , be wary of divulging your personal details, because once you do , there is no respite.

Friday, June 15, 2007

So here it is

During my last post I talked about a networking site that looked to have a problem with their site. Sine then, I have written to them detailing my understanding and interpretation of the issue, and they haven't got beyond thanking me and promising to have someone talk to me about it. Well , its been a long while, and apparently, they aren't interested.
So , here are the details on it:

http://linkedin.com/redirect?url=http://anerobic.blogspot.com sends you to this page.
url encoding the request to obfuscate it used to work earlier, when I first reported the problem, but stopped working after that. So , apparently, they did something, I mean, some fixing, to weed out potential phish bait urls which were url encoded. So, this doesnt work anymore

http://linkedin.com/%72ed%69re%63%74?url=%68tt%70%3A%2F%2Fw%77w%2Ey%61ho
%6F%2E%63om


but this still works

http://linkedin.com/%72ed%69re%63%74?url=%72ed%69re%63%74?url=%68tt%70%3
A%2F%2Fw%77w%2Ey%61ho%6F%2E%63om


Keep up the good work LinkedIn.com :-)