"Anna-Senpai, Look Me Right In Mirai"
For anyone who's not been keeping track of the increasingly clear-and-present danger that is poorly-or-otherwise-misconfigured Internet of Things (IoT) devices, here's the summary: they're bad.
For example, default credentials and services on a swath of routers, DVRs, and IP cameras have given rise to a unique (but not unprecedented) opportunity for attackers to use these devices to build an even greater ‘bot army’ to conduct massive DDoS attacks. One of the more notable instances of such activity is the ‘Mirai’ botnet, which took down several high-profile sites, including Dyn.com (a large DNS provider), OVH (a French hosting provider), and KrebsOnSecurity.com.
Well-known investigate journalist Brian Krebs dug quite deeply into determining just who was behind the development/release of Mirai and the massive attack that ensued. The story itself, the product of hundreds of hours of research, is rather long and comprehensive, and while we can't do it justice in a couple of paragraphs, the connections Krebs draws from usernames/handles, domain registrations, social networks, and conversations with people possibly involved with Mirai is, per usual, fascinating. Ultimately, Krebs' research points to the person who's likely behind Mirai and the aforementioned attacks. We encourage readers to check it out.
Beyond that, however, for those wondering how to reduce their risk of being a part of Mirai or other botnets, users should follow some simple rules:
• Change default passwords (and even usernames, if possible) on routers, wireless access points, and other network devices. Make the password long (minimum of 12-14 characters) and use a combination of lowercase and uppercase alphabetical characters, numbers, and symbols.
• Keep firmware and patches up to date on devices, and be sure to get updates only from the manufacturer's site or service. Most devices have a built-in web page or app to perform the update, and an increasing number of home network devices update automatically.
• If the device has a built-in firewall, review configuration options to block unnecessary ports and services. Additionally, if there are options to configure services such as Universal Plug and Play (UPnP), disable them if they are not necessary.
• Don't connect your "things" directly to the Internet. Instead, use a firewall (if available) to restrict device traffic.
For more tips and information, check out the following resources:
Cellebrite Breached (Cellebreached?)
While the ethics behind exploit/hacking tool sales may be murky, the fact is that intelligence, defense, and law enforcement agencies are willing to pay big bucks for cyber "capabilities" of all sorts ($80 billion USD in 2016 alone, according to Bloomberg). But, as we've seen before, the buyers and sellers of such tools are, themselves, targets of attackers, of the hacktivist, and nation-state varieties.
Most recently, Motherboard reports that Cellebrite, makers of a popular mobile phone forensics device used by many law enforcement agencies, had nearly a terabyte of company and customer data pilfered by way of a compromised web server (that happened to have, among other things, a database backup of the company's license management system, as well as evidence files from seized mobile devices). In the wake of the breach, whose motivations Motherboard viewed to be similar to the Gamma Group and Hacking Team attacks, Hacking Team's own CEO lambasted the people responsible, saying they are "self-appointed prosecutors, judges and executioners", and that they "exploit the very privacy protections they claim to be defending".
Regardless of respective opinions about the nature of Cellebrite's dealings, here are a few tips for mitigating the risk of a repeat of this:
• Suffice to say, don't store sensitive information on webservers. Just...don't. Don't do it. Also, disable unnecessary features, such as open directory listings, on webservers.
• If file sharing is necessary, set up or use an existing secure file exchange system/service.
• Use the "least-privilege" approach for applications, especially those that are network-facing; and harden/lockdown servers, enabling security features and eliminating any unnecessary services.
• Enable auditing features. Log application, database, system, and network activity regularly monitor logs, alerting for suspicious or malicious behavior.
• Use network and server/endpoint security controls and solutions to prevent malicious activity/attacks. Additionally, monitor device activity and logs for precursors and indicators of compromise.
• Regularly conduct security assessments/penetration tests of applications and services. Some tools offer means of automating this testing as part of Continuous Integration processes.
Most Expensive Checkbox Ever?
Indianapolis' IndyStar reports that Triano Williams, an IT employee − and sole sysadmin − for online college American College of Education was fired in April 2016, purportedly for refusing to move from Chicagoland to Indianapolis, where the college is headquartered. However, Williams didn't leave without what appeared to be a backup plan: when the college needed his assistance unlocking an administrative account for their Google Apps instance, he would only help if they gave him "a clean letter of reference and a payment of $200,000" (per his attorney).
This is certainly not the first time we've seen this type of vindictive response, and it's unlikely to be the last. In fact, with the increasing prevalence of ransomware and ransomware-as-a-service, disgruntled ex-employees could even go so far as unleashing this type of malware against an organization, potentially bringing the entire business to a halt. Additionally, imagine taking it to another level and encrypting-then-ransoming cloud-based storage. Sure, there are ways to rollback for most services, but it could still be a huge headache.
So, what are some tips that can help organizations avoid internal sabotage?
• Create (and maintain) corporate policies for provisioning and de-provisioning employees and user accounts. Also, create similar policies for managing administrative access for both on-premise and in the cloud.
• Regularly review accounts and access controls for any unauthorized or over privileged accounts or roles, and monitor user/account logs for suspicious activity or abuse.
• Eliminate single-points-of-failure by delegating rights and privileges to different groups. For example, Help Desk employees could be able to reset passwords, but not necessarily be full administrators.
• Use network and endpoint security controls and solutions to prevent malicious activity/attacks. Additionally, monitor device activity and logs for precursors and indicators of compromise.
• Create a solid business continuity and disaster recovery program, including backup and restore procedures for data, as well as an incident response process (and test them all regularly).
Bug-e-mon: (Android's) Gotta Fix 'Em All!
2017's only just begun, but the Android security team hasn't been resting on their laurels. January's Android Security Bulletin details the vulnerabilities and security issues tackled in the latest update.
This update addresses a whopping 94 CVEs in all, with 10 marked Critical, and 28 marked High. Of note, the Critical entries are rather serious, including multiple remote code execution and privilege escalation vulnerabilities. For example, an attacker could potentially use a specially crafted media file (such as an audio file) to trigger code execution, or a malicious app could take advantage of one of the privilege escalation bugs to run code in kernel space. Successful exploitation of such issues could allow for unfettered access to the entire device, including being able to snoop through text messages, call history, or even activate microphones/cameras.
Additionally, Google recently went into detail about their scoring system for identifying malicious apps, or rather ‘Potentially Harmful Apps’, in Google Play. In a nutshell, they use a combination of the ‘Verify Apps’ feature for identifying malware, but also use what they call their ‘Dead or Insecure’ (DOI) scorer to keep tabs on apps that no longer check up with ‘Verify Apps’, flagging those that deviate too far from a given average. The post itself is straightforward, but short enough that writing too much more about it would feel like copypasta. Check it out for yourself!
Our advice for any Android users out there is as follows:
• Always keep ‘Verify Apps’ set to ‘On’.
• Only install apps from trusted sources, such as Google Play. Don't install or sideload apps from untrusted sources, such as sketchy third-party app markets.
• Review the permissions that an app is requesting. Does a random flashlight application, for example, really need access to your microphone or contacts? For devices running Android 6.0 and up, users can also manage individual permissions for each app.
• While there are shortcomings across the rather diverse Android device market, it's nevertheless important to keep your Android devices (well, all your devices, really) up-to-date! If you're unsure what current security patch level your device is at, you can check it in Settings.
This will be an ongoing weekly series from the Cylance Research team - tune in next Friday for the next installment.