A Geek With Guns

Chronicling the depravities of the State.

Archive for the ‘Security’ tag

Set a Strong Password on Your Phone

without comments

My girlfriend and I had to take our cat to the emergency vet last night so I didn’t have an opportunity to prepare much material for today. However, I will leave you with a security tip. You should set a strong password on your phone:

How long is your iPhone PIN? If you still use one that’s only made by six numbers (or worse, four!), you may want to change that.

Cops all over the United States are racing to buy a new and relatively cheap technology called GrayKey to unlock iPhones. GrayShift, the company that develops it, promises to crack any iPhone, regardless of the passcode that’s on it. GrayKey is able to unlock some iPhones in two hours, or three days for phones with six digit passcodes, according to an anonymous source who provided security firm Malwarebytes with pictures of the cracking device and some information about how it works.

The article goes on to explain that you should use a password with lowercase and upper case letters, numbers, and symbols. Frankly, I think such advice is antiquated and prefer the advice given in this XKCD comic. You can create more bits of entropy if you have a longer password that is easier to remember. Instead of having something like “Sup3r53cretP@5sw0rd” you could have “garish-bethel-perry-best-finale.” The second is easier to remember and is actually longer. Moreover, you can increase your security by tacking on additional words. If you want a randomly generated password, you can use a Diceware program such as this one (which I used to generate the latter of the two passwords.

Written by Christopher Burg

April 19th, 2018 at 10:00 am

You Can’t Predict What Will Set an Individual Off

without comments

I’m sure you’ve already heard about the shooting at YouTube’s headquarters. Before evidence of the shooter’s motives was revealed, most people predicted the common justifications given by or ascribed to shooters (an attack in the name of ISIS, a domestic issue, the shooter taking revenge for being bullied, etc.). However, this shooting took a slightly unusual twist when it was revealed that the shooter may have perpetrated the crime because she was upset about YouTube’s policy changes:

In several videos posted over the last year or so, she angrily spoke about the company’s policies, saying they were filtering her videos so they wouldn’t get any more views, and she was upset over demonetization. It appears the channels have now been completely removed by YouTube, citing policy violations.

Since the shooter committed suicide, we’ll never know for sure what her motivations were. But evidence indicates that her motivation may have been changes to YouTube’s monetization policies that caused at least some of her videos to be demonetized. If this was indeed her motivation, it goes to show that you can’t predict what will set an individual off.

Any action a company or individual takes is potentially dangerous. Although a vast majority of policy decisions don’t result in violence, once in a while the decision to either maintain or change a policy can result in a disgruntled individual responding with violence.

Part of the reason security is so difficult is because people are unpredictable. Who would have predicted that YouTube’s decision to demonetize some videos would result in an individual going to the company’s headquarters and opening fire on employees before turning the gun on herself?

Written by Christopher Burg

April 5th, 2018 at 10:00 am

Posted in News You Need to Know

Tagged with

A Security Issue Is Still a Security Issue Even If It’s a Hit Job

with one comment

A series of flaws were revealed in AMD’s line of processors. The aftermath of these kinds of revelations usually involves a lot of people trying to assess the impact and threat. Can the flaws be exploited remotely? If they can be exploited remotely, is there a way to detect if a system has been exploited? What actions can be taken to mitigate these flaws? Instead of the usual assessment, the aftermath of this revelation has been dominated by people claiming that this revelation was actually a hit job secretly instigated by Intel and individuals wanting to manipulate AMD’s stock price:

Here’s a histrionic quote for you: “AMD must cease the sale of Ryzen and EPYC chips in the interest of public safety.”

That’s a real quote from Viceroy Research’s deranged, apoplectic report on CTS Labs’ security allegations against AMD’s Ryzen architecture. The big story today seemed to mirror Meltdown, except for AMD: CTS Labs, a research company supposedly started in 2017, has launched a report declaring glaring security flaws for AMD’s processors. By and large, the biggest flaw revolves around the user installing bad microcode.

There are roots in legitimacy here, but as we dug deep into the origins of the companies involved in this new hit piece on AMD, we found peculiar financial connections that make us question the motive behind the reportage.

The goal here is to research whether the hysterical whitepapers — hysterical as in “crazy,” not “funny” — have any weight to them, and where these previously unknown companies come from.

A lot of people seem to have lost sight of the fact that just because a revelation is a hit job (which I’m not saying this revelation is) doesn’t mean that the revealed exploit isn’t a legitimate exploit. Even if CTS Labs is a company secretly created by Intel for the specific purpose of wrecking AMD’s reputation, the revealed exploits need to be assessed and, if they’re found to be legitimate exploits, addressed.

Written by Christopher Burg

March 15th, 2018 at 10:00 am

Spook Squad

with one comment

I’ve often wondered how Geek Squad stays in business. The prices it charges for even the most trivial repairs are absurd. More and more I’m becoming convinced that Geek Squad stays in business because it is being propped up by the Federal Bureau of Investigations (FBI):

After the prosecution of a California doctor revealed the FBI’s ties to a Best Buy Geek Squad computer repair facility in Kentucky, new documents released to EFF show that the relationship goes back years. The records also confirm that the FBI has paid Geek Squad employees as informants.

EFF filed a Freedom of Information Act (FOIA) lawsuit last year to learn more about how the FBI uses Geek Squad employees to flag illegal material when people pay Best Buy to repair their computers. The relationship potentially circumvents computer owners’ Fourth Amendment rights.

While Geek Squad has been caught red handed working with the FBI, any employee at any computer repair company could be operating under the same deal. The FBI has a vested interest in access the information on as many computers as possible and people who repair computers often have unrestricted access to a lot of information on a lot of computers.

If you’re going to send your computer to somebody else for repairs, here are my recommendations to guard your privacy. If the device you’re sending in has a removable hard drive, remove the drive that is in it and replace it with a blank drive (one that has never been used to store personal information). On the blank drive install the operating system that came on the device and a user account with generic credentials (this is one of the few times where the password “password” is a good idea) so the repair person can log in. By doing this you ensure that the repair person doesn’t have access to any of your personal data. When the device comes back, format the drive that you provided the repair person, remove it, and install the hard drive with your data again.

If your device doesn’t have a removable drive, ensure that the first thing you do when you initially start the device after getting it out of the box is enable full disk encryption. When you need to send the device in for repairs, format the drive, reinstall the default operating system, setup a user account with generic credentials, and send the device in. When the drive comes back, wipe the drive again and restore your data from a backup. For those who are wondering why full disk encryption should be enabled it’s because formatting a drive doesn’t necessarily erase the data. By default formatting a drive wipes the file allocation table but leaves the data preserved. Enabling full disk encryption ensures that the data on the drive is unreadable without the proper decryption key. While formatting won’t erase the data, the data will be unreadable to the repair man if they attempt to restore the old file allocation table to pilfer your data for law enforcers.

Written by Christopher Burg

March 7th, 2018 at 11:00 am

The Beginning of the End for Unsecured Websites

without comments

Chrome looks to be the first browser that is going to call a spade a spade. Starting in July 2018, Chrome will list all websites that aren’t utilizing HTTPS as unsecured:

For the past several years, we’ve moved toward a more secure web by strongly advocating that sites adopt HTTPS encryption. And within the last year, we’ve also helped users understand that HTTP sites are not secure by gradually marking a larger subset of HTTP pages as “not secure”. Beginning in July 2018 with the release of Chrome 68, Chrome will mark all HTTP sites as “not secure”.

I think Let’s Encrypt was the catalyst that made this decision possible. Before Let’s Encrypt was released, acquiring and managing TLS certificates could be a painful experience. What made matters worse is that the entire process had to be redone whenever the acquired TLS certificates expired. Let’s Encrypt turned that oftentimes annoying and expensive process into an easy command. This made it feasible for even amateur website administrators to implement HTTPS.

The Internet is slowly moving to a more secure model. HTTPS not only prevents third parties from seeing your web traffic but, maybe even more importantly, it also prevents third parties from altering your web traffic.

Written by Christopher Burg

February 16th, 2018 at 10:00 am

Let’s Put a Remotely Accessible Computer in a Door Lock

without comments

Let’s put a remotely accessible computer in a door lock, what could possibly go wrong?

A HomeKit vulnerability in the current version of iOS 11.2 has been demonstrated to 9to5Mac that allows unauthorized control of accessories including smart locks and garage door openers. Our understanding is Apple has rolled out a server-side fix that now prevent unauthorized access from occurring while limiting some functionality, and an update to iOS 11.2 coming next week will restore that full functionality.

The Internet of Things (IoT) introduces all sorts of new and interesting exploits. These exploits range from minor, such as your lights turn colors, to severe, such as having your doors unlock for an unauthorized person. Unfortunately, since software is already incredibly complex and becoming more so every day it’s unlikely we’ll see secure IoT devices anytime in the near future. Fortunately, it appears that Apple caught this vulnerability and was able to patch it before it was actively exploited.

Written by Christopher Burg

December 8th, 2017 at 10:00 am

Posted in Technology

Tagged with ,

Physical Access Isn’t Necessarily Game Over

without comments

I swear Apple fanboys are some of the dumbest people on the planet. Quite a few of them have been saying, “If an attacker as physical access, it’s game over anyways,” as if that statement makes the root user exploit recently discovered in High Sierra a nonissue.

At one time that statement was true. However, today physical access is not necessarily game over. Look at all of the trouble the Federal Bureau of Investigations (FBI) has been having with accessing iOS devices. The security model of iOS actually takes physical access into account as part of its threat modeling and has mechanisms to preserve the integrity of the data contained on the device. iOS requires all code to be signed before it will install or run it, which makes it difficult, although far from impossible, to insert malicious software onto iOS devices. But more importantly iOS encrypts all of the data stored in flash memory by default. Fully encrypted disks protect against physical access by both preventing an attacker from getting any usable data from a disk and also by preventing them from altering the data on the disk (such as writing malware directly to the disk).

macOS has a boot mode called single user mode, which boots the computer to a root command prompt. However, if a firmware password is set, single user mode cannot be started without entering the firmware password. The firmware password can be reset on machines with removable RAM (resetting the password requires changing the amount of RAM connected to the mainboard) but most of Apple’s modern computers, some iMacs being the exception, have RAM modules that are soldered to the mainboard.

Physical access is especially dangerous because it allows an attacker to insert malicious hardware, such as a key logger, that would allow them to record everything you type, including your passwords. However, that kind of attack requires some amount of sophistication and time (at least if you want the malicious hardware to be difficult to detect), which is where the real problem with High Sierra’s root exploit comes in. The root exploit required no sophistication whatsoever. Gaining root access only required physical access (or remote access if certain services were enabled) to an unlocked Mac for a few seconds. So long as an attacker had enough time to open System Preferences, click one of the lock icons, and type in “root” for the user name a few times they had complete access to the machine (from there they could turn on remote access capabilities to maintain their access).

Attempting to write off this exploit as a nonissue because it requires physical access requires willful ignorance of both modern security features that defend against attackers with physical access and the concept of severity (an attack that requires no sophistication can be far more severe than a time consuming sophisticated attack under certain threat models).

Written by Christopher Burg

December 1st, 2017 at 11:00 am

The Fix for High Sierra’s Embarrassing Privilege Escalation Bug and the Fix for the Fix

without comments

Apple has already released a fix for its embarrassing privilege escalation bug. If you haven’t already, open the App Store, go to Updates, and install Security Update 2017-001. However, after installing that you may notice that file sharing no longer works. In order to fix this problem you need to perform the following steps:

  1. Open the Terminal app, which is in the Utilities folder of your Applications folder.
  2. Type sudo /usr/libexec/configureLocalKDC and press Return.
  3. Enter your administrator password and press Return.
  4. Quit the Terminal app.

In conclusion High Sierra is still a steaming pile of shit and you should stick to Sierra if you can.

Written by Christopher Burg

November 30th, 2017 at 11:00 am

Adaptability is an Established Military’s Greatest Weakness

without comments

You may have heard the phrase, “The military is always preparing to fight the last war.” Any military that has been established for a length of time seems to get dragged down by entrenched ideologies and traditions. This leads them to become very rigid. The United States military is a great example of this. During its War on Terror it has clung to its usual tactics, which work well against other large national militaries but are more or less useless against asymmetrical tactics. It has also proven incompetent at information security, which is no a major component in warfare:

After uncovering a massive trove of social media-based intelligence left on multiple Amazon Web Services S3 storage buckets by a Defense Department contractor, the cloud security firm UpGuard has disclosed yet another major cloud storage breach of sensitive intelligence information. This time, the data exposed includes highly classified data and software associated with the Distributed Common Ground System-Army (DCGS-A), an intelligence distribution platform that DOD has spent billions to develop. Specifically, the breach involves software for a cloud-based component of DCGS-A called “Red Disk.”

Don’t get me wrong, I’m all for government transparency and appreciate the military’s current, albeit accidental, dedication to it. However, from a strategy standpoint this is pretty damned pitiful.

Written by Christopher Burg

November 29th, 2017 at 11:00 am

macOS High Sierra is Still Terrible

without comments

macOS High Sierra may go down in the history books as Apple’s worst release of macOS since the initial one. Swapping the graphical user interface to use the Metal API wasn’t a smooth transition to say the least but the real mess is in regards to security. There was a bug where a user’s password could be displayed in the password hint field so logging in as a malicious user only requires entering a user’s password incorrectly to trigger the hint field. But yesterday it was revealed that the root account, which is normally disabled entirely, could be activated in High Sierra by simply typing root into the user name field in System Preferences:

The bug, discovered by developer Lemi Ergin, lets anyone log into an admin account using the username “root” with no password. This works when attempting to access an administrator’s account on an unlocked Mac, and it also provides access at the login screen of a locked Mac.

The only good news is that you can defend against this bug by enabling the root account and giving it a password.

The security mistakes in High Sierra are incredibly amateur. Automated regression testing should have caught both the password hint mistake and this root account mistake. I can only assume that Apple’s quality assurance department took the year off because both High Sierra and iOS 11 are buggy messes that should never have been released in the states they were released in.

Written by Christopher Burg

November 29th, 2017 at 10:00 am