macOS High Sierra Logs External Volume Passwords in Plaintext
30.3.2018 securityweek Apple
In macOS High Sierra, the passwords used for Apple File System (APFS)-encrypted external drives are logged and kept in on-disk log files, a security researcher has discovered.
The APFS file system was introduced by Apple with the release of macOS High Sierra and is automatically applied to the startup volume when the platform High Sierra is installed on a computer with a solid-state drive (SSD).
According to Apple, APFS provides strong encryption, fast directory sizing, space sharing, and improved file system fundamentals.
The newly discovered vulnerability, Sarah Edwards reveals, impacts macOS 10.13 platform versions. Initially found when creating a new APFS volume, the bug appears to occur when encrypting previously created but unencrypted volumes as well.
What the expert observed was that the password used for a newly created APFS-formatted FileVault Encrypted USB drive via Disk Utility could be found in unified logs in plaintext.
“The newfs_apfs command can take a passphrase as a parameter using the mostly undocumented “-S” flag. It is not documented in the man page. However when run without parameters, it will show it,” Edwards notes.
The vulnerability was initially discovered on a system running macOS High Sierra 10.13.1. To reproduce it, one would have to create a “clean” flash drive using Disk Utility.app.
The researcher formatted the drive “Mac OS Extended (Journaled),” but the issue appears with other base formats as well.
Next, one would have to create an Encrypted APFS volume on the drive, using the menu option “Erase” and wait for the process to complete.
Keeping an eye on the unified logs in the Terminal while the operation is being performed reveals the selected password in plaintext.
The issue appears to have been fixed in High Sierra 10.13.2, but only for newly created volumes. Thus, the vulnerability can still be triggered when encrypting an already existing unencrypted APFS volume in macOS 10.13.3, the researcher says.
By exploiting this issue, an attacker could view the encryption password of encrypted APFS external volumes on USB drives, portable hard disks, and other external drives.
In October last year, a developer in Brazil discovered that macOS High Sierra leaked the passwords for encrypted APFS volumes via the password hint. The developer discovered the bug after using the Disk Utility to add a new encrypted APFS volume to the container.
Drupalgeddon: Highly Critical Flaw Exposes Million Drupal Websites to Attacks
30.3.2018 securityweek Vulnerebility
All versions of the Drupal content management system are affected by a highly critical vulnerability that can be easily exploited to take complete control of affected websites in what may turn out to be Drupalgeddon 2.0.
While analyzing the security of Drupal, Jasper Mattsson discovered a serious remote code execution flaw that impacts versions 6, 7 and 8. This represents more than one million websites that can be hacked by a remote and unauthenticated attacker.
The security hole, tracked as CVE-2018-7600 and assigned a risk score of 21/25, can be exploited simply by accessing a page on the targeted Drupal website. Once exploited, it gives the attacker full control over a site, including access to non-public data and the possibility to delete or modify system data, Drupal developers warned.
The vulnerability has been patched with the release of Drupal 7.58, 8.5.1, 8.3.9 and 8.4.6. While Drupal 6 has reached end of life and it’s not supported since February 2016, a fix has still been developed due to the severity of the flaw and the high risk of exploitation.
Besides updating their installations to the latest version, users can protect their websites against attacks by making some changes to the site’s configuration. However, the required changes are “drastic.”
“There are several solutions, but they are all based on the idea of not serving the vulnerable Drupal pages to visitors. Temporarily replacing your Drupal site with a static HTML page is an effective mitigation. For staging or development sites you could disable the site or turn on a ‘Basic Auth’ password to prevent access to the site,” Drupal developers said.
Cloudflare also announced that it has pushed out a rule to its Web Application Firewall (WAF) to block potential attacks.
While no technical details have been made public, Drupal believes that exploits targeting the vulnerability will be created within hours or days, which is why it alerted users of the flaw and an upcoming patch one week in advance. This appears to have been a good strategy, but many websites may still remain vulnerable for extended periods of time.
In the case of the notorious Drupalgeddon vulnerability, hackers had used it to take control of websites nearly two years after a patch was released.
While there haven’t been many reports of Drupal flaws being exploited in the wild since Drupalgeddon, one of the vulnerabilities patched in June 2017 by the developers of the CMS had been leveraged in some spam campaigns.
Severe Vulnerabilities Expose MicroLogix PLCs to Attacks
30.3.2018 securityweek ICS
Rockwell Automation has released patches and mitigations for several potentially serious vulnerabilities discovered by Cisco Talos researchers in its Allen-Bradley MicroLogix 1400 programmable logic controllers (PLCs).
According to Cisco Talos, the vulnerabilities can be exploited for denial-of-service (DoS) attacks, modifying a device’s configuration and ladder logic, and writing or removing data on its memory module.
Since these controllers are typically used in industrial environments, including in critical infrastructure organizations, exploitation of the flaws could result in significant damage, Talos said.Vulnerabilities found in MicroLogix controllers
The most serious of the flaws, based on their CVSS score of 10, are a series of access control issues that have been assigned a dozen CVE identifiers. A remote and unauthenticated attacker can exploit these vulnerabilities to obtain sensitive information, modify a device’s settings, or change its ladder logic – all by sending specially crafted packets.
While exploiting many of these flaws requires that the controller’s keyswitch is in REMOTE or PROG position, reading the master password and the master ladder logic works regardless of the keyswitch setting.
Another potentially serious flaw is CVE-2017-12088, which allows a remote attacker to cause the controller to enter a fault state and potentially delete ladder logic by sending specially crafted packets to the Ethernet port.
DoS vulnerabilities also exist in the device’s program download and firmware update functionality, but these have been assigned only a “medium severity” rating.
Other issues considered less serious include a file-write vulnerability affecting a memory module, and a DoS flaw related to the session connection functionality.
While a CVE identifier has been assigned to the session communication bug, Rockwell says the system actually works as intended and no patches or mitigations are required.
Rockwell Automation has released firmware updates that address some of these flaws. The company has also proposed a series of mitigations that include migrating to more recent series of the MicroLogix 1400 controller, setting the keyswitch to “Hard Run” to prevent unauthorized changes to the device, and disabling impacted services.
Cisco has published technical details and proof-of-concept (PoC) code for each of the vulnerabilities. Rockwell Automation has also released an advisory, but it can only be accessed by registered users.
This is not the first time Cisco Talos researchers have found vulnerabilities in MicroLogix 1400 PLCs. In 2016, they reported discovering a weakness that could have been exploited to modify the firmware on these devices.
Crypto Mining Rampant in Higher Education
30.3.2018 securityweek Cryptocurrency
Figures from an analysis of 4.5 million monitored devices across 246 companies show that for every 10,000 devices and workloads, 165 contain active threats. The majority are given a low (113) or medium (18) threat priority; but 34 are ranked high or critical, requiring immediate attention.
Deeper analysis of these figures in Vectra's 2018 Attacker Behavior Industry Report (PDF) shows the different stages of the attackers' kill chain found within different vertical industry sectors. Overall, 37% of detections denote C&C activity, 31% denote reconnaissance activity, 24% denote lateral movement, and 6% actual exfiltration attempts. The reducing numbers seem to indicate analysts' success at mitigating the detections as they progress. The remaining 3% of detections indicate botnet activity.
Applied to the different vertical industries, the analysis shows the fewest threat detections are found in the technology sector (a total of 62 per 10,000 devices) the healthcare sector, (87 per 10,000), and in government (139 per 10,000). Standing out, however, is higher education -- with 542 detections per 10,000 devices. Most of these, 395, are considered low priority threats, and are related to crypto mining.
"The number of low alerts in higher education is over three-times the normal rate, which is indicative of attacker behaviors that are opportunistic," explains the report. "Inversely, the technology industry has a low volume of devices prioritized as high or critical, which indicates cyberattackers do not often progress deep into the attack lifecycle."
Other sectors that stop attacks in their early stages include government and healthcare -- indicating the presence of stronger policies, mature response capabilities and better control of the attack surface; possibly because of greater regulation and oversight in these sectors. The very high number of low priority threats in higher education is largely down to a spike in crypto mining.
Higher education is unlike any other industry sector. Its users are not employees and are traditionally averse to outside control -- they will not automatically accept the security controls that can be applied to direct employees, and security teams can rarely impose them. At the same time, the student environment is an attractive target, especially for crypto mining.
"Higher education has a large number of students who are not protected by universities with open networks," explains Vectra. These same students also engage in their own crypto mining because they get free electricity, which is the highest direct cost of crypto mining (crypto mining uses computer resources to convert electricity into money). Geographically, most of this mining activity is done in Asia (76%), with 20% in North America, and just 4% in Europe. Sixty percent of all crypto mining detections uncovered by Vectra occurred in higher education.
The breakdown between mining by malware and mining by choice is not clear. It's a mixture of both, Chris Morales, Vectra's head of security analytics told SecurityWeek. "It's more likely college students crypto mining from their dorm rooms with a dose of outside actors," he added. "For example, some students could be watching pirated movies from an untrusted website that is crypto mining throughout the entire watching session. It would go unnoticed. This movie watching example really happens and was described to me by a security director at a large university as a problem they have to handle.
"Students are more likely to perform crypto mining personally as they don't pay for power, the primary cost of crypto mining," continued Morales. "Universities also have high bandwidth capacity networks with a large volume of easy targets, especially as students are more likely to use untrusted sites (like illegal movies, music, and software) hosting crypto mining malware."
Higher education can only respond to students they discover engaged in crypto mining with a notice the activity is occurring. They can provide assistance in cleaning machines or in the case of the student being responsible, they can issue a cease and desist. Corporate enterprises can enforce strict security controls to prevent such behaviors; but universities do not have the same luxury with students. "They can at best," explains Morales, "advise students on how to protect themselves and the university by installing operating system patches and creating awareness of phishing emails, suspicious websites and web ads."
Vectra's Cognito platform -- the source for the analysis -- uses continuous AI-enhanced anomaly detection to uncover threat behavior from network logs. It applies a scoring system to flagged behavior to reduce the high number of detected events to a low number of actual threats. For example, in this study (and on average), 26,432 events were flagged in every 10,000 devices. These were distilled down through 1,403 detections to 818 devices (per 10,000) with detections.
San Jose, Calif-based Vectra Networks raised $36 million in a Series D funding in February 2018, bring the total raised to $123 million. The funds are earmarked for further development of the Cognito 'attack in progress' threat hunting platform, and to fund a new research-and-development (R&D) center in Dublin, Ireland.
Your new friend, KLara
29.3.2018 Kaspersky APT
GReAT’s distributed YARA scanner
While doing threat research, teams need a lot of tools and systems to aid their hunting efforts – from systems storing Passive DNS data and automated malware classification to systems allowing researchers to pattern-match a large volume of data in a relatively short period of time. These tools are extremely useful when working on APT campaigns where research is very agile and spans multiple months. One of the most frequently used tools for hunting new variants of malware is called YARA and was developed by Victor Manuel Alvarez while working for VirusTotal, now part of Alphabet.
In R&D we use a lot of open-source projects and we believe giving back to the community is our way of saying ‘Thank you’. More and more security companies are releasing their open-source projects and we would like to contribute with our distributed YARA scanner.
What is YARA?
YARA is defined as “a tool aimed at (but not limited to) helping malware researchers to identify and classify malware samples”. In other words, it is a pattern-matching tool, but on steroids. It can support complex matching rules as well as searching files with specific metadata (for example, it can search all files that use a certificate containing the string “Microsoft Corporation” but is not signed by “Microsoft”).
How can YARA help you find the next APT in your network?
YARA’s usefulness is amazing, especially given traditional protection measures are no longer enough in today’s complex threat landscape. Modern protection systems, combined with constant network monitoring and incident response have to be deployed in order to successfully protect equipment.
Protective measures that were effective yesterday don’t guarantee the same level of security tomorrow. Indicators of compromise (IoCs) can help you search for footprints of known malware or for an active infection. But serious threat actors have started to tailor their tools to fit each victim, thus making IoCs much less effective. Good YARA detection rules still allow analysts to find malware, exploits and 0-days which couldn’t be found any other way. The rules can be deployed in networks and on various multi-scanner systems.
That’s why, as part of our Threat Intelligence services, we offer a range of training courses, one of them being our world-famous YARA Training, held by our GReAT ninjas: Costin Raiu, Vitaly Kamluk and Sergey Mineev.
Finding exploits in the wild
One of the most remarkable cases in which Kaspersky Lab’s GReAT used YARA was the much publicized Silverlight 0-day. The team started hunting for it after Hacking Team, the Italian company selling “legal surveillance tools” for governments and LEAs, was hacked. One of the stories in the media attracted our researchers’ attention — according to the article, a programmer offered to sell Hacking Team a Silverlight 0-day, an exploit for an obsolete Microsoft plug-in which at one time had been installed on a huge number of computers.
GReAT decided to create a YARA rule based on this programmer’s older, publicly available proof-of-concept exploits. Our researchers found that he had a very particular style when coding the exploits, using very specific comments, shell code and function names. All of this unique information was used to write a YARA rule — the experts set it to carry out a clear task, basically saying “Go and hunt for any piece of malware that shows the characteristics described in the rule”. Eventually it caught a new sample, a 0-day, and the team immediately reported it to Microsoft.
KLara, GReAT’s distributed YARA scanner
As mentioned above, any team carrying out threat intelligence needs to have powerful tools in their arsenal in order to find the latest threats and detect attacks as soon as possible. Within our R&D department we have built a lot of tools internally, but we believe most progress is made when useful tools are shared with the community. As such, we are releasing our internal tool for running YARA rules over a large set of data (malware/virus collections).
What is KLara?
In order to hunt efficiently for malware, you need a large collection of samples to search through. Researchers usually need to fire a YARA rule over a collection/set of malicious files and then get the results back. In some cases, the rule needs adjusting. Unfortunately, scanning a large collection of files takes time. However, if a custom architecture is used instead, scanning 10TB of files can take around 30 minutes. Of course, if there are multiple YARA rules that need to be run simultaneously, it’s important the system is also distributed. And this is where KLara comes in. KLara is a distributed system written in Python, allowing researchers to scan one or more YARA rules over collections with samples, getting notifications by email and in the web interface when the scan results are ready. Systems like KLara are important when large collections of data are involved. Of course, researchers will have their own small virus collections on their computers in order to make sure their YARA rules are sound, but when searching for viruses in the wild, this task requires a lot of processing power and this can only be achieved with a cloud system.
Why is it important to have a distributed YARA scanner?
Attacks using APTs are extremely dangerous, regardless of whether the target belongs to the public, private or government sector. From our experience, constant monitoring of logs, netflow, alerts and any suspicious files helps mitigate an attack during reconnaissance stages. There are some projects similar to KLara that SOC teams can leverage, but most of them are private, meaning either the virus collection or rules exist somewhere in the cloud, outside the team’s direct control.
KLara, on the other hand, allows anyone running any kind of hardware to set up their own private YARA scanner, keeping TLP RED YARA rules local.
KLara under the hood
The project uses the dispatcher/worker model, with the usual architecture of one dispatcher and multiple workers. Worker and dispatcher agents are written in Python. Because the worker agents are written in Python, they can be deployed in any compatible ecosystem (Windows or UNIX). The same logic applies to the YARA scanner (used by KLara): it can be compiled on both platforms.
Jobs can be submitted and their status retrieved using a web-based portal, while each user has their own personal account allowing them to be part of a group, as well as share their KLara jobs with any other valid account.
Accounts have multiple properties that can be set by the administrator: what group they are part of, what scan repositories they can run their YARA rules over (based on group membership), if they can see other groups’ jobs, or the maximum number of jobs that can be submitted monthly (individual quotas).
By using the dashboard, authenticated users can submit jobs on the ‘Add a new job’ page:
And check their status on the ‘Current jobs’ page:
Once a user submits a task, they can view its status, resubmit it or delete it. One of the workers will fetch the job from the dispatcher and if it has eligible scan repositories on its file systems, will start the YARA scan. Once finished, the user is notified by email of the results.
Each job’s metadata consists of one or multiple YARA rules, the submitter’s account info and a set of scan repositories that can be selected:
On the main page, a summary is displayed:
Job status: New/Assigned/Finished/Error
Job management: Restart/Delete job
How many files have been matched
Name of the first rule in the rules set
The repository path over which YARA scanned for matches.
A more detailed status can be seen once we click on a job:
Any YARA results will be displayed at the bottom, as well as a list of matched MD5s.
Each user can have a search quota and be part of a group. Groups can choose to restrict users (preventing them from seeing what other jobs group members submit).
Finally, each user can change their email address if they want notifications to be sent to another email account.
API access
In order to facilitate automatic job submissions as well as automatic results retrieval, KLara implements a simple REST API allowing any valid account with a valid API Key to query any allowed job’s status. It allows scripts to:
Submit new tasks
Get the job results as well as job details (if it’s still scanning or assigned, finished or if there’s an unprocessed (new) job)
Get all the YARA results from a specific job.
Get all the matched MD5 hashes
More info about using the API can be found in the repository.
How can you get KLara?
The software was released on our official Kaspersky Lab GitHub account on 9 March, 2018.
We welcome anyone who wants to contribute to this project to submit pull requests. As we said before, we believe in giving back to the community the best tools we can provide in order to fight malware.
The software is open-sourced under GNU General Public License v3.0 and available with no warranty from the developers.
Boeing production plant infected with WannaCry ransomware
29.3.2018 securityaffairs Ransomware
According to a report from the Seattle Times, the dreaded WannaCry ransomware hit a Boeing production plant in Charleston, South Carolina on Wednesday.
WannaCry is back, this time it infected some systems belonging to US aircraft manufacturer Boeing.
According to a report from the Seattle Times, the dreaded ransomware hit a Boeing production plant in Charleston, South Carolina on Wednesday.
“All hands on deck,” reads an internal memo issued by Mike VanderWel, the chief engineer at Boeing Commercial Airplane production engineering.
“It is metastasizing rapidly out of North Charleston and I just heard 777 (automated spar assembly tools) may have gone down,”
The executive was concerned about the impact of the infection on the equipment used to test airframes after they roll off the production line.
What about if the infection will spread to other systems?
VanderWel was scared by the possibility that the WannaCry ransomware could “spread to airplane software.”
Of course, this scenario seems not possible because the airplane software is no more connected to another network that could be hit by a malware. In the past, the in-flight entertainment systems were sharing the same network used by systems running airplane software making possible a cyber attack.
“We’ve done a final assessment,” said Linda Mills, the head of communications for Boeing Commercial Airplanes. “The vulnerability was limited to a few machines. We deployed software patches. There was no interruption to the 777 jet program or any of our programs.”
“It took some time for us to go to our South Carolina operations, bring in our entire IT team and make sure we had the facts,” she added.
On Wednesday afternoon, Mills provided further details on the WannaCry infection that hit the Boeing production plant:
“Our cybersecurity operations center detected a limited intrusion of malware that affected a small number of systems,” she said. “Remediations were applied and this is not a production and delivery issue.”
In May 2016, WannaCry ransomware infected systems in more than 150 countries worldwide relying upon the EternalBlue Windows exploit.
WannaCry exploits a Microsoft Windows SMB vulnerability using an exploit stolen from the NSA arsenal and leaked by the Shadow Brokers hackers.
WannaCry, such as other wipers and ransomware, represents a serious threat to a manufacturing environment.