This Blog has Moved!

This blog is moving to


Thank you for visiting! Content will remain here for archival purposes.
Showing posts with label Vulnerabilities. Show all posts
Showing posts with label Vulnerabilities. Show all posts

Keurig 2.0 Genuine K-Cup Spoofing Vulnerability

Hello Slashdot! I apologize if the blog runs slow under the heavy load! -Ken

Overview

Keurig 2.0 Coffee Maker contains a vulnerability in which the authenticity of coffee pods, known as K-Cups, uses weak verification methods, which are subject to a spoofing attack through re-use of a previously verified K-Cup.

Impact

CVSS Base Score: 4.9
Impact Subscore: 6.9
Exploitability Subscore: 3.9

Access Vector: Local
Access Complexity: Low
Authentication: None

Confidentiality Impact: None
Integrity Impact: Complete
Availability Impact: None

Vulnerable Versions
Keurig 2.0 Coffee Maker

Technical Details

Keurig 2.0 is designed to only use genuine Keurig approved coffee K-Cups. However, a flaw in the verification method allows an attacker to use unauthorized K-Cups. The Keurig 2.0 does not verify that the K-Cup foil lid used for verification is not re-used.

Step 1: Attacker uses a genuine K-Cup in the Keurig machine to brew coffee or hot chocolate.
Step 2: After brewing is complete, attacker removes the genuine K-Cup from the Keurig and uses a knife or scissors to carefully remove the full foil lid from the K-Cup, ensuring to keep the full edges intact. Attacker keeps this for use in the attack.
Step 3: Attacker inserts a non-genuine K-Cup in the Keurig, and closes the lid. Attacker should receive an "oops" error message stating that the K-Cup is not genuine.
Step 4: Attacker opens the Keurig, leaving the non-genuine K-Cup in the Keurig, and carefully places the previously saved genuine K-Cup lid on top of the non-genuine K-Cup, lining up the puncture hole to keep the lid in place.
Step 5: Attacker closes the Keurig, and is able to brew coffee using the non-genuine K-Cup.

Since no fix is currently available, owners of Keurig 2.0 systems may wish to take additional steps to secure the device, such as keeping the device in a locked cabinet, or using a cable lock to prevent the device from being plugged in when not being used by an authorized user.

Please note that a proof of concept is already available online.

Credit: 
Proof of concept at http://www.keurighack.com/
Vulnerability Writeup by Ken Buckler, Caffeine Security http://caffeinesecurity.blogspot.com

NOTE: There has been some question regarding the video and who made it. This is not the security researcher you're looking for. I am not the person who created the video, and only found the KeurigHack website after I discovered this vulnerability on my own. To whoever created the website, great job!

Heartbleed: How it was introduced, How it was fixed, and What's Vulnerable?

The Register has an excellent writeup on how Heartbleed was introduced into OpenSSL.

After doing some digging on OpenSSL's GIT repository, I was able to identify the commits which introduced, as well as fixed, this bug.

The bug was originally introduced into OpenSSL's source code on Dec 31, 2011.  According to the diff, the heartbeat code was provided by Robin Seggelmann. Robin has already stated that the error was "trivial", but clearly the error had far-reaching consequences.

The bug was fixed with only a few lines of code, as you can see from this commit from April 5, 2014.

On a side note, Robin was also one of the contributors to RFC 6520, which described the TLS heartbeat extension.

If you'd like to see the Heartbleed vulnerability status of popular websites, visit the Github page which is tracking the status of Heartbleed patching.

@USNISTGOV CVE Alerts Now On @CaffSec Twitter

Thanks to the folks at NIST for providing an RSS feed of new CVEs, I have incorporated CVEs into my automated #exploitAlert feed on Twitter.

In addition to CVE content, the #exploitAlert feed provides information on new vulnerabilities/exploits found on PasteBin and similar sites.

If you're interested in how the CVE feed works, I have made the feed available on my IFTT profile.

How (not) to handle software vulnerability submissions

If you're a software vendor developing programs more complex than "Hello World", eventually you will face an issue with a security vulnerability in your products.

For those who don't know I currently have an automated crawler searching Pastebin for new exploits and vulnerabilities.  This crawler reports its results live via the Twitter hashtag #exploitAlert. Every once in a while if something catches my attention, I'll submit it to the software vendor.

For most vendors the process is very straightforward...just send an email or fill out a form.  For an example of the right way to allow submissions of security vulnerabilities take a look at Microsoft's method.

Recently a supposed "0 day" vulnerability for Parallels Plesk was found by my crawler (a permanent copy of this paste is available here).  I've never worked with Parallels software before, so I went to their website to try and find out where to submit a vulnerability.  Finally I found it was an option on their support form.

My jaw dropped when I saw the warning at the bottom of the support form...


Well that certainly puts a stopper on things.  I'm not a paying customer...so obviously I won't be able to continue.  And what's even worse...if I was a paying customer...I would be CHARGED for submitting a security vulnerability!

Policies such as the one above will only cause frustrated users to post the vulnerability publicly instead of through responsible disclosure.

If anyone from Parallels reads this I would like to encourage you to push for reform of your vulnerability submission practices.

New @CaffSec Twitter Feature: #exploitAlert

I've taken the Google Alert "zero day" exploit feed and created automated Twitter notifications.

You can get updated #exploitAlert notifications by following my Twitter account, @CaffSec.

The feed currently monitors PasteBin for new exploits.  Expect additional feeds soon!

Monitoring for New Zero Day Exploits through Google Alerts

In case you haven't read it, I previously posted a how-to for using Google Alerts to monitor for misuse of your personal information...

Misuse of Your Personal Information and Google Alerts

Today I'm going to expand on that post, and show how advanced Google search strings can be used to monitor for other things, such as when new zero day exploits are posted publicly to Pastebin.

For those not familiar with it, Pastebin is a large site which allows anyone to post large amounts of text.  One of the common uses for this site is the public disclosure of new vulnerabilities and exploits.

To leverage some of the more powerful features of Google, use advanced search syntax to narrow your search.  An excellent quick reference is available at Google Guide.

Using our previous method to create an "As it happens" alert, let's try writing a custom query which monitors for new exploits...

intext:exploit OR intext:vulnerability OR intext:"zero day" OR intext:"0day" site:pastebin.com
Further tweaking will allow you to target a specific software or manufacturer, such as...
intext:microsoft intext:exploit OR intext:vulnerability OR intext:"zero day" OR intext:"0day" site:pastebin.com

I have provided an example RSS feed for a wide zero day search here.

Of course, this won't give you up-to-the-minute searching of Pastebin, but it's better than not monitoring at all.

Netscape 8? Really?

I was browsing my demographics for target audience, and was VERY shocked by seeing Netscape 8 as one of the browsers someone was using to read this security blog.

The last update for Netscape 8 was in 2007...

I hate to imagine how many vulnerabilities that browser has.  I counted over 20 unpatched vulnerabilities at the SecurityFocus Vulnerability Database

If you're the person visiting my blog using Netscape...please...upgrade.

Ducati Motorcycle Default Password Vulnerability.

There's an interesting vulnerability writeup at osvdb.org detailing how to gain unauthorized access to a Ducati Motorcycle using the default ignition password.  Apparently by default the ignition password is set to the last 4 digits of the motorcycle's VIN number.