In a Blog we posted a few months ago, we observed how hackers use social networking sites to develop target lists for phishing scams. We even had an unfortunate example of how such a scam targeted the White House.

Recently, in October 2012, Research by Deloitte identified that 82% of CISOs see phishing & pharming as their greatest cyber security threat.

Modern Phishing

It is important to note that modern phishing and pharming techniques are just as effective and scary malware infection vectors as more traditional threats, such as SQL injection.

Pharming attacks can hit an organization by impersonating or imposing on a software vendor, an open source organization or a user forum, where malicious code is hidden or redirected to from the offending Web site.

For example, a pharming infection might:

1. Either hack an existing site (a common practice) or build a site offering an open-source “plugin-for-something-great” and make sure that the link redirects to malicious software
2. Users that need this piece of software will download the payload, or hacker will use a 0-day to infect them directly from the browser.
3. Infect.

The Facebook Incident

Today, Facebook disclosed that several of its developers got Hacked. The infection vector as stated, was a drive-by malware exploit that was hidden on a mobile site the developers were using. The attack used a 0-day Java vulnerability to infect their computers.

Although Facebook denies having any data loss because of this incident, it is almost impossible to know that is really the case.

What does this incident teach us?

In Facebook’s case they claim no data loss, which is difficult to guarantee, unless data access is regulated with proper controls. Controlling data access in your organization ensures that incidents such as this do not result in data loss, even when malware 0-days cannot be prevented – you can prevent data loss and business deep hit.

Facebook is considered a young company employing brilliant minds that are very good at what they do, and as a technology driven company most of its employees would be considered technology aware. And yet, a malware drive-by has caused a breach.

It has been recently discovered that the Ruby on Rails (RoR) environment suffer from certain parser vulnerabilities. The CVE-IDs associated with these vulnerabilities are CVE-2013-0155, CVE-2013-0156.

Both of the issues stem from RoR parser vulnerabilities. The handling of complex objects representations such as XML and JSON serialization formats, fails to address some scenarios raises several security issues.

What are the vulnerabilities mentioned?

CVE-2013-0156
In essence, the RoR parser can be told by the attacker to automatically instantiate complex objects of the YAML and Symbol type. These complex object instantiation may involve evaluating some arbitrary, attacker controlled, Ruby code. Some sources report they were able to abuse this vulnerability to run some arbitrary operating system (OS) commands.  This means once the attacker can basically own the server completely.

This vulnerability is Generic in the sense that it’s not related to a specific application running on top of RoR, but to the RoR infrastructure itself.

An example could be found on Rapid7’s blog.

CVE-2013-0155
Using JSON, an attacker can pass an array instead of the expected atomic type such as an integer or a string.

Abusing that vulnerability, the attacker can smuggle a NULL in one of the array elements, and bypass an application specific “IS NULL” check designed for atomic types, because the array contains other values besides the null.

Note that this vulnerability exploitation is very specific to the context of the application itself.

An example could be found on the Ruby On Rails Google Group here.

How to stay safe
In order to stay on the safe side of the lake, you should always harden your application from any unused capabilities in order to lower the risk.

A few steps to consider:

1. Profile your application; only allow actions that are explicitly required. For example, if your application does not use XML/JSON, simply don’t allow that traffic. A WAF should have a capability to block access against “Unauthorized Request Content Type” with respect to the application profile.
2. Blocking the creation of YAML or Symbol type in web messages. A simple WAF rule would stop that activity.
3. For CVE-2013-0155 the logic is to simply to disallow null values to the specific vulnerable array parameters.

After thoughts
The Ruby on Rails vulnerabilities discovery prove the importance of White List security in the Web application world.  These issues show the importance of  only allowing what is specifically permitted and then specifically precluding known bad input values.

In a recent public disclosure via pastebin.com TeamGhostShell claimed to have stolen 1.6 million records off public websites such as NASA, FBI and more under a project named “Project White Fox.”

An open letter that TeamGhostShell published states that the campaign is more of an effort to encourage Hacktivism rather than focus on a target like other groups usually do.

By analyzing a partial sample of the data posted, it was clear that most of the data was captured from CMS systems, and that the extraction method was SQL Injection. The reason for that conclusion is the names of CMS systems within the database content that got extracted alongside well identifiable content characteristics, and the output format that is unique to the database attack tool SQLmap, and even though that was the majority, there was a portion of data in simple CSV format.

Some data that was disclosed was private information such as usernames, passwords and contact information.  In some cases, financial data was disclosed.

Looking into the activity in depth, it seems that most of the database dumps that were taken came from closed or open source CMS based web sites with known vulnerabilities.

Naturally, it seems that the targets were chosen out of a list of vulnerable websites based on the mapping of a vulnerability to a CMS based. Then, they used an automated SQL Injection tool to pull out the data.

Recently, US banks were warned about automated attacks coming from Havij, a SQL injection attack tool. While we've blogged on stopping SQL injection in the past, it is a topic always worth revisiting. 

First, let's make clear what WON'T help.  Earlier this month, Kevin Mitnick gave a talk at the US Naval Academy.  The first lesson?

All the firewalls and intrusion detection systems in the world won’t be a guarantee that networks won’t be breached.  There’s no such thing as an impenetrable system, and no such thing as bugless software. Kevin’s demonstration of exploiting vulnerabilities in widely used commercial software proves this. Moreover, this isn’t just software being used in the private sector.  Many of the exploits he demonstrated take advantage of software that’s become an integral part of the way the military handles its information.

Havij exploits vulnerabilities in software and is totally invisible to network firewalls/IPS.  Havij relies on a blind SQL injection vector, so if you protect against it you are safe.  Here's how:

1. Negative security model:  Protect against SQL Injection by blacklisting certain known SQL injection manifestations.
2. Positive security model:  Every injection violates the normal application usage profile.
3. Identifying automated interactions:  Havij is not human and behaves like a robot.  You can detect it by merely detecting the specific user agent string but also more subtle details such as constant values within the SQL attack itself.
4. Clean code.

From a technology standpoint, only three types of products will help defeat Havij:

1. Vulnerability scanners
2. Code scanners
3. Web application firewalls

Often, we see companies using vulnerability scanners and, to a much lesser extent, code scanning.  These technologies are very important but they only find issues.  Scanners tell you have problems but you have to figure out where they may be.  Code review gives you a specific line to remediate, but this takes time.  If you are under an imminent Havij attack, these products won't help with immediate risk. 

OWASP has argued in the past that technologies focused on finding vulnerabilities are useful but have one major problem:  they don't block attacks.  This is why they recommend a web application firewall.  (Full disclosure:  we are a WAF vendor.)  WAFs do provide a shield against immediate attack and--at least in our case--we can recognize Havij and stop it.  Havij does come with some WAF evasion functionality--but it only works on Web Knight and ModSecurity.

This incident reminds us how easy it is as an organization, even as secure and well funded like the White House, to get infected since antivirus is so porous.  Lucky for the White House, their team of security specialists were able to find the compromised entity, but it is not trivial and usually happens very late, if ever.

While "phishing" is a technique which by hackers mimic sites such as IRS , or your Bank etc, in order to lure you to submit your credentials.  “spear phishing” is the targeted technique of identifying an individual in an organization that the hacker wishes to compromise,and uses different techniques in order to lure that individual to activate malware on his/her computer. Effectively, creating the compromised insider.

As you can see below, finding an individual to target is fairly easy in todays social networking world. All a hacker has to do is look for “White House” as the current position and select which is pertinent:

There are several known as infection methods, the three most common include:

• Email attachment of either executable in an EXE form ( less common now ) or a PDF with malicious code in it
• Link distribution of an infected site, that once you go into you get infected. Can come via email or any form.
• A gift. Something as simple as a USB given at a convention that contains malware

We would encourage you to read our “The Quantum Mechanics of Spear Phishing” blog to get yourself more familiarized with how it works.

As we said before, here is what you can do to protect yourself as a company or an individual :

1. Assume you've been compromised.  For more, read this. 
2. Treat Social Network messages like you do with your Emails. Check who is it from and understand context before you choose to reply.
3. Make sure that in your social networks profiles, you are not sharing your contact information, unless you explicitly approve them.
4. As an organization, have the tools to protect your employees from such scams, and a policy in place.
5. Education:  train employees and raise the levels of awareness.

(NOTE:  An old Sunday School teacher taught, "repetition is the art of learning."  Let's hope that applies for spear phishing).

The European Agency Network Information Security Agency (ENISA) warned today that antivirus programs only work to prevent 30% of attacks and instructed companies to be more diligent about protecting themselves.  “Antivirus only works in 30% of cases to prevent cyber attacks, so it is necessary for security and technology go far beyond what has been done so far in the EU,” explained ENISA’s executive director. (Ironically, this hasn’t been covered by the English media yet.  The article above was sent to me by a Spanish colleague.)

By contrast, in the US, rather than warning about the shortcomings of antivirus, the FBI warned of a "new" virus attack.  Specifically, on 17 September, they cited a "new trend in which cyber criminal actors are using spam and phishing e-mails, keystroke loggers, and Remote Access Trojans (RAT) to compromise financial institution networks and obtain employee login credentials."  Of course, a different version of the same old attack is not really new.

Is ENISA’s directive part of a growing trend away from antivirus?  It seems so.  This snippet from a hacker forum highlights the fundamental problem with antivirus and the ease of evasion:

When Flame was made public, Mikko Hyponnen’s famous mea culpa was quoted repeatedly across the internet:  “Flame was a failure for the antivirus industry. We really should have been able to do better. But we didn’t. We were out of our league, in our own game.”

In his blog, Neil MacDonald asks, “Is Antivirus Obsolete?”

Both articles argue you need it but by itself antivirus is not enough. Fair enough: You want to have an antivirus because it provides signatures to protect you against the high volume of the known malware attacks.  But what about the hardcore hackers who write new stuff daily?  You need to take them into account when securing your stuff.  Hardcore hackers are not reusing exploits, they are finding them and writing their own payloads.  Consequently, they are ahead of the antivirus industry until the hack is found and gets patched. 

Some recommend expanding endpoint protection.  Not enough.  With an industry built on evasion, modern data protection policies should be all about spotting aberrant behavior and whitelisting.  A good policy for an organization will be to monitor for unknowns and unwanted behavior, but audit all activity for a period of time.  Reviewing audits based on business events.  Banks, for example, look for audit trail of users while those users are on vacation, so they know there shouldn’t be activity. In this way, you can ensure complete control of your data access.

After seeing the Dark Reading article, What the IPS Saw, the question came up was, 'What Didn't the IPS See?' 

Why?  The billions upon billions of data points they collected contained one glaring gap:  the Web application attack vector (SQL Injection and Cross Site Scripting to name a few).  Since many security teams falsely believe that IPS can block or mitigate application attacks and IPS vendors increasingly claim application security features, understanding the gap is important.  

Fact:  Hackers love web applications and databases
In 2011, according to Verizon’s Data Breach Report (page 39), 83% of all data breached was from databases and 80% involved web application breaches.  In the case of hacktivism, our report, the Anatomy of an Anonymous attack, highlighted the paramount importance application attacks play in a hacker’s arsenal:

Analyzing hacker forum data (over a period of a year) helps us understand what interests “private” hackers.  Again, web attacks are the vector of choice:

It is easily recognizable that the largest vector of attack was in fact SQL Injection.

Bear in mind that the zero-day and shell code percentages also include XSS attempts to inject malicious code, which means even if the payload is shell code; the injection vector is a Web XSS.

Brute-Force will also be included in the Web Application Attack vector, as it will be mainly the attempt to break web logins by running dictionary attacks at them, via—surprise!—the Web.

Why don’t I see this information in IPS reports?
The answer is quite simple. The reason you can’t see this information in IPS reports, is because IPS can’t see it.

IPS technology is designed to follow patterns and to either match signatures against traffic, or understand structure of a flow.  For example, in an exploit that is known, the system will have an updated (or so you hope) dictionary of signatures that will match and the session will be dropped. And in other cases, IPS might work on thresholds for amounts of traffic, or what is “known to be good practice” threshold.

Tautology vs. Signatures
Let’s single out SQL Injection to make an important distinction. A SQL Injection utilizes a True statement, meaning a statement that the SQL Interpreter will analyze and will say “yes, this is valid, I will now analyze this”. Unfortunately for the world of IPS, there is no limit to True statements in the world.  For example:

• a<>b
• 1=1
• 1=((2-1)*2/2)
• date(today) != char(57)
• JimmyPage > Life
• The list goes on...

The point here is very simple … you can’t write a signature for unlimited amount of terms, and you can’t predict behavior of an application by analyzing traffic as a pattern, since every application is written differently, and every developer has his/her own quirks.

You don’t use an IPS for Web application security, like you don’t install an antivirus to protect yourself against spam.

One of problems we see in the last couple of years, has a direct connection to the rise of social networking. Social networks such as Facebook, LinkedIn and others, may hide our most valuable personal information, but it exposes some.

A Spear Phishing attack is an attack where the hacker  targets a specific identity within an organization in order to either steal information directly from this entity, or use it as a springboard into the corporate network.

If a hacker wishes to gain access to a database within an organization, the best way to do so will be to gain access to a DBA’s computer. Why?  This job role will have almost unlimited access to corporate data.

The Social Connection

In the information age, anyone who’s anyone , and wishes to advance and improve his Career and business network, uses some sort of a social network online to show “I exist.”  However it introduces some serious risks.

Social networks such as LinkedIn allow very simple search by head hunters, HR or sales organizations in order to target specific individuals for employment. With the industrialization of hacking, what is the hackers view?

How?

A Hacker that whishes to SpearPhish a DBA at a company may find that identifying the targets have become a lot easier. All you really have to do is use a tool like LinkedIn’s Advanced Search and look for “DBA” as current job, and “<put-company-name-here>” as current company, maybe add the industry – and you’re done . LinkedIn will do the job for you:

Search results will show us exactly who to target.

What can individuals and companies do to protect themselves?

1. Don’t accept ALL invites you receive in your social network. Not everyone is trying to hire you or make business with you, some just want to get your contact info after they target you so they can send the phishing emails etc.
2. Treat Social Network messages like you do with your Emails. Check who is it from and understand context before you choose to reply.
3. Make sure that in your social networks profiles, you are not sharing your contact information, unless you explicitly approve them.
4. As an organization, have the tools to protect your employees from such scams, and a policy in place.
5. Education:  train employees and raise the levels of awareness.
6. Assume you've been compromised.  For more, read this.

Following our blog post regarding the Anonymous breach of the Apple/FBI data where over 12m personal records were claimed to be stolen via compromising an FBI Agent’s laptop via a Java Vulnerability, we decided to outline the hack in order to better explain how things worked in the wild.

What the Hack?

Anonymous have claimed to use a specific vulnerability in order to gain control over the FBI Agent’s laptop, browse and find an interesting file that they claimed to contain Apple device user information complete with personal user information - in a CSV file. They then downloaded it and distributed a portion of it, which was 1 million out of 12 million records, sanitized for only meta data.

Some background

For a while now, there has been a known Java vulnerability CVE-2012-0507, that effects specific versions of Java on all platforms and allows the remote attacker to gain control over its victim.

The hacker needs to plant the payload either via a website, email, hidden link etc – and once the user interacts with the link – the system is owned.

Hack Anatomy

Lets go step by step through the different phases of the attack itself, remembering that other than the hack itself, there was a reconnaissance phase to be able to identify the specific target and address him individually.

First, the hacker uses a framework to load the exploit code and generates a host to let the victim download the malicious payload:

Second, the victim is tricked to access the malicious host, by either persistent XSS infection on a site, malicious link in an email, or plain social engineering to name a few:

Once the target has activated the URL, the payload is activated via the vulnerability vector and a reverse session is opened between the hacker and the victim:

The hacker at this stage has full control on the machine and is able to launch commands including a prompt to execute code or search the victims host:

The hacker then looks for relevant information that he wishes to steal and downloads it from the victims computer

Game over, no quarter:

So far the best coverage of this breach in terms of how it occurred is here.  We hope to answer a few more questions that seem to be swirling on the Web.

Is this breach real?

Probably. We think so for two reasons:

• The FBI agent that was supposedly breached is real.  He’s a known recruiter in the FBI focused on getting white hat hack hackers to work for the feds.  Here’s his Facebook video:  https://www.facebook.com/video/video.php?v=512364171294
• The data base that was breached seems authentic—though only Apple can confirm.  However, the structure and format of the data indicates that this is a real breach.  It would be hard to fake such data.

What is new about this hack?

There are two things interesting about this attack:

1. Shows a new angle on hacktivism—This breach resembles a new innovation by hacktivists.  Specifically, they targeted an individual in the same way government-sponsored hackers (a.k.a., APT hackers) would attack.  Sure, Anonymous/Lulzsec targeted HB Gary in the past but we haven’t seen this type of attack reappear until now.  Is this part of a broader trend of hacktivists expanding their attack methods?  Could be.  For example, the recent Saudi Aramco breach used malware, a type of attack not normally associated with hacktivists.
2. This attack was not pre-announced—Normally, hacktivist attacks are pre-announced, often an Operation [FILL IN THE BLANK].  Doesn’t seem to be the case here.

What can hackers or FBI use this data for?

If the hackers have what they claim, they may be able to cross reference the breached data to monitor a user’s online activity—possibly even a user’s location.  To be clear, the released database is sanitized so you cannot perform this type of surveillance today.  But with the full information that hackers claim to have, someone can perform this type of surveillance.  This implies that the FBI can track Apple users.

What scams can we expect?

How many people will get infected “finding out” if their apple device was one of the 12 million?  Here’s one blog that already points you do a site where you can “check” if your creds were stolen: 

http://www.zerohedge.com/news/find-out-if-your-apple-device-was-among-12-million-units-hacked-and-tracked-fbi

How do we know if such sites are real or scams to find out your real credentials?  Sites like this sometimes appear after high profile breaches and consumers shouldn't visit them.