Depending on whose version of the story is correct, a 20 GB data leak affecting Intel presents an important lesson on either the perils of default credentials and insecure server misconfigurations, or the risks of sharing proprietary secrets with third-party business partners and customers.
Software engineer Tillie Kottmann, whose Twitter account looks to have been suspended, last week tweeted that an anonymous hacker shared with him a spate of internal Intel documents – the first of might be a series of leaks. Kottmann uploaded these confidential assets – including source code, product guides and manuals, technical specs, development and debugging tools and more – online via the file-sharing site MEGA and dubbed the leak "exconfidential Lake."
Several news outlets published an apparent conversation between Kottmann and the mysterious hacker persona, in which the perpetrator said that he (or she) had exfiltrated from an improperly secured internet server hosted via Akamai's content delivery network. The anonymous hacker said he found the breached server using a scanning tool and leveraged a Python script to uncover username defaults and unsecure instances of file or folder access. Once inside a folder, root access was then possible.
However, Intel in a statement denied that there was a hack and instead suspects that a rogue third party individual with access to the company’s Resource and Design Center web portal maliciously downloaded and leaked the information. The company also thinks the culprit could have amassed the information from multiple web sources.
"Based on our ongoing investigation and review of the documents, much of the information appears to have been previously available from various web sources, while some appears to come from the Intel Resource and Design Center, which hosts information for use by our customers, partners and other external parties who have registered for access," the statement reads. "At this time, we are not aware of any customer or personal data being included.”
Regardless of the circumstances, there are key takeaways from the incident. First and foremost, the unauthorized disclosure of source code and other sensitive intellectual property could potentially be a boon for those seeking to steal corporate secrets.
“Intel’s technology is almost ubiquitous, and the leaked device designs and firmware source code can put businesses and individuals at risk,” said Ilia Sotnikov, VP of product management at Netwrix. “Hackers and Intel’s own security research team are probably racing now to identify flaws in the leaked source code that can be exploited. Companies should take steps to identify what technology may be impacted and stay tuned for advisory and hotfix announcements from Intel.”
“While we often think of data breaches in the context of customer data lost and potential PII leakage, it is very important that we also consider the value of intellectual property, especially for very innovative organizations and organizations with a large market share," said Erich Kron, security awareness advocate at KnowBe4. This intellectual property can be very valuable to potential competitors, and even nation states, who often hope to capitalize on the research and development done by others.”
If Intel’s account of the incident is accurate, then another key lesson that it only takes one untrustworthy individual at a third-party organization -- or someone with access to sensitive documentation who shouldn't have it -- to potentially threaten data.
Kron said the incident serves to “underline the security concerns around intellectual property when working with business partners both up and down the supply chain. There is always a risk when sharing potentially sensitive information to these business partners; however, this is often an unavoidable part of doing business.”
"Whenever providing intellectual property access to another organization or individual, it is important to log not only who has access, but when and what data they are accessing," Kron continued. "Even better, as in this case with Intel, ensuring that you know where the documents have been shared by potentially marking the document itself, can be very valuable when hunting potential misuse as appears to have occurred here."
“Intel appears to have quickly traced the source of the information and I have no doubt, will be taking steps to review access and logs as they seek to identify the source of this data."
Noting that it's "unusual that the leaker has released the information publicly with no confirmed ransom demands that we are aware of," Chris Clements, VP of solutions architecture at Cerberus Sentinel, said that if a third party did published the data after accessing it from the Intel Resource and Design Center, "it would explain why they couldn’t extort Intel to prevent [its] release or find another buyer for Intel’s internal information."
"It’s a challenge for all organizations that need to distribute non-public information to outside organizations. For the most part, once the documents leave your network you have very little control of where they end up. The attacker’s claim that they found the data on an unsecured server on the internet could be a security oversight by Intel, but it could just as easily have been an Intel partner that inadvertently exposed the data through their own systems."
If, however, the attacker did really hack Intel by taking advantage of misconfigurations and default, then this opens up another can of worms. In that case, “Apparently, there was very little or no segmentation or separation of access," said Sotnikov at Netwrix. "The fact that guessing a single [username] gave hackers access to the root folder and source code from so many different projects is astonishing. This was another data breach that was caused by poor data access policies."
Moreover, said Sotnikov, “The fact that hackers were able to access a server using default credentials indicates that cybersecurity had lower priority compared to ease of use. Organizations that invest in innovation should immediately revise their security policies and check to make certain their servers with IP are properly secured. They should make sure all usernames and passwords are unique and access is granted only to the minimum number of employees."
"Designing access policies around least privileges has proven to reduce the impact of breaches, yet it is ignored way too often," Sotnikov continued.
