Security News

As if regular hacking wasn’t bad enough, a man in Texas took it upon himself to illegally access a computer system and then go after over 100 people’s cars. Customers of Texas Auto Center were affected as their vehicles began to honk incessantly, or worse yet, not start.

Computer System Hack Leads To Disabled, Honking Cars

Kevin Poulsen reported, “The dealership used a system called Webtech Plus as an alternative to repossessing vehicles that haven’t been paid for. Operated by Cleveland-based Pay Technologies, the system lets car dealers install a small black box under vehicle dashboards that responds to commands issued through a central website, and relayed over a wireless pager network. The dealer can disable a car’s ignition system, or trigger the horn to begin honking . . .”

Only as it turns out, a dealer’s ex-employee can do the same things if he gains access to the system.

Omar Ramos-Lopez, who was let go from Texas Auto Center last month due to his driving record, used another employee’s account to wreak havoc for about five days. The trouble only stopped when the dealer changed all of its Webtech Plus passwords.

The police then got involved (prior to the password change, a malfunction of sorts had seemed possible), and they found Ramos-Lopez after sifting through IP addresses. The next step involved Ramos-Lopez’s arrest, and he now faces between 120 days and two years in jail if convicted on computer intrusion charges.

Meanwhile, it’s a good bet that at least 100 Texans are reconsidering how much technology they want in their cars. Maybe learning how to wield wire cutters, too. Many people missed work or school due to the incident, and a fair number had their cars towed to have repairs performed.

This is almost enough to make you feel lucky if you lose a netbook or laptop to malware.

Whether or not the American government knows it, we’ve apparently gone to (cyber) war. Iranian authorities claim to have arrested 30 people who were part of an online conspiracy, and they’ve attacked 29 sites that were supposedly backed by the U.S., too.

Iran Cracks Down On Alleged U.S. Cyber War Network

“The Islamic Revolution Guards Corps (IRGC) on Sunday announced that its cyber teams have hacked 29 websites affiliated with the US espionage network,” according to the Fars News Agency. The IRGC alleged that “the hacked websites acted against Iran’s national security under the cover of human rights activities.”

Obviously, this isn’t great news for relations between the two countries. Iran’s infamous for making bold statements about its willingness to retaliate, so we may see U.S. institutions under attack online before long.

Also, even if nothing happens, this case brings up questions that may be familiar to fans of Wag the Dog. The concept of cyber warfare has made it easier than ever for countries to fake attacks and spin things to suit their needs, meaning a pretense for war can be created with ease.

It should be very interesting to see how this situation resolves itself. At least Iran isn’t supposed to have nukes or any missiles capable of reaching the U.S. just yet.

A significant percentage of consumers continue to interact with spam despite their awareness of how bots and viruses spread through risky email behavior, according to a new survey by the Messaging Anti-Abuse Working Group.

Half Of Email Users Have Opened Spam

Even though over eighty percent of email users are aware of bots, tens of millions respond to spam in ways that could leave them open to a malware infection.

The survey found half of users have opened spam, clicked on a link in spam, opened a spam attachment, replied or forwarded it, actions that leave users susceptible to fraud, phishing, identity theft and infection. While most consumers said they are aware of bots, only one-third believed they were vulnerable to infection.

“Consumers need to understand they are not powerless bystanders. They can play a key role in standing up to spammers by not engaging and just marking their emails as junk,” said Michael O’Reirdan, MAAWG chairman.

“When consumers respond to spam or click on links in junk mail, they often set themselves up for fraud or to have their computers compromised by criminals who use them to deliver more spam, spread viruses and launch cyber attacks,” O’Reirdan said.

Less than half of the consumers surveyed saw themselves as the individual who should be most responsible for stopping the spread of viruses. Yet, only 36 percent of consumers believe they might get a virus and 46 percent of those who opened spam intentionally.

Younger consumers tend to consider themselves more security savvy, possibly from having grown up with the Internet, yet they also take more risks. Among the survey’s key findings:

*Almost half of those who opened spam did so intentionally. Many wanted to unsubscribe or complain to the sender (25%), to see what would happen (18%) or were interested in the product (15%).

*Men and email users under 35 are most likely to open or click on links or forward spam. Among email users under 35 years, 50 percent report having opened spam compared to 38 percent of those over 35. Younger users were also more likely to have clicked on a link in spam (13%) compared to less than 10 percent of older consumers.

One of the problems of covering security-related surveys is that the participants often aren’t representative of SecurityProNews readers; it’s a good bet that you guys are a lot more cautious than the average individual. But readers of Symantec’s Security Response blog were recently quizzed, and their approach to dealing with passwords seems worth repeating.

Symantec Discusses Password Use In The Security Community

It turns out that 45 percent of the readers who responded only have a few passwords that they use for different accounts. Which is a better approach than having just one password, of course, but significantly worse than having a lengthy list of unique ones. Also, 63 percent of respondents admitted to changing their passwords “not very often.”

On the bright side, 72 percent of the respondents haven’t used their birthday, their middle name, a pet’s name, “password,” or a variation of “123456.” Furthermore, 59 percent of respondents rely on their memory rather than another means of tracking passwords, and 57 percent of respondents haven’t given their passwords to their coworkers, friends, or spouses.

Hopefully this will give you a good idea of where you lie along the security continuum. And even if remembering numeric substitutions for Shakespeare passages isn’t your cup of tea, being better than average is definitely something to aim for.

Symantec’s Kevin Haley recommended achieving this by using odd characters, altered words and phrases, and lengthy terms.

Since Adobe Reader 9.3.1 came out, Secunia Personal Software Inspector has been reporting that I’m running a vulnerable version of Adobe Reader whenever a full scan is performed. When I select rescan, the detection goes away.

The detected file is C:\Program Files\Adobe\Reader 9.0\Reader\AcroRd32.exe . But 9.3.1 didn’t update that file. Adobe unfortunately only updates a file version when they change a file, so you can only look at add/remove programs or find the specific file that changed.

I searched on the Secunia Community forum and found a relevant thread. A “Secunia Official” says”

“This is a know (sic) bug, and is in the hands of our developers. The problem is caused by old versions of Acrobat/Reader on other drives, and the PSI using version info from files in their subdirs instead of the version that belongs to the detected instance. Thank you for reporting it, and sorry for the trouble. In the mean time, using the local rescan should produce accurate results.”

I dont see any old versions of Adobe Reader on other drives, but I did find that under windows.old I had a duplicate program files directory with an old Adobe Reader. I have an ignore rule for the windows.old directory so that shouldn’t be the problem. But at least I know they have acknowledged this behavior as a bug.

Normally when they find a vulnerable file version in some odd place they list that as the vulnerable file. In this case there is nothing wrong with the file they are reporting on.

Google engineers find 20 kernel flaws, half of which are still not patched.

The New York Times has an article about cameras in the subways. The article is all about how horrible it is that the cameras don’t work: Moreover, nearly half of the subway system’s 4,313 security cameras that have been installed — in stations and tunnels throughout the system — do not work, because of either shoddy software or construction problems,…

Privacy isn’t always easy.

We’re close to landing some changes in the Firefox development tree that will fix a privacy leak that browsers have been struggling with for some time. We’re really excited about this fix, we hope other browsers will follow suit. It’s a tough problem to fix, though, so I’d like to describe how we ended up with this approach.

History Sniffing

Links can look different on web sites based on whether or not you’ve visited the page they reference. You’ve probably seen this before: in some cases, visited links are purple instead of blue. This is just one of the many features web designers use to make the web the best it can be, and for the most part that’s a good thing.

The problem is that appearance can be detected by the page showing you links, cluing the page into which of the presented pages you’ve been to. The result: not only can you see where you’ve been, but so can the web site!

Originally specified as a useful feature for the Web, visited link styling has been part of the web for… well, forever. So this is a pretty old problem, and resurfaces every once in a while to generate more paranoid netizens.

The most obvious fix is to disable different styles for visited versus unvisted links, but this would be employed at the expense of utility: while sites can no longer figure out which links you’ve clicked, neither can you. David Baron has implemented a way to help keep users’ data private while minimizing the effect on the web, and we are deploying it to protect our users. We think this represents the best solution to the problem, and we’ll be delighted if other browsers approach this the same way.

Technical Details.

The biggest threats here are the high-bandwidth techniques, or those that extract lots of information from users’ browsers quickly. These are particularly worrisome since they enable not only very focused attacks, but also the widespread brute-force attacks that are, in general, more useful to a variety of attackers (potentially including fingerprinting).

The JavaScript function getComputedStyle() and its related functions are fast and can be used to guess visitedness at hundreds of thousands of links per minute. To make it harder for web sites to figure out where you’ve been without radically changing the web, we’re approaching the way we style links in three fairly subtle ways:

Change 1: Layout-Based Attacks
First of all, we’re limiting what types of styling can be done to visited links to differentiate them from unvisited links. Visited links can only be different in color: foreground, background, outline, border, SVG stroke and fill colors. All other style changes either leak the visitedness of the link by loading a resource or changing position or size of the styled content in the document, which can be detected and used to identify visited links.

While we are changing what is allowed in CSS, the CSS 2.1 specification takes into consideration how visited links can be abused:

“UAs may therefore treat all links as unvisited links, or implement other measures to preserve the user’s privacy while rendering visited and unvisited links differently.” [CSS 2 Specification]

Change 2: Some Timing Attacks
Next, we are changing some of the guts of our layout engine to provide a fairly uniform flow of execution to minimize differences in layout time for visited and unvisited links. The changes cause all styles to be resolved on all links for both visited and unvisited states, and it is stored; then, when the link is styled, the appropriate set of styles is chosen making the code paths for visited and unvisited links essentially the same length. This should eliminate some of the easy-to-mount timing attacks.

Change 3: Computed Style Attacks
JavaScript is not going to have access to the same style data it used to. When a web page tries to get the computed style of a link (or any of its sub-elements), Firefox will give it unvisited style values.

What does this mean for users?

For the most part, users shouldn’t notice a change in how the web works. A few web sites may look a little different, but visited links will still show up differently colored. A few sites that use more than color to differentiate visited links may look slightly broken at first while they adjust to these changes, but we think it’s the right trade-off to be sure we protect our users’ privacy. This is a troubling and well-understood attack; as much as we hate to break any portion of the web, we need to shut the attack down to the extent we can.

We have to be realistic, though: there are many ways all browsers leak information about you, and fixing CSS history sniffing will not block all of these leaks. But we believe it’s important to stop the scariest, most effective history attacks any way we can since it will be a big win for users’ privacy.

If the remaining attacks worry you, or you can’t wait for us to ship this fix, version 3.5 and newer versions of Firefox already allow you to disable all visited styling (immediately stops this attack) by setting the layout.css.visited_links_enabled option in about:config to false. While this will plug the history leak, you’ll no longer see any visited styling anywhere.

Enhancing Privacy on the Web.

We want to bridge the gap between our users’ expectations of privacy and what actually happens on the web. Sometimes users have an expectation that we preserve their privacy a certain way, and if we can, we want to live up to it. Privacy isn’t a feature that can simply be added to a browser, though; it often comes at the expense of utility. We think we’ve found a fix that will balance flexibility for web developers while providing a safer experience for our users on the web.

Sid Stamm, Mozilla Security