Entries Tagged "Linux"
Page 2 of 4
Inevitably we’re going to see articles pointing at this and at Heartbleed and claim a trend in vulnerabilities in open-source software. If anyone has any actual data other than these two instances and the natural human tendency to generalize, I’d like to see it.
Today’s device from the NSA’s Tailored Access Operations (TAO) group implant catalog:
(TS//SI//REL) An active 802.11 wireless exploitation and injection tool for payload /exploit delivery into otherwise denied target space. NIGHTSTAND is typically used in operations where wired access to the target is not possible.
(TS//SI//REL) NIGHTSTAND – Close Access Operations • Battlefield Tested • Windows Exploitation • Standalone System
- (U//FOUO) Standalone tool currently running on an x86 laptop loaded with Linux Fedora Core 3.
- (TS//SI//REL) Exploitable Targets include Win2k, WinXP, WinXPSP1, WINXPSP2 running Internet Explorer versions 5.0-6.0.
- (TS//SI//REL) NS packet injection can target one client or multiple targets on a wireless network.
- (TS//SI//REL) Attack is undetectable by the user.
(TS//SI//REL) Use of external amplifiers and antennas in both experimental and operational scenarios have resulted in successful NIGHTSTAND attacks from as far away as eight miles under ideal environmental conditions.
Unit Cost: Varies from platform to platform
Status: Product has been deployed in the field. Upgrades to the system continue to be developed.
Presumably, the NSA can use this “injection tool” in all the same ways it uses QUANTUM. For example, it can redirect users to FOXACID servers in order to attack their computers.
In the comments, feel free to discuss how the exploit works, how we might detect it, how it has probably been improved since the catalog entry in 2008, and so on.
New paper: “Security Analysis of Pseudo-Random Number Generators with Input: /dev/random is not Robust, by Yevgeniy Dodis, David Pointcheval, Sylvain Ruhault, Damien Vergnaud, and Daniel Wichs.
Abstract: A pseudo-random number generator (PRNG) is a deterministic algorithm that produces numbers whose distribution is indistinguishable from uniform. A formal security model for PRNGs with input was proposed in 2005 by Barak and Halevi (BH). This model involves an internal state that is refreshed with a (potentially biased) external random source, and a cryptographic function that outputs random numbers from the continually internal state. In this work we extend the BH model to also include a new security property capturing how it should accumulate the entropy of the input data into the internal state after state compromise. This property states that a good PRNG should be able to eventually recover from compromise even if the entropy is injected into the system at a very slow pace, and expresses the real-life expected behavior of existing PRNG designs. Unfortunately, we show that neither the model nor the specific PRNG construction proposed by Barak and Halevi meet this new property, despite meeting a weaker robustness notion introduced by BH. From a practical side, we also give a precise assessment of the security of the two Linux PRNGs, /dev/random and /dev/urandom. In particular, we show several attacks proving that these PRNGs are not robust according to our definition, and do not accumulate entropy properly. These attacks are due to the vulnerabilities of the entropy estimator and the internal mixing function of the Linux PRNGs. These attacks against the Linux PRNG show that it does not satisfy the “robustness” notion of security, but it remains unclear if these attacks lead to actual exploitable vulnerabilities in practice. Finally, we propose a simple and very efficient PRNG construction that is provably robust in our new and stronger adversarial model. We present benchmarks between this construction and the Linux PRNG that show that this construction is on average more efficient when recovering from a compromised internal state and when generating cryptographic keys. We therefore recommend to use this construction whenever a PRNG with input is used for cryptography.
The BMC is an embedded computer found on most server motherboards made in the last 10 or 15 years. Often running Linux, the BMC’s CPU, memory, storage, and network run independently. It runs Intel’s IPMI out-of-band systems management protocol alongside network services (web, telnet, VNC, SMTP, etc.) to help manage, debug, monitor, reboot, and roll out servers, virtual systems, and supercomputers. Vendors frequently add features and rebrand OEM’d BMCs: Dell has iDRAC, Hewlett Packard iLO, IBM calls theirs IMM2, etc. It is popular because it helps raise efficiency and lower costs associated with availability, personnel, scaling, power, cooling, and more.
To do its magic, the BMC has near complete control over the server’s hardware: the IPMI specification says that it can have “full access to system memory and I/O space.” Designed to operate when the bits hit the fan, it continues to run even if the server is powered down. Activity on the BMC is essentially invisible unless you have a good hardware hacker on your side or have cracked root on the embedded operating system.
What’s the problem?
Servers are usually managed in large groups, which may have thousands or even hundreds of thousands of computers. Each group typically has one or two reusable and closely guarded passwords; if you know the password, you control all the servers in the group. Passwords can remain unchanged for a long time—often years—not only because it is very difficult to manage or modify, but also due to the near impossibility of auditing or verifying change. And due to the spec, the password is stored in clear text on the BMC.
IPMI network traffic is usually restricted to a VLAN or management network, but if an attacker has management access to a server she’ll be able to communicate to its BMC and possibly unprotected private networks. If the BMC itself is compromised, it is possible to recover the IPMI password as well. In that bleak event all bets and gloves are off.
BMC vulnerabilities are difficult to manage since they are so low level and vendor pervasive. At times, problems originate in the OEM firmware, not the server vendor, adding uncertainty as to what is actually at risk. You can’t apply fixes yourself since BMCs will only run signed and proprietary flash images. I found an undocumented way of gaining root shell access on a major vendor’s BMC and another giving out-of-the box root shell via SSH. Who knows what’s on other BMCs, and who is putting what where? I’ll note that most BMCs are designed or manufactured in China.
Basically, it’s a perfect spying platform. You can’t control it. You can’t patch it. It can completely control your computer’s hardware and software. And its purpose is remote monitoring.
At the very least, we need to be able to look into these devices and see what’s running on them.
I’m amazed we haven’t seen any talk about this before now.
EDITED TO ADD (1/31): Correction—these chips are on server motherboards, not on PCs or other consumer devices.
Interesting research: “Countering Kernel Rootkits with Lightweight Hook Protection,” by Zhi Wang, Xuxian Jiang, Weidong Cui, and Peng Ning.
Abstract: Kernel rootkits have posed serious security threats due to their stealthy manner. To hide their presence and activities, many rootkits hijack control flows by modifying control data or hooks in the kernel space. A critical step towards eliminating rootkits is to protect such hooks from being hijacked. However, it remains a challenge because there exist a large number of widely-scattered kernel hooks and many of them could be dynamically allocated from kernel heap and co-located together with other kernel data. In addition, there is a lack of flexible commodity hardware support, leading to the socalled protection granularity gap kernel hook protection requires byte-level granularity but commodity hardware only provides pagelevel protection.
To address the above challenges, in this paper, we present HookSafe, a hypervisor-based lightweight system that can protect thousands of kernel hooks in a guest OS from being hijacked. One key observation behind our approach is that a kernel hook, once initialized, may be frequently “read”-accessed, but rarely “write”-accessed. As such, we can relocate those kernel hooks to a dedicated page-aligned memory space and then regulate accesses to them with hardware-based page-level protection. We have developed a prototype of HookSafe and used it to protect more than 5, 900 kernel hooks in a Linux guest. Our experiments with nine real-world rootkits show that HookSafe can effectively defeat their attempts to hijack kernel hooks. We also show that HookSafe achieves such a large-scale protection with a small overhead (e.g., around 6% slowdown in performance benchmarks).
The research will be presented at the 16th ACM Conference on Computer and Communications Security this week. Here’s an article on the research.
In April, I blogged about the Boston police seizing a student’s computer for, among other things, running Linux. (Anyone who runs Linux instead of Windows is obviously a scary bad hacker.)
Last week, the Massachusetts Supreme Court threw out the search warrant:
Massachusetts Supreme Judicial Court Associate Justice Margot Botsford on Thursday said that Boston College and Massachusetts State Police had insufficient evidence to search the dorm room of BC senior Riccardo Calixte. During the search, police confiscated a variety of electronic devices, including three laptop computers, two iPod music players, and two cellphones.
Police obtained a warrant to search Calixte’s dorm after a roommate accused him of breaking into the school’s computer network to change other students’ grades, and of spreading a rumor via e-mail that the roommate is gay.
Botsford said the search warrant affidavit presented considerable evidence that the e-mail came from Calixte’s laptop computer. But even if it did, she said, spreading such rumors is probably not illegal. Botsford also said that while breaking into BC’s computer network would be criminal activity, the affidavit supporting the warrant presented little evidence that such a break-in had taken place.
EDITED TO ADD (4/16): On further analysis, this seems more reasonable than I first thought.
According to The Age in Australia:
“We would have to pay a lot of money,” said Sephery-Rad, noting that most of the government’s estimated one million PCs and the country’s total of six to eight million computers were being run almost exclusively on the Windows platform.
“Secondly, Microsoft software has a lot of backdoors and security weaknesses that are always being patched, so it is not secure. We are also under US sanctions. All this makes us think we need an alternative operating system.”
“Microsoft is a national security concern. Security in an operating system is an important issue, and when it is on a computer in the government it is of even greater importance,” said the official.
Sidebar photo of Bruce Schneier by Joe MacInnis.