Update: According to a post on lwn that I can’t find at the moment, they’ve already reverted this decision with a subsequent update. It should be resolved soon.

…without root privileges, without authenticating.

Yeah, you read that right. SANS has the writeup:

A “bug” created back in November against the latest Fedora release (12) indicates that, through the GUI, desktop users of the Fedora system are able to install signed packages without root privileges or root authentication.  Yes, you just read that correctly.  (I’ll give you a second re-read that sentence so I don’t have to retype it.)  Yes, “it’s a feature, not a bug”.

In all my travels I’ve only ran across one company, ever, that has Fedora rolled out as an enterprise operating system on every desktop.  But what kind of security implications does this have?  I obviously don’t have to explain why this is (may be) a bad idea to the readers of the ISC, as we are all security minded people.

Now, the restrictions.  This change does not affect yum on the command line.  This only affects installing things through the GUI.  (Not that helps any, as most users will be running the GUI anyway.)  You can also disable it.

…

Currently in the bug, there is some debate about if they should revert this feature.  So, this may be just temporary.

I’m sure this shouldn’t affect most people’s real deployments of anything, since Fedora has always been something of a moving target and has, in my experience, been completely unsuitable for widespread deployment in an organization for a wide variety of other reasons. But just because it’s not appropriate for enterprise customers doesn’t mean that desktop users have nothing to worry about.

That’s because this extends the attack surface for malicious intruders by a really impressive amount. By allowing users unauthenticated access to play with the package manager, you create a nearly infinite attack surface for anyone looking to obtain a local privilege escalation on the system. Imagine this: you don’t need to exploit any one specific system service, because once you find a hole in something, anything at all that can be targeted in a default out-of-the-package configuration, you can install it and exploit it.

I’m not 100% aware of the implications of how this is designed — I may be fundamentally misunderstanding something that’s going on in the back end, and this may not be a Really Bad Thing. But imagine this: someone finds a bug in Firefox, or Flash, or Java. They exploit it to gain the ability to run arbitrary code under the user’s account. They can now silently install  Cfengine, Puppet, Bcfg2, or another root-configured service in the background using PolicyKit. They then attempt to exploit these services, which shouldn’t be running in the first place, and if they succeed, suddenly they have root access to do whatever they want.

Let me slip on my tinfoil hat for a minute: say some minor package maintainer gets through Fedora’s release engineering processes, and under the radar, slips a surreptitious backdoor into a package that only a handful of people use and nobody really keeps their eyes on. Where previously the damage might be so localized, from the package’s disuse, to be pretty much useless, now that package can be slipped into anyone’s system at will through a local unprivileged user exploit.

SELinux mitigates this, absolutely, and unlike in Debian, most important things won’t start by themselves until they’re explicitly enabled by the administrator. But the back door is there even if it’s locked, it’s only a matter of time until someone finds a real-world way to abuse this in very bad ways, and I really wish they would seriously consider reverting this behavior to something a bit less dangerous. This could be a very useful tool in a corporate environment, but the way I understand the situation right now, it’s a very bad default.

Slashdot linked to an interesting analysis of an ISCA Labs report, done by Help Net Security, about the underperformance of various network security products. The meat of the analysis focused on how most products fail to achieve certification on the first test, but I found this particular statistic incredibly enlightening:

Rounding out the top three is the startling finding that 44 percent of security products had inherent security problems. Security testing issues range from vulnerabilities that compromise the confidentiality or integrity of the system to random behavior that affects product availability. Even though it can be a demanding process, certification with a trusted, established third party is critical to verifying product quality, states the report. Product categories studied were: anti-virus, network firewall, Web application firewall, network IPS, IPSec VPN, SSL VPNs and custom testing.

The report has some caveats. For example:

Even the technology used to store and access test data has seen substantial change. We certainly cannot make the claim that a single, consistent data collection method was employed across all products throughout the timeframe of this study.

Check out the rest of the report; it’s a good read. I’ve long been of the belief that most high-end security products (beyond typical endpoint stuff) are snake oil and don’t provide any kind of real ROI; this report does nothing to change my opinion, especially in the IPS space, where a really remarkably huge portion of the sampled products failed to achieve certification.

El Reg writes:

Devious virus writers have come up with a new twist on ransomware-style malware.

A new strain of Trojan encrypts recently-opened files on compromised Windows PCs. But instead of demanding a ransom for a decryption key to unlock files, the malware relies on users to search the web for a possible way-out.

Hackers have cleverly baited searches for likely terms, with links to sites offering a supposed fix actually developed by the crooks behind the ruse.

A fuller explanation of the scam can be found Symantec’s write-up on the Ramvicrype Trojan here and in a blog posting by Symantec researcher Shunichi Imano here. ®

Say what you will about the data-centric approach of The New School of Information Security, there’s one fact that’s undeniable: money drives malware in the 21st century, and they’re getting smarter and smarter about how they take it.

A few weeks behind the ball on this one too, but I ran across it in a security discussion and it was way too cool (in a perverse sense) not to share:

From Wired.com:

New Malware Re-Writes Online Bank Statements to Cover Fraud

New malware being used by cybercrooks does more than let hackers loot a bank account; it hides evidence of a victim’s dwindling balance by rewriting online bank statements on the fly, according to a new report.

The sophisticated hack uses a Trojan horse program installed on the victim’s machine that alters html coding before it’s displayed in the user’s browser, to either erase evidence of a money transfer transaction entirely from a bank statement, or alter the amount of money transfers and balances.

The ruse buys the crooks time before a victim discovers the fraud, though won’t work if a victim uses an uninfected machine to check his or her bank balance.

The novel technique was employed in August by a gang who targeted customers of leading German banks and stole Euro 300,000 in three weeks, according to Yuval Ben-Itzhak, chief technology officer of computer security firm Finjan.

“The Trojan is hooked into your browser and dynamically modifies the text in the html,” Ben-Itzhak says. “It’s a very sophisticated technique.”

The information appears in a cybercrime intelligence report (.pdf) written by Finjan’s Malicious Code Research Center.

The victims’ computers are infected with the Trojan, known as URLZone, after visiting compromised legitimate web sites or rogue sites set up by the hackers.

Once a victim is infected, the malware grabs the consumer’s log in credentials to their bank account, then contacts a control center hosted on a machine in Ukraine for further instructions. The control center tells the Trojan how much money to wire transfer, and where to send it. To avoid tripping a bank’s automated anti-fraud detectors, the malware will withdraw random amounts, and check to make sure the withdrawal doesn’t exceed the victim’s balance.

The money gets transferred to the legitimate accounts of unsuspecting money mules who’ve been recruited online for work-at-home gigs, never suspecting that the money they’re allowing to flow through their account is being laundered. The mule transfers the money to the crook’s chosen account. The cyber gang Finjan tracked used each mule only twice, to avoid fraud pattern detection.

“They instruct the Trojan that the next time you log into your online banking account, they actually modify and change the statement you see there,” says Ben-Itzhak. “If you don’t know it, you won’t report it to the bank so they have more time to cash out.”

The researchers were able to capture screen shots showing the rogue bank statements in action, disguising, for example, a transfer of Euro 8,576.31 as Euro 53,94.

The researchers also found statistics in the command tool showing that out of 90,000 visitors to the gang’s rogue and compromised websites, 6,400 were infected with the URLZone trojan. Most of the attacks Finjan observed affected people using Internet Explorer browsers, but Ben-Itzhak says other browsers are vulnerable too.

Finjan provided law enforcement officials with details about the gang’s activities and says the hosting company for the Ukraine server has since suspended the domain for the command and control center. But Finjan estimates that a gang using the scheme unimpeded could rake in about $7.3 million annually.

“The example we found relates to German banks,” Ben-Itzhak says. “But we believe this will increase to other countries.”

From one of my favorite blogs, TaoSecurity:

I forgot to mention another thought in my last post “Protect the Data” from Whom? Intruders are not mindly attacking systems to access data. Intruders direct their efforts toward the sources that are easiest and cheapest to exploit. This produces an interesting corollary.

Once other options have been eliminated, the ultimate point at which data will be attacked will be the point at which it is useful to an authorized user.

For example, if a file is only readable once it has been decrypted in front of a user, that is where the intruder will attack once his other options have been exhausted. This means that the only way to completely “protect data” is to make it unusable. If data is not usable then it doesn’t need to exist, so that means intruders will always be able to access data if they are sufficiently resourced and motivated, as explained in my first post on this subject.

This meshes pretty well with my philosophy on information security — it doesn’t matter how much security you layer onto the server side. For any sufficiently secure system, your weakest point of potential compromise is almost always going to be your clients. Banks and online payment services (such as Paypal) have learned this the hard way. For every breach, no matter how insignificant, there are millions of successful phishing attacks.

So many system administrators forget about the client side of things because it’s not their job. Big mistake.