Month: May 2018
Originally Seen: TechTarget by Judith Myerson
A recent flaw in Intel’s Advanced Management Technology enables hackers to gain access to endpoint devices. Discover how this flaw can be mitigated with expert Judith Myerson.
A flaw in Intel’s Advanced Management Technology enables hackers to exploit a simple vulnerability and gain control of corporate laptops. How is this possible, and what is the best way to mitigate the Intel AMT flaw?
Exploiting the flaw in Intel’s Advanced Management Technology (AMT) takes a few seconds. An attacker boots up his laptop by pressing CTRL-P, and then logs on to the Intel Management Engine BIOS Extension using admin as the default password. After changing the password, the attacker sets the user opt-in to None and connects to the victim’s laptop, bypassing a strong BIOSpassword and username.
The flaw enables the attacker to remotely access, read and modify data and applications that are assigned to a corporate user, and potentially even transfer them to the attacker’s server. Potential victims may be untargeted and merely be located in a waiting room or a public place. If the attacker finds that the victim’s laptop doesn’t have AMT, they can then search until a victim whose laptop requires AMT is found.
The best way to mitigate the Intel AMT flaw is to use Microsoft System Center Configuration for laptops connected to a Windows domain. System administrators can use it to:
- Remotely query all corporate laptops about suspicious passwords.
- Provision each laptop to require a strong password of 8 or more characters — a combination of numbers, letters and special characters is strongly recommended — and establish a policy on how often the password should be changed.
- Disable AMT for all laptops that don’t require it. This means the corporate IT staff will not be able to have remote control over these laptops and will need to find other ways to remotely secure them.
Any laptops found to be affected should be addressed by enterprise security teams, and corporate incident response procedures should be used.
Originally Seen: Cyberscoop by Zaid Shoorbajee
A small cybersecurity company and research group is publicly reporting major, Meltdown-style vulnerabilities in chips made by AMD, yet the disclosure itself has sent security researchers into a frenzy about possible ulterior motives.
CTS Labs, an Israeli cybersecurity company that purportedly focuses on hardware, launched a website and released a white paper on Tuesday describing 13 security flaws in AMD’s EPYC, Ryzen, Ryzen Pro and Ryzen processors. The chips are used in laptops, mobile devices and servers.
The vulnerabilities reportedly include backdoors that would allow attackers to inject malicious code onto AMD’s chips. Such malware could allow attackers to take complete control of AMD processors, steal network credentials, install malware and read and write on protected memory areas, among other risks.
CTS Labs released the vulnerability information on a public website, amdflaws.com, saying it released the findings for the sake of public awareness.
“In particular, we urge the community to pay closer attention to the security of AMD devices before allowing them on mission-critical systems that could potentially put lives at risk,” the website reads.
The company says it has sent technical information to companies, including AMD, in order for patches to be developed. That technical information is not available on the public website.
AMD has addressed the claims on its investor relations page, saying that it is investigating the findings. The chip maker also took umbrage with CTS Labs for not giving proper notice before the research was published.
“This company was previously unknown to AMD and we find it unusual for a security firm to publish its research to the press without providing a reasonable amount of time for the company to investigate and address its findings,” AMD says.
CNET, which first reported on the bugs, wrote that CTS Labs gave AMD less than 24 hours of notice before they published their findings. Security researchers typically give a company 90 days to coordinate and patch flaws before they publicly disclosing their findings. That was the plan with Meltdown and Spectre — security flaws in Intel’s processors revealed earlier this year — but information about the flaws was leaked shortly before planned publication.
Up until Tuesday morning, little was known about CTS Labs. The company does not appear to have a social media presence. A glitzy video CTS posted alongside its report features interviews with CTS Labs representatives in front of stock photos of office space and data centers.
The company’s website states it was founded by Ido Li On and Yaron Luk-Zilberman in 2017. Li On’s LinkedIn page lists him as formerly serving in Israel’s Unit 8200, an Israeli intelligence agency equivalent to the NSA. Luk-Zilberman LinkedIn page lists him as being the managing director of NineWells Capital Partners, a hedge fund based out of New York. However, SEC documents currently list him as NineWells Capital’s president.
Additionally, a legal disclaimer on CTS’s disclosure website states the company might have a financial interest in the companies mentioned in its report. In its report, CTS discusses AMD hardware made by ASMedia, a subsidiary of Taiwanese technology company ASUS.
The disclaimer reads:
“Although we have a good faith belief in our analysis and believe it to be objective and unbiased, you are advised that we may have, either directly or indirectly, an economic interest in the performance of the securities of the companies whose products are the subject of our reports. Any other organizations named in this website have not confirmed the accuracy or determined the adequacy of its contents.”
The disclaimer also warns against using CTS Labs’ report as investment advice and classifies all of its findings as “opinions.”
Fraser Perring, a researcher with Viceroy, told CyberScoop that Viceroy received an advanced email with CTS Labs’ research from an anonymous source.
CTS Labs did not respond to request for comment.
Some third-party security researchers say they’ve confirmed the AMD flaws are legitimate. But that hasn’t stopped some in the community to point out oddities in CTS Labs’ approach.
“The fact that CTS Labs gave AMD less than 24 hours notice before public disclosure is extremely unusual in our industry and suggests an underlying motive,” said Jake Williams, president of Rendition Infosec. “It seems likely that the notice to AMD was done for legal reasons, thinking that some pre-disclosure notification (no matter how short) would offer some legal top cover.”
Udi Yavo, CTO of enSilo, told CyberScoop that the flaws need to go under further scrutiny.
“Based on the publicly available information, we believe that these claims have real legitimacy and certainly merit further analysis by the cybersecurity community and the vendor. However, we believe such publications should be followed by responsible disclosure procedures,” Yavo said.
Dan Guido, CEO of Trail of Bits, tweeted that his company has seen CTS Labs’ proof-of-concept and that the vulnerabilities are legitimate.
Regardless of the hype around the release, the bugs are real, accurately described in their technical report (which is not public afaik), and their exploit code works.
— Dan Guido (@dguido) March 13, 2018
AMD said in an emailed statement that it is working validate the findings.
“At AMD, security is a top priority and we are continually working to ensure the safety of our users as new risks arise. We are investigating this report, which we just received, to understand the methodology and merit of the findings,” the company said.
Update: This article has been updated to clarify the information surrounding Yaron Luk-Zilberman’s ties to NineWells Capital.
Chris Bing and Greg Otto contributed to this report.
Last Seen: March 2018 on Tech Target
An increase in fileless malware, including PowerShell malware, was reported in McAfee Labs’ December 2017 Threat Report. Discover how enterprises can defend again fileless attacks.
It can be easy to dispute or question industry reports from top security vendors because the data is often collected from those vendors’ customers, and it is frequently used to show how the vendors’ products can better protect enterprises.
However, these reports can often help enterprises improve their information security programs. Antimalware companies often use this data-driven tactic to dig into specific examples of threats so enterprises can determine if they are adequately protected from those threats.
In this tip, we’ll discuss PowerShell malware, the specific example of the Emotet Trojan and enterprise defenses for these threats.
PowerShell malware and the Emotet Trojan
McAfee reported a surge in fileless attacks in 2017’s Q3 in which malicious code in macros used PowerShell to execute malware. One notable piece of fileless malware was the Emotet Trojan.
Before getting into the details of the threat, it’s important to note than when a vendor report states that the highest number of incidents for a specific malware type was observed, that doesn’t necessarily mean that the number is all that meaningful. The amount of malware detected only matters to an antimalware company in terms of how many resources they need to analyze the malware, report on it and ensure that their customers are adequately protected.
When a report references fileless attacks, it also doesn’t necessarily mean that no files were used in the attack. Fileless usually means that no files were left behind on a system for persistence, but files were used in the attack.
The fileless aspect could also mean that PowerShell, cmd or WMIC were used as part of the attack to execute code on the endpoint. This could include downloading a file or writing data to the registry to create a persistence mechanism on the endpoint.
Emotet is a type of banking Trojan that is distributed by botnets; it spams recipients to socially engineer them into opening a malicious attachment — usually a Word document that has a malicious macro. When the macro runs, it calls a PowerShell, cmd or WMIC command to download malware onto the endpoint for persistence.
While files are used in several different parts of the attack, the fileless aspect occurs when PowerShell or cmd is used to download the next step in the attack. Unlike using a downloader to download a piece of malware to the endpoint, the fileless approach can help to avoid potential detection.
Enterprise defenses against PowerShell malware
Since responding to malware threats is absolutely critical, ensuring your enterprise is prepared is important. We’ve discussed fileless malware at length, but malware is constantly evolving and, thus, security tools must do the same.
Some tools have incorporated functionality to address fileless attacks, while other new endpoint security tools have emerged to address these threats and current attacks. However, attacks continue to use known vulnerabilities or insecure functionality, as well as legitimate tools and functions like PowerShell, to take over endpoints.
Your next step should be to check how your existing security tool vendors address Emotet because many different endpoint security vendors have different methods and advice on how to protect your enterprise. One common method among these tools is blocking executables or changes to the system via signatures, behavioral monitoring, or a combination of both detecting and monitoring common methods for persistence, such as preventing the Run registry keys from being modified.
Some of the tools specifically block Microsoft Word from calling out to PowerShell, which can block a malicious PowerShell command from executing on the system.
Examining infected systems on your network to determine how they were infected can identify which security controls need to be updated to properly protect your endpoints.
While the world is changing faster than anyone may realize or want to admit, some of the basics have stayed the same. Ensuring that you are regularly updating your information security program to identify which security controls are properly working is necessary to manage information security risk and protect your enterprise from the Emotet Trojan.
Originally seen: December 2017 on Tech Target
Cloud environments are no less susceptible to ransomware than other environments. However, they have properties that can make response and preparedness different. For example, they might employ different notification and communications channels, they might involve different personnel, and there may be a different control set in use. It can behoove organizations to think through ransomware in the cloud the same way they prepare for ransomware for internal systems and applications.
Ransomware in the cloud
Using an infrastructure as a service (IaaS) platform gives the cloud customer more visibility into the underlying OS than other cloud models, but this, in turn, means that issues, like patching — particularly in the case of legacy or special purpose systems — are just as complex as in other environments, and therefore may take longer than one might like.
The issue is that an IaaS environment might be susceptible to ransomware. What is different with IaaS, though, is how the organization discovers the ransomware, how it responds and how it protects against the threat. As a practical matter, different personnel are often responsible for direct oversight of IaaS workloads compared to other technology.
For example, cloud is conducive to shadow IT. It can be hard for enterprise security teams to identify and manage shadow cloud applications used by employees and lines of business across an organization. Will a development team, business team or other non-IT organization plan for — and be ready to remediate — ransomware in the cloud to the same extent as the technology organization?
Even if shadow IT isn’t a factor for an organization, initial notification of a ransomware event might come through a different channel than expected. For example, notifications could come from a relationship manager for larger deployments; a defined escalation channel with the service provider, which might be a business team; or through a provider-maintained service portal.
Also, keep in mind that both the resolution and implementation of specific countermeasures might need to be done through different channels. As an example, if a key activity in response to a rapidly proliferating ransomware, like WannaCry, is to proactively patch, the manner in which you affect this might vary for the cloud — an enterprise might need to schedule a maintenance window with its provider, for instance.
Aside from IaaS, other cloud models can be impacted, as well. Even SaaS isn’t immune — consider storage such as Dropbox, Google Drive, etc. Typically, these services work by syncing local files to the cloud; for a small organization, this might constitute its primary storage, backup or data sharing mechanism. What happens when the local files are encrypted, deleted, overwritten with garbage or otherwise compromised by ransomware? Those changes will be synced to the cloud.
Mitigation strategies for cloud ransomware
What can organizations do to prepare for ransomware in a cloud environment? There are a few things that can make response significantly easier. Probably the most effective thing organizations can do — for both cloud environments and for any other environment — is to specifically exercise response and escalation procedures.
For example, a tabletop exercise can be very helpful in this regard. A tabletop exercise defuses the primary question: will you pay the ransom? Invariably, someone will suggest paying it regardless of law enforcement and others arguing against it — discussing this specifically ahead of time helps clarify pros and cons when adrenaline levels aren’t off the charts.
Secondly, working through alert and response scenarios ahead of time means you get answers to key questions: how will you be notified of an event? Who will be notified, and what notification pathways correspond to specific cloud relationships? Also, what is required to take responsive action in each of those channels?
It’s also a useful idea to undertake a systematic risk assessment specifically for ransomware. You might, for example, look at backup and response processes to ensure that, should data be specifically targeted by ransomware that seeks to render it inaccessible, the organization has thought through protection and recovery strategies at the technical level.
For an IaaS relationship, think through and test backup and response services that service providers might offer, technical controls that they offer and the countermeasures the organization already employs. This level of risk analysis is probably already done for the enterprise as a whole, but you should take measures to specifically extend that to cloud relationships. This can be somewhat time-consuming for organizations that have numerous service provider relationships in place, but this effort can be folded into a broader activity that has value beyond just ransomware — for example, malware mitigation more generally, data gathering about cloud relationships, threat modeling, cloud governance or other activities that involve the systematic analysis of cloud relationships.
The arguably harder situation in the event of ransomware in the cloud is the intersection of SaaS and smaller organizations — specifically, the possibility of corruption of cloud storage through synchronization of ransomware-impacted files to a remote storage repository. Specific measures to prevent this are available, such as keeping a manually synced or time-initiated mirror of data at another repository, assuming that the volume in question isn’t such that this is prohibitively expensive.
Alternatively, backup solutions that keep prior iterations of data can provide a means of recovery even if the primary storage location is compromised. Regardless of what method an organization employs, though, the most important thing is to think through it in advance and view protection measures critically.
Chime in and let us know what you are doing to stay proactive.