Uber Had the Opportunity to Monitor Everything on Your iPhone’s Screen

Daniel Jalkut:

Yesterday, Gizmodo reported that Uber had been granted an entitlement for their iOS app that allowed them to capture an image of an iPhone’s screen at any time, even when the Uber app was not the active app on the phone. This is a big deal, because users don’t typically expect than an iPhone app that is not active might have the ability to eavesdrop on anything they are doing.

I have long felt that the sandboxing infrastructure on both iOS and Mac should be used to more accurately convey to users specifically what the apps they install are capable of doing. Currently the sandboxing system is used primarily to identify to Apple what a specific app’s privileges are. The requested entitlements are used to inform Apple’s decision to approve or reject an app, but the specific list of entitlements is not easily available to users, whose security is actually on the line.

This is absolutely fucking ridiculous. Fuck Uber. Apple should be ashamed for working with them at any level. Allowing an app to covertly record your screen without any prompting is exactly the kind of thing that Apple’s iOS app review process should prevent.

Uber claims they didn’t do anything wrong with this ability, the security researchers told Gizmodo that they didn’t detect anything going on with this code.

There are companies that are less trustworthy than Uber, but few have the opportunity to be as evil on such a large scale. Enabling them to do anything more than operate at a basic level on your platform is a mistake. At this point Apple should block them entirely and attempt to help the Taxi industry to reform and compete with Uber. Not that Apple would ever would, but still that would be the best thing to come out of this. The next best thing would be the improvements to the entitlement system that Jalkut suggests.

I wouldn’t even bother to wonder what Uber are doing on Android, where security is a fucking joke and carriers are still selling devices running ancient versions of that operating system that are affected by dozens of security vulnerabilities. This is especially true for pay-as-you-go phones sold cheaply at places like Walmart, Target, and so on. Those carriers and stores are endangering their customers by continuing to sell these devices.

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 AnnualCreditReport.com. 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:
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.