MetaFlows

Why Google Should Customize your Gmail Login Page to Prevent Phishing.

Thu, 27 Sep 2012 11:59:29 -0700

Disclaimer: The following post is uses Gmail and Google Accounts as a punching bag, but these problems discussed are both widely known, universal to identity providers on the web and not Google’s fault. Gmail has just been chosen to play the victim only due to it’s popularity and general bestness.

Password phishing attacks have been going on for over 25 years and the situation has only gotten worse. This post argues that by using a browser plugin to customize login pages on the client, attacks will have significantly greater difficulty forging believable login pages.

Two Phishing Attacks

I will argue this point by first showing two phishing attacks which would probably fool a fairly sophisticated computer user. These attacks are almost definitely not novel and are probably used in the wild. Compare these attacks to typical advice on preventing phishing. Consider the following two attacks:

Fake OAuth page: Websites will often allow users to authenticate with their google account using OAuth. If they are not logged into their Google account already it will ask them to login¹. The workflow looks like this:

Alice goes to a site that appears to have content that Alice wants.

To access the content Website requires that Alice authenticates with her Google account before making a purchase.

Alice clicks ‘authenticate with Google’ and is taken to a Google accounts login screen.

Alice enters her username and password and is then allowed into the site.

Eve wants to steal Alice’s password so she setups up a website as above but in step 3 Alice is sent to a fake, but realistic looking gmail login page. Alice just gave her username and password away. Eve can interactively check if Alice’s provided a real username/password by supplying it to Gmail to see if it works. If Alice had Two-Factor authentication setup Eve can merely request a verification code from Alice as part of the login request. In fact if Eve wants to change the password and lock Alice out of her own account she can claim that the first verification code that Alice supplied (as part of her second factor) was incorrect and ask for a second one (loading the page for 60 seconds to wait for the first verification token to expire).

Tabnapping: Gmail has a habit of signing users out of their gmail accounts, which has trained users to sign back in at random points during the day. This can be exploited by crafting a page which when it detects that the user is inactive or idle it transforms into a fake gmail page saying that user has been logged out and that they should login again. This general approach is called tabnapping.

Eve sents Alice a link to a fake Google Doc.

Alice opens link and goes to bed, while she is sleeping the fake Google Doc rewrites itself so that it looks like a “you’ve been logged out, please login here” Google page.

Alice wakes up, checks her laptop, logs into the fake Google login page. Game over.

Objections

Alice should be able to notice that she is signed into Google in other tabs: As [Google says]:(http://www.google.com/about/company/rewardprogram.html)

“At this time, the ability of malicious web sites to log users out of unrelated web applications is essentially unavoidable; it is a consequence of how the web is designed, and cannot be reliably prevented by any single website.” This means that Eve can log Alice out of her Google Account. In fact Eve can keep logging Alice out until Alice logs into Eve’s fake Google Account.

Alice can tell the difference between the fake login page and the real login page by inspecting the URL: Unfortunately there are really effective ways of making fake but undetectable urls (see also URL redirecting).

Alice uses HTTPS so she is safe: Phishing sites legally acquire valid HTTPS certificates. HTTPS offers zero protection in this scenario, other than the minimal cost to request a cert for a domain they control.

A Solution

The crux of the problem is that users have no way² of telling a real Google accounts or Gmail login page from a fake one since the styling of a login page can be easily copied.

Customize/Skin the Login Page: Users will often skin or customize the look of the internal gmail web application by choosing a theme. Google should force new users to choose a unique skin for their ‘trusted’ home computer and persist this skin even when they are not signed into their Gmail account so that the skin will be applied to the login screen for their Gmail account. This skin would persist on the client ³, so an attacker would not be able to learn it by querying Google. Since the attacker can’t learn the skin that user is using, the attacker can’t replicate what the user expects to see. Thus the attacker will have difficulty fooling the user⁴. An example skin is shown below.

qr-codes: For added security the page could display a qr-code which the user could scan with their mobile phone to log themselves in without typing in a password. Isaac Potoczny-Jones has a neat blog post on using qr-codes as authentication⁵.

Problems

There are several problems with training users to use the look of a website to determine its trustworthiness.

The unique skin is now acting as a authentication to the user, but browsers and security models are not designed to protect how gmail looks to a user. Screen sharing skype sessions, xss attacks and photos could expose the look of the skin which then an attacker could copy. Since the user now trusts login pages that have their unique skin they will be easier to fool if the skin is compromised.

This is a real risk, but users already use the look of a webpage to judge it’s trustworthiness. Most phishing attacks are not targeted and this would stop these sorts of attacks and seriously complicate more advanced attack.

The unique skin can not persist across clients. The first time a user uses a computer they have to login to a plain page or a page which has the skin of another user.

This solution probably wouldn’t be that useful for people that use many difficult computers.

Chrome already has this functionality in that you can sign into chrome.. Since you are signing into the browser rather than into webpage phishing is impossible.

Unfortunately, signing into Google Chrome does not automatically sign you into all your Google Accounts. Passwords can be saved in Google Chrome, but there are numerous ways to trick someone into entering their password into a realistic looking login screen.

For an example how legitimate sites do this go to goodreads.com in safe/incognito mode and click on the “sign in using Google” button. ↩

Yes, yes, they can check the certificate of the page and maybe catch a poorly generated cert, but how many times do you check the certificate of the page when you login to Gmail? ↩

This is really the tricky part as an attacker can wipe browser cookies at will. One surefire way would be to use a browser plugin or use the Google Chrome Sync functionality. ↩

All users can be fooled given enough time and effort. ↩

I don’t see any reason why Google is not doing this already. They support Two-Factor authentication. While qr-auth is as vulnerable as username/password schemes, a successful attack only steals a one-use token rather than a username and password. This would be perfect for situations in which someone is concerned about a keylogger. In fact if you combine qr-auth with a browser plugin it becomes more secure than username/password schemes since the plugin can verify if the page is gmail or not. ↩

Snort IP_List Performance

Fri, 10 Aug 2012 09:56:26 -0700

For a long time now we’ve been using a modification to snort that allows for more efficient processing of rules that match lists of IP addresses, but we’ve only recently taken a hard look at it’s performance properties.

In general, we rely on BotHunter for reputation alerts in snort and turn off the poorer performing reputation sets from other signature providers. However, we’ve had customers who have their own rule sets that follow the same method of matching long lists of IP addresses and have run into performance issues… so we broke out some perl scripts and ran some tests!

After the initial tests using tcpreplay showed a huge difference in the drop rate between the two methods, we decided to run snort directly against a 5GB pcap.

First using the standard reputation rule sets from ET Pro (1,365 rules which contain primarily long lists of IP addresses):

speed: 42605 packets per second
packet processing time: 210 seconds

Then we wrote up a script which would convert those rule files into a much smaller set of rules which reference the iplist component and ran the exact same trace:

speed: 218221 packets per second
packet processing time: 41 seconds

that’s a 512% increase in processing speed / throughput while generating the same alerts! no wonder the smart folks at SRI cooked this up for processing their reputation feeds.

The conversion script for list-of-ip type rules is still in early testing, and you’d have to be running our custom version of snort ( which is bundled with our sensor software https://nsm.metaflows.com/linux.zip ) or the snort that comes with BotHunter, but if you want to try this out then get in touch with us and we’ll be happy to work with you.

Ethan Heilman: Imagining a Secure Backdoor Cipher.

Thu, 09 Aug 2012 09:59:10 -0700

Ethan Heilman: Imagining a Secure Backdoor Cipher.:

ethanheilman:

Lets say that you have an unbreakable cipher (or it’s closest approximation) and that you, Eve, have the ability to break all other known ciphers. There is a risk that if you use or deploy your unbreakable cipher it may be captured by your enemy Alice and thus prevent you from…

A really interesting read, excellent work.

Current Events - top snort events for the last 24 hours, and a...

Wed, 08 Aug 2012 09:50:04 -0700

Top SIDs by Volume

Emerging Threats Current Events Hits

Current Events - top snort events for the last 24 hours, and a look at blackhole malware events that we’re seeing.

we also recovered the payload from one of these blackhole exploit kit hits, it was already known on virustotal.

Ethan Heilman: A Look at Security Through Obesity

Thu, 02 Aug 2012 17:10:37 -0700

Ethan Heilman: A Look at Security Through Obesity:

ethanheilman:

Jeremy Spilman has an excellent post (in two parts: part 1 and part 2) on ways to increase the security of the storing password hashes. Please read his full post for details as this post will be about the general idea and it’s further implications. I will be examining his scheme and…

More file extraction testing. Here we’re looking at the...

Wed, 01 Aug 2012 09:55:29 -0700

More file extraction testing. Here we’re looking at the highest ranked bothunter event for the last week, which is classified as “/snort-trojan-activity/Egg Download/: 1.7002773:E3-Egg Download ET TROJAN FSG Packed Binary via HTTP Inbound”. The reputation result from SRI is expected, and the direct integration to virustotal is working well.

Still not entirely sure why ntop is calling the windows client honeypot “ubuntu”, probably some kind of netbois naming confusion.

Overview of the last week of snort and service events for one of...

Tue, 31 Jul 2012 07:58:51 -0700

Overview of the last week of snort and service events for one of our server honeypot systems.

BotHunter Identified Malware Infections - Sunday July 29

Mon, 30 Jul 2012 11:07:50 -0700

BotHunter Identified Malware Infections - Sunday July 29:

Yesterdays BotHunter Events page. 30 excellent examples of infected systems and their profile data. Unfortunately the IP rep links aren’t publicly accessible right now.. but hopefully that will get fixed soon.

Does your company upload any malware you find to offensive computing?

Sat, 28 Jul 2012 18:06:00 -0700

Thank’s for the question! We haven’t so far, but it’s certainly possible. Our client honeypot systems crawl known malicious sites and are constantly encountering new (and old) malware, but we use the data primarily for ranking the real world severity of snort, log, and service events that are produced during the crawling. We do keep the payloads though (and do use them for testing our upcoming file-carving system and virustotal integration), at least for some time, and we’d like to learn more about offensive computing if our efforts could help to benefit the community.

quick investigation of a bothunter alert on an executable...

Fri, 27 Jul 2012 08:12:00 -0700

High Ranked Alert and Source Reputation

Quick tcpdump

Or if you prefer, tcpflow

File extraction for the binary

virus total results

quick investigation of a bothunter alert on an executable download, with a preview of our new file extraction system.

for the extra curious, here’s the virustotal link

Current Events: Seeing a lot of these corrupted/hostile excel...

Thu, 26 Jul 2012 07:54:00 -0700

Current Events: Seeing a lot of these corrupted/hostile excel rules from malware propagation sources lately.

BotHunter Users Google Group

Wed, 25 Jul 2012 07:57:55 -0700

BotHunter Users Google Group:

The staff here at MetaFlows has been given charge of setting up a google group for BotHunter users. This group is for helping people make the best of BotHunter. We use it in lots of deployments around the world and could not exist without it. We have a lot to contribute to the community of BotHunter users and hope you will share your ideas.

Feel free to join and share your experiences, ask questions, or brainstorm with us.

Current Events: Top SIDs that we’re seeing, by volume,...

Tue, 24 Jul 2012 07:43:17 -0700

Top SIDs by Volume

Client HoneyPot Current Events

Current Events: Top SIDs that we’re seeing, by volume, across all domains, as a snapshot from the last 24 hours. Also a quick look at the most recent events from one of our client honeypots, which is fed a constantly updated stream of suspicious urls to crawl and gives us good insight into what the most prevalent current client side threats are.

Lastline blog: Don't dismiss mass attacks

Mon, 23 Jul 2012 08:00:16 -0700

Lastline blog: Don't dismiss mass attacks:

lastlineblog:

With all the recent focus on APTs, cyber-espionage and the like, it is easy to dismiss some of the more “traditional” threats and attack vectors. However, dismissing threats does not make them go away.

Take spam, for example: botnets and rogue hosts are still churning out millions of spam…

We often see this same dismissive attitude for scripted “background noise” attacks such as mass brute force attempts or bots crawling for a short list of known vulnerabilities, as though only a highly targeted attack is a real threat. However, the number of new compromised systems we see on a daily basis do not lie; the attack that gets through is what counts, not the popularity of the buzzword it is associated with.

Resources For Using PF_RING

Sun, 22 Jul 2012 07:52:47 -0700

If you want to build stuff with pf_ring:

PF_RING Users Guide - official PDF from ntop

Official Download Page - from ntop

Instructions for PF_RING and Suricata on Ubuntu - OSIF wiki

Instructions for PF_RING and Snort on CentOS - MetaFlows website

Custom PF_RING source - version 5.1 with fixes from MetaFlows

If You want to buy stuff with pf_ring:

NICs designed for PF_RING with DNA Licenses

Pre-built appliances for PF_RING

Some cool graphs:

Got more helpful links related to PF_RING? or other cool graphs to add? let us know!

BotHunter Attackers List

Sat, 21 Jul 2012 07:58:38 -0700

BotHunter Attackers List:

Up to date list of current known malicious systems that have been identified by BotHunter users, Including forensic confidence data (number of users reporting, number of infection reports associated)

Do you use any type of cloud storage? If so, what kind, and why?

Fri, 20 Jul 2012 13:49:57 -0700

We use amazon EBS volumes for a lot of our storage. They are easy to manage, easy to move from one instance to another, and it’s easy to backup a whole disk with a snapshot. We’ve had great experiences with ec2/aws so far.

The Malware Lifecycle BotHunter is capable of declaring a host...

Fri, 20 Jul 2012 07:57:39 -0700

The Malware Lifecycle

BotHunter is capable of declaring a host infected when either of three dialog sequence combinations are observed:

Condition 1: Evidence of a local host infection, and evidence of outward malware coordination or attack propagation, or

Condition 2: At least two distinct signs of outward bot coordination, attack propagation, or attacker preparation sequences are observed.

Condition 3: Evidence that a local host has attempted to establish communication with a confirmed malware control host or drop site.

Learn more about BotHunter:

BotHunter.net

MetaFlows BotHunter Local Correlation

We're Now in the AWS MarketPlace - Neat!

Thu, 19 Jul 2012 16:12:00 -0700

We're Now in the AWS MarketPlace - Neat!:

You can now deploy MetaFlows sensors on Amazon EC2 through the Amazon MarketPlace. It is extremely easy to setup and you will be billed hourly as part of your EC2 instance subscription. You can use your existing MetaFlows account (or one will be automatically created for your), and monitor EC2 instances together with your existing physical sensors through a Browser.

Other Deployment Plans

Event categories for classifying the stages and types of malware...

Thu, 19 Jul 2012 07:59:01 -0700

Event categories for classifying the stages and types of malware communications. You can learn more at the BotHunter website http://www.bothunter.net/releasenotes.html

http://www.metaflows.com/technology/bothunter/