RSS
 

Archive for the ‘security’ Category

Self-signed SSL certificate warnings in Mozilla

04 Aug

Mozilla Firefox 3.0 throws a warning for self-signed certificate, and makes you do a couple of extra clicks to see the contents. Though some think its bad, I’m not sure what the fuss is all about. There are two reasons for the certificates. One is to encrypt the traffic, and the other to make sure no one intercepted your traffic using some kind of man-in-the-middle attack. One cant guarantee the second objective until a respected third party can sign/vouch the certificate. This is why these organizations exist.

imageIf this is such a big issue, the right approach should be for someone to setup a free certificate registry. There are few out there today like startcom, but the browser support on such registries is currently unimpressive.

Speaking on behalf of the 99% of the Internet population who doesn’t understand the significance of SSL certificates, I think the decision Mozilla took is courageous and admirable, and other browsers should do something similar if they don’t already.

 
Comments Off

Posted in security, ssl

 

Microsoft Live ID out : Google going to support OpenID soon… I predict

17 Aug

The other day I briefly mentioned the pain point of the web2.0 world and how consolidation, aggregation and summarization will help reduce some of it. Microsoft today formally announced the availability of Microsoft Live ID as a contender for the providing SSO (single sign on) services in the web 2.0 world. Live ID, incase you didnt know,  is the repackaged version of Microsoft Passport Network, which had failed so badly that it forced Microsoft to pull it out of the market. Here are some examples of how to use other languages like php, perl, python, ruby etc to do authentication using Live ID. Microsoft is not the first one to openly come out with a SSO technology. Liberty Alliance and OpenID are other opensource competitors which have some foothold in this market already.

The move to SSO, in the web 2.0 world, (Single sign on) is bound to happen regardless of how scary some people might find it to be. If you can trust your online bank with 100000 dollars and trust 3 companies you don’t really know with your entire credit history, then this shouldn’t be that much of a concern. The real question is whether you trust the technology leaders Microsoft, Google, Yahoo  or others like Verisign enough to provide these critical services for you.

In my opinion the reason why OpenID and Liberty Alliance have failed is because of fragmentation of standards and lack of leadership. While Microsoft failed the commercial venture into Authentication services (Microsoft Passport network) it might actually do well as long as it doesn’t screw up this time. Not because the they have done a great job in the past, but because the pain is now so unbearable that people are willing to give almost anything a try. But the real kicker is that almost everyone has a microsoft account anyway, so if I had an option to use my Microsoft account to login to a new web 2.0 product, I’ll do that in a heart beat. Creating yet another account with a new password and doing the email confirmation thing is not an adventure anymore… ( or may be I’m getting old ).

I predict that Google or Yahoo will soon jump into this with its own suite of authentication services (probably using OpenID or Liberty Alliance) which will then become the next battleground in the web2.0 world. I also predict that in a couple of years after that many of the web services will move towards supporting these forms of authentication services so that users are not forced to create new user accounts with new passwords every single time.

And if my predictions don’t really come true… hey, at least I know that I can dream.

References

 
Comments Off

Posted in internet, security, web20

 

DNS Rebinding what ?

13 Aug

Everyone who knows what a “DNS Rebinding attack” is please raise your hands. I’m so glad I can’t see yours, because I’m ashamed of myself for not knowing this one. For those who are “pretending” not to know please read on.
Browsers use domain names to enforce same-domain policy for a lot of security features. Interestingly depending on which client you are using its possible to set a low DNS TTL and change the IP address such that without a change in domain name a script could interact with another website as long as browser can be made to believe that its still the same domain. To do this, all that the client needs to do is initially server contents from its own server and while the javascript is running, update the DNS such that the javascript can interact with a new domain from where it could steel information for the attacker.

There are some safe gaurds to stop these kinds of attacks, but for most part these kinds of attack can be done easily on the internet today. The browsers are getting smarter though. And the “DNS Rebinding attack” isn’t new anyway… its been known for years at least. The way browsers try to defeat this is by limiting the minimum DNS TTL which can be set.

All was well and good until an attacker realized that the browser and plugins inside the browser each have different minimum DNS TTL set. So as long as the browser and plugin can talk to each other, there could be a point in time when the plugin could be talking to the attackers server and the browser could be connected to the real server streaming the information to the attacker through the plugin.
References

  1. Protecting browsers from rebinding attacks
  2. XSRF^2
  3. Anti-DNS pinning and DNS-rebinding attacks
  4. Defending network against DNS Reminding attacks
 
Comments Off

Posted in security

 

Scalable web architectures

03 Aug

I’ve been reading a lot about scalable web architectures lately and made a big enough collection of links to see that this could be interesting to others. Instead of putting all those links here in this blog, I’ve started a separate blog here http://www.royans.net/arch/. If you have an interesting link/links to share please send it over to me.

 
Comments Off

Posted in internet, security, storage, web20

 

Faking a Virtual Machine

19 Nov

One of the more popular trends in the recent years is the move of malicious code analysts towards virtual machines to test and reverse-engineer malicious code. And surprisingly the virus/worm writers have been adding mechanisms to their code to detect such environments.

I came across this particular piece of software called Themida which does exactly that. Lenny Zeltser from SANS reports about this on SANS. Whats interesting is that this kind of detection is now part of commercial packers around the world.
The question I have is this, how long will it take for someone to come up with a VMWare/Virtual Machine simulator/faker which I can run on my perfect non-virtual desktop/laptop/server and make malwares believe its running inside a Virtual machine ?

If that can kill even a small percent of fresh 0-day worms/viruses, it would be worth the effort. Wouldn’t it ?

 
Comments Off

Posted in security, vmware

 

The Blue Pill – 100% undectable malware

09 Aug

During Code Con 2006 7 months ago I first heard about the existence of virtual machines based rootkits. I’ve also been reading about hypervisor technology and about products like Xen which are trying to build a better virtual machine engines. Amd and Intel now, officially, have hooks in the processor itself to support this. Unlike traditional virtual machines which “emulate” all the processing within another OS, using this new technology, each OS could infact live along with each other talking directly with the processor.
But what took me by surprise is that within this short time of all this happening, there is a new technology called the “Blue Pill” which has been demonstrated and discussed in the underground world, which makes use of the virtualization features of the processors to make 100% undetactable malware.

Here is an extract from authors description of blue pill..

All the current rootkits and backdoors, which I am aware of, are based on a concept. For example: FU was based on an idea of unlinking EPROCESS blocks from the kernel list of active processes, Shadow Walker was based on a concept of hooking the page fault handler and marking some pages as invalid, deepdoor on changing some fields in NDIS data structure, etc… Once you know the concept you can (at least theoretically) detect the given rootkit.

Now, imagine a malware (e.g. a network backdoor, keylogger, etc…) whose capabilities to remain undetectable do not rely on obscurity of the concept. Malware, which could not be detected even though its algorithm (concept) is publicly known. Let’s go further and imagine that even its code could be made public, but still there would be no way for detecting that this creature is running on our machines…

References

 
1 Comment

Posted in hacking, programming, security

 

Google checkout and SSO

29 Jun

Google checkout is out, and as expected its so lean and mean that I couldn’t figure out if it was actually a new google component. With froogle already in place, Google checkout can cash on the goodwill people have for its froogle service. I think this news is a big one for other business organizations, but probably isn’t as significant for end user.

Remember Microsoft Passport ? Now think Google Single Sign on. I noticed a story about it being released and pulled yesterday due to some unkown reason. Personally I’ve always supported Federated authentication system, because it can reduce security problems due to reduced number of passwords one needs to remember. However, using a 3rd party single signon over which we have no control is like the government trying to control/monitor our income. That being said I’m still ready to subject myself to Google’s Single sign on if it reduces security risks.

 
Comments Off

Posted in google, security

 

Dont mess with my packets

06 Mar

We had some emergency network maintenance done over the weekend which went well except that I started noticing that I couldn’t “cat” a file on a server for some reason. Every time I login to the box everything would go fine, until I tried to cat a large log file which would freeze my terminal. I tried fsck (like chkdsk), reboots and everything else I could think off without any success. Regardless of what I did, my console would freeze as soon as I tried to cat this log file.

My first impression was that the network died, then when I was able to get back in I thought may be the file was corrupted, or even worse, that we got hacked and “cat” itself was corrupted. To make sure I was not hacked, I tried to “cat /etc/paswd”. And that worked fine. Then I tried to cat a different file in the logs directory and found that to freeze too. I figured that something is wrong with the box and gave up on it for the night, and decided to worry about it on Monday morning. Which was today.I go in to work this morning, and find a whole bunch of users complaining that they can’t go to any webserver on a particular loadbalancer in a this part of the DMZ. So, now I have a network modification, a bad unix file system and a loadbalancer (with few webservers behind it) all malfunctioning at the same time. With adrenalin kicked in, blood pressure rising, and 2 cups of coffee, I figured that there had to be something common between all of these.
After a little bit of investigation I found out that none of the users in my network are able to get to any of the servers in the target network using web. And though ssh is working fine, we couldn’t “cat” any large file on any of the servers in that network. Weird.
I tried to recollect a previous incident where some packets were not getting through a firewall which made the ssh session freeze. If every server on the same network has the same problem, it had to be a problem with one of the routers or firewall in between. So I did the next logical thing, which was to setup tcpdump on both sides of communication. This would allow me to sniff traffic at the moment the “freeze” happens.
Sure enough I see a whole bunch of packets going by, until I do a “cat logfile”. Thats when hell freezes over.

11:07:10.955656 server1.634 > server2.22: . ack 4046 win 24840  (DF) [tos 0x10]
11:07:10.958896 server1.634 > server2.22: . ack 4046 win 24840  (DF) [tos 0x10]
11:07:10.959221 server1.634 > server2.22: . ack 4046 win 24840  (DF) [tos 0x10]
11:07:10.959252 server2.22 > server1.634: . 4046:5426(1380) ack 1607 win 24840 (DF) [tos 0x10]
11:07:10.959538 server1.634 > server2.22: . ack 4046 win 24840  (DF) [tos 0x10]
11:07:10.959573 server2.22 > server1.634: . 6498:7878(1380) ack 1607 win 24840 (DF) [tos 0x10]
11:07:10.962011 server1.634 > server2.22: . ack 4046 win 24840  (DF) [tos 0x10]
11:07:10.962040 server2.22 > server1.634: . 7878:9258(1380) ack 1607 win 24840 (DF) [tos 0x10]
11:07:11.443579 server2.22 > server1.634: . 4046:5426(1380) ack 1607 win 24840 (DF) [tos 0x10]
11:07:12.433550 server2.22 > server1.634: . 4046:5426(1380) ack 1607 win 24840 (DF) [tos 0x10]
11:07:14.413493 server2.22 > server1.634: . 4046:5426(1380) ack 1607 win 24840 (DF) [tos 0x10]
11:07:18.373444 server2.22 > server1.634: . 4046:5426(1380) ack 1607 win 24840 (DF) [tos 0x10]
11:07:26.303489 server2.22 > server1.634: . 4046:5426(1380) ack 1607 win 24840 (DF) [tos 0x10]
11:07:42.172971 server2.22 > server1.634: . 4046:5426(1380) ack 1607 win 24840 (DF) [tos 0x10]

In the sniff above “server2″ is the server which is freezing and server1 was my desktop from where I was logging into. The interesting thing about the capture I did on my desktop was, that it accounted for all the packets which you see here except the last few packets which have the “ack 1607″ string in them. For those who don’t understand tcpdump, this is a capture of repeating packets which are not getting acknowledged by the other end.
So now we knew for sure that it has to be a routing or firewalling glitch of some kind. But it still didn’t explain why it was repeating. On a hunch I looked at the firewall logs to see if there is anything there about why its dropping my packets. May be it thinks that all of these servers are attacking it or something. It didn’t revile anything.

Mar 6 11:09:56 [10.1.10.5.2.2] Mar 06 2006 13:05:24: %PIX-4-106023: Deny icmp src inside:router1 dst vlan server2.22 (type 3, code 4) by access-group “inside”

But what I did see, is that once in a while, there is a weird log entry from the PIX (cisco firewall) complaining about an ICMP packet being dropped due to an ACL restriction. ICMP is a great protocol and almost every kid in the world knows how to use ping to find if a remote host is alive. What its also used for is error reporting and tracerouting. In our network we had ICMP enabled in such a way that errors being reported to the admin network are allowed to go through. And since there are too many reasons why errors should be going into a DMZ, they are generally blocked by edge-routers or firewalls. So the ACL which dropped the packet wasn’t that surprising. But what the heck is “type 3, code 4″ ?

Type 3, Code 4 according to RFCs is “The datagram is too big. Packet fragmentation is required but the DF bit in the IP header is set.” Fragmentation is the process of breaking down of large packets into smaller packets so that it can travel through network media which have different packet size limits. Finally, we know the reason why the packets were getting dropped. Apparently for some reason “DF” flag was getting set on the packets. DF (Dont Fragment) flag is a bit inside IP header which tells all intermediary devices not to ever “fragment” that particular IP packet.

Based on the PIX logs, it seems router1 dropped the packet and generated a “type 3, code 4″ error indicating the reasons why it dropped. Under normal scenarios any sniffer would have noticed an ICMP error packet coming back to server2. But since this was in a DMZ, and since inbound ICMP errors are getting dropped there was no way to know the reasons why some of these packets were going through.
The solution to this problem, apparently was to force the DF flag to be removed which then resolved all the connectivity problems. We also found out that all of our problems started sometime after the maintenance window during which some key networking devices were reconfigured.

 
Comments Off

Posted in interesting, networking, security

 

Two-way Two-factor SecureID

05 Mar

A lot of companies are moving towards two factor authentication which is a great because it tries to reduce the risk of weak authentication credentials. What it doesn’t do, unfortunately, is reduce phishing risk, which will become the next big problem after spamming. I wrote a few words on detecting phishing attacks a few days ago. This is the continuation of the same discussion.

“Passmark” and similar authentication mechanisms are one of the best current solutions in use today. Unfortunately, Passmark is one of those mechanisms which are built to be broken. The strength of this authentication mechanism, in this care, depends on the number of images in the Passmark database which according to the website is currently at 50000.

50000 variations might be alright for now, but we would be short-sighted if we stop at this. One of the serious drawbacks of this mechanism is that if the user guesses the users logon name, or captures that information in some other way, Passmark authentication effectively reduces to a one-way password authentication.

For example, if an attacker wants to steal a victims session and has somehow guessed the users logon name, all they have to do under the “passmark mechanism” is to go to the real website once with the users logon name and extract the image shown by the real website. Once this is done, since the image doesn’t change at all, ever, the attacker can prompt the victim with the cached image whenever the user logs on.

I think the day is not very far when companies like RSA will come out with two-way authentication mechanism where the token provided by the server keeps on changing. RSA already makes excellent two-factor one-way authentication, which changes based on time. They can easily extend it by doing a “two-way two-factor” authentication. If such a two-factor two-way authentication existed, even if the attacker knew victims logon name, he/she would have to go the real bank every time the user logs on, to get the latest SecureID token which the user could look for. Its just a mater of time after that for someone at the actual website to figure out phishing activity.

Before I end today’s rant, I’d like to admit that its totally possible that someone has already done this, and that I’ve just not seen it yet. If so, I hope it gets deployed fast.

 
Comments Off

Posted in hacking, phishing, security

 

Detecting Phishing sites

02 Mar

wikipedia [ "phishing is a form of criminal activity utilizing social engineering fraudulently acquire sensitive information, such as passwords and credit card details, by masquerading as a trustworthy person or business in an apparently official electronic communication, such as an email or an instant message. The term phishing arises from the use of increasingly sophisticated lures to "fish" for users' financial information and passwords." ]

According to Anti-Phishing.org there were 5490 more phishing sites reported in the month of December 2005 as compared to a year ago. And if you run a business which involves any kind of monetary (or identity) transactions, its just a matter of time before you become a victim.
A lot of companies today are working together to solve this problem, which is at least as hard, if not more, than shutting email-spam. The underlying reason why phishing is still a good business model is because the users aren’t technical enough to identify a phishing attack. As an example, one of the most common misconception among the users is that a secure website (running over ssl) with a valid ssl certificate is completely trust worthy. Unfortunately most users don’t know that getting a certificate is almost as simple as buying apples from a store. SSL certificates does help in encrypting traffic to a target server but it can’t tell you that you are going to https://www.ebey.com instead of https://www.ebay.com.

Help is on the way though. Some organizations are working on building visual tool (or a plugins) for the browsers which can intelligently identify and visually alert the user about a possible phishing attack. IE7, which is still in beta, aparently will have this tool built-into the browser itself. The sad part, however, is that most of these mechanisms still depend on the user to download and install, which may not happen overnight.

Most organizations which deal with sensitive data, are aware of the phishing problem and have a very reactive security team to identify and shutdown such websites. A few even take time to train its users. The lag between a phising website going operational to the point when its shutdown is still significantly long.

The technology behind such a detection engine for phishing attacks is not very different from that of a spam filter. They both rely on some kind of signature which have their share of false-positives and false-negatives. And just like spammers have been managing to get through our spam sensors, its just a matter or time before phising attacks will become more sophisticated.
For websites which have a more urgent need of anti-phishing intelligence, and cant wait for IE7 deployed everywhere, are resorting to a other interesting ideas. One which I have personally witnessed and appreciate is something called PassMark, which uses a two-way authentication mechanism instead of the standard two-factor authentication. In two way authentication, the server authenticates to the user before the user authenticates to the server. One example is where you select an image from a random set of images on the banking site. Before you enter your password to login, the banking website will show you the image you had previously selected. Since its easier to identify a change in image than detecting a minor variation in URL, this mechanism works well with technically-challenged users as well.

For a Phishing website to be setup by an attacker, the attacker has to mirror the real website. This is another area where security experts can setup their alerting agents. Unlike most search engines, attackers who want to mirror websites might download pages and images using automated tools which could behave differently than how a human operated browser will. Detecting such patterns might give the website sufficient heads-up to analyze and disable the offending website before the attack is launched.

But if the attacker succeeds to copy the content to setup a replica and moves to a different subnet, it might be hard to track and shutdown such websites. In order to maximize the number of victims caught in the trap (maximize profit) Phishing websites try their best to minimize service disruption for the users. Some websites will transfer users to the actual website almost as soon as username and password are types. One of the way to detect such attacks would be to analyze apache/www logs to look for “Referrer urls”. Since Referrer urls are reported by the browser for every HTTP request, there is a good chance that the Phishing site will leave a trace of its existence. If the server side application could detect “Referrer urls” coming from an un-authorized site it could proactively warn the user and shut the session down.

As I said before there are a lot of companies trying to solve this problem. I heard about one at CodeCon 2006 and I them fascinating. I hope we have some of these implemented very soon so that we IT folks can stop worrying about training the users and get down to do some real work.

 
2 Comments

Posted in hacking, internet, phishing, security

 
« Older Entries