HP’s Built-in Keystroke Logger

Many HP laptops have a built-in keylogger in their audio drivers according to computer security firm Modzero AG (via Ars’ Dan Goodin). Keyloggers record what you type, typically covertly, for the purposes of someone else getting access to that text data later on. In this case the researches did not find any malicious capability in the driver that uploads the recorded text to a remote location, but it is very easy to access the data coming out of the driver by anyone who has access to your computer.

It would make it very easy for a piece of malware on your computer to track what you type without jumping through extra steps.

That HP shipped this audio driver on their laptops to thousands or millions of customers since 2015 is very worrying.

You can test your HP laptop for this vulnerability by checking the list of affected models after the break or just delete these files if they’re installed on your computer:
C:\Users\Public\MicTray.log
C:\Windows\System32\MicTray64.exe
C:\Windows\System32\MicTray.exe

Continue reading “HP’s Built-in Keystroke Logger”

Typosquatting Package Managers

Fascinating attack on unmoderated package managers for programming libraries (via former TimeDoctor contributor, Vogon)  that would work just as well on unmoderated app stores:

In the second part of 2015 and the early months of 2016, I worked on my bachelors thesis. In this thesis, I tried to attack programming language package managers such as Pythons PyPi, NodeJS Npmsjs.com and Rubys rubygems.org. The attack does not exploit a new technical vulnerability, it rather tries to trick people into installing packages that they not intended to run on their systems

[…]

So basically we create a fake package that has a similar name as a famous package on PyPi, Npmjs.com or rubygems.org. For example we could upload a package named reqeusts instead of the famous requests module.

It ends up being very successful:

In two empirical phases, exactly 45334 HTTP requests by 17289 unique hosts (distinct IP addresses) were gathered. This means that 17289 distinct hosts executed the program above and sent the data to the webserver which was analyzed in the thesis. The number of HTTP requests is for various reasons higher than the number of distinct IP addresses. The main reason is that pip executes the setup.py file twice on installation. Don’t ask me why.

Money in the Bank

Money in the Bank

The decades-old institution of civil asset forfeiture just got amazingly worse through the new practice of  seizing cash in bank accounts at a whim without any due process:

Now, the Oklahoma Highway Patrol has a device that also allows them to seize money in your bank account or on prepaid cards.

It’s called an ERAD, or Electronic Recovery and Access to Data machine, and state police began using 16 of them last month.  

Here’s how it works. If a trooper suspects you may have money tied to some type of crime, the highway patrol can scan any cards you have and seize the money.

[…]

News 9 obtained a copy of the contract with the state. 

It shows the state is paying ERAD Group Inc., $5,000 for the software and scanners, then 7.7 percent of all the cash the highway patrol seizes.  

Yow.

Also, this is the second website I’ve seen today that still requires Flash to watch their videos. Chrome makes an OK sandbox for that garbage but everyone should stop supporting it. 

Misleading Headline Popularity Rises 200%

In a post titled “1Password Leaks Your Data”  software engineer, Dale Myers, argues that 1Password’s 1PasswordAnywhere feature is very insecure. Here’s how Myers describes the feature:

For those of you who don’t know, 1PasswordAnywhere is a feature of 1Password which allows you to access your data without needing their client software. 1Password originally only used the “Agile Keychain” format to store their data (not including when they were OS X keychain only). This format basically stores your data as a series of JavaScript files which are decrypted your data when you supply your master password. Since the files are JavaScript and implementations of various crypto algorithms exist in JavaScript, there was no reason why AgileBits couldn’t come along and make a HTML and JavaScript client for viewing your data, so they did.

If you browse to your .agilekeychain “file” on disk, you find that it is actually a directory. Inside this directory is a file named “1Password.html”. If you access this file over HTTP (note that using the file protocol won’t work), you will be greeted with a grey page which has a lock image and a password field. Enter your password and your keychain will unlock and you have a read only view of your data.

So what’s the problem? Well, it turns out that your metadata isn’t encrypted. I discovered this after having a sync issue with Dropbox (I use Dropbox to host my keychain). The file that had issues was 1Password.agilekeychain/data/default/contents.js. Being a curious kind of guy I opened the file to see what was in there. The answer is the name and address of every item that I have in 1Password. Every single one. In plain text.

This contents.js file does exist. It describes in plain text every URL that you have a login for in 1Password, Myers also goes on to explain the security issue in greater detail and a post in response by Agilebits (the developer of 1Password) gives their roadmap for phasing out the AgileKeychain format that is still the default in 1Password today in favor of the OPVault format that they’ve been working on for years. Technical descriptions of both formats for storing passwords and metadata aside, the important part is that AgileKeychain has this issue and OPVault doesn’t and Agilebits is working on fixing it and moving everyone to the more secure format. Neither format leaks your passwords and the headline and content of Myers’ post is misleading.

Myers’ description of the security hole gets even worse:

But it gets worse. I decided to have a look and see just how bad things were. Thanks to people having links for easy access to their keychain on their websites, Google has indexed some of these. A simple search brings up results. By looking at one of these it was a simple matter to identify the owner of the keychain and where he lived. I know what his job is. I even know the names of his wife and children. If I was malicious, it would be easy to convince someone that I had compromised their account and had access to all of their credentials. Not to mention the fact that they have revealed their location online which may put their personal safety at risk.

And in describing the newer OPVault format:

…Since the data is stored as JSON, I can’t figure out why, but perhaps AgileBits decided having your keychain accessible on the internet isn’t the best idea? 

The conclusion a reader of Myers’ post might reasonably come to if they read nothing else is that 1Password has a security hole where every site you’ve ever logged into has been leaked publicly. 

AgileBits was going easy on Myers in their response. The truth is that none of this public sharing happens by default.

Even if you store your 1Password keychain in the current default format of the AgileKeychain and decide to use Dropbox for syncing, it is not automatically pushed out to the public. A 1Password user would have to ignore AgileBits’ instructions for accessing 1PasswordAnywhere via Dropbox’s website and intentionally choose the option to share the files publicly via Dropbox or another method.

If you use 1Password, and have decided to sync it using Dropbox, you can check if you have shared your keychain directory publicly by going to the sharing section of Dropbox’s website and checking the list of directories and files you share on Dropbox. I would be extremely surprised if many people using 1Password have done shared their 1PasswordAnywhere files publicly.

Myers’ article is barely accurate in describing the extent of the contents.js security hole. If your computer’s hard disk isn’t encrypted anyone who has access to your computer, or anyone who can circumvent the encryption on it, could easily access the contents.js file and know what sites you have logins for. If anyone was boneheaded enough to share the file publicly, they may have unknowingly also shared the list of sites that they’ve stored passwords for.

By default, the web browsers FirefoxSafari, and Chrome also leak all of our web browsing history in a sqlite formatted file that is trivially viewable by anyone who has access to an unencrypted computer with a sqlite database browser. Just like 1Password these browsers don’t by default store this information publicly and you would have to go out of your way to make the data more insecure by sharing it publicly on the web.

The majority of Myers’ article is misleading in giving the reader the impression that contents.js is shared publicly by default. It is good that in response AgileBits appears to be accelerating their timeline for moving everyone to the OPVault format for storing passwords and metadata, and it should not have required Myers’ public shaming to do that, but it is ridiculous to scare people off of this password manager when their passwords security was never in doubt as even Myers’ concludes at the end of his article.

When is it the Wrong Time to Be an Android User

Dan Goodin writing for Ars about newly published vulnerabilities:

There’s a new round of Stagefright vulnerabilities that allows attackers to execute malicious code on more than one billion phones running ancient as well as much more recent versions of Google’s Android operating system.

Stagefright 2.0, as it’s being dubbed by researchers from security firm Zimperium, is a set of two bugs that are triggered when processing specially designed MP3 audio or MP4 video files. The first flaw, which is found in the libutils library and is indexed as CVE-2015-6602, resides in every Android version since 1.0, which was released in 2008. The vulnerability can be exploited even on newer devices with beefed up defenses by exploiting a second vulnerability in libstagefright, a code library Android uses to process media files. Google still hasn’t issued a CVE index number for this second bug.

When combined, the flaws allow attackers to used booby-trapped audio or video files to execute malicious code on phones running Android 5.0 or later. Devices running 5.0 or earlier can be similarly exploited when they use the vulnerable function inside libutils, a condition that depends on what third-party apps are installed and what functionality came preloaded on the phone.

It is always the wrong time to be an Android user.

Ransomware

For most people reading this, I would suppose that you are already kind of familiar with the de-centralized bullshit currency, Bitcoin. Either you’ve tried it out and made a little bit of money mining it and then were quickly outpaced by minining farms, or you at least know a little bit about it. That is my guess, anyway. My first real introduction to it was when somebody gave me a few tiny pieces of Bitcoin that I promptly spent on a Humble Bundle once they started taking it in exchange for game bundles. If I had held onto that, it would have been worth significantly more virtual space bucks.

For most people, that is not their introduction to Bitcoin. It’s irrelevant to every day life, I haven’t really touched it since that one trial run buying some games and people just don’t need to know about it. But, for some folks, their first introduction was the day their computer files were locked off from them by the ransomware known as CryptoLocker. Radiolab’s latest episode (Overcast link) has an interview with someone who had no idea what Bitcoin or CryptoLocker was, and how she had to deal with this ransomware. Surprisingly, the people holding the ransom even have customer service.

Attack code exploiting Android’s critical Stagefright bugs is now public

Dan Goodin:

Attack code that allows hackers to take control of vulnerable Android phones finally went public on Wednesday, as developers at Google, carriers, and handset manufacturers still scrambled to distribute patches to hundreds of millions of end users.

The critical flaws, which reside in an Android media library known as libstagefright, give attackers a variety of ways to surreptitiously execute malicious code on unsuspecting owners’ devices. The vulnerabilities were privately reported in April and May and were publicly disclosed only in late July. Google has spent the past four months preparing fixes and distributing them to partners, but those efforts have faced a series of setbacks and limitations.

Can Apple ship that switching app for Android before stagefright gets patched in the majority of devices?

Will anybody even be able to find it in the Google play store among the scam apps that claim to support iMessage and make your Android device have an iOS-style (but terribly implemented) home screen?

Probably no Iranian kill-screen coming up

Schneier’s write-up of the Stuxnet worm is good:

None of this points to the Bushehr nuclear power plant in Iran, though. Best I can tell, this rumor was started by Ralph Langner, a security researcher from Germany. He labeled his theory “highly speculative,” and based it primarily on the facts that Iran had an usually high number of infections (the rumor that it had the most infections of any country seems not to be true), that the Bushehr nuclear plant is a juicy target, and that some of the other countries with high infection rates–India, Indonesia, and Pakistan–are countries where the same Russian contractor involved in Bushehr is also involved. This rumor moved into the computer press and then into the mainstream press, where it became the accepted story, without any of the origina caveats.

via Schneier on Security: Stuxnet. Make sure to check out the comments as well.