Cyber Crimes Unit

Is there anything more annoying than infrastructure that turns on you?

For years we’ve been warned about the specter of hacker-induced nuclear power plant meltdowns, breached electric-grid control systems or Samsung TVs that let hackers watch you. We’ve even heard we could lose our data to juicejacking, when all we want is an emergency phone charge.

And the lack of security in SCADA systems? It’s more like SCAD-DON’T.

The latest entrant into the scary-infrastructure category comes from a technology that feels like it should be a lot warmer and fuzzier: namely, electric car-charging stations.

In a video recorded at Hack In The Box 2013 Amsterdam and posted courtesy of Help Net Security, Ofer Shezaf, founder of OWASP Israel, talks about the lack of security in these charging stations, which often amount to little more than a computer sitting behind a key-lock panel on the street.

A computer that takes customers financial and personal information, that is.

For three years, Shezaf, an application security expert, worked for a company that makes infrastructure for the car-charging stations.

The equipment in a charging station typically includes these components, he says:

• Main board;
• Communication equipment to connect with a central server and, often, with the internet;
• An RFID card reader that lets users identity themselves and begin charging their cars; and
• Electric components, such as a circuit breaker to protect from electrocution and a meter to measure the amount of electricity consumed.

Why do you need such a computer sitting on the street? Somebody has to pay for the electricity, Shezaf says, and controls are needed. You can’t have everybody getting electricity at the same time, or the system will fry.

But once you put a computer on the street, information security comes into play, as does the potential for hacking.

Here are the ways Shezaf says attackers might hack into an electric car-charging station:

1. Via physical access on the street equipment. The computers, typically Linux-based, are often protected with a panel opened with a simple key. Once an attacker opens the panel, he has access to the components, allowing analysis and reverse-engineering of hardware, CPU, and firmware. Also, attackers can connect via processor ports to enable real-time analysis while customers are charging their cars.



2. Via communications. In many cases, Shezaf says, there’s a large number of charging stations in a single parking lot, linked via serial connection, which he calls “very slow and very, very ancient, with very little security.” This can enable hackers to tap in to intercept information about the identities of the customers who are charging their cars, plus their payment information. Another potential is for attackers to conduct a man-in-the-middle attack.
3. Via RFID card. There’s high pressure on manufacturers to buy the cheapest ones available. Such cheap RFID cards are known to include either no encryption or insufficient encryption protocols.
4. Back doors that allow technicians to connect to charging stations and get immediate access. Maintainability is a key element of these large physical networks. It has to be cheap and easy for technicians to fix issues, Shezaf says. He found one example in an equipment manual online that describes how access to the charging station is gained through a physical key. Beyond that, there’s no security whatsoever – not even a password requirement.

What can hackers do once they’re in? Shezaf gave this list:

• Identity theft. Attackers can intercept information while people charge.
• Financial theft. Charging for free or charging on someone else’s account.
• DoS. A hacker can, for example, take out an entire parking lot, making cars inoperable. Hackers could also potentially shut down an entire network, shutting down electric car traffic in an entire city or region.

How likely are these types of physical attacks? Not very, Shezaf says, given a few things.

First, they sound simple, but they’re not:

“You need a subject matter expert. That limits the number of people who can do it.”

For one thing, encryption is a key challenge of securing charging infrastructure. But encryption is “a tough subject,” he says. There just aren’t that many people who know how to break it.

We don’t see charging stations getting hacked or, for that matter, planes falling out of the sky, but we do see virtual hacking galore.

The reason, Shezaf proposes, is that physical damage frightens us, from an evolutionary standpoint.

If you’re out to make some easy money, hacking a bank online is physically safe. The same can’t be said for physical attacks against, for example, smart cars or car-charging stations:

“While naturally criminals and nation states will use those techniques, a lot less people who are doing it for money will try to hack charging stations.”

Hopefully, that all adds up to this particular hacking scenario being relevant, for the most part, to Hollywood scriptwriters.

Follow @LisaVaas
Follow @NakedSecurity

Images of electric car, charging station and caution tape courtesy of Shutterstock.

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/i3iUQ5UiI3M/

Apple has released iTunes 11.0.3 for OS X and Windows today.

This update fixes a certificate validation issue for both Mac and Windows. If this vulnerability were exploited an attacker would be able to spoof an SSL certificate without a warning being presented, allowing the attacker to potentially execute arbitrary code.

They also fixed 40 other vulnerabilities in the Windows version of iTunes, which sounds really terrible (and might be), until you consider why.

iTunes renders a lot of HTML and Mac users already have the WebKit-based browser, Safari, installed on their Macs.

The Windows version of iTunes cannot rely on the Safari version of WebKit being present (thank God Apple doesn’t require Safari to be installed), so Apple includes the needed libraries inside of the iTunes for Windows package.

What is unclear is why Apple has waited for so long to release these fixes for Windows users of iTunes. Let’s take a look at the history of the oldest vulnerability fixed, CVE-2012-2824.

CVE-2012-2824 is a “use after free” vulnerability in the SVG parsing code in WebKit. It has a CVSS severity score of 10, is considered easy to remotely exploit and could result in remote code execution (RCE).

It was first reported on 27 April 2012 by miaubiz and was fixed in Google Chrome’s implementation of WebKit on 26 June 2012, about 2 months from initially being reported.

Apple’s first attempt at fixing this flaw was in iOS 6.0.1 and Safari 6.0.2 on 1 November 2012, approximately six months after being reported.

It is on of the vulnerabilities bundled into today’s iTunes 11.0.3 update more than one year after disclosure.

Another vulnerability of note fixed in today’s Windows version of iTunes is CVE-2012-5112, or as it is better known the Pinkie Pie vulnerability from Google’s Pwnium 2 contest at the Hack in the Box 2012 conference.

In combination with another flaw this bug won Pinkie Pie $60,000 USD and a Chromebook courtesy of Google.

While I do question the amount of time Apple needed to fix these bugs, that isn’t the point of this post.

The point is you should update iTunes now, especially if you are a Windows user who needs it to manage your music, movies, TV shows, iPad or iPod.

The latest version of iTunes for Windows or OS X is always available at http://www.apple.com/itunes/download/.

Follow @chetwisniewski

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/2qRw2SODRnk/

Members of the LulzSec hacking gang have been sentenced in London today, telling us what the judge thinks of their activities.

But why not tell us what you think, right here, right now?

Take Our Poll

Thanks for taking part in this poll, and come back soon to read more.

Follow @gcluley

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/8XMeduIoZBE/

Oh look, Sally Chipper wants you to like her new Page, Joe Smith is doing something with make-believe farm animals, and Misty Dogood wants you to sign three petitions.

Wouldn’t it be awful and yet kind of a relief were faux farmer Smith and all of his ilk to trip and fall on e-rakes?

Facebook thinks not.

It has, therefore, banned Social Roulette, an app launched on Saturday.

Social Roulette calls itself “a game of chance in which your identity is the grand prize.”

If you play, you get a 1 in 6 chance that your Facebook account will be deleted. Five out of six times, the app just posts “I played Social Roulette and survived” to your timeline.

It’s an online version of Russian Roulette: the game of chance in which a player places a single round in a revolver, spins the cylinder, places the muzzle against his temple, and pulls the trigger.

In this case, the chance was transferred to your Facebook temple. If you got a bullet through the Facebook skull, all your posts, friends, apps, likes, photos and games were removed before “completely deactivating” your account.

Social Roulette admits that “it’s very difficult to ‘permanently delete’ a Facebook account” and provides a link to Facebook’s instructions on ending your Facebook life as we know it.

In fact, the game gave the option of circumventing the kill switch.

That way, users could turn off their accounts but activate them later, without losing content and connections.

Co-founder Kyle McDonald told Tech Crunch that he recently whipped up the game (in four hours) as a quick fix for social networking exhaustion:

“Everyone thinks about deleting their account at some point, it’s a completely normal reaction to the overwhelming nature of digital culture. Is it time to consider a new development in your life? Are you looking for the opportunity to start fresh? Or are you just seeking cheap thrills at the expense of your social network? Maybe it’s time for you to play Social Roulette.”

As quickly as the game was created, so too was it axed.

McDonald says it took his team four hours to create Social Roulette, and within four hours of the launch Facebook responded by blocking the API key and restricting the makers’ ability to create Facebook applications.

Facebook flagged the game with an automated system for the crime of “creating a negative user experience,” McDonald said.

Facebook didn’t much like the logo, either, which features the Facebook logo’s “F” loaded into one of the six chambers of a pistol.

Facebook, in an official statement sent to Tech Crunch’s Josh Constine, didn’t specify which policy Social Roulette had breached, particularly since the game did give users that option of not deleting their accounts.

But heaven knows Facebook looks out for its warm, fuzzy glow, aka what it calls a “trustworthy” user experience:

“We take action against apps that violate our platform policies as laid out here: https://developers.facebook.com/policy/, in order to maintain a trustworthy experience for users.”

With its API access yanked, users can’t log in to Social Roulette with their Facebook account, nor can the game delete content from profiles.

McDonald, perhaps a bit optimistically, believes that Facebook will OK the game and that Social Roulette will live to kill again sometime this week.

Can account deletion be a good idea?

I can certainly understand the impulse, particularly if it’s motivated by Facebook activity that leads to, say, losing your job or that involves cyber bullying, or as a result of being victimized by revenge porn.

There are lots of reasons to delete your Facebook account: here’s a list of 10 from Business Insider.

Killing your Facebook account, however, is just one step. It doesn’t redeem your online reputation, nor does it allow you to rid yourself of trolls or disappear from the internet.

Still, users should have the option of pulling the trigger.

Pulling the trigger should be well thought-out. But Social Roulette wasn’t turning the decision into a casual one. It did, after all, offer users an opt-out.

I say, Facebook, let the game live.

Follow @LisaVaas
Follow @NakedSecurity

Image of blood drip courtesy of Shutterstock.

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/lO35cR8-u8k/

Just about every security company publishes some sort of prevalence data – those little bar charts and top tens showing the most important and widespread threats spotted in the last few days, weeks or months.

These lists are simple to absorb and make for easy, eye-catching PR stories: 90% of new malware comes from Greenland, 75% of spam is sent by the Vatican, etc etc.

At a more technical level, the raw data these summaries are based on can be a great resource for malware researchers, testers, security admins and academics studying the malware ecosystem.

How the data is gathered, compiled and interpreted is a rather involved and difficult process though, with plenty of opportunities for poor methodology choices leading to inaccurate or misleading results.

This week, I’ve been attending the AMTSO meetings in Bratislava, Slovakia, where prevalence issues have been the subject of some intense debate.

Picking the brains of the assembled experts from across the anti-malware industry (not to mention the major testing organisations, specialist security media and academia) has opened my eyes to some issues I’d not previously considered.

Data point

First up, why is prevalence so important? For product developers, it’s great to know what the biggest issues are. You can make sure you’re putting the effort into the right areas going forward.

Looking back, you can see how well your various techniques and technologies have performed, which ones need improving and which ones can be left as they are.

For sysadmins, it’s great to have a heads-up on a major new threat, to make sure your company networks are well secured and ready for the onslaught.

For testers, it allows tests to cover what really matters; there’s no way a test can hope to include every possible threat, so a subset has to be chosen, and accurate prevalence data allows that subset to be more representative of the real world, making the results more accurate.

Data sources

It’s no surprise that so many people invest so much effort into gathering this kind of data. Most products have some kind of ‘phone home’ feature, reporting back to base when a threat is spotted. Nowadays, many products use cloud look-up systems, which record reams of data on what’s being looked up at the server side.

In the enterprise, clients report back to central management systems, which may in turn feed back to product developers.

In these ways companies get to hear a lot about what their products are detecting.

Limitations of detection data

This is the first problem – what they are detecting. Prevalence is necessarily based on what people already know about, as it’s pretty hard to measure what you can’t see. So, a lot of things will go unreported, at least until such a time as they are spotted and detection for them is implemented.

For testers this is particularly problematic, especially when trying to test protection against emerging, targeted and zero-day threats.

But, in some cases, tests can be carried out on day one, as soon as something is picked up by the tester, and the importance of emerging threats measured retrospectively later on, as more information becomes available.

In some cases, testers may even prefer to work with vanishingly rare samples, the highly targeted attacks crafted for a specific purpose, as those can be the most devastating to targeted businesses.

Prevalence data can also help pin down just where these are, if only by their absence from the record.

Multiple sources

This limited vision can be improved by using data from a range of sources. The prevalence tables my team publish monthly at Virus Bulletin have long been compiled by merging together reports from several major firms (no easy task, given variations in the way data is recorded), and the disparity between what various people see most can be quite stark.

There is a cross-industry IEEE initiative offering a standardised format to facilitate sharing of metadata, operating alongside existing sample-sharing systems. The idea is that whenever people share samples with each other, they also share associated telemetry, info on when and where it was seen, how often, what it was classified as, and much more besides.

Once it is widely implemented, this system offers some opportunities for simplified and more accurate merging of data. This will hopefully lead to a clearer picture of the biggest threats.

Clustering

The second issue is defining exactly what a *threat* is.

For the most part, when looking at binary files, unique items are recorded by file hashes. But in many cases a single piece of malware will be morphed numerous times, either locally in the case of old-fashioned file-infecting viruses, or at the server side with modern polymorphic Trojans or poly-obfuscated script attacks.

So a single file hash may not be seen more than once, but it should ideally be classed as just one instance of a much bigger threat.

When looking only at one company’s data this can be avoided by simply splitting threat data by detection IDs rather than file hashes. When trying to cross-match reports between different products, these detection IDs will rarely if ever match up, making accurate clustering very difficult.

URL clustering

Similar issues apply to URL-related prevalence info. A test might use a URL as the sample, rather than a file, but the prevalence of that URL is difficult to measure, not least thanks to the tendency of malicious sites to come and go, sometimes serving up malware and sometimes not.

Some attempts may be made by reporting products to match up binary samples to source URLs, but this is very difficult and resource-hungry if the file is not detected immediately on download. It is also difficult to attribute a URL to a prevalent cluster of threats, as a given URL may redirect to different places each visit, serve multiple morphed versions of the same threat, or may just as well serve completely different threats from visit to visit.

Clustering these dangers by original source vector or by final infection type would give useful pictures from different angles, but both are very tricky to do.

Actual threat danger

In anti-malware testing, when we look at false positives, it’s a good idea to consider the prevalence of clean files. This ensures we’re not penalising products for detections on rare and obscure things, which are not going to cause anyone any problems in the real world.

But we should also consider the importance of files, and how much damage detecting them could cause. If a product false alarms on a component of your favourite game, it’s a minor annoyance; if it alerts on a key system DLL and cripples your machine, it’s a serious problem.

Likewise in detection tests, it is perhaps just as important to consider the actual danger of a malware sample, as well as how widespread it is.

An infection which runs a click fraud scam is not a welcome thing; as well as using up system resources, it opens up the system to further, more serious compromise. But in itself it doesn’t really harm the infected user much – it’s whoever is paying for the scammed Google ad clicks that’s losing out. Compare this to a banker Trojan which steals bank login info and drains your account.

So even if the first threat is seen much more often than the second, perhaps the significance of protecting against it should be consider slightly lower.

Measuring this significance is a major challenge though, and something that tends to be based on human intuition rather than nice clean science.

A brighter tomorrow

All in all, it’s clear that prevalence and telemetry data is vital stuff, hard to gather and handle, tricky to properly interpret, but bursting with promise.

New viewpoints on the same issue can bring up entirely new problems, and also new approaches to doing things better. That’s partly why expert groups like AMTSO exist: to facilitate this pooling of ideas, experience and knowledge.

The pooling of data from multiple sources is clearly the best way to produce the broadest, deepest and most accurate prevalence information.

I hope that cross-industry, cross-sector collaboration can overcome these problems to produce reliable, usable insights into just what’s going on out there.

Follow @Virusbtn
Follow @NakedSecurity

Image of Fighting frog, Brain cloud, and Brain number courtesy of Shutterstock

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/xSIdaEK25jk/