11/6/2018 Zero-day Denial of Service flaw in Cisco ASA and FTD appliances
Cisco has issued a security advisory describing a denial of service condition in both its flagship Adaptive Security Appliance (ASA) and Firepower Threat Defense (FTD). The flaw is in the Session Initiation Protocol (SIP) inspection engine of ASA versions 9.4+ and FTD versions 6.0+. An attacker can use this to crash these appliances. These are remotely executed denial of service (DoS) attacks, and instances of use have already been seen in the wild. The flaw is described in National Vulnerability Database (NVD) under the entry CVE-2018-15454.
InGuardians rates this vulnerability as High impact. As of the end of last week, InGuardians and several other organizations have identified these attacks in the wild. Cisco ASA and FTD appliances are widely deployed, and there are no patches available at the time of this writing.
InGuardians recommends that all clients running ASA or FTD appliances identify whether the appliances are vulnerable and apply Cisco’s mitigation advice poste haste. As noted, attacks have been seen in the wild, and have already caused outages at several organizations.
In the first link in our Additional Resources, Cisco has released the following potential mitigations:
-Disabling SIP inspection
-Filtering on sent-by-address of 0.0.0.0
-Rate limiting SIP traffic
-Blocking offending hosts
In addition, Cisco released information to help identify, through log analysis, whether or not your appliances have been affected by the DoS attacks. To hunt for active exploitation of this flaw, staff can run the following two commands.
This command will show a large number of incomplete SIP connections:
show conn port 5060
This will show a high CPU utilization:
show processes cpu-usage non-zero sorted
If the appliance has been attacked successfully, it will crash and reload. This indicator will also show up as an unknown abort of the DATAPATH thread in the output of the following command:
show crashinfo as
Cisco Adaptive Security Appliance Software and Cisco Firepower Threat Defense Software Denial of Service Vulnerability (Cisco)
Cisco ASA and FTD SIP Inspection denial-of-service vulnerability (CERT)
Cisco zero-day exploited in the wild to crash and reload devices (ZDNET)
InGuardians Resources and Events
On Thursday, the webinar “Kubernetes Hacking and Hardening Episode 2: Bust a Kube” goes live, presented by InGuardians CTO Jay Beale. Come learn how to hack and defend Kubernetes, containers, and cloud native environments!
Nov 8, 2018 | 10AM PST / 1PM EST
Awesome article about vulnerabilities that often get ignored by many security departments. Tyler Robinson shares his experience and provides you with helpful tips on how to minimize the risk of a cyber attack on non-computer vectors
Seattle folks, don’t miss out! Jay Beale will be speaking at HushCon sharing his Kubernetes Kung Fu on Dec 7 at 2PM. InGuardians will be sponsoring and attending the conference as well — come meet some of our most talented team members and say hi!
We are happy to announce that David Mayer, our Senior Security Consultant will hold a mentor session on “Network Penetration Testing and Ethical Hacking” class in Boca Raton, FL, Thu Feb 7 – Fri Feb 22, 2019. Reserve your spot now!
10/30/2018 Windows ‘Deletebug’ Zero-Day allows privilege escalation, data destruction.
A proof-of-concept exploit for a Windows zero-day vulnerability has been released that allows an attacker to delete any kind of file on a victim machine, including those containing data vital to the system. The exploit works on fully-patched Windows 10 machines. The vulnerability is in Microsoft’s Data Sharing Service (dssvc.dll). This is a local service that runs as a LocalSystem account with extensive privileges, and enables data to be brokered between applications.
Mitja Kolsek, describing the vulnerability to Threatpost, said, “Even a low-privileged user can make a request to this service for an undocumented function (only Microsoft and possibly a few outsiders know what this function does), and this function checks whether the requesting user has permissions to create a file in a chosen location,”
If a user does not have permission to write the file, it deletes it.
The problem is the service stops impersonating the user and runs the last step with system privileges, giving the user the ability to delete arbitrary files on the system, whether log files or files they might seek to replace. For example, an attacker may escalate privileges more fully if they could delete the dynamically loaded library (DLL) file from a privileged program, if that program would search for its missing DLL file in a directory to which the attacker can write.
However, as the discoverer SandboxEscaper tweeted. “Here’s a low quality bug that is a pain to exploit…” If SandboxEscaper’s opinion is correct, it is unlikely that there will be immediate wide-reaching uses of the vulnerability. This is in part because an attacker already needs system access or needs to chain this with a remote exploit. With that said, attackers and even automated worm/bot programs chain exploits. InGuardians takes this vulnerability seriously, as does Microsoft, whose Security Response unit notes that the vulnerability is in scope for its Bug Bounty program.
Recognize that this vulnerability is for NEW versions of Windows, Windows 10, Server 2016 and 2019. Checking event logs and network logs for any unauthorized access should already be part of IT security efforts. Add to it looking for “impersonation” events as shown in 0patch’s description.
It is also important to realize that any service running as system may be susceptible to similar flaws or exploits that are as yet unknown. Network access visibility is a critical part of recognizing potential unauthorized intrusions.
Windows ‘Deletebug’ Zero-Day Allows Privilege Escalation, Destruction
Sandbox Escaper’s tweet
Kolsek’s tweet, 0Patch’s co-Founder, confirming the zero-day vulnerability
Tweet from 0Patch, regarding micro-patching the vulnerability
Microsoft Security Response Tweet regarding bug bounty
InGuardians Events and Resources
Seattle folks, don’t miss out! Jay Beale will be speaking at HushCon sharing his Kubernetes Kung fu on Dec 7 at 2PM. We will be hanging out after the conference as well, come say hi!
We are happy to announce that David Mayer, our Senior Security Consultant will hold a mentor session on “Network Penetration Testing and Ethical Hacking” class in Boca Raton, FL, Thu Feb 7 – Fri Feb 22, 2019. Reserve your spot now!
10/22/2018 Libssh authentication bypass leaves devices vulnerable to unauthenticated shell access.
A critical authentication bypass bug in libssh versions after 0.6 has been identified. Libssh is a library implementation of the SSH version 2 protocol for the C programing language, able run on multiple platforms as both a server and a client. The actual vulnerability itself is exploited by sending a SSH2_MSG_USERAUTH_SUCCESS message to the server, which in turn presents a shell to the unauthenticated user, giving them access to the end point. The code for the exploit is a mere 27 lines of code and is currently publicly available. Fortunately, fingerprints for the affected services are also publicly available to allow organizations to scan for exploitable end points. So far, the biggest vendor to publicly disclose that they are affected by this issue is F5 networks, with their BIG-IP Advanced Firewall Manager (AFM) product, versions 12 or newer, vulnerable to the exploit.
While the full impact of this issue is still being analyzed, the majority of publicly discovered vulnerable devices, outside of the F5 Big-IP AFM, are SFTP servers, routers, printers, modems, and Internet of Things (IoT) devices. While the libssh library is not the most popular choice for implementing SSHv2, it is used in a wide variety of devices that could be embedded in any network. Libssh is a relatively new library and as such only devices purchased or updated after 2014 are likely to be affected.
InGuardians recommends that organizations scan their networks for vulnerable libssh versions and either manually update libssh or, if that is not possible, restrict access to the affected interfaces and work with their software/device vendors to resolve the issue. The additional recommendations below include a Python program to scan networks for this vulnerability.
Note that this serious vulnerability was created in an apparent attempt to update a code library. Remember: as code ages, updates to patch make sense, but things are NOT always better merely because they are newer. Test and evaluate BEFORE deploying new code.
F5 Vulnerability Advisory “K52868493: libssh vulnerability CVE-2018-10933” (F5) https://support.f5.com/csp/article/K52868493
“CVE-2018-10933 – libssh’s server-side state machine“ (F5 Customer Post)
“CVE-2018-10933 Detail” (NIST)
CVE-2018-10933 Vulnerability Scanner (Leap Security)
Proof of Concept Exploit (GitHub user kn6869610)
InGuardians Events and Resources
If you are at Wild West Hacking Fest this Friday, watch InGuardians’ Suzanne Pereira and Larry Pesce’s talk, “What to Expect When You are Expecting … A Penetration Test”
10/17/2018 California Bill SB-327 Highlights IoT’s Weak Password Security Practices
The “Internet of Things” (IoT) has massively increased the number of Internet-connected devices which can be hacked by anyone with access to those devices’ well-known passwords. The state of California, with the fifth largest economy in the world, has passed a law that will require all devices in the state to either have unique initial passwords or to have a feature allowing owners to set up a method of authentication before first connecting to the device. This law takes effect on the first day of 2020.
By 2020, makers of Internet-connected devices will be banned from selling devices that have per-product initial passwords. While the presence of default or trivial (eg, “admin/admin”) credentials might seem almost laughable in the year 2018, unfortunately that is not the case. The Mirai botnet used both default and trivial credentials to compromise more than 600,000 IoT devices in 2016. Using these devices, it sent some of the largest recorded distributed denial of service (DDoS) attacks, in excess of 1.1 terabits per second. The Graham Cluley article referenced below lists the 60 hard coded passwords, including common manufacturer-set initial passwords, like “admin,” “00000000,” and “Zte521.” This problem isn’t confined to IoT devices, either. Last month, Cisco corrected its use of a static root password for all deployed Cisco Video Surveillance Manager devices in two of the last three released.
InGuardians recommends that every organization check its own devices for trivially weak authentication, whether that entails static, simple, shared passwords (e.g., found in device manuals) or a lack of authentication. While not guaranteed to be comprehensive, a vulnerability scanner like Tenable’s Nessus, Bomgar’s Retina, or the open source OpenVAS, can be particularly helpful, as these tools check for a number of default credentials.
InGuardians recommends that product vendors take the following additional steps to avoid this type of problem:
- Conduct internal or third party security product reviews to discover these issues well before the first release of a product, as well as before any major update to a product.
- Review existing manuals and product penetration testing results to determine if password security practices meet best practice and California Bill SB-327.
- Share California Bill SB-327 with in-house counsel and compliance officers.
InGuardians recommends that product customers take the following additional steps to avoid this type of problem:
- Conduct regular vulnerability scanning as a component of a process-oriented security program
- Build and maintain an inventory of all network-connected devices, including IoT and BYOD.
- Confirm that all administrative passwords for all devices are unique, strong, differ from vendor defaults, and are maintained in a separate, secure password management system.
- Place IoT and BYOD devices on separate network/VLAN’s, monitored and segmented from each other, from the internal network, and from wide-ranging Internet access.
California Senate Bill SB-327 (California Legislature)
Cisco Video Surveillance Manager Appliance Default Password Vulnerability (Cisco Security)
These 60 dumb passwords can hijack over 500,000 IoT devices into the Mirai botnet (Graham Cluley)
InGuardians Resources and Events
Online this Thursday, you can learn from InGuardians CTO Jay Beale, as he demonstrates attack and defense on a Linux Capture-the-Flag machine.
If you are at Wild West Hacking Fest next Friday, watch out for InGuardians’ Suzanne Pereira and Larry Pesce’s talk, “What to Expect When You are Expecting … A Penetration Test”
10/11/2018 Web App Penetration Testing without Threat Hunting May Leave Indicators of Compromise Undetected
Many web applications that are available from the Internet handle very sensitive information governed under various compliance initiatives such as HIPAA, PCI, GDPR, etc. Understanding how that information is protected within the application is just as important as understanding the attack surface of the application. If a threat actor has gained unauthorized access to a web application and its associated data via a particular vector of vulnerability, they will correct the vulnerability immediately, to keep other threat actors out. Even automated threat actors historically perform this action. For example, in April of 2017, the Adylkuzz malware used the same ETERNALBLUE exploit that WannaCry would use a month later in May. WannaCry was unable to infect the quarter million Adylkuzz victims, because Adylkuzz hardened the systems it compromised (by deactivating SMB). Because attackers so often remove the vulnerabilities they used to compromise systems and networks, a penetration test alone may not demonstrate the full security posture of a web application and the sensitive data housed within.
In cases where penetration tests are performed without subsequent auditing of the system for embedded threat actors, years may pass before an enterprise learns about a compromise and a threat actor’s presence in its system. The organization may be violating regulations that govern sensitive data or, even worse, exposing itself to downstream liability issues should the threat actor steal or modify data or conduct fraudulent activity.
Likewise, if proper security controls are not in place to protect the data from a threat actor who has gained access to the application server, then the internal security posture of the application is weak and exposes the organization to risk.
Whenever it is appropriate for a penetration test to be performed on a web application, ensure that two other tasks are also performed. First, threat hunting on the operating systems in which the application and its data reside, and a development of a clear understanding of data flows, encryption, and other internal controls that should protect the data in the case of a compromise.
“Getting Ahead of The Adversary – Splunk and Johns Hopkins Demonstrate Threat Hunting Tactics” (Splunk)
“How to Become a Master Threat Hunter” (Carbon Black)
Blue Team Services (InGuardians)
InGuardians Events and Resources
A huge thank you to everyone that came by the booth and caught up with us at Derbycon! A special shout goes out to Annah W. for winning our Derbycon raffle.
If you are at Wild West Hacking Fest, be sure to catch Suzanne Pereira and Larry Pesce’s presentation “What to expect when you’re expecting… a pentest”. Two of our directors join forces to discuss how you should prepare and operate during a penetration test.
10/2/2018 Which of your secrets do cloud services see?
Which of your secrets are upload to cloud services, without your explicit instruction? Consider these cases: a Microsoft Word document about an upcoming merger or executive changeover gets infected with malware, triggering its upload to the anti-virus vendor’s cloud service. Or a software crash on a laptop causes an upload of logs and memory dumps, which contain encryption keys, passwords, and confidential files. Or an anti-virus triggers on a ZIP file, uploading the company’s most sensitive financial data to a service. It’s nearly impossible to affirmatively control this data once uploaded. While cloud-based services can bring enormous benefit in cutting off attacks before many ever see them, they rely mostly on automated guesses about files that may grab sensitive information.
Modern security products often look far different from their predecessors from a mere decade ago. In addition to basic functions of blocking unwanted network traffic, anti-virus programs, web proxies, firewalls, VPNs, and even operating systems send various information to cloud-based services. The products’ vendors do this to collect intelligence about malicious activity, crashes, and use patterns to help them understand and react to their customers’ environments.
Security vendors monitor the provided data in real time, reducing many of their customers’ reaction time to potential threats from days to minutes, often automating most of the process. The data have done much to limit opportunities for attackers to obtain unauthorized access or to damage networks after first detection.
However, it’s very easy for proprietary data to get caught up in this. In 2014, software from Kaspersky Labs uploaded suspicious files from a home computer in Maryland. These turned out to be highly classified tools from the National Security Agency’s Tailored Access Operations group, copied by an employee from his work computer to his personal computer. Once the NSA’s tools were compromised, there was no way of reversing this, and the NSA had to halt usage of those tools, likely at significant cost.
The same holds true for anyone using cloud-tied security services. Content from the sites you visit, the files you open, and the software you run may all find its way to a cloud-based vendor. Most will ignore the irrelevant details, but some may parse contents, and some may even sell aggregate or detailed information.
Of course, this problem isn’t confined to security software. Other vendors have used crash data to identify common faults and help developers fix crashes. Photos are automatically uploaded to Apple’s iCloud or Google Photos. Google Sync may automatically back up documents, and cloud storage providers like Box, Dropbox, and Microsoft OneDrive can be configured similarly. Note that any of these services might be configured to use a personal account, rather than one controlled by your organization.
The vast majority of cloud-based security companies take security very seriously and only a tiny fraction of uploaded files are held for very long. Even fewer receive close scrutiny. However, the need to manually
review some submissions means that there is always someone who can see them in their raw state. At that point, the uploading entity has essentially lost all control of the uploaded data. The data is subject to subpoena or warrants, misuse such as insider trading, or theft or leaking by malicious actors.
Avoiding this is possible, but not always easy. The most sensitive files might be managed on “air-gapped” systems (i.e., never connected to a network). Working with air-gapped systems limits productivity, but, when properly done, also creates some of the most secure conditions possible.
InGuardians recommends that companies determine which software running on their systems uploads data to cloud services, what data could be uploaded, and how that data is handled once in the vendor’s hands. Companies can start by investigating Terms of Service, End User License Agreements, and applicable laws and regulations. The next step involves using or establishing vendor security questionnaires, whether custom or from one of the three most popular standards: VSAQ, CAIQ, and SIG/SIG-Lite.
Even strong promises should be approached with caution. Appropriate safeguards for the most sensitive data should be in place using a combination of policy and technology to reduce the risk of inadvertent loss of control. This not only limits the ability of cloud services to gain unexpected access, but also limits dissemination among internal personnel who do not have a need to know.
Vendor Security Assessment Questionnaire (Google)
Consensus Assessments Working Group (Cloud Security Alliance)
Standardized Information Gathering Questionnaire (SFG Shared Assessments)
Kaspersky: Yes, we obtained NSA secrets. No, we didn’t help steal them (Nov 16, 2017)
Dropbox takes a peek at files. But it’s totally nothing, says Dropbox. (Sep 13, 2013)
How artificial intelligence stopped an Emotet outbreak (Feb 14, 2018)
Derbycon: If you are at Derbycon this week, stop by InGuardians booth. Many of our operators will be there demonstrating tools, as well as teaching skills ranging from lock picking to RFID hacking.
09/17/2018 A new Cold Boot attack puts data on full-disk encrypted computers at risk again
Revisiting the Cold Boot attack, researchers from F-Secure were able to circumvent current protections, gaining access to data on computers even when Full Disk Encryption (FDE) was enabled.
In the original Cold Boot attack, a bad actor boots the computer from a powered-off state. Booting the target system from removable media (such as a USB thumb drive), the attacker uses memory harvesting tools to recover the contents of RAM from the previous boot. Most importantly, the attacker gains the decryption keys for the computer’s encrypted drive.
After the publication of the original Cold Boot attack methodology, hardware manufacturers instituted methods for protecting the RAM storing the full disk encryption (FDE) keys. In the most common protection method, specified by the Trusted Computing Group, the computer overwrites the RAM storing those keys at the time of boot. Unfortunately, this overwrite only occurs when the Memory Overwrite Request (MOR) bit is set in non-volatile memory.
F-Secure’s researchers found that they were able to modify the BIOS system configuration to flip the MOR bit back to zero, disabling the boot-time FDE key RAM overwrites, allowing themselves to use the original Cold Boot attacks to access the full disk encryption keys, and thus the computer’s drive contents.
With a successful re-implementation of the Cold Boot attack using the updated methodology, it is possible for an attacker to gain access to all of the data stored on a computer, even when FDE is enabled. Should the system contain sensitive information, the attacker can gain full access to the data. The attacker also gains the ability to compromise the computer.
There are some hurdles to overcome for an attacker attempting to deliver the updated Cold Boot attack. The attacker must have:
Unrestricted physical access to the computer under attack
Knowledge and experience delivering the first generation Cold Boot attack
Knowledge, experience, and the appropriate hardware tool set to update the system BIOS to disable memory overwrites.
These hurdles are surmountable, yet the additional requirement to disable memory overwrites is currently obscure.
In limited cases, F-Secure’s researchers were unable to execute the updated Cold Boot attack. The researchers identified that the most recent Apple computers were currently unaffected by their research, as those machines carry an Apple T2 chip, which places encryption keys in a “secure enclave.”
In most cases there are some simple opportunities to thwart the updated Cold Boot attack introduced by F-Secure’s researchers. These opportunities include:
- Train employees to power off or hibernate, rather than sleep, their computers. Consider using group policy to enforce this behavior across all computers belonging the the organization.
- Proper physical security of computers: computers in public or semi-public (such as a laptop in a hotel room), should never be left “out in the open” or unattended. They should remain with the owner or physically secured in a manner that would prevent tampering (such as being placed in a safe, in the case of a hotel room)
- Improved FDE implementations: Adoption of robust Bitlocker PINs, entered at time of boot to unlock FDE, can significantly thwart Cold Boot attacks. In the case where the encryption keys are recovered, the user password would still be required to decrypt.
“Security flaw in ‘nearly all’ modern PCs and Macs exposes encrypted data” (TechCrunch)
“New modification of the old cold boot attack leaves most systems vulnerable” (Ars Technica)
The Chilling Reality of Cold Boot Attacks (F-Secure)
TCG Platform Reset Attack Mitigation Specification (Trusted Computing Group)
InGuardians Resources and Events
The popular, actionable and insightful piece, “12 Things I Learned the Hard Way about Being a Project Manager in Infosec, by InGuardians’ Director of Operations Suzanne Pereira, contains lessons and reminders on how to manage projects, by focusing on people, communication and advocacy. Read more: https://www.linkedin.com/pulse/12-things-i-learned-hard-way-being-project-manager-infosec-pereira/
Get some serious RF/Wireless kung fu training from InGuardians Director of Research Larry Pesce at SANS in Las Vegas, Sept 23 – 28, 2018.
Dive deep into ICS Security with hands-on training from Justin Searle, our Director of ICS Security at SANS Las Vegas, Sept 23 – 27, 2018.
09/10/2018 Over 400k websites expose sensitive data via .git/ directory
Speed + Complexity => Errors => Vulnerability. Your system is probably exposed.
Every week we try to focus on a relevant vulnerability to describe the issue in terms of client exposure. We point to information resources and mitigation strategies to improve security posture and vulnerability detection. This week, InGuardians’ editorial team had too many from which to choose. Here are but a few of the week’s disclosures:
– NotPetya would have destroyed Maersk’s system if not for ONE server that had been offline due to a power outage.
– IoT malware infecting aircraft SATCOM systems
– Schneider controller vulnerability
– British Airways data breach
– mSpy’s second data breach
– 400,000 websites expose sensitive system development data via .git/ directories.
The real question then is, if you presume you are exposed, how do you detect and mitigate the risks?
In this weeks newsletter, we focus the .git/ directory exposure in particular.
Open .git directories can contain a great deal of sensitive information, including the web application’s structure, database passwords, API keys, development IDE settings, and more. Czech researcher Vladimir Smitka discovered over 390,000 websites, the majority .COM TLDs, that had internet-readable development directories.
The cause is in part an error in the queries many developers use to confirm that /.git is hidden. Querying a web server for /.git produces an HTTP 403 Error, which is a false negative. This error indicates that no index file exists in the directory (index.html, index.php, …) and that the directory is not auto-indexed. Smitka demonstrated that by querying for the /.git/HEAD file, he could determine that many web applications contained internet-readable .git/ directory contents.
Checking for visibility of a directory is good, provided it’s a valid check. For the specific case of verifying directories, consider the ways to frame the query and what happens when URL and other queries fail; what is the error trap and error message? Are THOSE valid?
Developers and other staff are under pressure to create and deploy systems quickly – that’s not going to change. However the process must provide for thorough systems review and policy guidance to catch potential for failure early. In today’s multiple-releases-per-day DevOps modality, this will likely involve automating good checks as part of the build process.
These themes ran through the breaches and vulnerabilities discovered this week. Consider mSpy, a popular spyware tool for monitoring kids and others. Let’s take a leap of faith and say it’s used for GOOD THINGS, like ensuring the kids are home after school. The hacked database required no authentication. It revealed large amounts of broad categories of data, including Apple iCloud usernames and authentication tokens, Facebook posts, emails, credit card transactions, and more. So, the information from the mSpy breach could include the information necessary to access a company network. Our mobile devices collect more than we may realize.
The general lesson is that a website error can lead to information leaks for internal disruption and for external leaks. The plethora of choices this week were not (necessarily) related, but EVERY week there is something. Every organization must continuously examine the security architecture to mitigate single points of failure and to prevent resident info on one victimized system from providing the keys for a successful pivot to domain controllers or the organization’s key networks. Mobile devices mean internal networks have more external connections than their architects may realize. It’s important to remember gadgets, BYOD mobile devices, and apps like mSpy when considering information technology’s footprint.
“400,000 Websites Vulnerable through Exposed .git Directories” (SC Magazine)
“Open git Global Scan” (Vladimir Smitka)
NotPetya analysis (Wired)
IoT Malware and SATCOM (Helpnet Security)
Schneider Electric Controller Vulnerability (Security Week)
British Airways Data Breach (CNN Money)
mSpy Mobile Spyware data breach (Krebs on Security)
InGuardians Resources and Events
The popular, actionable and insightful piece, “12 Things I Learned the Hard Way about Being a Project Manager in Infosec, by InGuardians’ Director of Operations Suzanne Pereira, contains lessons and reminders on how to manage projects, by focusing on people, communication and advocacy. Read more: https://www.linkedin.com/pulse/12-things-i-learned-hard-way-being-project-manager-infosec-pereira/
Jay Beale, InGuardians Founder and CTO, will be speaking this weekend at ToorCon in San Diego. His talk, “Hacking and Hardening Kubernetes” focuses on exploiting the technology’s weaknesses and then using its features to lock it down. Track: Seminars, When: 9.14.18 at 16:00 PST. For more information: https://sandiego.toorcon.net/
InGuardians will sponsoring Idaho Falls’ first BSides event this weekend. Stop by our booth and chat with our Head of Offensive Services and Idaho local, Tyler Robinson. For more information: https://infosec-conferences.com/events-in-2018/bsides-idaho-falls/
08/28/2018 Apache Struts 2 RCE Vulnerability Affects Many Web Apps, including products from Aruba Networks, Cisco Systems, and NetApp
Last week, the Apache Struts team publicly announced a severe remote code execution security vulnerability in Apache Struts 2. Similar to the Strutshock vulnerability used in the 2017 Equifax breach, this vulnerability will allow an attacker to run programs of their choice on a web application that uses specific configurations or functionality. The Equifax 2018 breach is considered by many to be the worst corporate breach in US history, wherein bad actors stole personal information, including social security numbers, belonging to 147 million people in the US, or roughly 58% of the US adult population. This vulnerability is present in Apache Struts versions 2.3 – 2.3.34 or 2.5 – 2.5.16.
Applications are vulnerable if they either:
1) use results with no namespace, where its upper actions have no namespace or a wildcard namespace.
2) use a url tag without a value and action set.
Many vendors’ products use Apache Struts 2, in addition to organizations’ internally-developed applications, use Apache Struts 2 as detailed in the next section.
Many web applications and product web front end interfaces are potentially vulnerable. As Apache Struts 2 is a “middleware” web application framework, organizations may not realize that they have web applications susceptiblevulnerable to this vulnerability. Several vendors have already determined that their products are vulnerable, including Aruba Networks, whose announcement covers its ClearPass servers, Cisco Systems, whose announced 4four vulnerable products, and NetApp, who announced 82 vulnerable products.
Vulnerable products and web applications will allow an attacker full remote control of the host. This canmay lead to organizational compromise, ransomware attack, or crypto-mining activity, whether on a small scale or through automated worm programs.
As this vulnerability was discovered in April, with some likelihood of independent discovery or leak before patches came available four months later in August, it is especially important to correct vulnerable applications quickly. Staff can accomplish implement the correction by upgrading the Apache Struts 2 framework to either versions 2.3.35 or 2.5.17. If the vulnerable application is provided by a vendor, InGuardians recommends seeking out the vendor’s advisory for corrective action.
Apache Struts Security Bulletin
“Semmle Discovers Critical Remote Code Execution Vulnerability in Apache Struts (CVE-2018-11776)” (Semmle Blog)
Aruba Networks ClearPass Policy Manager Security Advisory ARUBA-PSA-2018-005
Apache Struts Remote Code Execution Vulnerability Affecting Cisco Products: August 2018
NetApp Security Advisory NTAP-20180822-0001
Three Public Exploits Posted
Nessus Plugin 112064 (Checks for Vulnerability)
08/20/2018 VIA C3 CPUs Allow Unauthenticated Code Execution
VIA C3 CPUs allow unauthenticated code execution, granting an attacker elevated privileges. A new tool named project:rosenbridge exploits a backdoor on VIA C3 CPUs. The C3 chips are found primarily on embedded x86 devices such as: point-of-sale machines, automated teller machines (ATM’s), healthcare hardware, industrial automation devices, and a limited percentage of desktops and laptops. The chip is a small non-x86 core embedded alongside the x86 main processor. The “backdoor” in the C3 provides access to debug mode, which should require elevated kernel access to access. Researchers discovered that unauthenticated access to the backdoor is occasionally enabled by default. Thus far, neither researchers nor VIA have named which devices shipped with the backdoor on by default. This exposure allows any unprivileged code to modify the kernel of the operating system.
Impact level of this exposure is high, as it is a remote code execution vulnerability for which there currently are no patches and few workarounds. Exposure of healthcare devices, ATMs, and industrial automation devices should be taken very seriously.
InGuardians recommends that your organization identify your deployed hardware to determine which machines are affected by this flaw. Once investigation is complete, enumerate the Windows Active Directory machine accounts corresponding to the affected devices. Each of these machine accounts must have a strong password. The affected machines must be segregated from the enterprise network with strong network access control. If segregation is not possible, then permit access to the devices on a case-by-case basis, using a white list approach until the a patch is released or the devices reach the end of their life cycle.
VIA C3 processors (VIA Manufacturer Product Page)
Project:rosenbridge (GitHub project page, Christopher Domas)
08/14/2018 Princeton researchers warn home IoT devices could cause serious issues for utilities
This week, a team of researchers from Princeton University will be presenting their research on home Internet of Things (IoT) devices at the USENIX conference in Baltimore, MD. They used the grid software packages MATPOWER and Power World to run simulations to determine how many devices, each using how much power, would be required to negatively impact the power grid. In this case, they based their model on a small Polish power grid from 2008. They discovered that they could create a “cascading blackout” of 86% of the power grid by arbitrarily and unexpectedly increasing the power demands by only 1%. The researchers were able to cause this increase with a botnet containing as few as 42,000 compromised IoT water heaters.
This awareness has just recently come out of the research phase and there is no current indication of a botnet made up of compromised water heaters. However, given the history of IoT botnets and their negative impacts, such as with the Mirai botnet in October of 2016, this type of research should be considered an early warning. In the past, refrigerators,, DVRs, smart TVs, and a whole host of other home IoT devices have been found to be a part of malicious botnets with hundreds of thousands of devices which have caused network outages via distributed denials of service (DDoS) attacks.Utility companies employ experts who predict the level of power requirements and configure generative devices accordingly. However, this type of attack on the demand side of the equation, involving large home appliances such as water heaters and air conditioners, could hit unexpectedly.
For the consumer, vigilance, and isolation of home IoT devices is key. Identify IoT devices on your networks, and put in controls and audit measures in order to prevent and detec abuse. While there are standards in place for devices deployed by the utility companies, such a smart meters, there are currently no secure deployment standards for devices deployed by the homeowner. InGuardians believes a standard, as such, should be created and a working group assembled to ensure that the risk of these home IoT devices are mitigated.Additional Resources
“A Quick History of IoT Botnets” (Radware)
https://blog.radware.com/uncategorized/2018/03/history-of-iot-botnets/“Mirai (Malware) [Botnet]” (Wikipedia)
https://en.wikipedia.org/wiki/Mirai_(malware)“How Hacked Water Heaters Could Trigger Mass Blackouts” (Wired)
08/08/2018 Reddit Hack Reveals Flaws in SMS Based Two-Factor Authentication
On June 19th, the popular community messaging site Reddit revealed that it had suffered a successful intrusion of several user accounts, cloud infrastructure, and source code. Reddit revealed that the data access was read-only. The attacker was unable to modify any website content or user data. Data accessed included database backups from 2005 to 2007, account credentials (with salted and hashed passwords, email addresses, and email digests (providing a link between e-mail addresses and account names).
The manner in which the attacker was able to gain access to Reddit’s systems is more troubling than this particular compromise of data. Of the accounts accessed for Reddit’s systems, all claimed to have had Two Factor Authentication (2FA) enabled. In this particular case the 2FA mechanism on these accounts was purported to have been a PIN delivered via SMS to a mobile device. Typically enabling 2FA is enough to protect these accounts, delivery of PINS via SMS can be compromised in at least two ways. While we do not know the specific method employed by the attacker in this case the like attack vectors are:
- Creation of a rogue cellular tower signal, in order to lure the victim’s mobile devices. Once connected to the rogue tower, the attacker could perform cellular traffic interception, acting as Man in the Middle (MiTM), ultimately allowing for the recovery of the SMS based PINs for the affected users.
- Social engineering the cellular provider customer support call center in order to port the victim’s phone number to a device under the control of the attacker. This effectively delivers the SMS based PINs directly to the attacker.
While speculative, based on the level of effort for the two attack scenarios it is most likely that the number porting attack was utilized in this scenario. InGuardians Operators have recently been made aware of similar type of attacks using number porting, however the basis was often to recover account credentials for cryptocurrency.
With a successful compromise of a users 2FA delivery method, through either number porting or rogue cellular tower, it is possible for an attacker to gain unfettered access to a victim network, applications and other credentials. As shown in this example with Reddit, the overall outcome can be quite severe, resulting in complete compromise of the organization.
While creating a rogue cellular tower is non-trivial, the number porting attack scenario is a more likely attack vector. Taking only the boldness of the attacker to perform appropriate social engineering, this becomes a fairly low barrier to overcome.
As a result of more high profile attacks against 2FA utilizing SMS PIN delivery methods, organizations should carefully review and revise their stance on 2FA implementations. At this time it is recommended that organizations move away from SMS based 2FA methods to those requiring hardware or software based tokens, in addition to passwords..
For those organizations looking to start 2FA implementations for either their users or customers, it is recommended to avoid the option of SMS based delivery and move right to hardware or software token based authentication, in addition to passwords.
While the adoption of hardware and software based tokens can be more expensive, and more obtrusive for the end user, the overall gain in security is much greater.
Reddit: We had a security incident. Here’s what you need to know.
Reddit hack shows even strong security measures can be bypassed
07/30/2018 Browsers Begin Marking Unencrypted Sites as “Not Secure”
The lack of HTTPS on a website has slowly become a sign that a company hosting a web application does not understand the impact of unencrypted traffic to their clients. As a result, browser companies have adopted increasingly conspicuous approaches to alert users to the basic risks of unencrypted websites. They have long warned users that entering credentials into an unencrypted page is dangerous. Last week, Google released Chrome 68, which marks unencrypted sites as “Not Secure” in the top URL bar. Mozilla added a similar (albeit a manually activated) feature in 2017 and might soon make it standard. Microsoft and Apple may follow suit.
Most criticism of unencrypted websites describe the risk of some nefarious group reading the web traffic or stealing passwords, but properly-configured HTTPS offers much more than just those protections. Users of properly configured HTTPS websites can be sure of three things:
- Authentication: The content is provided by the entity they expect.
- Integrity: The content has not been modified between the server and the browser.
- Confidentiality: The content is safe from decryption by third parties.
The risk the first two points pose is not theoretical. Numerous countries route all web traffic through a single national proxy. University of Toronto researchers found that one of these national proxies added cryptocurrency mining code to unencrypted websites. Citizens and tourists alike executed this code.
The same report identified two other countries adding state-sponsored malware to unencrypted downloads. This places a company’s customers and traveling personnel (and ultimately the enterprise environment) at risk. Those who notice will point to the company as the culprit, suggesting that it was compromised since the malicious code appeared to come from its site.
Even some US internet service providers (ISPs) have injected content on unrelated sites, and some may still do so. ISPs Verizon, Comcast, and CMA Communications have all been previously identified as modifying traffic passing through their networks.
Ultimately, HTTPS sites will lose the green “Secure” indication as browsers consider it the norm. The currently “Not Secure” text could change to something more ominous. Within hours of the release, some prominent retailers had already implemented HTTPS by default to avoid the potential trust issues. This had likely been planned for some time–enabling HTTPS is often not trivial–but it demonstrated how seriously many companies take the change.
InGuardians recommends that all companies protect their websites and services with a properly-issued HTTPS certificate and updated encryption settings, including mandatory HTTPS. These measures protect your clients, employees, and other users not only from a threat agent obtaining information but also from modifying it in ways that may not be easily detected.
Deployment of HTTPS has become much easier and less expensive, as certificate authorities (CAs) have adopted new models to promote its use. Let’s Encrypt offers free certificates, and some certificate vendors offer wildcard certificates that can be used on an unlimited number of systems.
Google Chrome 68 Release Notes (Jul 24, 2018)
BAD TRAFFIC: Sandvine’s PacketLogic Devices Used to Deploy Government Spyware in Turkey and Redirect Egyptian Users to Affiliate Ads? (Mar 9, 2018)
Verizon’s “supercookies” violated net neutrality transparency rule (Mar 7, 2016)
Comcast is still forcing pop-up ads on customers to upsell its modems (Dec 11, 2018)
How a banner ad for H&R Block appeared on apple.com—without Apple’s OK (Apr 7, 2013)
Qualys SSL Labs Server Test
Let’s Encrypt: Free Certificates
07/25/2018 “Devil’s Ivy” Flaw Renders Millions of Internet of Things (IoT) Devices Vulnerable
An integer overflow in a library used by security cameras and many other Internet of Things (IoT) devices has been discovered and disclosed by security researchers at Senrio. While the Senrio researchers demonstrated the exploit against one camera, an AXIS security camera, the vulnerable library, gSOAP by Genivia, is used by many IOT device manufacturers. It is present in 249 distinct Axis camera models alone.
The impact of this vulnerability is likely to grow in the coming weeks, as proof of concept exploits surface and additional vulnerable targets are identified. Almost one year ago, a flaw in a security camera opened the way a botnet called Mirai botnet to take hold. At its peak, Mirai compromised more than 600,000 IoT devices and sent distributed denial of service (DDoS) attacks in excess of 1.1 terabits per second, slowing or stopping Internet access for nearly the entire eastern United States for a part of a day. At this time, there are at least thirteen (13) versions of Mirai active on the Internet.
While the Devil’s Ivy flaw has not yet resulted in a Mirai-style botnet, the announcement of the vulnerability gives us pause to think of the wide ranging consequences of vulnerabilities in widely-deployed devices. Now is the time to identify the products using the gSOAP library, and check your networks for vulnerable devices.
At the time of this briefing, Axis Communications has not issued a patch for CVE-2017-9765. Their main recommendation, which InGuardians will echo, is to restrict network access to and from the devices.
Network segmentation, along with controls and audit measures, are the first line of defense here. This is a remote execution flaw that requires no authentication or credentials, merely network access.
Often times, IOT devices are ignored by organization’s security operations teams, because the devices are either externally managed or simply not managed at all. It is imperative to identify the systems you have in place, and be sure to spell out ownership and maintenance in an IT governance plan.
IoT security differs in some aspects from traditional IT security as many of these devices provide little in the way of configuration and management. InGuardians recommends adding IoT devices to your asset inventory, and including them in regular maintenance, and security audits.
Devil’s Ivy: Flaw in Widely Used Third-party Code Impacts Millions (Senrio, July 18 2018)
Axis Communications Security Advisory for Devil’s Ivy
Genivia advisory for Devil’s Ivy Vulnerability in gSOAP:
CVE Advisory for Devil’s Ivy:
“Devil’s Ivy” Vulnerability Could Afflict Millions of IoT Devices (Wired, July 18, 2018)
How a Dorm Room Minecraft Scam [Mirai] Brought Down the Internet (Wired, December 13, 2017)
Wikipedia Article on Mirai
07/16/2018 HP iLO 4: Simple Authentication bypass can lead to system compromise.
In August of 2017 Hewlett Packard (HP) silently patched an authentication bypass vulnerability in their proprietary Integrated Lights Out (iLO) version 4. iLO runs on a dedicated baseboard management controller on high end HP servers, to enable remote management even when the operating system itself cannot doesn’t function. The vulnerability, present in versions prior to 2.54, is particularly concerning because of the criticality of the systems that many organizations utilize HP iLO4 to remotely manage. These systems include those of the utmost importance in the organization, such as Windows Active Directory domain controllers.This authentication bypass is over a year old and received a CVSS score of 9.8 (out of 10) upon release. However, it appears that many organizations have NOT patched their systems. Until just recently the researchers who discovered the flaw have been publicly speaking about it. During recent presentations, it was disclosed that simply including a crafted HTTP host header to the iLO4 device including the phrase “Connection: “ followed by 29 “A” characters. This simple attack grants full access to the iLO4 subsystem, allowing total control of the host system. This includes the ability to gain access to the system console as the active user, mount additional file systems (such as various bootable penetration testing linux distributions), and the ability to reboot the hosts systems.
Recently InGuardians operators have successfully leveraged the HP iLO4 authentication bypass using the described scenario to gain full control of active directory where certain conditions were met. While simple to exploit with tools such as curl under linux, several other PoC code releases, as well as a Metasploit module are available.
HP iLO3 and iLO5 are not affected, as well as iLO4 versions 2.54 and greater.
The impact of this vulnerability will differ based on the overall adoption, use cases, and policies concerning remote system management especially centered around the use of and of iLO4. However, should the vulnerable version be in use, it is possible for an attacker to gain full control of an organization’s computing infrastructure, depending on the services hosted with iLO4 available. In cases where lower privilege systems are managed with affected versions iLO4, it can merely provide an initial foothold for an attacker, likely leading to full compromise.
While remote management of systems is critical to effective IT operations, several things should be considered during its use to help protect the overall security of the environment:
PATCH: Add remote management solutions to the critical “short-list” for monitoring for and applying patches.
Evaluate the overall number of staff needed to conduct remote management and limit which systems can access the remote management interfaces through robust network segmentation and firewalling, potentially including the use of well secured jump hosts.
Limit systems in which the remote management can reach, especially for mounting remote filesystems. Consider mounting of remote file systems from trusted sources, restricted by robust network segmentation and firewalling.
Establish a policy for login sessions for remote access, specifically for remote terminal sessions. In cases where privileged accounts can be left “logged in” indefinitely to a remote session, should an attacker access that same session, they gain all of the rights provided by the logged in user. Set short timeouts for automatic logout for inactivity for remote sessions.
HP iLO4 vulnerability:
https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-hpesbhf03769en_usA authentication bypass and execution of code vulnerability in HPE Integrated Lights-out 4 (iLO 4) version prior to 2.53:
Subverting your server through its BMC: the HPE iLO4 case [Fabien Périgaud , Alexandre Gazet , and Joffrey Czarny]:
07/09/2018 Google confirms external apps can scan and allow their staff to read your emails.
Google continues to allow outside software developers to “scan the inboxes of millions of Gmail users who signed up for email-based services offering shopping price comparisons, automated travel-itinerary planners or other tools.” (see WSJ report link below) Additionally, people who have connected third-party apps to their accounts may have unwittingly caused human staff permission to read messages those people considered private.Impact
All reports available to date suggest this is a common practice and not limited to Google. In June 2017, Google announced that it would allow users to opt out of its ad personalization via e-mail scanning. It seems that the company instead is allowing third party application developers do so both electronically (machine reading) and via human staff. Google has made statements assuring that these developers are vetted, but remains silent about any subsequent verification of their process.
Many organizations as well as individuals rely on Gmail and similar provider managed email services. This suggests that anything discussed in such emails is potentially exposed to apps and to the developers of those apps. It raises significant questions about the security of email exchanges and highlights the need for organizational policy and practice to mitigate loss of intellectual property and exposure of confidential information.
While that is not new, this is a new vector for exposure. Even if Google’s vetting is sound and developers adhere to reasonable security procedures, we know that data breaches of third parties is a common source of data exposure (see EXACTIS link below). It also raises a question about possible exposure of ANY hosted services. Reporting has limited discussion to Gmail and has been silent about whether or not G Suite “<person>@<company><dot>com“ emails are in the mix.
Review written policies for all external email communication among employees and to clients to ensure they proscribe discussion of sensitive information. Remind staff to remain vigilant about discussing business dealings in emails.
Review written policies to confirm that employees are not permitted to send sensitive organization data via free/consumer-level Gmail or other third-party email providers.
Wall Street Journal article and report:
ArsTechnica: Scroogled no more: Gmail won’t scan e-mails for ads personalization
Business Insider article and discussion:
Wired (UK) news article:
(article is apparently NOT on the US *.com website)
Wired article about EXACTIS breach:
ABC (Australia) article with a good guide to checking apps:
07/02/2018 New attacks against LTE networks
Three new attack vectors in the LTE (aka 4G) standard have been unveiled by researchers from Ruhr-Universität Bochum and New York University Abu Dhabi. These new vulnerabilities include two passive attacks that allow for identity mapping and website fingerprinting, and one active cryptographic attack called aLTEr. The last would allow attackers to remotely redirect network connections via DNS spoofing. The major issue with these new attack vectors is that the flaw is in the standard, which is ubiquitous in mobile communication, and therefore affects ALL devices using LTE.There are three main attack vectors:
Website fingerprinting – identify which sites that users in a radio cell are visiting
Identity mapping – identify individual users in the radio cell
aLTEr – abusing flaws in the standard to redirect network communications via DNS spoofing
The impact of aLTEr and its related attack vectors is large, with hundreds of millions of devices using the vulnerable standard. Researchers worked with the GSM Association (GSMA) and 3rd Generation Partnership Program (3GPP) along with telephone companies to ensure that all parties responsible for addressing the problem were notified prior to the release of the paper.The three main attacks outlined in the paper (mapping user identities in the radio cell, identifying websites a user visited, and the alteration attack via DNS manipulation) currently require special equipment and knowledge to be performed, but it will not be long before these attacks are going to show up in the wild.The long term impact will depend on whether the GSMA & the 3GPP will fix the current standard in addition to ensuring that it is fixed in the next generation of the standard (5G).
The impact on individuals is hard to quantify at the moment, but the potential impact to critical infrastructure is serious. Many of our critical infrastructure systems rely on LTE communications, for example: smart grid relies heavily on the use LTE networks to transmit data.
The main recommendation for the moment is to identify which parts of your business operations rely on LTE communications and ensure that your vendors are using strong encryption and authentication independent of the LTE layer.Additional Resources
Website for the attack research:
https://alter-attack.netAcademic paper on the research:
Hacker news article:
06/26/2018 Attackers leverage cost of GDPR fines to extort businesses
In what appears to be an exploit of the concept of “the lesser of two evils”, hackers in Europe have began changing the approach of ransom based attacks. Two Bulgarian companies have recently had their data compromised, but instead of encrypting it and demanding that the victim pay up to get the data back, these attackers are threatening to make the data public. This would expose the company to risk of fines with Europe’s General Data Protection Regulation (GDPR) that went into effect in May. These fines would be upward of 4% of annual revenue.The attackers, acutely aware of the potentially high cost of GDPR fines, typically ask for much less. At their highest, attackers are currently asking for the equivalent of €20,000. This type of attack may be effective as GDPR is still relatively new, and businesses are still trying to grasp the risk of fines and levels of enforcement.Impact
A wrinkle in this scheme, is that the the GDPR requires companies to report a breach within 72 hours of becoming aware of it, or also face steep fines. As of today, if the company self-reports a breach, they are still liable for the 4% fine. These attacks force the victimized companies to consider the value of profit motive over full compliance with the law.
Due to the level of potential loss, and the possibility of running afoul of European law, companies subject to the GDPR should ensure that they do more than merely meet the minimum regulations of compliance dictated by GDPR. They also should apply defense-in-depth strategies and perform periodic penetration testing to ensure that their most sensitive data is protected in ways that are beyond reproach. Demonstrating that this due diligence has been performed is the only way to avoid a fine in the event of a reportable breach.
What is GDPR:
06/18/2018 ZipSlip: Vulnerabilities in compression archive file processing can lead to system compromise.
This is due to two major factors: vulnerable libraries and lack of centralized file archive extraction libraries. The vulnerable libraries span multiple languages. These include, but may not be limited to:
C# / .NET: DotNetZip.Semverd
C# / .NET: SharpCompress
C# / .NET: mholt/archiver
C# / .NET: SharpZipLib
The lack of centralized libraries for performing archive file extraction, leading to the development of hand-crafted methods. These hand-crafted methods often do not feature robust error trapping routines to prevent extracted files from being written outside of the extraction path. These hand-crafted code “snippets” are often shared publicly (through websites such as StackOverflow) and adopted across many projects. With these three factors considered, many closed and open source projects are writing or have adopted vulnerable archive file extraction processing. This issue can result in overwriting of sensitive system files with a malicious file archive, potentially resulting in remote code execution and full system compromise.
The researchers discovering this issue have identified a number of common applications that carry the vulnerability, including the Apache projects: Ant, Hadoop, Hive, Maven, and Storm. A comprehensive list of these applications can be found at:
The impact of this vulnerability will differ from environment to environment, depending on the various software packages deployed. However, should an organization be utilizing one of the affected and identified applications, it is possible for a malicious actor to deliver a specifically-crafted archive file to a victim program, which can cause a full system compromise simply by extracting the file. Because of the nature of the code sharing nature and the affected programming language deficiencies it is highly likely that this issue far exceeds the current identified scope.
Our recommendations fall into two separate categories:
Developers and Enterprise Development operations:
Evaluate the quality of shared code, and fully test it for “outside cases” before implementation.
Integrate the use of shared code evaluation into the DevOps process.
Select and adopt a standard set of libraries for core application functions, and document and standardize on its implementation based on testing results.
Carefully select development languages at the start of any new project, taking into account the use of well developed core libraries essential to the success of the project.
Perform robust and regular testing of all application input functions at time of adoption and during major code updates or releases.
When possible, perform regular code audits of open source projects in use in the organization in order to discover similar failures.
When possible, encourage your software vendors to perform perform regular code audits in order to discover similar failures. Ask them to share the results (under NDA or otherwise) so that proper risk decisions and corrective actions can me made.
Ultimately all organizations should be mindful of the ZipSlip vulnerability, patch currently identified vulnerable applications, and watch for additional discoveries. Remember, this specific exploit of a vulnerability has revealed previously unknown or only narrowly known general vulnerabilities that may enable many more exploits.
ZipSlip Release and White Paper:
Current list of known vulnerable software and patch status:
05/29/2018 New “VPNFilter” malware targets at least 500K networking devices worldwide.
Dubbed “VPNFilter” by Cisco’s Talos research group, this multi-stage, modular platform has versatile capabilities to support both intelligence-collection and destructive cyber attack operations. The first stage will persist through a device reboot, enabling downloads of other stages and full reinfection. It also redundantly maintains the IP address(es) of second stage deployments, enabling robust maintenance of the malware command and control (C2) environment even in the face of unpredictable changes, such as those occurring as system administrators attempt to track and remove malware.
The code collects intelligence (scans) and has multiple attack features that can either execute additional commands or simply “brick” a device. From the Talos blog, “… the code of this malware overlaps with versions of the BlackEnergy malware — which was responsible for multiple large-scale attacks that targeted devices in Ukraine.” That overlap with known attack code and two separate upticks in malware on Ukrainian IP addresses in mid-May 2018 prompted Talos to release information before completing full analysis.
VPNFilter includes modules to use the Tor anonymity network to mask C2 IP addresses and foster misattribution. It is designed to attack devices on the perimeter of the network, with no intrusion protection system (IPS) in place, and that typically do not have an available host-based protection system such as an anti-virus (AV) package.
Specific sequences in the malware include:
- kill: Overwrites the first 5,000 bytes of /dev/mtdblock0 with zeros, and reboots the device (effectively bricking it).
- exec: Executes a shell command or plugin.
- tor: Sets the Tor configuration flag (0 or 1).
- copy: Copies a file from the client to the bad actor’s remote server.
The inherent destructive capability is of particular concern because it allows the operators of this malware to ‘brick’ the network connections of any infected organizations. That would eliminate remote operations control for ICS/SCADA systems, as well as shut down any other network connections. The combination of intelligence gathering and mapping seems aimed at finding systems from which to launch effective attacks.
- Reset SOHO routers and directly-connected NAS devices to factory settings, then update with up to date, non-vulnerable firmware.
- Work with ISPs to reset devices provided by ISPs
- For any directly connected device that may be infected or suspect, contact and work closely with manufacturers to ensure devices have up-to-date firmware and that they are not infected.
- ISP should also work aggressively with customers to address potential problems.
This is a harbinger of IoT risks that will likely become more common. Look at the ‘heat’ map in the SDX Central article below to see this is, at least so far, clearly targeting or being tested against the Ukraine and appears to be a direct descendant of the previously-discovered Russian malware, BlackEnergy. It has, however, also been discovered in 54 other countries, so far. It is not going away.
Cisco Talos Group blog warns of “VPNFilter” malware
SDX Central – Cisco Warms Massive Russian Malware Attack Hit 500K Routers Globally
IBM X-Force report on Russian malware BlackEnergy
05/21/2018 New PDF malware combines recent Windows & Adobe exploits
New PDF malware combines two zero day exploits discovered as recently as last week. The malware, detected by anti-malware firm ESET, combines the most recent Windows & Adobe exploits to compromise Microsoft Windows operating systems. The patches for the flaws being exploited have been available for a short period of time; Microsoft released their patches May 8th, with Adobe releasing security patches for Reader and Acrobat on May 14th. The PDF malware in question compromises Window’s systems when users open an infected PDF on a vulnerable system. Both the flaws offer remote command execution to the attacker, with the Windows flaw offering System level access. The major impact of this is that these are two new zero day exploits found in a malicious PDF file, in the wild.
The impact of combining two zero days into a lethal piece of malware could be devastating. How many were hit before the patches? The end result is not known at this time. The sample identified by ESET did not contain a final payload, so the initial goal of the malware is not known. That said, the malware is sophisticated and the zero day exploits embedded in it are more so.
With zero day exploits in the wild it is usually too late to simply patch your systems. By all means, we are not advocating delaying in patching your systems, but at this time it is advisable to engage in a full, internal hunt team to identify vulnerable and/or compromised systems. This is a good reminder that we need to implement the basics first: patch/vulnerability management, software/data inventory, governance etc. Once shored up, start to look at additional segmentation, access management, application firewalls and white listing. Zero day exploits are in the wild, and our organizations have to evolve to be resilient against exploits we do not have patches for.
Microsoft Patch for CVE-2018-8120
Adobe Security Bulletin:
Anton Cherepanov Blog on the two zero days found in PDF malware
05/14/2018 Industrial Control System product vendor Schneider Electric’s InduSoft and InTouch products contain critical security vulnerabilities.
Schneider Electric makes products that allow HMI clients to read, write, tags and monitor alarms and events. Their InduSoft and InTouch software is vulnerable to remote compromise, and should be patched immediately.
Schneider Electric’s software is often deployed on critical Industrial Control systems, and it’s InduSoft and InTouch applications are vulnerable to remote compromise. The vulnerable software runs with high privilege level, so compromised systems should be completely wiped and reinstalled before being put back into production. Given the severity of the vulnerability, and the criticality of the systems we would rate the impact as high.
InGuardians recommends the following steps be taken:
- Identify if you run either of the two applications – software inventory
- If running the software, ensure that it is running on isolated network segments
- Check production systems for indicators of compromise
- Patch vulnerable systems &/or rebuild compromised systems
Schneider Electric Security Bulletin LFSEC00000125
Schneider Electric InduSoft Web Studio and InTouch Machine Edition Remote Code Execution (Tenable Research Advisory Detail)
Tenable Research Advisory: Critical Schneider Electric InduSoft Web Studio and InTouch Machine Edition Vulnerability
05/07/2018 Plaintext Passwords Exposed on Twitter and Github, Suggesting Password Safes and MFA
Last week, both Twitter and GitHub publicly announced that their services had exposed plaintext passwords in internal log streams. While neither company has disclosed a compromise, mature information security programs assume that at least one machine in the organization is under the control of a bad actor, and thus that any cleartext password must be replaced. While Twitter has begun requiring some users to change passwords and Github has made no such requirement, it would behoove all users of both Twitter and Github to assume their passwords are compromised.
If one or more bad actors have compromised either Twitter or GitHub, they may possess your organization’s credentials for the respective service. If your organization uses multi-factor authentication (MFA/2FA) for any accounts, the bad actors will likely not have gained access using those accounts.
A GitHub account compromise produces significant risk in multiple ways. First, if a bad actor can alter code stored on GitHub that a user deploys to your or their own systems, they can achieve an indirect compromise of those systems and any systems accessible by them. Second, a bad actor may find access credentials, private certificate keys, or other secrets stored in GitHub. InGuardians often finds this kind of data in its red team penetration tests, particularly API keys that provide full cloud service administration capabilities. Finally, when targeting a DevOps environment, a bad actor with GitHub access gains full knowledge of routing, firewall and system provisioning code.
InGuardians recommends changing all organization accounts on both Twitter and GitHub. Given the tendency for code and data to proliferate to both personal and business GitHub accounts, InGuardians recommends requiring all staff to change their personal and business GitHub passwords and implement multi-factor authentication on that platform.
InGuardians also recommends deploying password safe software or hardware, whether free or commercial, to ensure that every password an organization uses is unique. Bad actors will gain access to passwords – to understand, contain and recover from the damage, its important to make sure that compromised passwords are useful only on one service.
Further, InGuardians recommends conducting a quarterly internal review of what code, data and secrets lie in GitHub repositories, to both understand and reduce the amount of sensitive or secret information is entrusted there.
Twitter Admits Recording Plaintext Passwords in Internal Logs, Just Like GitHub
GitHub Accidentally Recorded Some Plaintext Passwords in Its Internal Logs
04/30/2018 Multiple known Java and HPE iLO vulnerabilities being targeted for ransomware
Software management is often boring. It is, however, essential to business survival. The many “new” attacks the grab media attention all too often exploit known vulnerabilities for which patches have been published – and missed or ignored. Atlanta’s recent ransomware attack exploited Java’s deserialization bug, which was called the most under-hyped vulnerability of 2015.
It’s is NOT just Java. HPE iLO, an integrated remote management console for HP servers, has many known vulnerabilities. They are now being hit with disconnect and lock out ransom demands. This one may not be encrypting drives, but instead is remotely locking out administrators. The effect and impetus for ransom is the same.
Atlanta’s one case has so far incurred $2.6 million in external consulting costs, there is no capture of internal costs or disruption effects, and as of this writing Atlanta’s departments are still using paper and other offline tools. In many commercial environments, this is a business killer. The iLO attacks effectively take servers offline – they are no longer under your control.
Any unpatched or unresolved vulnerability is opportunity for exploitation and disaster. Delays in patching increase the window of vulnerability and the likelihood of exploitation. A ‘standardized’ weekly or monthly or worse patch cycle, if known publicly, advertises an organization’s unpreparedness. E.g., Outfit A, Inc., patches on first Mondays of the month; a vulnerability and patch are published in the second week; attackers can posit Outfit A will remain vulnerable AT LEAST 3 weeks … and maybe even into more than one cycle.
1. Do frequent and aperiodic vulnerability assessments. Scan for vulnerabilities and create a realistic, prioritized, ACTION list.
2. Pay attention to other organizations, news, and vulnerability announcements.
3. PATCH. Just Do It. When patches are more complex, mitigate with layered defenses and architecture – network segmentation.
4. Review policy and architecture to ensure systems that should NOT face the internet, such as HPE iLO interfaces, DON’T.
5. And do not let anyone tell you to relax, it’s only a “theoretical vulnerability.” Ever.
In 2015 the Java vulnerabilities “were considered to be theoretical and hard to exploit.”(1)
STOP. That mistaken viewpoint goes back decades – was wrong then and is wrong now.
Atlanta fall-out continues
2018 – Atlanta projected to spend at least $2.6 million on ransomware recovery
This is NOT new – it’s been skipped and left to fester:
2015 – Java Serialization Vulnerability Threatens Millions of Applications
… and it persists
2018 – Cisco Secure Access Control System Java Deserialization Vulnerability
(1) 2016 – Lessons Learned from the Java Deserialization Bug
And it is NOT just Java
2018 – Ransomware Hits HPE iLO Remote Management Interfaces
The CVE list of HPE iLO vulnerabilities:
04/23/2018 Attackers Compromising Drupal-based Web Sites En Masse for Financial Gain
Attackers are using two vulnerabilities, including Drupalgeddon2, to compromise Drupal installations, install DDoS and currency-mining malware, and attack non-Drupal machines made accessible by that foothold.
The impact for organizations which run Drupal now (or ran it at any time since March 28th, 2018) is severe. Multiple organized criminal groups have raced to exploit the first vulnerability, named Drupalgeddon2. The most prolific uses malware named “Muhstick,” which infects a host, then spreads to other machines using SSH and WebDav, as well as exploits against the Drupalgeddon2 vulnerability and vulnerabilities in Oracle’s WebLogic, ClipBucket, Webuzo, and the WordPress content management system. Muhstick is a variant of Tsunami, which has infected tens of thousands of Linux hosts. Muhstick has built a botnet from servers and Internet of Things (IoT) “smart devices,” allowing it to scan the Internet for vulnerable hosts very quickly.
For any site that ran Drupal since March 28th, it’s critical to patch the Drupal software immediately. InGuardians further recommends assuming that Internet-facing Drupal installations have been compromised, until that assertion can be ruled out. The Muhstik malware doesn’t spread only using software vulnerabilities. It also scans for SSH servers, trying both a pre-populated set of password possibilities as well as credentials that it finds on the system from which it runs. If Muhstik compromised a single Drupal system, it has likely spread to other systems.
InGuardians has seen many clients use a best practice approach to content management system-provided websites. These clients bifurcate their Drupal application servers into two servers: an internal dynamic server and an external static server. The internal server runs the content management system (Drupal) to allow organization staff to update the site’s content. On any update, this server pushes a static mirror of the site to the external server. The external server serves content statically, exposing far less code to attackers. This can be accomplished on Drupal using the Static Generator module.
Additionally, InGuardians recommends disallowing root login via SSH and relocating the SSH server port from 22 to a less well-known number. These two measures massively reduce the number of successful SSH-based attacks, whether in initial infection or lateral movement.
Drupal Patch Instructions for Drupalgeddon2
Drupal Static Generator Module
Botnet Muhstik is Actively Exploiting Drupal CVE-2018-7600 in a Worm Style (Netlab at 360.com)
Big IoT Botnet Starts Large-Scale Exploitation of Drupalgeddon 2 Vulnerability (Bleeping Computer)
04/16/2018 Researchers Can Hijack ATI Systems’ Emergency Alert Sirens Using Software Defined Radio (SDR)
Security researchers at Bastille Networks were able to capture, analyze and replay packets to trigger emergency alert sirens in the city of San Francisco provided by ATI Systems. Over a 2 year period, researchers captured the weekly transmission to initiate system tests. Upon analyzing the captured radio protocol, it was discovered that the transmissions were neither encrypted nor authenticated.
While the ATI Systems emergency alert sirens are a unique implementation, the vulnerability in these systems extends to those installed outside of San Francisco, with identical systems deployed across the globe. Attacks against these types of systems are not unique, as it is theorized similar attacks were used in the erroneous activation of the Tornado Warning sirens. In Dallas, Texas
Adoption of proprietary Radio Frequency (RF) systems is quite common in both legacy and current systems.
InGuardians often finds that organizations do not have an accurate inventory of RF-enabled systems in their environment, nor do they understand the overall implications of compromise of the unknown RF-enabled systems.
This proof of concept is specific to the ATI Systems implementations, which by design, could cause widespread panic should the emergency sirens be triggered by an attacker. However, a bad actor or researcher could use the overall methodology and tools for discovering an attack surface for this system on other RF-enabled systems. Overall impact to an organization will depend on the affected system discovered and analyzed, but it is not outside the realm of possibility that there could be pecuniary or life safety issues.
With the increased development in Software Defined Radio (SDR) and expertise in these tools being gained by the security community, RF protocols that formerly enjoyed “security through obscurity” are unlikely to remain free from attack much longer. This becomes particularly challenging in legacy systems where the RF protocols were designed with obscurity as the only security measure either due to lack of available technology, or little future consideration in technology advancements.
InGuardians recommends its clients perform or commission an overall discovery of RF-enabled systems in the enterprise environment, followed by a thorough risk analysis. Should the risk impact be determined to be elevated for any of the discovered systems, it is recommended, at a minimum, to contact the vendor to in order to determine methods in use for securing, encrypting, and performing authentication of transmissions. Should the answers from the vendor be insufficient, or the RF-enabled systems be critical to the operation of the business, a thorough review and analysis of the RF transmissions should be performed.
Dallas Tornado Siren Hack [Washington Post]
04/09/2018 Security vulnerabilities in two Moxa Industrial Control Systems (ICS) devices
04/02/2018 Drupal CMS High-Critical Remote Code Execution Vulnerability
Security researchers have discovered and publicly released several Highly-Critical Remote Code Execution (RCE) vulnerabilities in Drupal versions 7 through 8.5, as well as the end-of-lifed version 6. Due to the serious nature of these remote code execution vulnerabilities, Drupal has released patches for older, unsupported versions including version 6.
The Drupal Content Management System (CMS) powers 6% of the 10,000 most popular public web sites. Over 647,000 publicly-accessible web sites use this software. This may increase the risk that bad actors may either quickly attack companies running Drupal or will create and release malware targeting this software.
Remote code execution vulnerabilities like these allow an attacker to execute code of their own choosing on an unpatched installation. This could ultimately result in full system compromise and/or allow the attacker to move laterally to compromise other machines, including those on internal network segments.
InGuardians often finds that organizations do not have an accurate inventory of Internet-facing hosts or the applications which they host. In these cases, application vulnerabilities are particularly challenging to defend, as it is impossible to update software that isn’t known to the patch management staff.
Unless Drupal CMS versions are updated to 7.58 or 8.51, it is possible for an attacker to gain full control of the affected system. Drupal CMS version 6 permits the same behavior unless patched against SA-CORE-2018-2. Depending on the attacker’s skillset, as well as the defender’s level of network segmentation, it is possible that an attacker could take full control of the defender’s infrastructure.
InGuardians recommends immediate patching of the Drupal content management system (CMS) across all versions. Until such time as a patch can be applied, InGuardians recommends that affected organizations restrict access severely to a few trusted IP addresses. This restriction should only be utilized to perform appropriate upgrades and patches, before restoring full access.
This is also the perfect opportunity to undergo an aggressive look at internet-facing resources in order to develop an accurate inventory, with the intent of finding previously unknown assets including Drupal. Upon completion of internet-facing asset discovery, InGuardians recommends performing a similar discovery on internal network segments.
Drupal core – Highly critical – Remote Code Execution – SA-CORE-2018-002
FAQ about [Security Advisory] SA-CORE-2018-002
[Content Management System] CMS Usage Statistics
03/28/2018 Municipal governments battle cyber attacks.
The Georgia cities of Atlanta and Loganville are the latest victims in an ongoing trend of attacks on municipalities. First, on Thursday, March 22nd, the City of Atlanta announced that its networks had been shut down due to a ransomware attack. At the time of this posting, the city is working with the FBI and the Department of Homeland Security, as well as external partners from Microsoft and Cisco’s cybersecurity response team, to investigate the situation.
The City of Loganville (a suburb of Atlanta), announced on Monday, March 26th on its Facebook page that an external threat actor had successfully perpetrated a breach of an internal server. The Loganville breach may not be related to that of Atlanta.
In Atlanta, the ransomware has cut off electronic access to court records, while many departments are using pen and paper to perform their duties. Many city services, such as electronic bill pay, are still unavailable to city residents. As a precautionary measure, the public wireless network (Wi-Fi) at Hartsfield-Jackson airport has also been suspended.
Evidence suggests the Atlanta malware is SamSam, which has been seen in other government targeted attacks, like the one that occurred at Colorado’s state Department of Transportation. In particular, the letter shared by local media during the early stages of the ransomware infection in Atlanta is clearly a SamSam ransom note.The wording — including typos — is identical to the examples shared by researchers working for Cisco’s Talos group earlier this year. The only difference was the directory where the contact portal is hosted.
Once attribution to SamSam became public knowledge, the SamSam group deleted the contact portal that the city of Atlanta would use to make payment. Given the SamSam group’s actions, it isn’t clear if payment is even possible now. While it is possible other portals exist for the systems infected in Atlanta, the city hasn’t released any technical details to the public.
In Loganville, the breach is believed to have exposed personally identifiable information, (PII) such as social security numbers, to the attacker.
InGuardians echoes the sentiments of the newly elected Atlanta Mayor who is quoted as saying, “this is bigger than a ransomware attack, it’s an attack on government and therefore an attack on all of us.”
It is increasingly apparent that organizations must make the resources available and establish effective policies and preventative measures to strengthen their security postures in order to mitigate these threats.
InGuardians recommends that all leaders of municipal governments view themselves as a likely soft target and create internal Information Security programs to address the emerging threats. We also recommend that all business leaders continue to follow this case for lessons learned, such as:
- Do not leave Remote Desktop Protocol (RDP), Windows Server Message Block (SMB), Secure Shell (SSH) or Telnet available to the Internet – use VPNs and firewall white lists
- Confirm that no operations systems use SMB version 1
- Apply Windows group policy objects (GPOs) to harden government systems uniformly
- Do not allow users to have local administrative privilege on their desktop machines
- Make sure that all patches are deployed quickly – malware victims have lost a race with an attacker
Small Towns Confront Big Cyber Risks (GovTech)
Atlanta Working “Around the Clock” to Fight Off Ransomware Attack (NPR)
We Are a Resilient City – Atlanta Works to Move Forward Following Cyber Attack (11Alive)
Metro Atlanta City Reports Its Own Data Breach (Atlanta Journal Constitution)
Atlanta’s Computers Crippled by Ransomware – Issues Unresolved After 4 Days (SmartCities Dive)
03/19/2018 New DHS alert on breaches of power grid and other control systems
Disabling safety or security controls invalidate risk assessment and mitigation. It won’t matter if the control was disabled by a hacker or by an employee.
New information is surfacing about breach of control systems first identified in August 2017. One conceptual flaw and one implementation or operating error combined to defeat safety systems and shut down systems.
In a SCADA environment, the TRICONEX system is a sound concept, using triple redundancy comparison of signals as a check of proper operating conditions. If one of the 3 is different, the system enters a safety condition with appropriate alerts and changes. That could mean opening vales to increase cooling, or shutting fuel valves to stop machinery. The firmware of the controllers can, of course, be updated.
To ensure security, a physical switch is used to change it from “read only” to “read-write” for updates. A variety of implementation factors, from remote locations to limited personnel managing large automated systems, may have contributed to operators leaving systems in read-write. In at least one case, one of the maintenance management computers was compromised allowing hackers access to now fully modifiable controllers. In another case, the SCADA system was on a larger network and not properly isolated from external connections leaving it vulnerable to external penetration.
Remote network access to systems enabled hackers to destroy hard drives inside the company’s computers and their data was wiped clean. (NYT). It also appears that only an error in the attack code prevented physical damage and possibly explosions.
InGuardians’ clients may be at LOW risk for the specific attacks used against these Industrial Control Systems (ICS).
However, the broader issue of increased risk from “work arounds” which inevitably occur in every business may be negating what you think is in place for risk mitigation. The focus is NOT on malicious employees, but on those trying to succeed in the face of unintended policy conflicts. Too few people required to do detailed checks on too many systems too widely separated or remotely located is only one of the sorts of situations that creep in to daily ops.
Review ACTUAL operating conditions and procedures compared to policy. Third party audits or interdepartmental audit teams provide fresh perspectives.
Think more like an attacker. Be less sure – “my door is locked, I can relax” – and more – “the door has a lock but how would it get picked? Broken? Simply evaded? If it was picked, how would I know”. Red Teams don’t simply do set penetration tests, but use creative thinking to find the unexpected gaps, the new approaches. Those attacking your systems don’t have any rules.
03/12/2018 Dofoil trojan variant used to install cryptocurrency-mining malware
Microsoft’s Windows Defender Research group identified a new variant of the Win32/Dofoil remote access trojan which installed a cryptocurrency miner for Electroneum (ETN) coin.
The impact of this trend is severe, due in part to the trojan’s ability to download and execute code on command. The Dofoil family of trojans give the attackers full command and control of the compromised system. In addition to crypto mining, the trojan has previously been used to install ransomware and other malicious code.
In this latest attack, Dofoil used a technique known as process hollowing, copying legitimate binaries for explorer.exe and swapping malware in its place.
Many attackers are using cryptocurrency mining as a major revenue stream. During the WannaCry outbreak, at least two other groups used the same exploits to install crypto miners and subsequently earn millions of dollars (far better than the WannaCry authors fared.)
InGuardians recommends having a robust segmented network, with good instrumentation of inbound and outbound traffic. Organizations can use network and host monitoring tools that identify unusual behavior and activity to help identify and contain malware outbreaks. Some of the tools that can be used for detection and containment are Bro, Snort, and Windows Defender. Many anti-malware and threat protection services claim to detect and protect against cryptocurrency miners.
In addition to segmentation and instrumentation, InGuardians recommends having solid backup and recovery solutions in place. These should be tested on a regular basis, with verification of the recovered systems.
Win32/Dofoil (Microsoft Windows Defender Security Intelligence)
DoFoil: Crypto-mining Malware Outbreak Infects 500,000 Computers In One Day (Newsweek)
The State of Malicious Crypto-mining (MalwareBytesBlog)
03/05/2018 Widespread SSL Certificate Revocation Disrupting Internet Transport Encryption with Further Disruption Planned for April and October
On Wednesday, Trustico (a Symantec reseller) triggered the revocation of roughly 23,000 SSL/TLS certificates, in advance of April and October’s certificate disruptions on any certificate sold under the brands Symantec, GeoTrust, Thawte, and RapidSSL.
While the April deadline for Symantec, GeoTrust, Thawte and RapidSSL certificates looms, Trustico’s method of revocation has caused further concern. Trustico wanted to move its customers from roughly 50,000 Symantec-provided certificates to new ones provided by Comodo. Digicert, who had purchased Symantec’s certificate business, initially refused, on the basis that it would only revoke so many certificates in the case of a security breach. Trustico’s CEO then e-mailed 23,000 certificates’ private keys without encryption to Digicert, thus creating a breach. The breach was compounded when a remote code execution vulnerability was found in Trustico’s website.
This situation calls into question Trustico’s practices as a certificate reseller. First, certificate vendors should not retain private keys. Second, Trustico’s choice to e-mail private keys put all communications using those keys at risk and may have failed to give customers the opportunity to replace the certificates before this risk window.
Any organization using one of the revoked Trustico-resold Symantec SSL certificate has lost the integrity of HTTPS connections to any server using that certificate. Users will generally see an untrusted connection error immediately and many will understand that a problem exists. Further, any organization using a Symantec certificate, including those branded as GeoTrust, Thawte and RapidSSL, will face a similar problem on April 17th or in October, at which point Google’s Chrome and Mozilla’s Firefox browsers will begin stating that the certificates are untrusted. See the schedule below (under “Recommendations”) for more detail.
InGuardians strongly recommends that organizations audit their SSL/TLS certificates, determining which have been provided by Symantec, GeoTrust, Thawte and RapidSSL. Staff should replace every certificate provided by these companies well before the following deadlines:
April 17th: Certificates issued before June 1, 2016 will not work with Chrome 66.
May: Certificates issued before June 1, 2016 will not work with Firefox 60.
October: Certificates will no longer be trusted, as of Firefox 63.
October 23rd: Certificates will no longer be trusted, as of Chrome 70.
Organizations can use a number of tools to check its SSL/TLS certificates, whether for its web servers or its other SSL/TLS-enabled services. The popular open source tool, nmap, will display information about the certificate enabled on one or more ports, like so:
nmap -v -sT -p 443 –script=ssl-cert www.inguardians.com | egrep ‘(Issuer|valid)’
| Issuer: commonName=GeoTrust RSA CA 2018/organizationName=DigiCert Inc/countryName=US/organizationalUnitName=www.digicert.com
| Not valid before: 2018-01-25T00:00:00
| Not valid after: 2019-02-24T12:00:00
Organizations should be careful to check all ports on a system, and not just the standard service ports for SSL/TLS.Additional Resources
Google: “Chrome’s Plan to Distrust Symantec Certificates”
Mozilla: “CA:Symantec Issues”
DigiCert: “How do you handle mass revocation requests?”
Trustico® Abandons Symantec® SSL Certificates
02/26/2018 Increased attacker focus on exposed cloud services, specifically AWS Simple Storage Service (S3) Buckets
Amazon’s cloud-based Simple Storage Service Buckets, colloquially referred to as “S3 Buckets”, have been a recent focus of attackers and security researchers. With the advent of new open source and publicly-available tools to search for improperly configured S3 buckets, bad actors and information security firms have found many cases where the buckets’ owners have inadvertently granted access to every user on the Internet.
In moving to cloud-hosted services, many organizations have failed to heed widespread warnings with this message:
Organizations must secure and monitor cloud-based services just as strongly as with traditional on-premise infrastructure.
Impact from exposure of Amazon S3 is varied, depending on an organization’s adoption and configuration of Amazon’s cloud-based storage infrastructure:
Known adoption of Amazon S3: The risk level varies from low to critical, depending on individual bucket configuration for read/write access, granularity of defined accesses, types of content stored, and use cases for the stored content. The overall level of risk would be determined by these factors and will be different for each individual bucket within an organization’s cloud infrastructure.
No known adoption of Amazon S3: The current risk is undefined, and merits analysis to identify whether your organization is using S3, and if it is see above.
InGuardians recommends performing a self-assessment of existing S3 Buckets using currently available tools, such as AWSBucketDump and BuckHacker. Results of these tools should then undergo a thorough inventory and risk analysis.
In addition to these open source tools, Amazon makes the AWS Trusted Advisor tool available to customers with a Business or Enterprise-level support plan. Trusted Advisor can analyze an AWS environment, including its S3 buckets, and make best practice recommendations.
Tesla Cryptojacked by Currency Miners
AWSBucketDump, an Open Source S3 Bucket Search Tool
BuckHacker, an S3 Search Engine
AWS S3 Documentation: Which Access Control Method Should I Use?
AWS Trusted Advisor
02/20/2018 Theft of Newtek domains is a reminder to stay vigilant
Last week a web services company (Newtek) responsible for hosting over 100,000 e-commerce based websites and email servers had three of its core domains stolen. These domains originally hosted software that allowed customers of these services to manage their websites.
The attackers then replaced the application that users would normally use to manage their websites with his own application in the form of a live-chat service. When users logged in, they believed themselves to be chatting with a helpful admin, when in fact they were communicating with the attacker.
The full impact of this is still being determined. However, corporate email for many of their customers became unavailable, business websites no longer resolved, and sensitive information was most likely communicated to the attacker.
InGuardians recommends that all businesses consider domain hijacking as a potential event in their Business Continuity Plans (BCP). It’s important to stay vigilant in ensuring continued ownership of domains. It’s also important to have plans to use secondary domains for web and email traffic in the event of having lost ownership of a domain.
InGuardians recommends building your own capabilities to gather counter-intelligence and to proactively monitor your organizations digital footprint. Consider scripts or services for monitoring DNS changes to the domains that you control.
Wikipedia list these options as a means to prevent an unwanted domain transfer:
- Use strong email passwords and enable two-factor authentication if available.
- Disable POP if your email provider is able to use a different protocol.
- Tick the setting “always use https” under email options.
- Make sure to renew your domain registration in a timely manner – with timely payments and register them for at least five (5) years.
- Use a domain-name registrar that offers enhanced transfer protection, i.e., “domain locking” and even consider paying for registry locking.
02/12/2018 Smart devices add exposure and threat during a breach and are a source of intelligence and forensic data during incident response.
A common challenge in any incident response is figuring out how access was gained, which vulnerability or exploits were used, and how to prevent recurrence. Many breaches are not single events, but the end of a longer series of probes, penetrations, and exfiltrations. The reality is that we are often dealing not with “a breach,” but a series of incidents that can have been going on longer than many realize.
The explosion of smart devices creates many more opportunities not only to reveal information, but for attack vectors. A “phishing” email might be read on an employee’s cell phone and not directly breach a corporate system. But, it might install malware on that phone so the next time it is in WiFi or Bluetooth proximity of a business network the malware starts searching for new opportunities. This shifts what would have been an external penetration to an internal one.
The specific impact to InGuardians customers is relatively low.
The real challenge is in mapping the many additional connections to your networks, and identifying where such connections are logged – if at all. You cannot effectively investigate the cause or source of a breach if you do not have a clear record of the network.
InGuardians recommends regular review of network architecture as it develops, not merely as planned. Systems and connections often grow organically and in creeping increments, and too often expedient solutions are imperfectly documented. It is important to know what the network looks like today, to know where device access logs are stored, and whether they have ever been reviewed. InGuardians highly recommends robust egress filtering and monitoring.
InGuardians also recommends reviewing the policy for the devices managed by your organization. Secretary of Defense Mattis is reconsidering DoD’s policies for every personal electronic device that “transmits a two-way signal”. That’s much more than just cell phones, but you should at least know WHAT you allow.
02/05/2018 Strava heatmap exposes sensitive military bases invokes the law of unintended consequences.
Something as innocuous as a running application paired with cloud access and GPS location data allowed users to identify sensitive military and government bases and users. The Guardian newspaper used a script to generate GPS data to upload to a Strava account. Following this, they used the application to find other users that also do the same run. The runs matched sensitive locations such as military installations and classified government facilities. They identified 50 users by name.
With so many interconnecting devices, where is the boundary of your data. If you don’t know where your data is, and where it goes, you cannot secure it. With multiple devices providing cloud or syncing functionality, the ease at which data can unintentionally leak out of the environment is astounding.
Impact from the Strava heatmap to InGuardians customers is relatively low. The issue does present us with the conundrum of securing our data, performing operational security, and still being able to use that data and the many applications that have become intrinsic to our businesses.
InGuardians primary recommendation is analyze the potential exfiltration threats that applications pose, and create policy to deal with these accordingly. Some examples of applications and policies in this arena would be: social media use policy, onsite photography or mobile phone use, or modifying the meta data.
InGuardians also recommends implementing a Mobile Device Management (MDM) solution to enforce policy onto the devices managed by your organization. Implementing steps in order to lock down functionality on these devices based on your internal processes and policies is critical. Unknown, unmanaged devices should not be allowed on your network. The larger concern goes beyond “Strava” and may include data that is gathered but not publicly mapped.
Strava Heatmap and related articles
07/25/2017 Mac malware (FruitFly) that was detected and patched in January, still making rounds according to BlackHat presenter.
In January, malware that infects Mac OS X was detected impacting organizations performing research in the biomedical field. This malware leveraged old functions that have been around in OS X for many years. The main goal of the malware appears to be surveillance, given that it captures screenshots, accesses the webcam, and reportedly performs key logging.
Apple released a patch for this issue in January when the malware was first detected. Many news outlets are incorrectly reporting that there is no known way to detect this malware. However, most all major AV companies have signatures to detect FruitFly.
According to the BlackHat presenter, the recent infections appear to be mostly home users. This is likely due to the fact that all properly licensed versions of OS X have been patched by Apple through a behind-the-scenes update mechanism, as of January.
The impact of this particular issue is low at the moment.
Even with a low impact, the detection of this malware is a reminder to practice good opsec (operational security) and keep built-in webcams covered unless in use. Also, it is a reminder that even Apple systems can be vulnerable to malware.
InGuardians recommends that organizations ensure that all operating systems are licensed and up-to-date with all relevant security patches. InGuardians also recommends that organizations endpoint security products to properly monitor all operating systems, including Apple products.
MalwareBytes writeup detailing how FruitFly works:
VirusTotal list of AV vendors that detect FruitFly:
07/17/2017 Kaspersky anti-virus removed from two GSA Schedules
Kaspersky Anti-Virus (AV) has been removed from two GSA (Government Services Administration) schedules, due to concerns that the Kremlin may use Kaspersky products to compromise US Government computers.
A commonly used anti-virus product has been banned for purchase by any U.S. Government agencies which use GSA schedules 67 and 70. While the US government has not yet banned Kaspersky products already purchased, or those purchased outside the GSA schedule, the Senate version of the 2018 defense bill places a blanket ban on Kaspersky products. This bill has not yet been passed. Many government and private organizations receiving funding from the U.S. or state governments are required to make such purchases via the GSA schedule.
This ban limits further acquisition of Kaspersky AV by those organizations required to follow GSA. However, many organizations may already have this product entrenched within their infrastructure. Still, organizations which are not required to adhere to the GSA schedule may decide to follow suit with the GSA’s ban on Kaspersky AV. Organizations may have many questions on how to move forward.
Hold tight. There is a significant amount of posturing and saber rattling on the geopolitical stage at the moment. A number of independent research organizations are currently examining Kaspersky’s software, and reports should be forthcoming.
InGuardians recommends that organizations not rely on solely one vendor’s solutions for security products. Organizations should evaluate multiple providers and select only those with which they can form a trusted relationship. In the event that trusted relationship becomes compromised, the organizations should have plans for contingencies which enable the removal and selection of a new vendor without losing coverage. Most of our clients favor endpoint protection, in addition to layered application and network defenses, over traditional anti-virus.
07/10/2017 DHS & FBI warn of attacks against US energy & manufacturing companies and employees
DHS and the FBI released a TLP:AMBER report warning US energy sector and manufacturing companies about ongoing cyber operations. These operations include sophisticated physical and cyber attacks, as well as activities targeting employees and operators with the aim of infiltrating air-gapped networks.
Our customers in the energy sector have seen scanning and attacks increase in the last month, but one interesting twist about the report is the targeting of individual employees in order to infiltrate secure networks. Many details regarding the attacks are now known to the public, in part because an irresponsible organization shared a TLP:AMBER report with the press. The approach of going after operators and employees to target secure networks is reminiscent of how GHCQ hacked into Belgicom’s NOC.
This warning comes almost one month since Robert Lee and his team at Dragos released their research on the CRASHOVERRIDE malware, along with ESET’s analysis of Industroyer. Keep in mind that Robert Lee will be presenting details on CRASHOVERRIDE at Black Hat in just a few weeks.
Your key operations and security staff should be trained in operational security (opsec). Include physical security tests and targeting specific roles and personnel as part of your routine security assessments.
News regarding recent hacking of nuclear plant:
07/03/2017 Wiperware disguised as ransomware strikes globally, taking advantage of unpatched systems and flat networks.
The recent wave of supposed ransomware attacks, NotPetya, spread rapidly due to non-segmented (“flat”) networks after its initial infection. It is reported to have first hit the Ukraine and subsequently spread internationally. Many of the targets that reported infection are industrial, financial, health or other components of critical infrastructure.
Whereas the Petya ransomware that first emerged last year was actual ransomware, the variant that wormed its way through non-segmented (“flat”) networks in June 2017 (NotPetya) does not allow for decryption of the data. As such, InGuardians classifies this as wiperware.
NotPetya uses many different vectors to infect and perform subsequent infections. Even though it does use the NSA exploits EternalBlue and EternalRomance that were addressed by Microsoft security update MS17-010, NotPetya also leverages many other vectors of attack. It includes mimikatz, with that tool’s LSADump module. This is used for recovering passwords with the aim of gaining administrative access locally and eventually at the domain level. NotPetya also uses PSExec as a means of subsequent infection, as well as WMI calls.
Many people responsible for network security claim that they thought they were patched against the NSA exploits. It’s key to note that NotPetya has multiple initial infection vectors, including phishing. Even if one of the NSA exploits became the vector of initial infection on an unpatched machine, the other vectors of subsequent infection allow it to spread unhindered through flat networks, full of otherwise patched systems.
Infections of NotPetya spread rapidly across non-segmented, or “flat,” networks, stealing credentials and leveraging privileges and trust. The technical result is mangled data on infected systems. This data is unrecoverable. The business impact has been a shutdown of operations in many of the impacted targets.
The one common issue that allows the spread of NotPetya is networks that are not segmented with access control. Logically segmented networks are still considered flat networks, as they lack access controls. When access controls restrict traffic from traversing network segments, hosts are well isolated and this stymies infections of this type, containing them to a single host or portion of the network.
InGuardians recommends implementing restrictive access controls at the network level and isolating hosts using host-based firewalls or Private VLANs. InGuardians also recommends using Group Policies within Microsoft Active Directory to lock down endpoints and implement the Principle of Least Privilege, preventing the lateral spread from affected, internal systems. These tactics are highly recommended to defend against modern malware attacks like NotPetya.
Setting up Private VLANs
Implementing the Principle of Least Privilege within Various Versions of Windows
06/26/2017 Three Drupal updates patch critical vulnerabilities
One of the three critical vulnerabilities patched last week in the Drupal web content management system, allows for remote code execution.
Drupal is one of the most popular content management systems in use, and the vulnerability described in CVE-2017-6920 gives an attacker the same capabilities on the system as Drupal itself.
This vulnerability is in the PECL YAML parser, and is related to a bug found recently in PHP. PHP updated their documentation alerting developers to not pass unsanitized user input to these functions, which did not “fix” the vulnerability.
Drupal updated their code, changing the way they pass input to the affected functions, and is no longer vulnerable to this attack vector.
YAML parsing vulnerabilities have led to quick widespread exploitation in the past, in multiple web frameworks and languages, and are thus considered quite dangerous.
Recent high profile website hack and defacements emphasize the need to check your content management system implementation and ensure it is up to date.
- Tactical recommendation: If your organization has deployed Drupal, update to Drupal 8.3.4 or Drupal 7.56, as both branches include the fixes for these vulnerabilities.
- Strategic recommendation: Consider using a static publishing script to separate your editing/publishing platform from your delivery system. This allows your team to reap the benefits of a content management system, and couples it with the security of a static site. WordPress, Drupal and other popular systems have static publishing plugins or scripts.
06/19/2017 Nation states in the ransomware business
Nation states are now confirmed to be using ransomware campaigns to fund state coffers. British National Cyber Security Center (NCSC) reported this week that the wannacry ransomware attack was launched from North Korea. This follows the United States National Security Agency (NSA) assessment with the same conclusion. Security experts believe that the attack was launched by the Lazurus Group tied to the government in Pyongyang.
This revelation further emphasizes the need for full backup, recovery and continuity plans to be tested and refreshed. While most of our customers have a robust patching, backup and recovery processes in place, we see from news reports the impact wannacry had on critical production networks. Many organizations have lost their data, or access to critical systems while being locked out during a ransomware attack. E.G. British National Health Service systems were crippled during the wannacry attack
InGuardians recommends reviewing, testing and validating your patching, and backup/recovery processes. Incident response capabilities should be tested as well, guided by an internal Red Team exercise designed to emulate the ransomware attack threat model. InGuardians does not recommend paying for the return of your data. See link below for new regulations that might impact the practice of paying your way out of ransomware.
Articles related to this issue:
NIST Incident Response:
Bitcoin regulations to prevent infosec companies from helping organizations pay ransom:
06/12/2017 Powershell scripts execute in Powerpoint without macros
Microsoft’s powerful native scripting language, Powershell, is able to execute inside a Powerpoint presentation without using macros. This presents an issue for many organizations that rely on blocking macros or documents with macros to minimize the risk of compromise via Microsoft Office documents.
InGuardians RedTeam operators used this very technique to compromise one of our toughest clients just last week. This is a very real threat posing risk to the information security of your organization. Determine which controls and audit measures best fit your security posture and move swiftly to lock down this threat vector.
InGuardians recommends first determining if systems need powershell. If needed, ensure powershell is up to date. Older versions of powershell do not have many of the security feature set that version 5 has. Take the necessary steps (outlined here:https://adsecurity.org/?p=2604) to detect powershell being used offensively on your systems.
Excellent technical write-up on Powershell Security: https://adsecurity.org/?p=2921
Recent article on this threat: https://thehackernews.com/2017/06/microsoft-powerpoint-malware.html