How to Check If Your Information Was Stolen in the Equifax Hack

To check if your information was stolen in that Equifax attack you have to attempt to sign up for a year of free credit monitoring through a service called TrustedID Premier that Equifax is providing out of the goodness of their hearts in order to get you subscribed to something you’ll have to pay for eventually:

  1. Go here
  2. Click on the button that says “Begin Enrollment”
  3. Enter the information you’re asked for.

If you’re given a date to enroll in the service your information was possibly stolen, it isn’t very clear if that is a guarantee or not. As over one hundred million accounts worth of data were stolen, it is extremely likely that yours will be too.

If you actually want this service you’ll have to come back to the same site on that day you’re given in order to sign up, because they’re staggering the sign-ups with this shitty enrollment program.

These services can’t really do much to protect you from people using your social security number and other personal information in order to sign up for services like cell phone plans and damaging your credit. The only thing that can actually prevent damage to your credit is getting your credit frozen which then makes doing anything that involves credit a nightmare.

This is an absolutely garbage response from Equifax to anyone affected by this attack. Credit agencies are some of the worst businesses and their executives should all be shot into the sun.

At this point my strategy is to just assume that my social security number is freely available to anyone who wants it and I constantly monitor the credit bureaus to check for any new accounts opened in my name.

The only legitimate place to get a free credit check is through Many other places attempt to sign you up for a monitoring service that also can’t do anything to protect you in the event that your information is stolen. I also use a service called Credit Karma that pulls reports once a month. Their business is to provide you with credit card offers (that you should never sign up for) in exchange for the data. They’re scum too, but at least they’re upfront about what kind of scum they are.

Equifax Managers Sold Stock Before Telling The Public About Getting Hacked

Bloomberg’s Anders Melin:

Three Equifax Inc. senior executives sold shares worth almost $1.8 million in the days after the company discovered a security breach that may have compromised information on about 143 million U.S. consumers.

The credit-reporting service said late Thursday in a statement that it discovered the intrusion on July 29. Regulatory filings show that three days later, Chief Financial Officer John Gamble sold shares worth $946,374 and Joseph Loughran, president of U.S. information solutions, exercised options to dispose of stock worth $584,099. Rodolfo Ploder, president of workforce solutions, sold $250,458 of stock on Aug. 2. None of the filings lists the transactions as being part of 10b5-1 pre-scheduled trading plans.

Equifax said in the statement that intruders accessed names, Social Security numbers, birth dates, addresses and driver’s-license numbers, as well as credit-card numbers for about 209,000 consumers. The incident ranks among the largest cybersecurity breaches in history.


Valve Games Were Vulnerable to Software Exploits When Your Character Died

The One Up Security firm, who must be very new because this is their only published research article and their domain name appears to have been registered about 8 months ago, has released information on a vulnerability that Valve patched in their Source engine back in June.

It’s an amusing vulnerability because the exploitation of it occurs when your character dies on a game server, and your character model’s ragdoll is replaced with an exploitative payload that the researcher was able to exploit because certain security flags weren’t set on portions of Steam. This is what you see in action when you watch One Up Security’s video embedded above.

Variety’s Janko Roettgers Interviews the Latest Hollywood Studio That Got Hacked

Some time last year the audio post-production studio, Larson, got hacked and the attackers leaked Netflix’s latest season of Orange is the New Black. Variety’s Janko Roettgers has an interview with Larson’s folks to talk about the attack. It’s not an incredibly technical overview, but it is fascinating to read.

After reading the article I would very much recommend visiting Larson’s website. It’s very 2000.

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:

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 and Rubys 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, or 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 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.  


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.


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.