Killer discovery: What does a new Intel kill switch mean for users?

Recently, security researchers from Positive Technologies discovered a way to disable the Intel Management Engine that referenced a National Security Agency (NSA) program.

Over the years, the Intel ME has caused controversy while being touted as a backdoor into systems for governments, mainly the NSA. With the finding of the Intel kill switch, many people seemed to take it as a nefarious and secretive method the NSA used to spy on systems. But, before we jump to any conclusions, let's dig deeper into what actually occurred.

First of all, the Intel ME has been considered a security risk and backdoor by many people in the past. These chips have separate CPUs, they can't be disabled out of the box with code that's unaudited and they are used by Active Management Technology (AMT) to remotely manage systems. Likewise, these chips have full access to the TCP/IP stack, the memory, they can be active when the system is hibernating or turned off, and they have dedicated connections to the network interface card.

These facts must be pointed out to make a more logical hypothesis based off of what was found by the researchers. The risk that the Intel ME function could come under attack or have a vulnerability that enabled attackers to access systems directly, without interfacing directly with the OS, is a large concern in general, but especially for government agencies.

By setting and using the undocumented feature in a configuration file, the researchers were able to find a way to turn off the Intel ME function and disable it from being used. This configuration setting was labeled HAP, which stands for High Assurance Platform, and it is a framework developed by the NSA as part of a guide on how to secure computing platforms.

Intel has further confirmed that the HAP switch within the configuration was put there per the request of the U.S. government; however, it was only used in a limited release, and it is not an official part of the supported configuration.

Now, before we get too upset about the NSA, I firmly believe that asking to have the Intel kill switch enabled was a good move. The Intel ME is an accident waiting to happen, and if it can't be disabled by default, then the configuration of this code to kill its function actually helps harden the device's security. I wouldn't be as concerned with the NSA requesting the Intel kill switch, since they're probably trying to harden the U.S. government's system from attack.

Intel and other vendors include config changes like this in their hardware to accommodate the needs of large customers. Overall, this HAP config change simply enables you to harden your system against the use of the Intel ME feature. The blame should land more on Intel for allowing this function in the first place, than on the NSA for looking to remove it.

My article at: http://searchsecurity.techtarget.com/answer/Killer-discovery-What-does-a-new-Intel-kill-switch-mean-for-users

WireX botnet: How did it use infected Android apps?

WireX was recently taken down by a supergroup of collaborating researchers from Akamai Technologies, Cloudflare, Flashpoint, Google, Oracle, RiskIQ and Team Cymru. This group worked together to eliminate the threat of WireX and, in doing so, brought together opposing security vendors to work toward a common goal.

The WireX botnet was a growing menace, and it was taken down swiftly and collectively. We're starting to see this happen more often, and this was a great example of what the security community can do when information is shared.

The WireX botnet was an Android-based threat that consisted of over 300 different infected apps found in the Google Play Store. The botnet started ramping up application-based distributed denial-of-service (DDoS) attacks that were able to continually launch, even if the app wasn't in use.

The WireX botnet is assumed to have been created for use in click fraud to make money off of advertising fraud, but quickly seemed to move toward the DDoS route after it gained a large enough botnet. The WireX botnet itself is estimated at 70,000 endpoints, but some researchers think it might be larger. Due to the fluid nature of the mobile device endpoints, the IP addresses from these systems are likely to change as a user moves geographically.

The researchers were able to work together and share data on the attacks they were seeing and piece together their intelligence to get a complete story. By sharing details on a peculiar DDoS attack against a particular customer with this collective group, the teams were able to identify the source of the attack as malicious Android apps. After determining the source, they were then able to reverse engineer the apps, find the command-and-control servers, and remove them. The group worked with service providers to assist with cleaning the networks and with Google to remove the infected apps.

Security groups are now coming together more frequently to help defeat large attacks on the internet. Previously, we saw a very competitive industry -- and there are still some others that don't play nice – but, in general, it's encouraging to watch competitors team up and work together to stop attacks for the common good and not for a marketing scheme.

Security groups are now coming together more frequently to help defeat large attacks on the internet.
This has to do directly with the larger attacks, such as Mirai and NotPetya, which have recently attacked the internet on a global scale. Many of the same vendors that worked together on the WireX removal were also involved with teaming up on the Mirai and NotPetya attacks.

At this point, vendors are working together to protect themselves and their customers, since all botnets must be addressed; however, they are also working with each other because it allows for a clearer look into these threats and, thus, remediation is quickened.

We saw from the internet of things attacks with Mirai botnet just how devastating a DDoS attack can be on the internet, so when a similar Android botnet was ramping up on mobile devices, it was in everyone's best interest to act quickly. The lesson to remove a threat as a team before it reaches the strength of something like Mirai was learned and taken into consideration with the WireX botnet.

My article at: http://searchsecurity.techtarget.com/answer/WireX-botnet-How-did-it-use-infected-Android-apps

How should security teams handle the Onliner spambot leak?

A list of 711 million records stolen by the Onliner spambot was recently discovered, and it's utterly staggering to think of the sheer size of this data set. To put things into perspective: the United States only has 323 million people. Even if everyone in America had their data on this list, it would only make up half of that data.

The list of data that the Onliner spambot stole was given to security researcher Troy Hunt, who then imported the entire list onto his site Have I been pwned? This site creates a searchable database of email addresses and usernames that have shown up following today's largest breaches, such as those at LinkedIn, Adobe and Myspace.

It would be beneficial for you to personally validate if your email addresses or usernames have been compromised in these breaches. By submitting your email address or username, the site queries the aggregated list of dumped credentials found and informs you if you were a part of it. If your credentials are found in the aggregated list, then you should reset the passwords for those accounts immediately.

There are also ways for organizations to determine and be notified if a user account on their domain has been caught in a data breach. Once an enterprise has submitted its domain name to the site and completed the verification process, an email is sent each time an email address with that domain is found in a data breach that's within the Have I been pwned? database.

In addition to changing passwords as soon as possible, users should also determine if they are reusing the hacked password on any other sites. If so, those passwords should be changed as well, since we've seen attackers use breaches like these and attempt to reuse the credentials on other sites in hopes of the credentials being the same.

Some advice to users who reuse their credentials would be to start using password vaults to store passwords, as this is an easier way to manage multiple complex passwords for different accounts. Likewise, users should attempt to use some sort of multifactor authentication on their accounts to limit the effect of massive breaches, as attackers won't have the second form of authentication. Even though the credentials would still be public, the second factor would not be within these lists, thus acting as a stop gap to limit attackers from using these accounts.

Using Have I been pwned? as a tool to increase your situational awareness on the status of current major breaches, such as the Onliner spambot, is an added way to keep yourself and your organization safe. Similarly, enforcing multifactor authentication and eliminating credential reuse can go a long way to help you stay safe.

My article at: http://searchsecurity.techtarget.com/answer/How-should-security-teams-handle-the-Onliner-spambot-leak

Monitoring employee communications: What do EU privacy laws say?

According to the European Court of Human Rights, employers must inform their users if their business-related communications are being monitored while working for the organization. The court informed individuals that there must be a clear distinction of the type of monitoring, the timeframes, which content is monitored and the administrators that have access to the data.

The EU's privacy laws are head and shoulders above those in the United States. Just look at their General Data Protection Regulation (GDPR), which will go into effect soon.

The GDPR regulates the privacy of EU citizens in relation to user data being sent to third parties, breach notification requirements, data security restrictions and the right to be forgotten. GDPR also necessitates that companies perform privacy impact assessments, validate the existence of a data protection officer and review how data is transferred to other countries. Organizations that don't meet these stipulations will be fined. While these are just a few examples of how the EU is enforcing the regulation, it shows that it takes the privacy of its citizens' data extremely seriously.

When it comes time to review how monitoring employee communications should be handled within the workplace, it's not surprising to see that the EU is taking a similar privacy-based approach.

Personally, I have no problem with what they're doing, and I agree that people should be alerted when their communications are being monitored. I also don't have an issue with organizations monitoring employee communications from a business perspective -- in today's world, both of these options need to be in place. Organizations need to monitor communications to validate that attacks and insider threats aren't occurring, but users should be made aware of how and when this is occurring -- it should never come as a surprise.

When you start a company, you normally use some type of communication filtering system, such as for email or the web. In the United States, it's legal to monitor these communications as long as they're a part of the organization and not for the user's personal use. This means that if you're browsing personal websites on a business-related internet network or system, then it will be monitored.

Many organizations are aware that this is happening and whitelist filtering for particular categories, such as banking, so there's never a question if they're monitoring personal information that doesn't pose a risk to the organization. Just keep in mind that anything employer-owned can be monitored.

Furthermore, unlike the EU, the legal right to monitor and how far it can go in the U.S. is state-dependent. There are no federal guidelines on how monitoring employee communications should be handled, and it's completely left up to the local and state levels to decide.

My article at: http://searchsecurity.techtarget.com/answer/Monitoring-employee-communications-What-do-EU-privacy-laws-say

How does the Ursnif Trojan variant exploit mouse movements?

As security researchers and vendors improve the security within their products, malicious actors are continually looking for ways to bypass them and continue their efforts. This cat and mouse game continues to play out, and is best seen in how malware authors are continually developing creative ways to create new attacks or workarounds. Many times, these techniques are very creative and, with a new variant of the Ursnif Trojan, we saw attackers use mouse movements to decrypt and evade sandbox detection.

Sandboxes are used to validate that downloaded files from the internet are safe to run on the endpoint. They're sent to the sandbox and executed on a virtual machine to determine their intended purpose. Since this can detect malware, attackers are continually looking for ways to bypass this security layer.

There have been multiple methods used in the past to detect sandboxes, such as searching for VMware registry keys, virtual adapters, low CPU and RAM, and doing nothing for hours to determine if a file is on a VM.

In this case, the malware would sit idle. This is also a way to avoid sandboxes, since the scans don't last hours, and users don't perform the malicious actions if they are tipped off to these variables. This would allow the files to enter your network where, like a Trojan horse, they'd wreak havoc.

The Ursnif Trojan's spin on sandbox detection is to use the previous and current mouse point locations to validate that it's not sitting in a sandbox. The technique, discovered by Forcepoint Security Labs, looks for the delta between these pointer locations and uses these variables to create a base seed that can assist with decryption.

The Ursnif Trojan goes through the base seeds to decipher the key, and once it matches the proper checksum, which can essentially take a brute force-like combination to achieve, the malware executes the remainder of the code. It does this because the D-value of the mouse movement is always zero, and it will never be able to decipher the proper decoded code at this starting point. Since this is the case, it will never execute within a sandboxed environment.

Read the rest of my article here: http://searchsecurity.techtarget.com/answer/How-does-the-Ursnif-Trojan-variant-exploit-mouse-movements

Flash's end of life: How should security teams prepare?

Whether you're a fan of Adobe Flash or not, it has been a building block for interactive content on the web, and we must acknowledge what it has accomplished before talking about its eventual removal from the internet. These plug-ins helped usher in a new age of web browsing and, at the same time, were targets for vulnerabilities and exploits within browsers.

As HTML5 becomes more popular, even now becoming close to a standard, use of the once-popular Flash is diminishing. Using HTML5 enables a more secure and efficient browsing experience that works across both mobile and desktop platforms.

Adobe is aware that, even though Flash is steadily declining, there are still many sites that rely on their technology to function; therefore, Adobe has given a timeframe of 2020 before Flash's end of life. The company knew it needed to give clients who are currently using its software the proper lead time to migrate toward other software to run their applications before pulling the plug.

Adobe itself has encouraged those using Flash to migrate any existing Flash content to new open formats. During this time, Adobe has mentioned that it will stop updating and distributing Flash, but will continue to support it through regular security patches, features and capabilities. Hearing this, I get the feeling that they'll be keeping Flash on life support for a while, before they completely pull the plug on the project altogether.

In order to not be caught off guard when Flash's end of life is official, security teams should be aware of which applications in their organization are currently using Flash, and then create migration paths to have them updated to HTML5 or other open standards. Even if there might be small portions of support after 2020, you never want to be running end-of-life code, especially code that has historically had security vulnerabilities.

Also, security teams should take notice of which desktops are currently using the Flash plug-in and attempt to have it removed around this time. Since Flash acceptance has declined, and will continue to take a nose-dive after this news, there should be less need for the Flash plug-in moving forward.

You should prepare for Flash's end of life by taking stock of your systems; remove the plug-in for systems that may connect to sites that haven't migrated away from Flash yet. By following the school of thought of least privilege and having only software that's needed installed, the attack surface becomes limited.

Eventually, Flash won't be supported, and if bugs are found within the software, then attackers could utilize them for phishing attacks by supporting sites that are designed to use Flash and haven't migrated away. If you don't need it, don't install it.

Read the rest of my article here: http://searchsecurity.techtarget.com/answer/Flashs-end-of-life-How-should-security-teams-prepare

How does a private bug bounty program compare to a public program?

It really depends on what you're looking to offer and receive out of your bug bounty program. There are differences between a public and private bug bounty; normally, we see programs start as private, and then work their way into public. This isn't always the case, but most of the time, organizations will open a private bug bounty by inviting a subset of security researchers in order to test the waters, before having it publically available to the community.

There are a few things to consider before launching a public bug bounty. There's going to be a testing period with your application, and before you call down the thunder from the internet abroad, it's wise to work with a group of skilled researchers or an organization that specializes in this area to validate your processes and procedures.

Many times, organizations aren't comfortable with opening this to the public, and they tend to limit the scope of the testing and those that can test it; your risk appetitive will reduce the amount of tests, and also limit the vulnerabilities that can be found within the application. Many organizations want to validate their security posture, use external resources to test their security and supplement this testing to find vulnerabilities before they're found by malicious actors.

Before flipping from a private to a public bug bounty program, there are a few things to consider. First, open the program to researchers or organizations that are tested and trusted. You don't want to go to just anyone right away, as vulnerabilities could cost you your reputation and revenue if they are found.

Since many of these researchers are doing this for financial gain, you need to have a firm grip on your payout structure within the private bug bounty to better understand how to use it if it goes public. Are your applications so insecure that you'll be paying out numerous bounties at a high rate? Understanding your payout structure upfront will help you maintain a manageable bug bounty program.

Before you go public with a bug bounty program, you also need to have a good reason to have the program public. What is the end goal of the program going public versus keeping it private? If you want to find vulnerabilities, and you have a process to do this internally, then maybe a private vulnerability program is right for you. If you already have a vulnerability management process in line and are performing static and dynamic analysis, but want to supplement that with additional manual testing from a larger community, then public testing might be what you're looking for.

Lastly, it's very important to have a bug bounty rules of engagement page on your site or application to let participants know how to act, what to expect and the rewards for each bug. It will also help to let researchers know what to expect when it comes to how bugs should be submitted using responsible disclosure practices.

Many sites have bug bounties now, but just because you open it publically doesn't mean you'll have a horde of white hat hackers crashing through your site to search for bugs. Determining what the best bounty is, the section of the code that you'd like to test and how to act operationally when you start seeing attacks occur is important to your bug bounty submissions and your overall day-to-day operations.

Read the rest of my article here: http://searchsecurity.techtarget.com/answer/How-does-a-private-bug-bounty-program-compare-to-a-public-program