We're starting to see some information on the Israeli cyber-weapons arms manufacturer that sold the iPhone zero-day exploit to the United Arab Emirates so they could spy on human rights defenders.
from NSO Group
Wednesday, August 31, 2016
Combating the Major Risks Your Business Could be Facing
Organizations face all sorts of risks that threaten to derail their progress and inhibit future growth. The headlines likely don’t provide much comfort as you read about another major company becoming a victim of a massive security breach. There’s a lot to worry about out there, and the tiniest mistake can quickly be exploited, putting […]… Read More
The post Combating the Major Risks Your Business Could be Facing appeared first on The State of Security.
from Combating the Major Risks Your Business Could be Facing
Back-to-School Tips on How Your Children Can Stay Safe Online
There’s no hiding it. The days are getting cooler. The sun’s setting earlier. And the leaves are beginning to change. Summer’s gone as quickly as it came, which means one thing and one thing only: it’s back-to-school season. Soon, kids around the world will be starting up a new year of classes. That means they’ll […]… Read More
The post Back-to-School Tips on How Your Children Can Stay Safe Online appeared first on The State of Security.
from Back-to-School Tips on How Your Children Can Stay Safe Online
VMworld 2016 Day Two: End User Computing, vSphere Integrated Containers and Hyper-Converged Infrastructure
Happenings in the VMworld 2016 day two keynote VMware's announcements in the VMworld 2016 day two keynote read more
from VMworld 2016 Day Two: End User Computing, vSphere Integrated Containers and Hyper-Converged Infrastructure
from VMworld 2016 Day Two: End User Computing, vSphere Integrated Containers and Hyper-Converged Infrastructure
Enterprises and SMBs need security support, says Kaspersky Lab
From the smallest business to the biggest enterprise, every company needs to combat security risks – but when resources are limited, the effort can be challenging. Increasingly, organizations are employing full-time security staff to help …
The post Enterprises and SMBs need security support, says Kaspersky Lab appeared first on DataGravity Blog.
from Enterprises and SMBs need security support, says Kaspersky Lab
Señoras y Señores, Mirad Aquí la Internets Cubanos
El Paquete Semanal via Kottke, here.Permalink
from Señoras y Señores, Mirad Aquí la Internets Cubanos
from Señoras y Señores, Mirad Aquí la Internets Cubanos
Malware: From Detection to the Source
One beautiful summer evening last month, I did one last check of email before shutting down.There it was. The paralyzing email from the HPE Cyber Defense Center.
from Malware: From Detection to the Source
from Malware: From Detection to the Source
IT/Dev Connections 2016 Speaker Highlight: Thomas Maurer
Part of an ongoing series, we're highlighting the excellent speakers we have handpicked to present phenomenal and extremely valuable content at the IT/Dev Connections conference. Want more? Get the Insider’s Scoop About IT/Dev Connections 2016 on September 8!
from IT/Dev Connections 2016 Speaker Highlight: Thomas Maurer
Things I hearted Last Week
For the week ending 28th August 2016 We had a bank holiday Monday here in London, so I’m a bit off – and may have skipped a day or two. Not that anyone would really notice, but I felt the need to preface my tardiness with an excuse. When security and convenience collide […]
from Things I hearted Last Week
from Things I hearted Last Week
Amazon Gift Card from Kelihos!
Arsh Arora and Max Gannon, malware researchers in our lab at the University of Alabama at Birmingham (UAB) continue their on-going analysis of the Kelihos botnet. We call this a "longitudinal malware study." Today Arsh returns with some interesting observations about the Kelihos botnet as it sends out Amazon Gift Card.
Arsh take it from here.
This is the first time it has geo-targeted US customers, unlike previous occasions where it had targeted Canadian [Canada] , German and UK, [German and UK] and Dutch [Dutch] customers. The delivery mechanism is the same in which the botnet delivers emails containing suspicious links to a Microsoft Word document that will download a Nullsoft installer and eventually affect you with Nymaim/CryptoLocker.
Now, we can surely say that the operators of Kelihos botnet are formulating a strategy in choosing their targets for the spam campaign. Basically, they are trying to gain back the attention of the industry and trying to proclaim its spot of the longest surviving spamming botnet. Recently, the botnet size increased tremendously and has been a hot topic among the cyber industry.
The most common email subjects we observed being used in the spam campaign are:
Subject: Amazon Gift Team just wants to make a present for you
Subject: Awesome news! You recieved a gift from Amazon!
Subject: Don't wait, get free voucher! Amazon Promo chosen you!
Subject: Gift from Amazon was just recieved, redeem yours now
The URLs sent in the email are presented below with its corresponding resolved IP address, via WHOIS search
http://ift.tt/2bzWbvd – 104[.]168[.]181[.]99; Oklahoma
http://ift.tt/2bzHM71 – 104[.]168[.]181[.]99
http://ift.tt/2bzVGBs – 149[.]202[.]194[.]178; Nord-pas-de-calais
http://ift.tt/2bzGysE - 149[.]202[.]194[.]178
http://ift.tt/2bzUdv1 – 198[.]105[.]215[.]36; Utah
Registrant Name: Frank Gilmer
Registrant Organization: Private Person
Registrant Street: 22 Bakinskih komissarov 2k1, 51
Registrant City: Moscow
Registrant State/Province: Moscow
Registrant Postal Code: 119571
Registrant Country: RU
Registrant Phone: +7.9681673922
Registrant Email: frankgilmer416@gmail.com
After downloading the Word document and viewing its content, it shows the above message. Interestingly, it contains a URL that is meant to excite the victim. So in order to receive this “amazing” offer, the user first has to press the “Enable Editing” button.
After clicking the 'Enable Editing' button, another window asks to 'Enable Macros', aka "ENCRYPT ME" button. The gift card is still unavailable and can be only be retrieved after clicking the URL in the email.
This behavior has been seen for the first time where the user is asked to click a URL. While the user is occupied trying to find his/her gift code, the ransomware is performing its task in the background. By the time the user realizes a scam is underway, the machine is already encrypted. Threat actors have perfectly social engineered user behavior in order to succeed in causing damage to the user.
As of now, my colleague Max Gannon, Malware Analyst at UAB, notes that these samples are extraordinarly VM-aware. It performs the usual registry check for references to Virtualization Software, but it also checks the display adapters and color settings which are harder to disguise and less frequently modified by malware analysts. It checks the local machine language as well as the keyboard layout which is again not frequently changed. It checks the clipboard contents and if the clipboard is linked to a Virtual Machine. Lastly it checks the system for a pre-defined set of programs that it considers indicative of a normal system. This is a significant increase in the number of checks when compared to similar malware families and may require additional focus and analysis time.
from Amazon Gift Card from Kelihos!
Arsh take it from here.
Amazon Gift Card from Kelihos botnet! Anyone up for a Nymaim banking trojan or CryptoLocker?
Here it is, the Kelihos botnet back with a bang. Today, Kelihos is in a festive mood and giving away a free “Amazon Gift Card”, especially for US customers. Instead of ALL American spam recipients receiving the malware, however, only those whose email ends in the country code ".us" received this malware. As you can see in the sample list below, this means that many school employees will have received this spam, as K-12 schools very commonly use .us domain names.This is the first time it has geo-targeted US customers, unlike previous occasions where it had targeted Canadian [Canada] , German and UK, [German and UK] and Dutch [Dutch] customers. The delivery mechanism is the same in which the botnet delivers emails containing suspicious links to a Microsoft Word document that will download a Nullsoft installer and eventually affect you with Nymaim/CryptoLocker.
Now, we can surely say that the operators of Kelihos botnet are formulating a strategy in choosing their targets for the spam campaign. Basically, they are trying to gain back the attention of the industry and trying to proclaim its spot of the longest surviving spamming botnet. Recently, the botnet size increased tremendously and has been a hot topic among the cyber industry.
| Geo Targeted emails to US based victims |
The body of the message sent contains a malicious word doc link
Subject: Amazon Gift Team just wants to make a present for you
Hi our beloved client!
Our company glad to notify, that our improbable promotion special offer to say thanks to limited number of our buyers.
In this greetings list you can find costless Amazon Gift Card for $65 balance!!! It can be redeemed in our online webstore for any further purchase on Amazon. You can activate promo eGift using this link: http://ift.tt/2bzVlP3
Hurry up! This offer have limited time, and limited number of promo vouchers available, that can be activated during promo, so do not forget to obtain your one!
Huge thanks from Amazon for being a part of our team, we really apreciate that!
----------------------------------------
You can discover useful information using our FAQ on http://ift.tt/1erJ3rh or via the phone +180012343212
Amazon Promo Team
______________________________________________
Subject: Amazon Gift Team just wants to make a present for you
Subject: Awesome news! You recieved a gift from Amazon!
Subject: Don't wait, get free voucher! Amazon Promo chosen you!
Subject: Gift from Amazon was just recieved, redeem yours now
The URLs sent in the email are presented below with its corresponding resolved IP address, via WHOIS search
http://ift.tt/2bzWbvd – 104[.]168[.]181[.]99; Oklahoma
http://ift.tt/2bzHM71 – 104[.]168[.]181[.]99
http://ift.tt/2bzVGBs – 149[.]202[.]194[.]178; Nord-pas-de-calais
http://ift.tt/2bzGysE - 149[.]202[.]194[.]178
http://ift.tt/2bzUdv1 – 198[.]105[.]215[.]36; Utah
An interesting observation is that 4 out of 5 Urls share the same Whois contact information[Whois]
Registrant Name: Frank Gilmer
Registrant Organization: Private Person
Registrant Street: 22 Bakinskih komissarov 2k1, 51
Registrant City: Moscow
Registrant State/Province: Moscow
Registrant Postal Code: 119571
Registrant Country: RU
Registrant Phone: +7.9681673922
Registrant Email: frankgilmer416@gmail.com
Moving on, the delivery mechanism remains to consistent as seen on previous occasions
| Document opened in Protected view with a URL link |
| Enable Content AKA Encrypt Me! |
| Congratulating the user! |
This behavior has been seen for the first time where the user is asked to click a URL. While the user is occupied trying to find his/her gift code, the ransomware is performing its task in the background. By the time the user realizes a scam is underway, the machine is already encrypted. Threat actors have perfectly social engineered user behavior in order to succeed in causing damage to the user.
The URL provided in the email doesn't actually exist at Amazon:
http://ift.tt/2bzVjXG
http://ift.tt/2bzVjXG
| Too late to say Sorry! |
When the link is clicked, we get Amazon's 404 page -- an image of a cute dog and a message saying “Sorry, we couldn’t find that page”. On the contrary, guess what happens? When you close the browser you will find that your files are encrypted. Unfortunately, we were not able to get our system encrypted as the installer checked registry keys for the presence of the virtual environment.
After not being able to accomplish my mission, I checked virus total for extra information
MD5 of the Word Document - 2843a3b7805ffc7fd058b9fd744ec836 [VT result]
Of course, the Word document was a downloader, but the file that was download was indeed malicious.
MD5 of the NSIS installer named 'Sys_Driver' - 766169d508d0eee096e07619c2a1416a [VT results]
| VT results 10/57, CryptoLocker |
When we reviewed the malicious file on Virus Total, contradicting results were found. On one side, the AV vendors classified it as Cryptolocker. On the contrary, when I checked the comments section, one user has posted it to be Nymaim. We believe this is due to targeting, where the same URL may drop different malware depending on the visitor. Hence, I thought to probably avoid getting into the discussion of who is right, and leave it up to the discretion of the user to pick his side.
| #Nymaim in the comments section |
While CryptoLocker is unlikely - it hasn't been seen in some time - we don't want to contradict the AV vendors until we can execute the malware ourselves.
Hopefully, this will widen up the eyes of Amazon and the individuals who have the authority to take action. Eventually, taking appropriate measures to cause damage to the threat actors. Beware American friends.
Stay tuned for latest updates on the Kelihos botnet in the coming future.
from Amazon Gift Card from Kelihos!
Tuesday, August 30, 2016
Tesla auto pilot had the ability to be hacked which makes us worried.
http://ift.tt/2ccLVhl The reality is that a totally auto pilot car will be a possibility not that far down the roadway. The concern is how safe will it be and how safe will it be. Just think some day you will be able to get in your automobile struck a button and be taken home while you sleep or enjoy a motion picture. It is an fantastic idea, but is it a safe one? It will be really challenging to make the infrastructure needed to be safe and hack evidence. I guess only time will inform, but it is something we at Cyber Security Portal eagerly anticipate seeing. Scientists from the University of South Carolina and a couple of others have actually just checked this concern on a Tesla. In a series of tests, they had the ability to discover that Tesla's sensors can undoubtedly be hacked and taken control of. The group is going to reveal their screening in the Defcon Hacker conference.
Using Wi-Fi Signals to Identify People by Body Shape
Another paper on using Wi-Fi for surveillance. This one is on identifying people by their body shape. "FreeSense:Indoor Human Identification with WiFi Signals":
Abstract: Human identification plays an important role in human-computer interaction. There have been numerous methods proposed for human identification (e.g., face recognition, gait recognition, fingerprint identification, etc.). While these methods could be very useful under different conditions, they also suffer from certain shortcomings (e.g., user privacy, sensing coverage range). In this paper, we propose a novel approach for human identification, which leverages WIFI signals to enable non-intrusive human identification in domestic environments. It is based on the observation that each person has specific influence patterns to the surrounding WIFI signal while moving indoors, regarding their body shape characteristics and motion patterns. The influence can be captured by the Channel State Information (CSI) time series of WIFI. Specifically, a combination of Principal Component Analysis (PCA), Discrete Wavelet Transform (DWT) and Dynamic Time Warping (DTW) techniques is used for CSI waveform-based human identification. We implemented the system in a 6m*5m smart home environment and recruited 9 users for data collection and evaluation. Experimental results indicate that the identification accuracy is about 88.9% to 94.5% when the candidate user set changes from 6 to 2, showing that the proposed human identification method is effective in domestic environments.
from Using Wi-Fi Signals to Identify People by Body Shape
Keystroke Recognition from Wi-Fi Distortion
This is interesting research: "Keystroke Recognition Using WiFi Signals." Basically, the user's hand positions as they type distorts the Wi-Fi signal in predictable ways.
Abstract: Keystroke privacy is critical for ensuring the security of computer systems and the privacy of human users as what being typed could be passwords or privacy sensitive information. In this paper, we show for the first time that WiFi signals can also be exploited to recognize keystrokes. The intuition is that while typing a certain key, the hands and fingers of a user move in a unique formation and direction and thus generate a unique pattern in the time-series of Channel State Information (CSI) values, which we call CSI-waveform for that key. In this paper, we propose a WiFi signal based keystroke recognition system called WiKey. WiKey consists of two Commercial Off-The-Shelf (COTS) WiFi devices, a sender (such as a router) and a receiver (such as a laptop). The sender continuously emits signals and the receiver continuously receives signals. When a human subject types on a keyboard, WiKey recognizes the typed keys based on how the CSI values at the WiFi signal receiver end. We implemented the WiKey system using a TP-Link TL-WR1043ND WiFi router and a Lenovo X200 laptop. WiKey achieves more than 97.5% detection rate for detecting the keystroke and 96.4% recognition accuracy for classifying single keys. In real-world experiments, WiKey can recognize keystrokes in a continuously typed sentence with an accuracy of 93.5%.
News article.
from Keystroke Recognition from Wi-Fi Distortion
iPhone Zero-Day Used by UAE Government
Last week, Apple issued a critical security patch for the iPhone: iOS 9.3.5. The incredible story is that this patch is the result of investigative work by Citizen Lab, which uncovered a zero-day exploit being used by the UAE government against a human rights defender. The UAE spyware was provided by the Israeli cyberweapons arms manufacturer NSO Group.
This is a big deal. iOS vulnerabilities are expensive, and can sell for over $1M. That we can find one used in the wild and patch it, rendering it valueless, is a major win and puts a huge dent in the vulnerabilities market. The more we can do this, the less valuable these zero-days will be to both criminals and governments -- and to criminal governments.
Citizen Lab blog post and report. New York Times article. More news articles.
from iPhone Zero-Day Used by UAE Government
Apple Patents Collecting Biometric Information Based on Unauthorized Device Use
Apple received a patent earlier this year on collecting biometric information of an unauthorized device user. The obvious application is taking a copy of the fingerprint and photo of someone using as stolen smartphone.
Note that I have no opinion on whether this is a patentable idea or the patent is valid.
from Apple Patents Collecting Biometric Information Based on Unauthorized Device Use
Monday, August 29, 2016
Our most valued reviews come from the toughest jury: our customers
Our most valued reviews come from you. See what Security First had to say about Emsisoft Internet Security's detection capabilities.
from Our most valued reviews come from the toughest jury: our customers
Related Posts:
from Our most valued reviews come from the toughest jury: our customers
What We Should Learn From the Aussies about Data Protection – Australian Edition, 2016 Vormetric Data Threat Report
It’s a pretty simple story once you get down to it. We found in the results of the report that Australian Enterprises that they feel very threatened by cyberattacks, and when you look at it there seem to be some pretty good reasons for it. Click to Tweet: Aussie #DataSecurity Pros under fire – 2016 #DataThreat Report bit.ly/2c5SQps http://pic.twitter.com/fJNNRRviGJ First let’s look at how vulnerable respondents felt to internal and external threats to data. The highest rate of “Extremely Vulnerable” […]
The post What We Should Learn From the Aussies about Data Protection – Australian Edition, 2016 Vormetric Data Threat Report appeared first on Data Security Blog | Vormetric.
from What We Should Learn From the Aussies about Data Protection – Australian Edition, 2016 Vormetric Data Threat Report
VMworld 2016 Day One: VMware announces VMware Cloud Foundation and Cross-Cloud Services
VMware annouces VMware Cloud Foundation and Cross-Cloud Services VMware annouces VMware Cloud Foundation and Cross-Cloud Services at VMworld 2016 read more
from VMworld 2016 Day One: VMware announces VMware Cloud Foundation and Cross-Cloud Services
from VMworld 2016 Day One: VMware announces VMware Cloud Foundation and Cross-Cloud Services
Getting Useful Info From the Log Hell with Awk
Getting useful info from log file should be piece of cake …if the file is properly formatted! Usually, one event is written on a single line with useful info delimited by a separator or extractable using regular expressions. But it’s not always the case, welcome to the log hell… Sometimes,
[The post Getting Useful Info From the Log Hell with Awk has been first published on /dev/random]
from Getting Useful Info From the Log Hell with Awk
Back-to-school security tips for IT admins [Infographic]
from Back-to-school security tips for IT admins [Infographic]
SecurityIQ Case Study – Westcon Group
I’m sure you’ve noticed that we’ve been writing a lot about security awareness and phishing lately. Our team has been working hard on our SecurityIQ offering and it has been gaining...
Go on to the site to read the full article
from SecurityIQ Case Study – Westcon Group
Go on to the site to read the full article
from SecurityIQ Case Study – Westcon Group
iPhone Zero-Day Used by UAE Government
Last week, Apple issued a critical security patch for the iPhone: iOS 9.3.5. The incredible story is that this patch is the result of investigative work by Citizen Lab, which uncovered a zero-day exploit being used by the UAE government against a human rights defender. The UAE spyware was provided by the Israeli cyberweapons arms manufacturer NSO Group. This is...
from iPhone Zero-Day Used by UAE Government
from iPhone Zero-Day Used by UAE Government
Fantom ransomware impersonates Windows update
Windows 10 has been notorious about automatically installing updates on users’ machines and now there is a ransomware that aims to capitalize on it. The new ransomware, Fantom, is based on the EDA2...read more
The post Fantom ransomware impersonates Windows update appeared first on Webroot Threat Blog.
from Fantom ransomware impersonates Windows update
Banner Health Data Breach Leads to Series of Class Action Lawsuits
Earlier this month, Banner Health announced a data breach affecting approximately 3.7 million people. Since then, a series of class action lawsuits have been filed against the healthcare provider. The breach involved two separate attacks, Banner Health said. The first targeted payment cards used at food and beverage outlets across some Banner Health locations. The second targeted patient, insurance, and provider information. The… Read More
from Banner Health Data Breach Leads to Series of Class Action Lawsuits
from Banner Health Data Breach Leads to Series of Class Action Lawsuits
German Speakers Targeted by SPAM Leading to Ozone RAT
Remote Administration Tools (RAT) have been around for a long time. They provide users and administrators with the convenience of being able to take full control of their systems without needing to be physically in front of a device. In this age of global operations, that’s a huge deal. From troubleshooting machines across countries to observing employees across rooms, RAT solutions have become widely used tools for remote maintenance and monitoring. Unfortunately, malware authors often utilize these same capabilities to compromise systems....
from German Speakers Targeted by SPAM Leading to Ozone RAT
from German Speakers Targeted by SPAM Leading to Ozone RAT
Why Social Networking Is Important When Job Hunting For Cybersecurity
Ever wondered why some people so easily and quickly land a dream job in their dream company? If we were to give you one reason, it would be networking.
Networking is one of the most powerful and effective ways to become successful in just about any career or walk of life. In cybersecurity, it counts even more. The entire IT industry is based upon networking, relationships and credibility, which is why you should be building connections all the time.
Here are some tips to get you started with building your ultimate network of professionals and land your perfect job.
As soon as you are ready to look for an entry level job in cybersecurity, you should start building relationships with people in the industry. Go and join cybersecurity forums, blogs and other places where people interact. Start contributing and build a network with people.
Whenever you can, offer assistance to people. Find places where people come seeking advice and other help based in IT security. If you have the knowledge, you can help anyone. This way you will get attention from gurus in the industry who will start thinking you are a valuable person to build relationships with. In return, you can ask these ‘gurus’ to help you with entry level jobs by giving you advice and pointing you to the right direction.
The best place to build extremely useful connections is through regularly visiting cybersecurity conferences. Check your local listings for any thing related to IT security happening in your area and go there and start making some connections. There you will also come in contact with professionals who are more than willing to help you fill the gaps.
Once you have found the ultimate platform to help and seek advice, constantly provide your feedback and become a permanent part of that community. You will grow as a personality and a lot of people with start respecting you. As your name becomes known through out the cybersecurity industry, you will automatically start receiving offers from big name companies to help you find a career with them.
The post Why Social Networking Is Important When Job Hunting For Cybersecurity appeared first on Cyber Security Portal.
from Lavina Bentley – Cyber Security Portal http://ift.tt/2c376PI
Tips And Advice For Entry Level Cybersecurity Job Seekers
Having problem getting a job in cybersecurity?
You may be thinking too much. Getting a job in Cyber-security is easier than you think.
You probably landed on this page because you have decided to seek a job in IT security, but are unsure where to begin. Researching is the very first step and you are doing it perfectly. Now that you are here, we are going to help you find your first entry level cyber security job by giving you some golden advice and tips.
Sure, when it comes to getting a good job in an industry, experience is vital. But our aim is to help you build a reputation that speaks experience through your persona. A compilation for several tips can be read below which we believe will effectively help you in your job hunt.
Planning is the most important thing
Rule number one of finding the perfect job is to plan, plan and plan ahead. You need to think like a strategist and see what opportunities lie in front of you and how you can catch those opportunities. When you finally come up with a game plan, stick to it and work on it. Here are some crucial points that will help you get an entry level job in Cyber Security:
- First of all, plan ahead as mentioned above. You need to know the different kinds of careers available and what career leads to which position in the long term. Pursue the career that best suits your needs.
- Find out which skills are absolutely necessary in the career you have chosen. Look for job postings to see what companies are demanding.
- Find ways to get the skills that are required. You can volunteer, compete in hacking contests, attend IT security conferences, get a degree or even complete a professional certificate.
- Get practical by doing projects on your own. There are several places where you can volunteer to work on a project or you can start your own.
- Master all the popular and latest technology available to IT security professionals. If this is too much, stick to one or two popular tools that are commonly used in IT security.
- Start blogging! if you think you have the knowledge, why not pen it down. Show it your employers when you are going for an interview and they will be immediately impressed.
- Finally, create a powerful self promotion pitch that will help you sell yourself to employers. The speech must include who you are and why you are perfect for the job. Include all or most powerful points from above.
Getting a job in cybersecurity is all about having practical and theoretical knowledge. Sharpen your skills in both departments and you are on your way to becoming a guru in cybersecurity.
The post Tips And Advice For Entry Level Cybersecurity Job Seekers appeared first on Cyber Security Portal.
from Lavina Bentley – Cyber Security Portal http://ift.tt/2bvOj0Z
Sunday, August 28, 2016
Opera resets passwords after sync server hacked
But the company won't say how the passwords are stored, which may indicate if they can be unscrambled by an attacker.
from Opera resets passwords after sync server hacked
from Opera resets passwords after sync server hacked
Do you want to get trained, or do you prefer to learn?
“I see you’re listing the Straight Talk for Leaders as an Executive Course. What’s an executive course?” I got that question more than once after launching. As explained in the need to launch to learn, I overlooked some key details. Despite the energy I put into building something useful, I never explained it. Allow me […]
The post Do you want to get trained, or do you prefer to learn? appeared first on Security Catalyst.
from Do you want to get trained, or do you prefer to learn?
Managed Hacked PCs as a Service Type of Cybercrime-friendly service Spotted in the Wild
With the cybercrime ecosystem, persistently, supplying, new, malware, releases, cybercriminals continue occupying multiple market segments, within, the, cybercrime, ecosystem, generating, tens, of, thousands, of fraudulent revenue, in, the, process, po...
from Managed Hacked PCs as a Service Type of Cybercrime-friendly service Spotted in the Wild
from Managed Hacked PCs as a Service Type of Cybercrime-friendly service Spotted in the Wild
New Cybercrime-Friendly Service Offers Fake Documents and Bills on Demand
The market segment, for, fake, documents, and, bills, continues, flourishing, thanks, to, a, vibrant, cybercrime, ecosystem, offering, access, to, a, variety, of commoditized, underground, market, items, further generating fraudulent revenue for the cy...
from New Cybercrime-Friendly Service Offers Fake Documents and Bills on Demand
from New Cybercrime-Friendly Service Offers Fake Documents and Bills on Demand
Ransomware Recovery and Prevention page.
I’ve intended for a while to break out some of the scattered information in the ransomware resource page and sub-pages into its own Ransomware Recovery and Prevention page. And finally got around to it. Much of the same information (and more) remains in the Ransomware Resources page and/or sub-pages. (Sorry, but I’m happy to duplicate information where […]
from Ransomware Recovery and Prevention page.
from Ransomware Recovery and Prevention page.
SC Magazine on paying ransomware crooks
In an article called Ransomware locks experts in debate over ethics of paying, Bradley Barth picks up on a point I made in my blog article for ESET – Ransomware: To pay or not to pay?. He quotes both my article for ESET and some subsequent commentary by my friend and colleague Stephen Cobb. I may […]
from SC Magazine on paying ransomware crooks
from SC Magazine on paying ransomware crooks
Google: easier access to content on mobile
Google: Helping users easily access content on mobile Takes two approaches, the latter maybe more security-related. One relates to the removal of the mobile-friendly label, since most sites now meet that criterion, so the removal is seen as reducing clutter. The other introduces measures to reduce the impact of intrusive pop-ups and standalone interstitials that obscure the […]
from Google: easier access to content on mobile
from Google: easier access to content on mobile
Making the Top Smart City in Europe
Google: Helping users easily access content on mobile Takes two approaches, the latter maybe more security-related. One relates to the removal of the mobile-friendly label, since most sites now meet that criterion, so the removal is seen as reducing clutter. The other introduces measures to reduce the impact of intrusive pop-ups and standalone interstitials that obscure the […]
from Making the Top Smart City in Europe
from Making the Top Smart City in Europe
Saturday, August 27, 2016
iPhone, Halved
Ed Catmull, Ph.D. proudly displaying the Pixar animation render farm in 1995. It is rather important to note the farm - as depicted - can now be calculated to be the equivalent to 1/2 of a iPhone 6's comput...
from iPhone, Halved
from iPhone, Halved
Cipher and Password Bruteforcing with OpenSSL
Ever had to crack something, but you don’t know the cipher? Sometimes the encrypted text gives you clues on which encryption algorithm has been used, but not always. For those cases, it might be useful with the script I am talking about in this post. Bruteforcing the cipher type might be the only way to … Continue reading Cipher and Password Bruteforcing with OpenSSL →
from Cipher and Password Bruteforcing with OpenSSL
from Cipher and Password Bruteforcing with OpenSSL
FortiGuard Threat Intelligence Roundup
For those of you who don’t know, Fortinet publishes a threat intelligence roundup every Friday, the Fortinet Threat Intelligence Brief, that reviews new threats and trends. It is a treasure trove of analysis and information that ought to be part of your regimen every Friday. This week is no exception. Here are a couple of teasers and takeaways: 1. Ransomware isn’t going away any time soon. Every time organizations think they have a handle on this, ransomware developers come up with a new variant designed to evade detection....
from FortiGuard Threat Intelligence Roundup
from FortiGuard Threat Intelligence Roundup
RIPPER ATM Malware and the 12 Million Baht Jackpot
On Aug. 23, 2016, FireEye detected a potentially new ATM malware sample that used some interesting techniques not seen before. To add more fuel to an existing fire, the sample was uploaded to VirusTotal from an IP address in Thailand a couple of minutes before the Bangkok Post newspaper reported the theft of 12 million baht from ATMs at banks in Thailand.
In this blog, FireEye Labs dissects this new ATM malware that we have dubbed RIPPER (due to the project name “ATMRIPPER” identified in the sample) and documents indicators that strongly suggest this piece of malware is the one used to steal from the ATMs at banks in Thailand.
Connection to previous ATM Malware
- Targets the same ATM brand.
- The technique used to expel currency follows the same strategy (already documented) performed by the Padpin (Tyupkin), SUCEFUL and GreenDispenser.
- Similar to SUCEFUL, it is able to control the Card Reader device to Read or Eject the card on demand.
- Can disable the local network interface, similar to capabilities of the Padpin family.
- Uses the “sdelete” secure deletion tool, similar to GreenDispenser, to remove forensic evidence.
- Enforces a limit of 40 bank notes per withdrawal consistently, which is the maximum allowed by the ATM vendor.
New features, capabilities, or behaviors in RIPPER
- It targets three of the main ATM Vendors worldwide, which is a first.
- RIPPER is installed on the ATM by inserting a specially manufactured ATM card with an EMV chip that serves as the authentication mechanism. Although this technique was already used by the Skimmer family, it is an uncommon mechanism.
Similarities between RIPPER and the recent ATM theft in Thailand
RIPPER analysis
MD5: 15632224b7e5ca0ccb0a042daf2adc13
RIPPER Persistence:
RIPPER can maintain persistence using two modes: either as standalone service or masquerading as a legitimate ATM process.
RIPPER is installed as a service if called with the following arguments:
service install
Before creating the service, it will kill the process “dbackup.exe”, which is specific to one common ATM vendor:
cmd /c taskkill /IM dbackup.exe /T /F
Then it will replace the original dbackup.exe binary under c:\Windows\system32\ (if present) with itself.
Finally it will install a persistent service with following attributes:
RIPPER can delete the “DBackup Service” service if run with the following arguments:
service remove
RIPPER can stop or start the “DBackup Service” with the following arguments:
“service start” or “service stop”
RIPPER also supports the following command line switches:
/autorun: Will Sleep for 10 minutes and then run in the background, waiting for interaction.
/install: RIPPER will replace the ATM software running on the ATM as follows:
Upon execution, RIPPER will kill the processes running in memory for the three targeted ATM Vendors via the native Windows “taskkill” tool.
RIPPER will examine the contents of directories associated with the targeted ATM vendors and will replace legitimate executables with itself. This technique allows the malware to maintain the legitimate program name to avoid suspicion.
RIPPER will maintain persistence by adding itself to the \Run\FwLoadPm registry key (that might already exist as part of the vendor installation), passing the “/autorun” parameter that is understood by the malware, as seen in Figure 1.
Figure 1: Registry key added for persistency
/uninstall: RIPPER removes the registry keys created
Running without parameters
If RIPPER is executed without any parameters, it will perform the following actions:
1. It will connect with the Cash Dispenser, Card Reader and the Pinpad. Since every ATM brand has its own unique devices names, RIPPER will identify the current devices installed by enumerating them under the following registry key:
HKEY_USERS\.DEFAULT\XFS\LOGICAL_SERVICES\
2. RIPPER will make sure the devices are available by querying their status (Figure 2), and if not available, will exit.
Figure 2: Querying the devices status via WFSGetInfo() API
3. For the Dispenser it will obtain information such as the Cash Unit details to determine the number and type of available notes.
4. Finally it starts two threads; the first of which will monitor the status of the ATM devices to make sure they are available and will read all the keystrokes received from the Pinpad device waiting to interact with the thieves (see step 7), as seen in Figure 3.
Figure 3: Monitoring Pinpad keystrokes
5. The second thread monitors the Card Reader, and once a card is inserted it validates the EMV chip for authentication to the ATM Malware.
6. Once a valid card with a malicious EMV chip is detected, RIPPER will instantiate a timer to allow a thief to control the machine. Figure 4 depicts the timer function.
Figure 4: Monitoring the Card Reader
7. Once the thieves start interacting with RIPPER, they enter instructions via the Pinpad and multiple options are displayed, including methods for dispensing currency. Figure 5 depicts some of the options available to the thieves.
a. CLEAN LOGS: Will clear the log stored at: C:\WINDOWS\temp\clnup.dat
b. HIDE: Will hide the Malware GUI by calling ShowWindow() API.
c. NETWORK DISABLE: Will shut down the ATM local network interface to prevent it from communicating with the bank. It can re-enable the connection if needed.
Figure 5: Main Menu
d. REBOOT: Will call ExitWindowsEX() API without sending WM_QUERYENDSESSION message to avoid prompts for confirmation, causing the system to reboot.
e. BACK: Ejects the malicious ATM card back to the thieves by calling the WFSExecute() with the command: WFS_CMD_IDC_EJECT_CARD. This option, depicted in Figure 6, was observed being used by the SUCEFUL family.
Figure 6: Asking Card Reader to eject the chip card
Conclusion
Through open sources, we’ve identified a family of malware that may have been used in recent ATM robberies and which bears some similarities to known families of malware. This malware family can be used to compromise multiple vendor platforms and leverages uncommon technology to access physical devices. In addition to requiring technical sophistication, attacks such as that affecting the ATMs in Thailand require coordination of both the virtual and the physical. This speaks to the formidable nature of the thieves.
from RIPPER ATM Malware and the 12 Million Baht Jackpot
Notes on that StJude/MuddyWatters/MedSec thing
I thought I'd write up some notes on the StJude/MedSec/MuddyWaters affair. Some references: [1] [2] [3] [4].
St Jude Medical (STJ) is one of the largest providers of pacemakers (aka. cardiac devices) in the country, around ~$2.5 billion in revenue, which accounts for about half their business. They provide "smart" pacemakers with an on-board computer that talks via radio-waves to a nearby monitor that records the functioning of the device (and health data). That monitor, "Merlin@Home", then talks back up to St Jude (via phone lines, 3G cell phone, or wifi). Pretty much all pacemakers work that way (my father's does, although his is from a different vendor).
MedSec is a bunch of cybersecurity researchers (white-hat hackers) who have been investigating medical devices. In theory, their primary business is to sell their services to medical device companies, to help companies secure their devices. Their CEO is Justine Bone, a long-time white-hat hacker. Despite Muddy Waters garbling the research, there's no reason to doubt that there's quality research underlying all this.
Muddy Waters is an investment company known for investigating companies, finding problems like accounting fraud, and profiting by shorting the stock of misbehaving companies.
Apparently, MedSec did a survey of many pacemaker manufacturers, chose the one with the most cybersecurity problems, and went to Muddy Waters with their findings, asking for a share of the profits Muddy Waters got from shorting the stock.
Muddy Waters published their findings in [1] above. St Jude published their response in [2] above. They are both highly dishonest. I point that out because people want to discuss the ethics of using 0day to short stock when we should talk about the ethics of lying.
Update from @lippard: Abbot Labs agreed in April to buy St Jude at $85 a share (when St Jude's stock was $60/share). Presumable, for this Muddy Waters attack on St Jude's stock price to profit from anything more than a really short term stock drop (like dumping their short position today), Muddy Waters would have believe this effort will cause Abbot Labs to walk away from the deal. Normally, there are penalties for doing so, but material things like massive vulnerabilities in a product should allow Abbot Labs to walk away without penalties.
The first two, which can kill somebody, are the salient ones. The others are more normal cybersecurity issues, and may be of concern because they can leak HIPAA-protected info.
CVE-2016-xxxx: Pacemaker can be crashed, leading to death
Within a reasonable distance (under 50 feet) over several hours, pounding the pacemaker with malformed packets (either from an SDR or a hacked version of the Merlin@Home monitor), the pacemaker can crash. Sometimes such crashes will brick the device, other times put it into a state that may kill the patient by zapping the heart too quickly.
CVE-2016-xxxx: Pacemaker power can be drained, leading to death
Within a reasonable distance (under 50 feet) over several days, the pacemaker's power can slowly be drained at the rate of 3% per hour. While the user will receive a warning from their Merlin@Home monitoring device that the battery is getting low, it's possible the battery may be fully depleted before they can get to a doctor for a replacement. A non-functioning pacemaker may lead to death.
CVE-2016-xxxx: Pacemaker uses unauthenticated/unencrypted RF protocol
The above two items are possible because there is no encryption nor authentication in the wireless protocol, allowing any evildoer access to the pacemaker device or the monitoring device.
CVE-2016-xxxx: Merlin@Home contained hard-coded credentials and SSH keys
The password to connect to the St Jude network is the same for all device, and thus easily reverse engineered.
CVE-2016-xxxx: local proximity wand not required
It's unclear in the report, but it seems that most other products require a wand in local promixity (inches) in order to enable communication with the pacemaker. This seems like a requirement -- otherwise, even with authentication, remote RF would be able to drain the device in the person's chest.
So these are, as far as I can tell, the explicit bugs they outline. Unfortunately, none are described in detail. I don't see enough detail for any of these to actually be assigned a CVE number. I'm being generous here, trying to describe them as such, giving them the benefit of the doubt, there's enough weasel language in there that makes me doubt all of them. Though, if the first two prove not to be reproducible, then there will be a great defamation case, so I presume those two are true.
The report is clearly designed to scare other investors to drop St Jude stock price in the short term so that Muddy Waters can profit. It's not designed to withstand long term scrutiny. It's full of misleading details and outright lies.
For example, it keeps stressing how shockingly bad the security vulnerabilities are, such as saying:
The term "orders of magnitude" is math, by the way, and means "at least 100 times worse". As an expert, I claim these problems are not even one order of magnitude (10 times worse). I challenge MedSec's experts to stand behind the claim that these vulnerabilities are at least 100 times worse than other public medical device hacks.
In many places, the language is wishy-washy. Consider this quote:
Such language is pervasive throughout the document, things that aren't technically lies, but which aren't true, either.
Also pervasive throughout the document, repeatedly interjected for no reason in the middle of text, are statements like this, repeatedly stressing why you should sell the stock:
The Muddy Water's document attempts to violate this principle. Besides the the individual vulnerabilities, it makes the claim that St Jude cybersecurity is inherently bad because it's open. it uses off-the-shelf chips, standard software (line Linux), and standard protocols. St Jude does nothing to hide or obfuscate these things.
Everyone in cybersecurity would agree this is good. Muddy Waters claims this is bad.
For example, some of their quotes:
Medical device manufacturers should do the opposite of what Muddy Waters claims. I'll explain why.
Either your system is secure or it isn't. If it's secure, then making the details public won't hurt you. If it's insecure, then making the details obscure won't help you: hackers are far more adept at reverse engineering than you can possibly understand. Making things obscure, though, does stop helpful hackers (i.e. cybersecurity consultants you hire) from making your system secure, since it's hard figuring out the details.
Said another way: your adversaries (such as me) hate seeing open systems that are obviously secure. We love seeing obscure systems, because we know you couldn't possibly have validated their security.
The point is this: Muddy Waters is trying to profit from the public's misconception about cybersecurity, namely that obscurity is good. The actual principle is that obscurity is bad.
But it's almost certainly not true. Without authentication/encryption, then the fact that hackers can crash/drain a pacemaker is pretty obvious, especially since (as claimed by Muddy Waters), they've successfully done it. Specifically, the picture on page 17 of the 34 page Muddy Waters document is a smoking gun of a pacemaker misbehaving.
The rest of their document contains weasel-word denials that may be technically true, but which have no meaning.
Indeed, having been assessed by Deloitte is a good indicator that something is wrong. It's not that they are incompetent (they've got some smart people working for them), but ultimately the way the security market works is that you demand of such auditors that the find reasons to believe your product is secure, not that they keep hunting until something is found that is insecure. It's why outsiders, like MedSec, are better, because they strive to find why your product is insecure. The bigger the enemy, the more resources they'll put into finding a problem.
It's like after you get a hair cut, your enemies and your friends will have different opinions on your new look. Enemies are more honest.
The most obvious lie from the St Jude response is the following:
That St Jude deliberately lies here brings into question their entire rebuttal. (see what I did there?)
So let's get to the ethical issue everyone wants to discuss:
There's no insider trading. Some people wonder if there are insider trading issues. There aren't. While it's true that Muddy Waters knew some secrets that nobody else knew, as long as they weren't insider secrets, it's not insider trading. In other words, only insiders know about a key customer contract won or lost recently. But, vulnerabilities researched by outsiders is still outside the company.
Watching a CEO walk into the building of a competitor is still outsider knowledge -- you can trade on the likely merger, even though insider employees cannot.
Dropping 0day might kill/harm people. That may be true, but that's never an ethical reason to not drop it. That's because it's not this one event in isolation. If companies knew ethical researchers would never drop an 0day, then they'd never patch it. It's like the government's warrantless surveillance of American citizens: the courts won't let us challenge it, because we can't prove it exists, and we can't prove it exists, because the courts allow it to be kept secret, because revealing the surveillance would harm national intelligence. That harm may happen shouldn't stop the right thing from happening.
In other words, in the long run, dropping this 0day doesn't necessarily harm people -- and thus profiting on it is not an ethical issue. We need incentives to find vulns. This moves the debate from an ethical one to more of a factual debate about the long-term/short-term risk from vuln disclosure.
As MedSec points out, St Jude has already proven itself an untrustworthy consumer of vulnerability disclosures. When that happens, the dropping 0day is ethically permissible for "responsible disclosure". Indeed, that St Jude then lied about it in their response ex post facto justifies the dropping of the 0day.
No 0day was actually dropped here. In this case, what was dropped was claims of 0day. This may be good or bad, depending on your arguments. It's good that the vendor will have some extra time to fix the problems before hackers can start exploiting them. It's bad because we can't properly evaluate the true impact of the 0day unless we get more detail -- allowing Muddy Waters to exaggerate and mislead people in order to move the stock more than is warranted.
In other words, the lack of actual 0day here is the problem -- actual 0day would've been better.
This 0day is not necessarily harmful. Okay, it is harmful, but it requires close proximity. It's not as if the hacker can reach out from across the world and kill everyone (barring my movie-plot section above). If you are within 50 feet of somebody, it's easier shooting, stabbing, or poisoning them.
Shorting on bad news is common. Before we address the issue whether this is unethical for cybersecurity researchers, we should first address the ethics for anybody doing this. Muddy Waters already does this by investigating companies for fraudulent accounting practice, then shorting the stock while revealing the fraud.
Yes, it's bad that Muddy Waters profits on the misfortunes of others, but it's others who are doing fraud -- who deserve it. [Snide capitalism trigger warning] To claim this is unethical means you are a typical socialist who believe the State should defend companies, even those who do illegal thing, in order to stop illegitimate/windfall profits. Supporting the ethics of this means you are a capitalist, who believe companies should succeed or fail on their own merits -- which means bad companies need to fail, and investors in those companies should lose money.
Yes, this is bad for cybersec research. There is constant tension between cybersecurity researchers doing "responsible" (sic) research and companies lobbying congress to pass laws against it. We see this recently how Detroit lobbied for DMCA (copyright) rules to bar security research, and how the DMCA regulators gave us an exemption. MedSec's action means now all medical devices manufacturers will now lobby congress for rules to stop MedSec -- and the rest of us security researchers. The lack of public research means medical devices will continue to be flawed, which is worse for everyone.
Personally, I don't care about this argument. How others might respond badly to my actions is not an ethical constraint on my actions. It's like speech: that others may be triggered into lobbying for anti-speech laws is still not constraint on what ethics allow me to say.
There were no lies or betrayal in the research. For me, "ethics" is usually a problem of lying, cheating, theft, and betrayal. As long as these things don't happen, then it's ethically okay. If MedSec had been hired by St Jude, had promised to keep things private, and then later disclosed them, then we'd have an ethical problem. Or consider this: frequently clients ask me to lie or omit things in pentest reports. It's an ethical quagmire. The quick answer, by the way, is "can you make that request in writing?". The long answer is "no". It's ethically permissible to omit minor things or do minor rewording, but not when it impinges on my credibility.
A life is worth about $10-million. Most people agree that "you can't put value on a human life", and that those who do are evil. The opposite is true. Should we spend more on airplane safety, breast cancer research, or the military budget to fight ISIS. Each can be measured in the number of lives saved. Should we spend more on breast cancer research, which affects people in their 30s, or solving heart disease, which affects people's in their 70s? All these decisions means putting value on human life, and sometimes putting different value on human life. Whether you think it's ethical, it's the way the world works.
Thus, we can measure this disclosure of 0day in terms of potential value of life lost, vs. potential value of life saved.
Is this market manipulation? This is more of a legal question than an ethical one, but people are discussing it. If the data is true, then it's not "manipulation" -- only if it's false. As documented in this post, there's good reason to doubt the complete truth of what Muddy Waters claims. I suspect it'll cost Muddy Waters more in legal fees in the long run than they could possibly hope to gain in the short run. I recommend investment companies stick to areas of their own expertise (accounting fraud) instead of branching out into things like cyber where they really don't grasp things.
This is again bad for security research. Frankly, we aren't a trusted community, because we claim the "sky is falling" too often, and are proven wrong. As this is proven to be market manipulation, as the stock recovers back to its former level, and the scary stories of mass product recalls fail to emerge, we'll be blamed yet again for being wrong. That hurts are credibility.
On the other the other hand, if any of the scary things Muddy Waters claims actually come to pass, then maybe people will start heading our warnings.
Ethics conclusion: I'm a die-hard troll, so therefore I'm going to vigorously defend the idea of shorting stock while dropping 0day. (Most of you appear to think it's unethical -- I therefore must disagree with you). But I'm also a capitalist. This case creates an incentive to drop harmful 0days -- but it creates an even greater incentive for device manufacturers not to have 0days to begin with. Thus, despite being a dishonest troll, I do sincerely support the ethics of this.
Muddy Waters thinks the security problems are severe enough that it'll destroy St Jude's $2.5 billion pacemaker business. The argument is flimsy. St Jude's retort is equally flimsy.
My prediction: a year from now we'll see little change in St Jude's pacemaker business earners, while there may be some one time costs cleaning some stuff up. This will stop the shenanigans of future 0day+shorting, even when it's valid, because nobody will believe researches.
from Notes on that StJude/MuddyWatters/MedSec thing
The story so far
tl;dr: hackers drop 0day on medical device company hoping to profit by shorting their stock
MedSec is a bunch of cybersecurity researchers (white-hat hackers) who have been investigating medical devices. In theory, their primary business is to sell their services to medical device companies, to help companies secure their devices. Their CEO is Justine Bone, a long-time white-hat hacker. Despite Muddy Waters garbling the research, there's no reason to doubt that there's quality research underlying all this.
Muddy Waters is an investment company known for investigating companies, finding problems like accounting fraud, and profiting by shorting the stock of misbehaving companies.
Apparently, MedSec did a survey of many pacemaker manufacturers, chose the one with the most cybersecurity problems, and went to Muddy Waters with their findings, asking for a share of the profits Muddy Waters got from shorting the stock.
Muddy Waters published their findings in [1] above. St Jude published their response in [2] above. They are both highly dishonest. I point that out because people want to discuss the ethics of using 0day to short stock when we should talk about the ethics of lying.
"Why you should sell the stock" [finance issues]
In this section, I try to briefly summarize Muddy Water's argument why St Jude's stock will drop. I'm not an expert in this area (though I do a bunch of investment), but they do seem flimsy to me.
Muddy Water's argument is that these pacemakers are half of St Jude's business, and that fixing them will first require recalling them all, then take another 2 year to fix, during which time they can't be selling pacemakers. Much of the Muddy Waters paper is taken up explaining this, citing similar medical cases, and so on.
If at all true, and if the cybersecurity claims hold up, then yes, this would be good reason to short the stock. However, I suspect they aren't true -- and they are simply trying to scare people about long-term consequences allowing Muddy Waters to profit in the short term.
@selenakyle on Twitter suggests this interest document [4] about market-solutions to vuln-disclosure, if you are interested in this angle of things.
Update from @lippard: Abbot Labs agreed in April to buy St Jude at $85 a share (when St Jude's stock was $60/share). Presumable, for this Muddy Waters attack on St Jude's stock price to profit from anything more than a really short term stock drop (like dumping their short position today), Muddy Waters would have believe this effort will cause Abbot Labs to walk away from the deal. Normally, there are penalties for doing so, but material things like massive vulnerabilities in a product should allow Abbot Labs to walk away without penalties.
The 0day being dropped
Well, they didn't actually drop 0day as such, just claims that 0day exists -- that it's been "demonstrated". Reading through their document a few times, I've created a list of the 0day they found, to the granularity that one would expect from CVE numbers (CVE is group within the Department of Homeland security that assigns standard reference numbers to discovered vulnerabilities).The first two, which can kill somebody, are the salient ones. The others are more normal cybersecurity issues, and may be of concern because they can leak HIPAA-protected info.
CVE-2016-xxxx: Pacemaker can be crashed, leading to death
Within a reasonable distance (under 50 feet) over several hours, pounding the pacemaker with malformed packets (either from an SDR or a hacked version of the Merlin@Home monitor), the pacemaker can crash. Sometimes such crashes will brick the device, other times put it into a state that may kill the patient by zapping the heart too quickly.
CVE-2016-xxxx: Pacemaker power can be drained, leading to death
Within a reasonable distance (under 50 feet) over several days, the pacemaker's power can slowly be drained at the rate of 3% per hour. While the user will receive a warning from their Merlin@Home monitoring device that the battery is getting low, it's possible the battery may be fully depleted before they can get to a doctor for a replacement. A non-functioning pacemaker may lead to death.
CVE-2016-xxxx: Pacemaker uses unauthenticated/unencrypted RF protocol
The above two items are possible because there is no encryption nor authentication in the wireless protocol, allowing any evildoer access to the pacemaker device or the monitoring device.
CVE-2016-xxxx: Merlin@Home contained hard-coded credentials and SSH keys
The password to connect to the St Jude network is the same for all device, and thus easily reverse engineered.
CVE-2016-xxxx: local proximity wand not required
It's unclear in the report, but it seems that most other products require a wand in local promixity (inches) in order to enable communication with the pacemaker. This seems like a requirement -- otherwise, even with authentication, remote RF would be able to drain the device in the person's chest.
So these are, as far as I can tell, the explicit bugs they outline. Unfortunately, none are described in detail. I don't see enough detail for any of these to actually be assigned a CVE number. I'm being generous here, trying to describe them as such, giving them the benefit of the doubt, there's enough weasel language in there that makes me doubt all of them. Though, if the first two prove not to be reproducible, then there will be a great defamation case, so I presume those two are true.
The movie/TV plot scenarios
So if you wanted to use this as a realistic TV/movie plot, here are two of them.
#1 You (the executive of the acquiring company) are meeting with the CEO and executives of a smaller company you want to buy. It's a family concern, and the CEO really doesn't want to sell. But you know his/her children want to sell. Therefore, during the meeting, you pull out your notebook and an SDR device and put it on the conference room table. You start running the exploit to crash that CEO's pacemaker. It crashes, the CEO grabs his/her chest, who gets carted off the hospital. The children continue negotiations, selling off their company.
#2 You are a hacker in Russia going after a target. After many phishing attempts, you finally break into the home desktop computer. From that computer, you branch out and connect to the Merlin@Home devices through the hard-coded password. You then run an exploit from the device, using that device's own radio, to slowly drain the battery from the pacemaker, day after day, while the target sleeps. You patch the software so it no longer warns the user that the battery is getting low. The battery dies, and a few days later while the victim is digging a ditch, s/he falls over dead from heart failure.
The Muddy Water's document is crap
There are many ethical issues, but the first should be dishonesty and spin of the Muddy Waters research report.The report is clearly designed to scare other investors to drop St Jude stock price in the short term so that Muddy Waters can profit. It's not designed to withstand long term scrutiny. It's full of misleading details and outright lies.
For example, it keeps stressing how shockingly bad the security vulnerabilities are, such as saying:
We find STJ Cardiac Devices’ vulnerabilities orders of magnitude more worrying than the medical device hacks that have been publicly discussed in the past.This is factually untrue. St Jude problems are no worse than the 2013 issue where doctors disable the RF capabilities of Dick Cheney's pacemaker in response to disclosures. They are no worse than that insulin pump hack. Bad cybersecurity is the norm for medical devices. St Jude may be among the worst, but not by an order-of-magnitude.
The term "orders of magnitude" is math, by the way, and means "at least 100 times worse". As an expert, I claim these problems are not even one order of magnitude (10 times worse). I challenge MedSec's experts to stand behind the claim that these vulnerabilities are at least 100 times worse than other public medical device hacks.
In many places, the language is wishy-washy. Consider this quote:
Despite having no background in cybersecurity, Muddy Waters has been able to replicate in-house key exploits that help to enable these attacksThe semantic content of this is nil. It says they weren't able to replicate the attacks themselves. They don't have sufficient background in cybersecurity to understand what they replicated.
Such language is pervasive throughout the document, things that aren't technically lies, but which aren't true, either.
Also pervasive throughout the document, repeatedly interjected for no reason in the middle of text, are statements like this, repeatedly stressing why you should sell the stock:
Regardless, we have little doubt that STJ is about to enter a period of protracted litigation over these products. Should these trials reach verdicts, we expect the courts will hold that STJ has been grossly negligent in its product design. (We estimate awards could total $6.4 billion.15)I point this out because Muddy Waters obviously doesn't feel the content of the document stands on its own, so that you can make this conclusion yourself. It instead feels the need to repeat this message over and over on every page.
Muddy Waters violation of Kerckhoff's Principle
One of the most important principles of cyber security is Kerckhoff's Principle, that more openness is better. Or, phrased another way, that trying to achieve security through obscurity is bad.The Muddy Water's document attempts to violate this principle. Besides the the individual vulnerabilities, it makes the claim that St Jude cybersecurity is inherently bad because it's open. it uses off-the-shelf chips, standard software (line Linux), and standard protocols. St Jude does nothing to hide or obfuscate these things.
Everyone in cybersecurity would agree this is good. Muddy Waters claims this is bad.
For example, some of their quotes:
One competitor went as far as developing a highly proprietary embedded OS, which is quite costly and rarely seen
In contrast, the other manufacturers have proprietary RF chips developed specifically for their protocolsAgain, as the cybersecurity experts in this case, I challenge MedSec to publicly defend Muddy Waters in these claims.
Medical device manufacturers should do the opposite of what Muddy Waters claims. I'll explain why.
Either your system is secure or it isn't. If it's secure, then making the details public won't hurt you. If it's insecure, then making the details obscure won't help you: hackers are far more adept at reverse engineering than you can possibly understand. Making things obscure, though, does stop helpful hackers (i.e. cybersecurity consultants you hire) from making your system secure, since it's hard figuring out the details.
Said another way: your adversaries (such as me) hate seeing open systems that are obviously secure. We love seeing obscure systems, because we know you couldn't possibly have validated their security.
The point is this: Muddy Waters is trying to profit from the public's misconception about cybersecurity, namely that obscurity is good. The actual principle is that obscurity is bad.
St Jude's response was no better
In response to the Muddy Water's document, St Jude published this document [2]. It's equally full of lies -- the sort that may deserve a share holder lawsuit. (I see lawsuits galore over this). It says the following:We have examined the allegations made by Capital and MedSec on August 25, 2016 regarding the safety and security of our pacemakers and defibrillators, and while we would have preferred the opportunity to review a detailed account of the information, based on available information, we conclude that the report is false and misleading.If that's true, if they can prove this in court, then that will mean they could win millions in a defamation lawsuit against Muddy Waters, and millions more for stock manipulation.
But it's almost certainly not true. Without authentication/encryption, then the fact that hackers can crash/drain a pacemaker is pretty obvious, especially since (as claimed by Muddy Waters), they've successfully done it. Specifically, the picture on page 17 of the 34 page Muddy Waters document is a smoking gun of a pacemaker misbehaving.
The rest of their document contains weasel-word denials that may be technically true, but which have no meaning.
St. Jude Medical stands behind the security and safety of our devices as confirmed by independent third parties and supported through our regulatory submissions.
Our software has been evaluated and assessed by several independent organizations and researchers including Deloitte and Optiv.
In 2015, we successfully completed an upgrade to the ISO 27001:2013 certification.These are all myths of the cybersecurity industry. Conformance with security standards, such as ISO 27001:2013, has absolutely zero bearing on whether you are secure. Having some consultants/white-hat claim your product is secure doesn't mean other white-hat hackers won't find an insecurity.
Indeed, having been assessed by Deloitte is a good indicator that something is wrong. It's not that they are incompetent (they've got some smart people working for them), but ultimately the way the security market works is that you demand of such auditors that the find reasons to believe your product is secure, not that they keep hunting until something is found that is insecure. It's why outsiders, like MedSec, are better, because they strive to find why your product is insecure. The bigger the enemy, the more resources they'll put into finding a problem.
It's like after you get a hair cut, your enemies and your friends will have different opinions on your new look. Enemies are more honest.
The most obvious lie from the St Jude response is the following:
The report claimed that the battery could be depleted at a 50-foot range. This is not possible since once the device is implanted into a patient, wireless communication has an approximate 7-foot range. This brings into question the entire testing methodology that has been used as the basis for the Muddy Waters Capital and MedSec report.That's not how wireless works. With directional antennas and amplifiers, 7-feet easily becomes 50-feet or more. Even without that, something designed for reliable operation at 7-feet often works less reliably at 50-feet. There's no cutoff at 7-feet within which it will work, outside of which it won't.
That St Jude deliberately lies here brings into question their entire rebuttal. (see what I did there?)
ETHICS EHTICS ETHICS
First let's discuss the ethics of lying, using weasel words, and being deliberately misleading. Both St Jude and Muddy Waters do this, and it's ethically wrong. I point this out to uninterested readers who want to get at that other ethical issue. Clear violations of ethics we all agree interest nobody -- but they ought to. We should be lambasting Muddy Waters for their clear ethical violations, not the unclear one.So let's get to the ethical issue everyone wants to discuss:
Is it ethical to profit from shorting stock while dropping 0day.Let's discuss some of the issues.
There's no insider trading. Some people wonder if there are insider trading issues. There aren't. While it's true that Muddy Waters knew some secrets that nobody else knew, as long as they weren't insider secrets, it's not insider trading. In other words, only insiders know about a key customer contract won or lost recently. But, vulnerabilities researched by outsiders is still outside the company.
Watching a CEO walk into the building of a competitor is still outsider knowledge -- you can trade on the likely merger, even though insider employees cannot.
Dropping 0day might kill/harm people. That may be true, but that's never an ethical reason to not drop it. That's because it's not this one event in isolation. If companies knew ethical researchers would never drop an 0day, then they'd never patch it. It's like the government's warrantless surveillance of American citizens: the courts won't let us challenge it, because we can't prove it exists, and we can't prove it exists, because the courts allow it to be kept secret, because revealing the surveillance would harm national intelligence. That harm may happen shouldn't stop the right thing from happening.
In other words, in the long run, dropping this 0day doesn't necessarily harm people -- and thus profiting on it is not an ethical issue. We need incentives to find vulns. This moves the debate from an ethical one to more of a factual debate about the long-term/short-term risk from vuln disclosure.
As MedSec points out, St Jude has already proven itself an untrustworthy consumer of vulnerability disclosures. When that happens, the dropping 0day is ethically permissible for "responsible disclosure". Indeed, that St Jude then lied about it in their response ex post facto justifies the dropping of the 0day.
No 0day was actually dropped here. In this case, what was dropped was claims of 0day. This may be good or bad, depending on your arguments. It's good that the vendor will have some extra time to fix the problems before hackers can start exploiting them. It's bad because we can't properly evaluate the true impact of the 0day unless we get more detail -- allowing Muddy Waters to exaggerate and mislead people in order to move the stock more than is warranted.
In other words, the lack of actual 0day here is the problem -- actual 0day would've been better.
This 0day is not necessarily harmful. Okay, it is harmful, but it requires close proximity. It's not as if the hacker can reach out from across the world and kill everyone (barring my movie-plot section above). If you are within 50 feet of somebody, it's easier shooting, stabbing, or poisoning them.
Shorting on bad news is common. Before we address the issue whether this is unethical for cybersecurity researchers, we should first address the ethics for anybody doing this. Muddy Waters already does this by investigating companies for fraudulent accounting practice, then shorting the stock while revealing the fraud.
Yes, it's bad that Muddy Waters profits on the misfortunes of others, but it's others who are doing fraud -- who deserve it. [Snide capitalism trigger warning] To claim this is unethical means you are a typical socialist who believe the State should defend companies, even those who do illegal thing, in order to stop illegitimate/windfall profits. Supporting the ethics of this means you are a capitalist, who believe companies should succeed or fail on their own merits -- which means bad companies need to fail, and investors in those companies should lose money.
Yes, this is bad for cybersec research. There is constant tension between cybersecurity researchers doing "responsible" (sic) research and companies lobbying congress to pass laws against it. We see this recently how Detroit lobbied for DMCA (copyright) rules to bar security research, and how the DMCA regulators gave us an exemption. MedSec's action means now all medical devices manufacturers will now lobby congress for rules to stop MedSec -- and the rest of us security researchers. The lack of public research means medical devices will continue to be flawed, which is worse for everyone.
Personally, I don't care about this argument. How others might respond badly to my actions is not an ethical constraint on my actions. It's like speech: that others may be triggered into lobbying for anti-speech laws is still not constraint on what ethics allow me to say.
There were no lies or betrayal in the research. For me, "ethics" is usually a problem of lying, cheating, theft, and betrayal. As long as these things don't happen, then it's ethically okay. If MedSec had been hired by St Jude, had promised to keep things private, and then later disclosed them, then we'd have an ethical problem. Or consider this: frequently clients ask me to lie or omit things in pentest reports. It's an ethical quagmire. The quick answer, by the way, is "can you make that request in writing?". The long answer is "no". It's ethically permissible to omit minor things or do minor rewording, but not when it impinges on my credibility.
A life is worth about $10-million. Most people agree that "you can't put value on a human life", and that those who do are evil. The opposite is true. Should we spend more on airplane safety, breast cancer research, or the military budget to fight ISIS. Each can be measured in the number of lives saved. Should we spend more on breast cancer research, which affects people in their 30s, or solving heart disease, which affects people's in their 70s? All these decisions means putting value on human life, and sometimes putting different value on human life. Whether you think it's ethical, it's the way the world works.
Thus, we can measure this disclosure of 0day in terms of potential value of life lost, vs. potential value of life saved.
Is this market manipulation? This is more of a legal question than an ethical one, but people are discussing it. If the data is true, then it's not "manipulation" -- only if it's false. As documented in this post, there's good reason to doubt the complete truth of what Muddy Waters claims. I suspect it'll cost Muddy Waters more in legal fees in the long run than they could possibly hope to gain in the short run. I recommend investment companies stick to areas of their own expertise (accounting fraud) instead of branching out into things like cyber where they really don't grasp things.
This is again bad for security research. Frankly, we aren't a trusted community, because we claim the "sky is falling" too often, and are proven wrong. As this is proven to be market manipulation, as the stock recovers back to its former level, and the scary stories of mass product recalls fail to emerge, we'll be blamed yet again for being wrong. That hurts are credibility.
On the other the other hand, if any of the scary things Muddy Waters claims actually come to pass, then maybe people will start heading our warnings.
Ethics conclusion: I'm a die-hard troll, so therefore I'm going to vigorously defend the idea of shorting stock while dropping 0day. (Most of you appear to think it's unethical -- I therefore must disagree with you). But I'm also a capitalist. This case creates an incentive to drop harmful 0days -- but it creates an even greater incentive for device manufacturers not to have 0days to begin with. Thus, despite being a dishonest troll, I do sincerely support the ethics of this.
Conclusion
The two 0days are about crashing the device (killing the patient sooner) or draining the battery (killin them later). Both attacks require hours (if not days) in close proximity to the target. If you can get into the local network (such as through phishing), you might be able to hack the Merlin@Home monitor, which is in close proximity to the target for hours every night.Muddy Waters thinks the security problems are severe enough that it'll destroy St Jude's $2.5 billion pacemaker business. The argument is flimsy. St Jude's retort is equally flimsy.
My prediction: a year from now we'll see little change in St Jude's pacemaker business earners, while there may be some one time costs cleaning some stuff up. This will stop the shenanigans of future 0day+shorting, even when it's valid, because nobody will believe researches.
from Notes on that StJude/MuddyWatters/MedSec thing
Notes on that StJude/MuddyWatters/MedSec thing
I thought I'd write up some notes on the StJude/MedSec/MuddyWaters affair. Some references: [1] [2] [3] [4].
St Jude Medical (STJ) is one of the largest providers of pacemakers (aka. cardiac devices) in the country, around ~$2.5 billion in revenue, which accounts for about half their business. They provide "smart" pacemakers with an on-board computer that talks via radio-waves to a nearby monitor that records the functioning of the device (and health data). That monitor, "Merlin@Home", then talks back up to St Jude (via phone lines, 3G cell phone, or wifi). Pretty much all pacemakers work that way (my father's does, although his is from a different vendor).
MedSec is a bunch of cybersecurity researchers (white-hat hackers) who have been investigating medical devices. In theory, their primary business is to sell their services to medical device companies, to help companies secure their devices. Their CEO is Justine Bone, a long-time white-hat hacker.
Muddy Waters is an investment company known for investigating companies, finding problems like accounting fraud, and profiting by shorting the stock of misbehaving companies.
Apparently, MedSec did a survey of many pacemaker manufacturers, chose the one with the most cybersecurity problems, and went to Muddy Waters with their findings, asking for a share of the profits Muddy Waters got from shorting the stock.
Muddy Waters published their findings in [1] above. St Jude published their response in [2] above. They are both highly dishonest. I point that out because people want to discuss the ethics of using 0day to short stock when we should talk about the ethics of lying.
The first two, which can kill somebody, are the salient ones. The others are more normal cybersecurity issues, and may be of concern because they can leak HIPAA-protected info.
CVE-2016-xxxx: Pacemaker can be crashed, leading to death
Within a reasonable distance (under 50 feet) over several hours, pounding the pacemaker with malformed packets (either from an SDR or a hacked version of the Merlin@Home monitor), the pacemaker can crash. Sometimes such crashes will brick the device, other times put it into a state that may kill the patient by zapping the heart too quickly.
CVE-2016-xxxx: Pacemaker power can be drained, leading to death
Within a reasonable distance (under 50 feet) over several days, the pacemaker's power can slowly be drained at the rate of 3% per hour. While the user will receive a warning from their Merlin@Home monitoring device that the battery is getting low, it's possible the battery may be fully depleted before they can get to a doctor for a replacement. A non-functioning pacemaker may lead to death.
CVE-2016-xxxx: Pacemaker uses unauthenticated/unencrypted RF protocol
The above two items are possible because there is no encryption nor authentication in the wireless protocol, allowing any evildoer access to the pacemaker device or the monitoring device.
CVE-2016-xxxx: Merlin@Home contained hard-coded credentials and SSH keys
The password to connect to the St Jude network is the same for all device, and thus easily reverse engineered.
CVE-2016-xxxx: local proximity wand not required
It's unclear in the report, but it seems that most other products require a wand in local promixity (inches) in order to enable communication with the pacemaker. This seems like a requirement -- otherwise, even with authentication, remote RF would be able to drain the device in the person's chest.
So these are, as far as I can tell, the explicit bugs they outline. Unfortunately, none are described in detail. I don't see enough detail for any of these to actually be assigned a CVE number. I'm being generous here, trying to describe them as such, giving them the benefit of the doubt, there's enough weasel language in there that makes me doubt all of them. Though, if the first two prove not to be reproducible, then there will be a great defamation case, so I presume those two are true.
The report is clearly designed to scare other investors to drop St Jude stock price in the short term so that Muddy Waters can profit. It's not designed to withstand long term scrutiny. It's full of misleading details and outright lies.
For example, it keeps stressing how shockingly bad the security vulnerabilities are, such as saying:
The term "orders of magnitude" is math, by the way, and means "at least 100 times worse". As an expert, I claim these problems are not even one order of magnitude (10 times worse). I challenge MedSec's experts to stand behind the claim that these vulnerabilities are at least 100 times worse than other public medical device hacks.
In many places, the language is wishy-washy. Consider this quote:
Such language is pervasive throughout the document, things that aren't technically lies, but which aren't true, either.
Also pervasive throughout the document, repeatedly interjected for no reason in the middle of text, are statements like this, repeatedly stressing why you should sell the stock:
The Muddy Water's document attempts to violate this principle. Besides the the individual vulnerabilities, it makes the claim that St Jude cybersecurity is inherently bad because it's open. it uses off-the-shelf chips, standard software (line Linux), and standard protocols. St Jude does nothing to hide or obfuscate these things.
Everyone in cybersecurity would agree this is good. Muddy Waters claims this is bad.
For example, some of their quotes:
Medical device manufacturers should do the opposite of what Muddy Waters claims. I'll explain why.
Either your system is secure or it isn't. If it's secure, then making the details public won't hurt you. If it's insecure, then making the details obscure won't help you: hackers are far more adept at reverse engineering than you can possibly understand. Making things obscure, though, does stop helpful hackers (i.e. cybersecurity consultants you hire) from making your system secure, since it's hard figuring out the details.
Said another way: your adversaries (such as me) hate seeing open systems that are obviously secure. We love seeing obscure systems, because we know you couldn't possibly have validated their security.
The point is this: Muddy Waters is trying to profit from the public's misconception about cybersecurity, namely that obscurity is good. The actual principle is that obscurity is bad.
But it's almost certainly not true. Without authentication/encryption, then the fact that hackers can crash/drain a pacemaker is pretty obvious, especially since (as claimed by Muddy Waters), they've successfully done it. Specifically, the picture on page 17 of the 34 page Muddy Waters document is a smoking gun of a pacemaker misbehaving.
The rest of their document contains weasel-word denials that may be technically true, but which have no meaning.
Indeed, having been assessed by Deloitte is a good indicator that something is wrong. It's not that they are incompetent (they've got some smart people working for them), but ultimately the way the security market works is that you demand of such auditors that the find reasons to believe your product is secure, not that they keep hunting until something is found that is insecure. It's why outsiders, like MedSec, are better, because they strive to find why your product is insecure. The bigger the enemy, the more resources they'll put into finding a problem.
It's like after you get a hair cut, your enemies and your friends will have different opinions on your new look. Enemies are more honest.
The most obvious lie from the St Jude response is the following:
That St Jude deliberately lies here brings into question their entire rebuttal. (see what I did there?)
So let's get to the ethical issue everyone wants to discuss:
There's no insider trading. Some people wonder if there are insider trading issues. There aren't. While it's true that Muddy Waters knew some secrets that nobody else knew, as long as they weren't insider secrets, it's not insider trading. In other words, only insiders know about a key customer contract won or lost recently. But, vulnerabilities researched by outsiders is still outside the company.
Watching a CEO walk into the building of a competitor is still outsider knowledge -- you can trade on the likely merger, even though insider employees cannot.
Dropping 0day might kill/harm people. That may be true, but that's never an ethical reason to not drop it. That's because it's not this one event in isolation. If companies knew ethical researchers would never drop an 0day, then they'd never patch it. It's like the government's warrantless surveillance of American citizens: the courts won't let us challenge it, because we can't prove it exists, and we can't prove it exists, because the courts allow it to be kept secret, because revealing the surveillance would harm national intelligence. That harm may happen shouldn't stop the right thing from happening.
In other words, in the long run, dropping this 0day doesn't necessarily harm people -- and thus profiting on it is not an ethical issue. We need incentives to find vulns. This moves the debate from an ethical one to more of a factual debate about the long-term/short-term risk from vuln disclosure.
As MedSec points out, St Jude has already proven itself an untrustworthy consumer of vulnerability disclosures. When that happens, the dropping 0day is ethically permissible for "responsible disclosure". Indeed, that St Jude then lied about it in their response ex post facto justifies the dropping of the 0day.
No 0day was actually dropped here. In this case, what was dropped was claims of 0day. This may be good or bad, depending on your arguments. It's good that the vendor will have some extra time to fix the problems before hackers can start exploiting them. It's bad because we can't properly evaluate the true impact of the 0day unless we get more detail -- allowing Muddy Waters to exaggerate and mislead people in order to move the stock more than is warranted.
In other words, the lack of actual 0day here is the problem -- actual 0day would've been better.
This 0day is not necessarily harmful. Okay, it is harmful, but it requires close proximity. It's not as if the hacker can reach out from across the world and kill everyone (barring my movie-plot section above). If you are within 50 feet of somebody, it's easier shooting, stabbing, or poisoning them.
Shorting on bad news is common. Before we address the issue whether this is unethical for cybersecurity researchers, we should first address the ethics for anybody doing this. Muddy Waters already does this by investigating companies for fraudulent accounting practice, then shorting the stock while revealing the fraud.
Yes, it's bad that Muddy Waters profits on the misfortunes of others, but it's others who are doing fraud -- who deserve it. [Snide capitalism trigger warning] To claim this is unethical means you are a typical socialist who believe the State should defend companies, even those who do illegal thing, in order to stop illegitimate/windfall profits. Supporting the ethics of this means you are a capitalist, who believe companies should succeed or fail on their own merits -- which means bad companies need to fail, and investors in those companies should lose money.
Yes, this is bad for cybersec research. There is constant tension between cybersecurity researchers doing "responsible" (sic) research and companies lobbying congress to pass laws against it. We see this recently how Detroit lobbied for DMCA (copyright) rules to bar security research, and how the DMCA regulators gave us an exemption. MedSec's action means now all medical devices manufacturers will now lobby congress for rules to stop MedSec -- and the rest of us security researchers. The lack of public research means medical devices will continue to be flawed, which is worse for everyone.
Personally, I don't care about this argument. How others might respond badly to my actions is not an ethical constraint on my actions. It's like speech: that others may be triggered into lobbying for anti-speech laws is still not constraint on what ethics allow me to say.
There were no lies or betrayal in the research. For me, "ethics" is usually a problem of lying, cheating, theft, and betrayal. As long as these things don't happen, then it's ethically okay. If MedSec had been hired by St Jude, had promised to keep things private, and then later disclosed them, then we'd have an ethical problem. Or consider this: frequently clients ask me to lie or omit things in pentest reports. It's an ethical quagmire. The quick answer, by the way, is "can you make that request in writing?". The long answer is "no". It's ethically permissible to omit minor things or do minor rewording, but not when it impinges on my credibility.
A life is worth about $10-million. Most people agree that "you can't put value on a human life", and that those who do are evil. The opposite is true. Should we spend more on airplane safety, breast cancer research, or the military budget to fight ISIS. Each can be measured in the number of lives saved. Should we spend more on breast cancer research, which affects people in their 30s, or solving heart disease, which affects people's in their 70s? All these decisions means putting value on human life, and sometimes putting different value on human life. Whether you think it's ethical, it's the way the world works.
Thus, we can measure this disclosure of 0day in terms of potential value of life lost, vs. potential value of life saved.
Is this market manipulation? This is more of a legal question than an ethical one, but people are discussing it. If the data is true, then it's not "manipulation" -- only if it's false. As documented in this post, there's good reason to doubt the complete truth of what Muddy Waters claims. I suspect it'll cost Muddy Waters more in legal fees in the long run than they could possibly hope to gain in the short run. I recommend investment companies stick to areas of their own expertise (accounting fraud) instead of branching out into things like cyber where they really don't grasp things.
This is again bad for security research. Frankly, we aren't a trusted community, because we claim the "sky is falling" too often, and are proven wrong. As this is proven to be market manipulation, as the stock recovers back to its former level, and the scary stories of mass product recalls fail to emerge, we'll be blamed yet again for being wrong. That hurts are credibility.
On the other the other hand, if any of the scary things Muddy Waters claims actually come to pass, then maybe people will start heading our warnings.
Ethics conclusion: I'm a die-hard troll, so therefore I'm going to vigorously defend the idea of shorting stock while dropping 0day. (Most of you appear to think it's unethical -- I therefore must disagree with you). But I'm also a capitalist. This case creates an incentive to drop harmful 0days -- but it creates an even greater incentive for device manufacturers not to have 0days to begin with. Thus, despite being a dishonest troll, I do sincerely support the ethics of this.
Muddy Waters thinks the security problems are severe enough that it'll destroy St Jude's $2.5 billion pacemaker business. The argument is flimsy. St Jude's retort is equally flimsy.
My prediction: a year from now we'll see little change in St Jude's pacemaker business earners, while there may be some one time costs cleaning some stuff up.
from Notes on that StJude/MuddyWatters/MedSec thing
The story so far
tl;dr: hackers drop 0day on medical device company hoping to profit by shorting their stock
MedSec is a bunch of cybersecurity researchers (white-hat hackers) who have been investigating medical devices. In theory, their primary business is to sell their services to medical device companies, to help companies secure their devices. Their CEO is Justine Bone, a long-time white-hat hacker.
Muddy Waters is an investment company known for investigating companies, finding problems like accounting fraud, and profiting by shorting the stock of misbehaving companies.
Apparently, MedSec did a survey of many pacemaker manufacturers, chose the one with the most cybersecurity problems, and went to Muddy Waters with their findings, asking for a share of the profits Muddy Waters got from shorting the stock.
Muddy Waters published their findings in [1] above. St Jude published their response in [2] above. They are both highly dishonest. I point that out because people want to discuss the ethics of using 0day to short stock when we should talk about the ethics of lying.
"Why you should sell the stock" [finance issues]
In this section, I try to briefly summarize Muddy Water's argument why St Jude's stock will drop. I'm not an expert in this area (though I do a bunch of investment), but they do seem flimsy to me.
Muddy Water's argument is that these pacemakers are half of St Jude's business, and that fixing them will first require recalling them all, then take another 2 year to fix, during which time they can't be selling pacemakers. Much of the Muddy Waters paper is taken up explaining this, citing similar medical cases, and so on.
If at all true, and if the cybersecurity claims hold up, then yes, this would be good reason to short the stock. However, I suspect they aren't true -- and they are simply trying to scare people about long-term consequences allowing Muddy Waters to profit in the short term.
@selenakyle on Twitter suggests this interest document [4] about market-solutions to vuln-disclosure, if you are interested in this angle of things.
The 0day being dropped
Well, they didn't actually drop 0day as such, just claims that 0day exists -- that it's been "demonstrated". Reading through their document a few times, I've created a list of the 0day they found, to the granularity that one would expect from CVE numbers (CVE is group within the Department of Homeland security that assigns standard reference numbers to discovered vulnerabilities).The first two, which can kill somebody, are the salient ones. The others are more normal cybersecurity issues, and may be of concern because they can leak HIPAA-protected info.
CVE-2016-xxxx: Pacemaker can be crashed, leading to death
Within a reasonable distance (under 50 feet) over several hours, pounding the pacemaker with malformed packets (either from an SDR or a hacked version of the Merlin@Home monitor), the pacemaker can crash. Sometimes such crashes will brick the device, other times put it into a state that may kill the patient by zapping the heart too quickly.
CVE-2016-xxxx: Pacemaker power can be drained, leading to death
Within a reasonable distance (under 50 feet) over several days, the pacemaker's power can slowly be drained at the rate of 3% per hour. While the user will receive a warning from their Merlin@Home monitoring device that the battery is getting low, it's possible the battery may be fully depleted before they can get to a doctor for a replacement. A non-functioning pacemaker may lead to death.
CVE-2016-xxxx: Pacemaker uses unauthenticated/unencrypted RF protocol
The above two items are possible because there is no encryption nor authentication in the wireless protocol, allowing any evildoer access to the pacemaker device or the monitoring device.
CVE-2016-xxxx: Merlin@Home contained hard-coded credentials and SSH keys
The password to connect to the St Jude network is the same for all device, and thus easily reverse engineered.
CVE-2016-xxxx: local proximity wand not required
It's unclear in the report, but it seems that most other products require a wand in local promixity (inches) in order to enable communication with the pacemaker. This seems like a requirement -- otherwise, even with authentication, remote RF would be able to drain the device in the person's chest.
So these are, as far as I can tell, the explicit bugs they outline. Unfortunately, none are described in detail. I don't see enough detail for any of these to actually be assigned a CVE number. I'm being generous here, trying to describe them as such, giving them the benefit of the doubt, there's enough weasel language in there that makes me doubt all of them. Though, if the first two prove not to be reproducible, then there will be a great defamation case, so I presume those two are true.
The movie/TV plot scenarios
So if you wanted to use this as a realistic TV/movie plot, here are two of them.
#1 You (the executive of the acquiring company) are meeting with the CEO and executives of a smaller company you want to buy. It's a family concern, and the CEO really doesn't want to sell. But you know his/her children want to sell. Therefore, during the meeting, you pull out your notebook and an SDR device and put it on the conference room table. You start running the exploit to crash that CEO's pacemaker. It crashes, the CEO grabs his/her chest, who gets carted off the hospital. The children continue negotiations, selling off their company.
#2 You are a hacker in Russia going after a target. After many phishing attempts, you finally break into the home desktop computer. From that computer, you branch out and connect to the Merlin@Home devices through the hard-coded password. You then run an exploit from the device, using that device's own radio, to slowly drain the battery from the pacemaker, day after day, while the target sleeps. You patch the software so it no longer warns the user that the battery is getting low. The battery dies, and a few days later while the victim is digging a ditch, s/he falls over dead from heart failure.
The Muddy Water's document is crap
There are many ethical issues, but the first should be dishonesty and spin of the Muddy Waters research report.The report is clearly designed to scare other investors to drop St Jude stock price in the short term so that Muddy Waters can profit. It's not designed to withstand long term scrutiny. It's full of misleading details and outright lies.
For example, it keeps stressing how shockingly bad the security vulnerabilities are, such as saying:
We find STJ Cardiac Devices’ vulnerabilities orders of magnitude more worrying than the medical device hacks that have been publicly discussed in the past.This is factually untrue. St Jude problems are no worse than the 2013 issue where doctors disable the RF capabilities of Dick Cheney's pacemaker in response to disclosures. They are no worse than that insulin pump hack. Bad cybersecurity is the norm for medical devices. St Jude may be among the worse, but not by an order-of-magnitude.
The term "orders of magnitude" is math, by the way, and means "at least 100 times worse". As an expert, I claim these problems are not even one order of magnitude (10 times worse). I challenge MedSec's experts to stand behind the claim that these vulnerabilities are at least 100 times worse than other public medical device hacks.
In many places, the language is wishy-washy. Consider this quote:
Despite having no background in cybersecurity, Muddy Waters has been able to replicate in-house key exploits that help to enable these attacksThe semantic content of this is nil. It says they weren't able to replicate the attacks themselves. They don't have sufficient background in cybersecurity to understand what they replicated.
Such language is pervasive throughout the document, things that aren't technically lies, but which aren't true, either.
Also pervasive throughout the document, repeatedly interjected for no reason in the middle of text, are statements like this, repeatedly stressing why you should sell the stock:
Regardless, we have little doubt that STJ is about to enter a period of protracted litigation over these products. Should these trials reach verdicts, we expect the courts will hold that STJ has been grossly negligent in its product design. (We estimate awards could total $6.4 billion.15)I point this out because Muddy Waters obviously doesn't feel the content of the document stands on its own, so that you can make this conclusion yourself. It instead feels the need to repeat this message over and over on every page.
Muddy Waters violation of Kerckhoff's Principle
One of the most important principles of cyber security is Kerckhoff's Principle, that more openness is better. Or, phrased another way, that trying to achieve security through obscurity is bad.The Muddy Water's document attempts to violate this principle. Besides the the individual vulnerabilities, it makes the claim that St Jude cybersecurity is inherently bad because it's open. it uses off-the-shelf chips, standard software (line Linux), and standard protocols. St Jude does nothing to hide or obfuscate these things.
Everyone in cybersecurity would agree this is good. Muddy Waters claims this is bad.
For example, some of their quotes:
One competitor went as far as developing a highly proprietary embedded OS, which is quite costly and rarely seen
In contrast, the other manufacturers have proprietary RF chips developed specifically for their protocolsAgain, as the cybersecurity experts in this case, I challenge MedSec to publicly defend Muddy Waters in these claims.
Medical device manufacturers should do the opposite of what Muddy Waters claims. I'll explain why.
Either your system is secure or it isn't. If it's secure, then making the details public won't hurt you. If it's insecure, then making the details obscure won't help you: hackers are far more adept at reverse engineering than you can possibly understand. Making things obscure, though, does stop helpful hackers (i.e. cybersecurity consultants you hire) from making your system secure, since it's hard figuring out the details.
Said another way: your adversaries (such as me) hate seeing open systems that are obviously secure. We love seeing obscure systems, because we know you couldn't possibly have validated their security.
The point is this: Muddy Waters is trying to profit from the public's misconception about cybersecurity, namely that obscurity is good. The actual principle is that obscurity is bad.
St Jude's response was no better
In response to the Muddy Water's document, St Jude published this document [2]. It's equally full of lies -- the sort that may deserve a share holder lawsuit. (I see lawsuits galore over this). It says the following:We have examined the allegations made by Capital and MedSec on August 25, 2016 regarding the safety and security of our pacemakers and defibrillators, and while we would have preferred the opportunity to review a detailed account of the information, based on available information, we conclude that the report is false and misleading.If that's true, if they can prove this in court, then that will mean they could win millions in a defamation lawsuit against Muddy Waters, and millions more for stock manipulation.
But it's almost certainly not true. Without authentication/encryption, then the fact that hackers can crash/drain a pacemaker is pretty obvious, especially since (as claimed by Muddy Waters), they've successfully done it. Specifically, the picture on page 17 of the 34 page Muddy Waters document is a smoking gun of a pacemaker misbehaving.
The rest of their document contains weasel-word denials that may be technically true, but which have no meaning.
St. Jude Medical stands behind the security and safety of our devices as confirmed by independent third parties and supported through our regulatory submissions.
Our software has been evaluated and assessed by several independent organizations and researchers including Deloitte and Optiv.
In 2015, we successfully completed an upgrade to the ISO 27001:2013 certification.These are all myths of the cybersecurity industry. Conformance with security standards, such as ISO 27001:2013, has absolutely zero bearing on whether you are secure. Having some consultants/white-hat claim your product is secure doesn't mean other white-hat hackers won't find an insecurity.
Indeed, having been assessed by Deloitte is a good indicator that something is wrong. It's not that they are incompetent (they've got some smart people working for them), but ultimately the way the security market works is that you demand of such auditors that the find reasons to believe your product is secure, not that they keep hunting until something is found that is insecure. It's why outsiders, like MedSec, are better, because they strive to find why your product is insecure. The bigger the enemy, the more resources they'll put into finding a problem.
It's like after you get a hair cut, your enemies and your friends will have different opinions on your new look. Enemies are more honest.
The most obvious lie from the St Jude response is the following:
The report claimed that the battery could be depleted at a 50-foot range. This is not possible since once the device is implanted into a patient, wireless communication has an approximate 7-foot range. This brings into question the entire testing methodology that has been used as the basis for the Muddy Waters Capital and MedSec report.That's not how wireless works. With directional antennas and amplifiers, 7-feet easily becomes 50-feet or more. Even without that, something designed for reliable operation at 7-feet often works less reliably at 50-feet. There's no cutoff at 7-feet within which it will work, outside of which it won't.
That St Jude deliberately lies here brings into question their entire rebuttal. (see what I did there?)
ETHICS EHTICS ETHICS
First let's discuss the ethics of lying, using weasel words, and being deliberately misleading. Both St Jude and Muddy Waters do this, and it's ethically wrong. I point this out to uninterested readers who want to get at that other ethical issue. Clear violations of ethics we all agree interest nobody -- but they ought to. We should be lambasting Muddy Waters for their clear ethical violations, not the unclear one.So let's get to the ethical issue everyone wants to discuss:
Is it ethical to profit from shorting stock while dropping 0day.Let's discuss some of the issues.
There's no insider trading. Some people wonder if there are insider trading issues. There aren't. While it's true that Muddy Waters knew some secrets that nobody else knew, as long as they weren't insider secrets, it's not insider trading. In other words, only insiders know about a key customer contract won or lost recently. But, vulnerabilities researched by outsiders is still outside the company.
Watching a CEO walk into the building of a competitor is still outsider knowledge -- you can trade on the likely merger, even though insider employees cannot.
Dropping 0day might kill/harm people. That may be true, but that's never an ethical reason to not drop it. That's because it's not this one event in isolation. If companies knew ethical researchers would never drop an 0day, then they'd never patch it. It's like the government's warrantless surveillance of American citizens: the courts won't let us challenge it, because we can't prove it exists, and we can't prove it exists, because the courts allow it to be kept secret, because revealing the surveillance would harm national intelligence. That harm may happen shouldn't stop the right thing from happening.
In other words, in the long run, dropping this 0day doesn't necessarily harm people -- and thus profiting on it is not an ethical issue. We need incentives to find vulns. This moves the debate from an ethical one to more of a factual debate about the long-term/short-term risk from vuln disclosure.
As MedSec points out, St Jude has already proven itself an untrustworthy consumer of vulnerability disclosures. When that happens, the dropping 0day is ethically permissible for "responsible disclosure". Indeed, that St Jude then lied about it in their response ex post facto justifies the dropping of the 0day.
No 0day was actually dropped here. In this case, what was dropped was claims of 0day. This may be good or bad, depending on your arguments. It's good that the vendor will have some extra time to fix the problems before hackers can start exploiting them. It's bad because we can't properly evaluate the true impact of the 0day unless we get more detail -- allowing Muddy Waters to exaggerate and mislead people in order to move the stock more than is warranted.
In other words, the lack of actual 0day here is the problem -- actual 0day would've been better.
This 0day is not necessarily harmful. Okay, it is harmful, but it requires close proximity. It's not as if the hacker can reach out from across the world and kill everyone (barring my movie-plot section above). If you are within 50 feet of somebody, it's easier shooting, stabbing, or poisoning them.
Shorting on bad news is common. Before we address the issue whether this is unethical for cybersecurity researchers, we should first address the ethics for anybody doing this. Muddy Waters already does this by investigating companies for fraudulent accounting practice, then shorting the stock while revealing the fraud.
Yes, it's bad that Muddy Waters profits on the misfortunes of others, but it's others who are doing fraud -- who deserve it. [Snide capitalism trigger warning] To claim this is unethical means you are a typical socialist who believe the State should defend companies, even those who do illegal thing, in order to stop illegitimate/windfall profits. Supporting the ethics of this means you are a capitalist, who believe companies should succeed or fail on their own merits -- which means bad companies need to fail, and investors in those companies should lose money.
Yes, this is bad for cybersec research. There is constant tension between cybersecurity researchers doing "responsible" (sic) research and companies lobbying congress to pass laws against it. We see this recently how Detroit lobbied for DMCA (copyright) rules to bar security research, and how the DMCA regulators gave us an exemption. MedSec's action means now all medical devices manufacturers will now lobby congress for rules to stop MedSec -- and the rest of us security researchers. The lack of public research means medical devices will continue to be flawed, which is worse for everyone.
Personally, I don't care about this argument. How others might respond badly to my actions is not an ethical constraint on my actions. It's like speech: that others may be triggered into lobbying for anti-speech laws is still not constraint on what ethics allow me to say.
There were no lies or betrayal in the research. For me, "ethics" is usually a problem of lying, cheating, theft, and betrayal. As long as these things don't happen, then it's ethically okay. If MedSec had been hired by St Jude, had promised to keep things private, and then later disclosed them, then we'd have an ethical problem. Or consider this: frequently clients ask me to lie or omit things in pentest reports. It's an ethical quagmire. The quick answer, by the way, is "can you make that request in writing?". The long answer is "no". It's ethically permissible to omit minor things or do minor rewording, but not when it impinges on my credibility.
A life is worth about $10-million. Most people agree that "you can't put value on a human life", and that those who do are evil. The opposite is true. Should we spend more on airplane safety, breast cancer research, or the military budget to fight ISIS. Each can be measured in the number of lives saved. Should we spend more on breast cancer research, which affects people in their 30s, or solving heart disease, which affects people's in their 70s? All these decisions means putting value on human life, and sometimes putting different value on human life. Whether you think it's ethical, it's the way the world works.
Thus, we can measure this disclosure of 0day in terms of potential value of life lost, vs. potential value of life saved.
Is this market manipulation? This is more of a legal question than an ethical one, but people are discussing it. If the data is true, then it's not "manipulation" -- only if it's false. As documented in this post, there's good reason to doubt the complete truth of what Muddy Waters claims. I suspect it'll cost Muddy Waters more in legal fees in the long run than they could possibly hope to gain in the short run. I recommend investment companies stick to areas of their own expertise (accounting fraud) instead of branching out into things like cyber where they really don't grasp things.
This is again bad for security research. Frankly, we aren't a trusted community, because we claim the "sky is falling" too often, and are proven wrong. As this is proven to be market manipulation, as the stock recovers back to its former level, and the scary stories of mass product recalls fail to emerge, we'll be blamed yet again for being wrong. That hurts are credibility.
On the other the other hand, if any of the scary things Muddy Waters claims actually come to pass, then maybe people will start heading our warnings.
Ethics conclusion: I'm a die-hard troll, so therefore I'm going to vigorously defend the idea of shorting stock while dropping 0day. (Most of you appear to think it's unethical -- I therefore must disagree with you). But I'm also a capitalist. This case creates an incentive to drop harmful 0days -- but it creates an even greater incentive for device manufacturers not to have 0days to begin with. Thus, despite being a dishonest troll, I do sincerely support the ethics of this.
Conclusion
The two 0days are about crashing the device (killing the patient sooner) or draining the battery (killin them later). Both attacks require hours (if not days) in close proximity to the target. If you can get into the local network (such as through phishing), you might be able to hack the Merlin@Home monitor, which is in close proximity to the target for hours every night.Muddy Waters thinks the security problems are severe enough that it'll destroy St Jude's $2.5 billion pacemaker business. The argument is flimsy. St Jude's retort is equally flimsy.
My prediction: a year from now we'll see little change in St Jude's pacemaker business earners, while there may be some one time costs cleaning some stuff up.
from Notes on that StJude/MuddyWatters/MedSec thing
New threats in July 2016
| New threats in July 2016 | |
|
(This post is the first in a monthly series highlighting some of the new threats detected by Sky ATP's deep analysis engines.)
In July, Sky ATP detected tens of thousands of malicious applications and documents as they passed through SRX firewalls. While most of these were known threats, Sky ATP also detected new malware strains, including multiple forms of ransomware as well as assorted trojans, droppers, spyware, and other potentially unwanted programs. In this post, we'll look at two new ransomware variants, plus an old threat that has evolved into highly-evasive (almost) fileless malware.
Early in the Sky ATP analysis pipeline, we run each new sample against a suite of anti-virus engines. AV engines are a fast and efficient way to catch and filter out known threats and their close variants. Removing these known threats from the analysis pipeline as early as possible reduces the load on the more computationally-expensive parts of the pipeline, which includes static analysis engines and full sandbox detonation. But for new threats, hashes and signatures are not enough. In this post, we’ll look at some of the threats we saw in July, which were undetected by numerous AV engines but caught by Sky ATP’s deep analysis.
Zepto ransomware We discussed Locky in previous posts. Zepto is a new variant, but looks and behaves much like Locky, except it uses ".zepto" as the file extension for the encrypted files:
Cerber ransomware Sky ATP’s deep analysis detected a number of variants of the Cerber ransomware that evaded traditional antivirus engines. The ransom process includes an automated voice announcing the infection.
Kovter's (almost) fileless malware Some of the most interesting samples detected by our deep analysis pipeline in July were several variants of the Kovter click-fraud malware. This malware strain has become increasingly evasive and maintains almost fileless persistence on a victim’s machine.
Kovter's authors use a clever trick to achieve persistence without leaving any of their malware on the actual Windows filesystem. The malware drops a randomly generated file with an arbitrary (but important!) file extension, along with a batch file and a shortcut.
The batch file "opens" the garbage .fcb676eie file with the start command.
Instead of opening the file, a registry key associated with the .fcb676eie extension instructs Windows to execute an altogether different command.
This uses Microsoft's mshta engine to execute the obfuscated Javascript stored in the registry. The bulk of the payload is a 5000+ character hexadecimal string, with is decoded and executed with the Javascript eval() function. This produces another Javascript program, this time with a very long string encoded in Base64.
This, in turn, is decoded to form a Powershell script containing raw shellcode that is injected and launched to create a malicious Windows process, using a technique taken from an old Metasploit template.
With this convoluted process, the malware can remain on the victim's computer without leaving anything on the filesystem besides the garbage file and its associated batch file and shortcut. Its malicious behavior, however, is still detected by Sky ATP's deep analysis techniques. Until next month... As mentioned above, these threats are just a few of many detected by Sky ATP's deep analysis engines. Thanks for reading, and please check back next month for another installment in this series! |
|
| Copyright © 1996-2016 Juniper Networks, Inc. All rights reserved Update preferences | |
from New threats in July 2016
Subscribe to:
Posts (Atom)