<div dir="ltr"><div><div class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><a href="https://www.riskbasedsecurity.com/2018/06/myheritage-bad-security-or-bad-luck/">https://www.riskbasedsecurity.com/2018/06/myheritage-bad-security-or-bad-luck/</a><br></div><div dir="ltr"><br></div><div dir="ltr"><p style="margin:0px;padding:0px 0px 10px;color:rgb(68,68,68);font-family:Arial,Tahoma,Verdana;background-color:rgb(247,247,247);text-decoration-style:initial;text-decoration-color:initial"><span style="font-weight:400">In the early afternoon of June 4</span><span style="font-weight:400">th</span><span style="font-weight:400">, the CISO of MyHeritage received the message every security professional dreads. A researcher was reaching out to share the news they had found a file containing users’ email addresses and hashed passwords – 92,283,889 records in total – for nearly every account created with the service through October 26, 2017.</span></p><p style="margin:0px;padding:0px 0px 10px;color:rgb(68,68,68);font-family:Arial,Tahoma,Verdana;background-color:rgb(247,247,247);text-decoration-style:initial;text-decoration-color:initial"><span style="font-weight:400">In some respects, the</span><a href="https://blog.myheritage.com/2018/06/myheritage-statement-about-a-cybersecurity-incident/" style="color:rgb(0,103,162);text-decoration:none"><span> </span><span style="font-weight:400">breach announcement</span></a><span style="font-weight:400"><span> </span>reads like so many others we see – regrets for the incident, launching a full investigation to determine scope, and promises of strengthening security thanks to the lessons learned. From the announcement it might be tempting to dismiss the breach as yet another example of a high profile firm playing fast and loose with sensitive data. But buried between the lines of the announcement are signs that myHeritage is getting a number of things “right” when it comes to their security practices.</span></p><p style="margin:0px;padding:0px 0px 10px;color:rgb(68,68,68);font-family:Arial,Tahoma,Verdana;background-color:rgb(247,247,247);text-decoration-style:initial;text-decoration-color:initial"></p><p style="margin:0px;padding:0px 0px 10px;color:rgb(68,68,68);font-family:Arial,Tahoma,Verdana;background-color:rgb(247,247,247);text-decoration-style:initial;text-decoration-color:initial"><span style="font-weight:400">Consider this evidence; first, the incident was discovered<span> </span></span><i><span style="font-weight:400">and</span></i><span style="font-weight:400"><span> </span>disclosed in less than 24 hours. According to the company’s statement on the event, the CISO first learned of the breach at approximately 1pm Eastern on June 4</span><span style="font-weight:400">th,<span> </span></span><span style="font-weight:400">which would be around 8pm at the company’s Israeli headquarters. MyHeritage was able to react immediately, starting with validating the legitimacy of the exposed data, looking for indications the data had been used maliciously, confirming other systems had not been compromised, and bringing in outside forensic assistance. All and all, the team gained enough visibility into the event they were able to<span> </span></span><a href="https://blog.myheritage.com/2018/06/cybersecurity-incident-june-5-6-update/" style="color:rgb(0,103,162);text-decoration:none"><span style="font-weight:400">inform users within<span> </span></span><i><span style="font-weight:400">8 hours</span></i><span style="font-weight:400"><span> </span>of first learning there was a problem</span></a><span style="font-weight:400">. That is incredibly fast by any measure.</span></p><p style="margin:0px;padding:0px 0px 10px;color:rgb(68,68,68);font-family:Arial,Tahoma,Verdana;background-color:rgb(247,247,247);text-decoration-style:initial;text-decoration-color:initial"><span style="font-weight:400">Beyond the speedy response, there are also the company’s statements about their technical practices. The</span><a href="https://cyberriskanalytics.com/" style="color:rgb(0,103,162);text-decoration:none"><span> </span><span style="font-weight:400">Cyber Risk Analytics</span></a><span style="font-weight:400"><span> </span>breach database is littered with organizations that chose to use weak encryption for passwords or worse, stored passwords in plain text. From their statement, MyHeritage appears to be following well-established practices for storing user passwords:</span></p><blockquote style="background:rgb(232,232,232);margin:0px 15px 15px;padding:10px 20px 0px 15px;color:rgb(68,68,68);font-family:Arial,Tahoma,Verdana;text-decoration-style:initial;text-decoration-color:initial"><p style="margin:0px;padding:0px 0px 10px"><i><span style="font-weight:400">MyHeritage does not store user passwords, but rather a one-way hash of each password, in which the hash key differs for each customer. This means that anyone gaining access to the hashed passwords does not have the actual passwords.</span></i></p></blockquote><p style="margin:0px;padding:0px 0px 10px;color:rgb(68,68,68);font-family:Arial,Tahoma,Verdana;background-color:rgb(247,247,247);text-decoration-style:initial;text-decoration-color:initial"><span style="font-weight:400">What’s more, MyHeritage appears to be following the dictum of only processing the sensitive data that you absolutely must, and where possible, segregating and hardening systems that hold sensitive data:</span></p><blockquote style="background:rgb(232,232,232);margin:0px 15px 15px;padding:10px 20px 0px 15px;color:rgb(68,68,68);font-family:Arial,Tahoma,Verdana;text-decoration-style:initial;text-decoration-color:initial"><p style="margin:0px;padding:0px 0px 10px"><i><span style="font-weight:400">We have no reason to believe that any other MyHeritage systems were compromised. As an example, credit card information is not stored on MyHeritage to begin with, but only on trusted third-party billing providers (e.g. BlueSnap, PayPal) utilized by MyHeritage. Other types of sensitive data such as family trees and DNA data are stored by MyHeritage on segregated systems, separate from those that store the email addresses, and they include added layers of security.</span></i></p></blockquote><p style="margin:0px;padding:0px 0px 10px;color:rgb(68,68,68);font-family:Arial,Tahoma,Verdana;background-color:rgb(247,247,247);text-decoration-style:initial;text-decoration-color:initial"><span style="font-weight:400">Finally, consider this – MyHeritage is open to receiving the work of security researchers. The company has not revealed who reached out with the information on the exposed file, nor do we know how much of a struggle it might have been to get the organization’s attention. Having had plenty of experience trying to reach companies with this type of information ourselves, we can say from first hand experience that getting through with the news of a security problem is rarely an easy or straightforward process.  We can also say from first hand experience that wasn’t the case with MyHeritage in the past.</span></p><p style="margin:0px;padding:0px 0px 10px;color:rgb(68,68,68);font-family:Arial,Tahoma,Verdana;background-color:rgb(247,247,247);text-decoration-style:initial;text-decoration-color:initial"><span style="font-weight:400">In March of 2013, </span><a href="https://www.riskbasedsecurity.com/2013/06/critical-vulnerabilities-in-the-myheritage-search-engine-activex-component/" style="color:rgb(0,103,162);text-decoration:none"><span style="font-weight:400">Risk Based Security’s Chief Research Officer Carsten Eiram discovered critical vulnerabilities in the MyHeritage search engine ActiveX component</span></a><span style="font-weight:400">. While the code maturity of the ActiveX component was fairly low, and it did take two attempts to reach the correct contacts at MyHeritage, and once we did, it was escalated to the CTO, COO, and CEO who took the report seriously and were very responsive. They immediately investigated the issue and removed the offending ActiveX control from their website to prevent it from being installed on more users’ systems. They also acknowledged that they would heed our advice to contact Microsoft to have the kill-bit set for it, so it would not be possible to instantiate it on their users’ systems. A full research report on the findings including a timeline of events</span><a href="https://www.riskbasedsecurity.com/research/RBS-2013-004.pdf" style="color:rgb(0,103,162);text-decoration:none"><span> </span><span style="font-weight:400">is still available for download here</span></a><span style="font-weight:400">.</span></p><p style="margin:0px;padding:0px 0px 10px;color:rgb(68,68,68);font-family:Arial,Tahoma,Verdana;background-color:rgb(247,247,247);text-decoration-style:initial;text-decoration-color:initial"><span style="font-weight:400">Breaches can happen to any organization. The data breach research team at Risk Based Security has documented over 30,500 such events and we’ve seen it all from minor mistakes to whopper events stemming from inexcusable security practices. On the surface MyHeritage losing 92.2 million user credentials might seem like another one of those inexcusable events but that may not be the case. From our experience and what we know about the event to date, the MyHeritage breach is much more an example of how breaches can happen despite making good security choices.</span></p><br></div><div dir="ltr"><br></div><div dir="ltr"><br><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><b><span style="font-size:10pt"></span></b><span style="font-size:10pt"></span><span style="font-family:arial,helvetica,sans-serif"></span><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>