Link

Ross Ulbricht, the alleged operator and mastermind of the underground website Silk Road was denied bail, which I guess is unsurprising given the vast amount of resources that have been invested into the investigation that lead to his eventual arrest.

Much of the material in the documents tendered to the court reeks of parallel construction. I believe that those who rely upon tor hidden services should be extremely concerned about their continued anonymity.

Advertisements

What Can We Learn From badBIOS

As time passes it becomes increasingly likely that we are unlikely to see compelling confirmatory evidence from Dragos Ruiu regarding his claims surrounding the malware he has coined badBIOS. One of his latest tweets begins with the disclaimer “No matter which way things work out with this search” which appears to be a stark contrast to the convincing way he spoke about his discovery just a few weeks earlier.

I’ve mentioned on this blog that malware of the type described is indeed technically plausible. One could produce a piece of traditional Windows malware that pulls the current BIOS image and attaches its own code to the image before reflashing. The small payload could simply ensure persistence in much the same way as the venerable anti-theft solution Computrace which was embedded into laptop BIOS images as an ISA component to assure persistence even if the HDD was replaced or erased. Computrace’s BIOS code had rudimentary NTFS support that allowed it to replace a file that Windows executes on boot (rpcnet.exe) with itself. The original file is renamed and is loaded by the persistence code once it has done its thing. In much the same way a trojan could either include its own code (if it was small enough) or run a small downloader to reinfect the machine. As many PCI devices include option code that the BIOS will execute on boot (e.g. PXE code from a NIC or a RAID controller’s array test code) this could also be a potential means of ensuring your code is executed at boot time.

The most controversial claim that Dragos made was that the malware was able to breach an airgap by using a laptop’s built in microphone and speaker. I have elaborated on this in a previous post and even linked to a functional proof of concept. Suffice to say that using the audio hardware to create a low speed mesh network is indeed possible but may be of low utility as throughput would be limited and the risk of detection would be significant. The latter could be minimized by incorporating some kind of negotiation to test the upper usable frequency of the hardware as high frequency characteristics differ wildly between vendors and are dependent not only on the DAC but also the speakers itself (with ceramic speakers being much more favorable) and vice versa on the receiving end. Another technique would be to first sample the ambient noise in the room. It is possible that while a quiet room would allow for an ideal SNR if stealth is the goal a moderately noisy environment may be more useful to mask the noise generated. By using the system clock and sampling the ambient noise the malware could determine a likely time when the environment is unattended (e.g. if it is 0300 local time and the area has been silent for many hours it is a fair bet everyone has gone home). Using the minimum effective amplitude would also make sense.

The most incredible remark that Ruiu has made was that the malware was cross platform and could spread via a USB thumb drive on both Windows and BSD with the latter occurring even when the device hasn’t even been mounted. While we can speculate that the malware was somehow modifying the flash controller of the infected USB thumb drives to present some kind of string that would exploit the system during USB device enumeration I believe the likelihood of not only this occurring but also of the bug being leveraged to allow some kind of cross platform infection is remote. This appears to be the weakest of his arguments.

If we assume for the sake of this argument that Dragos has misdiagnosed the existence of badBIOS, what can we learn from the experience? Well, certainly the first lesson to any aspiring security researcher would be to organize themselves prior to going public. Our hypothetical researcher should have concrete proof that an issue exists and have elucidated the purpose and origin of the malware. It would also help to have a sample of the malware to share with others. Even if this delays your disclosure by weeks or months, it is imperative that you can successfully defend your findings. Failing to adhere to this advice could be disastrous to your reputation and by extension your future career prospects.

Secondly, if you need external help then there should not be an issue in asking for it. Sometimes a second set of eyes will be able to resolve an issue that an individual could be stuck attempting to understand for an extended period of time. From Ruiu’s public discourse on Google+ and Twitter it appears that he has been sitting on badBIOS for approximately three years. Bringing in the community at an early stage and doing so without poorly researched grandiose claims of a new “advanced persistent threat” (ad nauseum) would be well advised.

My final point is that you can bet that malware authors have been reading all about Ruiu’s allegations regarding badBIOS’s feature set and at least some of them will attempt to emulate some of the traits that Ruiu suggested badBIOS possessed. This means that malware that leverages audio hardware or perhaps ensures its own persistence by appending itself to your current BIOS image (in much the same way as Mebromi) are likely just around the corner. In a way, just speaking about badBIOS will likely bring something similar into existence in the medium term.

We can hope that this has drawn some attention toward some aspects of the PC architecture that really aren’t all that robust. Perhaps the ability to flash a BIOS from within the operating system has seen the end of its useful life. In this day and age where all BIOS setup tools have their own integrated flashing tool with USB support then it would make sense to deprecate and eventually remove the ability to reflash except within setup. Cryptographically signing BIOS updates won’t necessarily mitigate some of the issues we have touched on so long as vendors continue to produce BIOS customization tools for their OEMs that invariably leak or are reverse engineered.

I sincerely hope that Dragos Ruiu’s analysis is at least partially on target, however as time goes by I am becoming increasingly skeptical that we will obtain the evidence that we are looking for to confirm the existence of such an advanced threat. Nevertheless as security professionals we must consider the entire system as a whole to assess its overall security. The ability to reflash the BIOS (and other peripherals that, by extension could allow arbitrary code injection on startup) from within user mode remains a concern of mine that is yet to be fully mitigated.

Link

The Register posted recently about a new Linux backdoor discovered in the wild on some compromised virtual servers that disguised its C&C traffic in an ssh stream to avoid detection.

While many are claiming this is a significant new threat I personally see this as just a more covert alternative to the traditional bindshell.

Terminal Cornucopia Exposes Security Theater

I often talk about many government (and corporate) security practices being mere theater. An appropriate example is the airport where post-9/11 paranoia has made a select few companies (body scanner manufacturers, explosive detection companies, portable GC unit suppliers, etc.) very rich while inconveniencing the majority of the public. Many countries around the world do not need elaborate hardware to maintain adequate security. Often behavioral monitoring by trained staff is far more effective as Israel has found.

With airport security there will always be some permeability and that’s expected. It is a trade off we must make to live in a nation that has any semblance of personal freedom. If this means the occasional hull loss through terrorism then so be it. The increased security has proven to be ineffective and easily adapted around.

Security researcher Evan Booth has published his findings on constructing weapons using items available after security screening. I can’t say I am surprised that all this additional security could be for naught. There’s vigilance and then there’s paranoia. We must always ensure in IT our security procedures do not adversely affect usability to the point of making the product unusable. This is a real world example.

Link

OSNews has a interesting article on the potential security vulnerability goldmine that is the modern phone baseband. I have a lot more to add to this subject including how the baseband could covertly aid the surveillance of a phone user, but I will leave this for a more thoroughly researched article that I will no doubt place upon this blog at some point in the near future (think E911 geolocation and remote enabling of autoanswer to create a “walking bug” as the FBI has been known to call them)

Link

InfoWorld security advisor Roger Grimes published an article entitled, appropriately enough “4 Reasons badBIOS Isn’t Real” describing why he doubts the veracity of Dragos Ruiu’s story. My personal belief is that while the core concepts that Dragos mentioned (persistence by flashing BIOS with an infected component, audio communication between compromised hosts using the upper audible frequency range, advanced detection evasion techniques) are all indeed practically possible to implement the entire story he has provided so far doesn’t completely add up. This isn’t to say that badBIOS doesn’t exist – it may just be achieving similar goals using different means (for example as his BIOS dumps appear clean it may instead be achieving execution at boot time by residing in a modified firmware of a bus connected peripheral – such as the video or Ethernet card. The BIOS dutifully executes the “option ROM” of each connected device – you may have seen this with, for example the PXE boot function of your Ethernet card).

Unfortunately as more time goes by it appears increasingly likely that we may not receive a prompt resolution in this saga. I maintain that Dragos is a professional with sizeable credibility as an event organizer and I continue to take the man at his word that he has indeed a new kind of APT. Naturally extraordinary claims require extraordinary evidence and both myself and the community eagerly await a full analysis and a sample.

BlackHash Allows Password Audit Without Access To Hashes

When performing a security audit, particularly as an outside consultant you may occasionally encounter “trust” issues, particularly when requesting sensitive information. Often this is simply required to complete the work that their execs have paid you to perform, but in the case of password strength auditing Richard B. Tilley’s BlackHash provides another alternative.

In the traditional process the security auditor will request a dump of password hashes from all systems that are to be scrutinized. Sources would include /etc/passwd (or shadow on shadow password enabled hosts), SQL (often used as a backend for RADIUS servers and other AAA systems), Active Directory, etc. All sources are dumped and then provided to the security team to run through dictionary cracking software like hashcat. The problem, of course, is that any guessed passwords could then be used for nefarious purposes and one has to trust the security team implicitly.

A more traditional way would be to anonymize the data provided. The simplest way of doing such a thing would be to provide only the hashes to the security team. They would report back with the weak hashes and the company’s trusted internal IT department would grep for the affected hashes and notify those users. This isn’t an ideal solution for a variety of reasons, the most obvious being that the security auditor still has a list of the hashes and this can’t be a good thing. Blackhash solves these problems by using bloom filters, which basically results in a workflow where the trusted IT team run the data into blackhash to produce a filter which the security team can then run against their dictionaries. If weak hashes are detected the file of weak filtered hashes is returned to the trusted IT team who then run it back through the software to determine the users and hashes affected.

Yes, it sounds convoluted and possibly isn’t of much help as most security audits require permissions which could be potentially more damaging to an organization than even leakage of their passwd files. Given the more paranoid organizations will have the security auditor accompanied by at least a minimally trained sysadmin at all times this appears to fill a niche need. Nonetheless I am continually impressed with Tilley’s work, which includes TCHead.