Singapore Invites Cyberattacks to Strengthen Defenses

Hundreds of hackers have targeted Singapore’s defence ministry –- but the attacks were at the government’s invitation in an unusual attempt to strengthen cybersecurity.

Authorities said Wednesday they had paid out US$14,750 in prize money to the best of the 264 so-called “white hat” hackers — specialists who seek to break into networks to check for vulnerabilities — involved in the project.

Learn More at SecurityWeek’s Singapore ICS Cyber Security Conference

The program, which ran from mid-January to early February, was introduced after an embarrassing breach last year which saw hackers steal personal data from about 850 military servicemen and other employees from a defence ministry web portal.

It was run with cybersecurity network HackerOne, which specializes in coordinating “bug bounty programs” in which hackers are rewarded for spotting weaknesses in computer systems.

The top hacker in the contest was a Cyber Security Manager from Ernst and Young Singapore who gave his name only as Darrel and goes by the online moniker “Shivadagger”. He was awarded US$5,000.

A total of 97 vulnerability reports were submitted from 34 participants during the program, with 35 reports deemed valid, according to the defence ministry.

David Koh, the defence ministry’s cybersecurity chief, hailed the project. “Our systems are now more secure,” he said.

While Singapore has some of the most advanced weaponry in the region, Koh said the ministry was at increasing risk of being targeted, and attackers could range from high-school students in their basements to criminals and state-actors.

Related: Pentagon Hacked in New U.S. Air Force Bug Bounty Program

Learn More at SecurityWeek’s Singapore ICS Cyber Security Conference

view counter

© AFP 2018

Previous Columns by AFP:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/Ai6NAH8g5LQ/singapore-invites-cyberattacks-strengthen-defenses




Automated Compliance Testing Tool Accelerates DevSecOps

Chef Software’s InSpec 2.0 Compliance Automation Tool Helps Organizations Maintain an Up-to-Date View of Compliance Status

Software developers are urged to include security throughout the development cycle. This requires testing for compliance with both house rules and regulatory requirements before an application is released. Compliance testing is difficult, time-consuming and often subject to human error.

A January survey by Seattle-based software automation firm Chef Software shows that 74% of development teams assess for software compliance issues manually, and half of them remediate manually. Chef further claims that 59% of organizations do not assess for compliance until the code is running in production, and 58% of organizations need days to remediate issues.

Now Chef has released InSpec version 2.0 of its compliance automation technology. InSpec evolved from technology acquired with the purchase of German startup company VulcanoSec in 2015. The latest version improves performance and adds new routines. Chef claims it offers 90% Windows performance gains (30% on Linux/Unix) over InSpec 1.0. New in version 2.0 is the ability to verify AWS and Azure policies (with the potential to eliminate accidental public access to sensitive data in S3 buckets); and more than 30 new built-in resources.

The S3 bucket compliance problem is an example of InSpec’s purpose. Earlier this month, two separate exposed databases were discovered in AWS S3 buckets. Last week, FedEx was added to the growing list, with (according to researchers) a database of “more than 119 thousands of scanned documents of US and international citizens, such as passports, driving licenses, security IDs etc.”

In each case — and the many more examples disclosed during 2017 — the cause was simple: the databases were set for public access. The potential regulatory compliance effects, however, are complex. Just the EU General Data Protection Regulation (GDPR, coming into effect in May 2018) would have left FedEx liable to a fine of up to 4% of its global revenue if any of the ‘international citizens’ were citizens of the EU. FedEx revenue for 2017 is approximately $60 billion.

In all cases the cause was most likely simple human error. But this discloses a bigger problem within secure and compliant software development: it involves multiple stakeholders with different priorities and, to a degree, different languages of expression. “Compliance requirements are often specified by high level compliance officers in high level ambiguous Word documents,” explains Julian Dunn, Chef’s director of product marketing. 

“But at the implementation level you have the DevOps folks who are in charge of the systems — but they don’t understand ambiguous Word documents. What they understand is code, computer systems and the applications. There’s a failure to communicate because everyone uses different tools to do so — and that just slows down the process.”

InSpec 2.0 can verify AWS and Azure policies (with the potential to eliminate public access to sensitive data in S3 buckets); and more than 30 new built-in resources. It provides a simple easy-to-understand code-like method of defining compliance requirements. These requirements are then regularly checked against the company’s infrastructure, both cloud and on-prem. A few lines of this code language would solve the S3 bucket exposure problem: “it { should have_mfa_enabled }” and “it { should_not have_access_key }”.

Another example could be a database that compliance requires has access controls. For a Red Hat Linux system, the InSpec code would include, “control “ensure_selinux_installed” do”, and “it { should be_installed }”.

InSpec then regularly checks the infrastructure and detects whether anything is not compliant or has slipped out of compliance with the specified rules. It is part of the InSpec cycle that Chef describes as ‘detect, correct, automate’. Detection provides visibility into current compliance status to satisfy audits and drive decision-making; correction is the remediation of issues to improve performance and security; and automation allows for faster application deployment and continuous code risk management.

“We help the customer in the automate phase with pre-defined profiles around the common regulatory requirements,” explains Dunn. “But InSpec is fundamentally a generic toolkit for expressing rules and positive and negative outcomes from those rules — so it deals with everything from soft compliance (rules of the house) all the way through to GDPR, PCI, SOX and so on.”

But there is a further benefit. Software development has embraced the concept of DevOps to avoid siloed software development and deployment. Increasing security compliance regulations are now driving the concept of DevSecOps, to bring the security team into the mix. InSpec automatically involves security and compliance with the code development process — a fully-functioning DevSecOps environment able to improve rather than inhibit the agility of software development is an automatic byproduct of InSpec 2.0.

Related: What Security Teams Need to Know about DevOps  

Related: Where DevOps Could Be Increasing The Attack Surface

view counter

Kevin Townsend is a Senior Contributor at SecurityWeek. He has been writing about high tech issues since before the birth of Microsoft. For the last 15 years he has specialized in information security; and has had many thousands of articles published in dozens of different magazines – from The Times and the Financial Times to current and long-gone computer magazines.

Previous Columns by Kevin Townsend:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/bF3X__9hqcM/automated-compliance-testing-tool-accelerates-devsecops




uTorrent bugs let websites control your computer and steal your downloads

Enlarge / A screenshot of one of the uTorrent PoC exploits in action.

Two versions of uTorrent, one of the Internet’s most widely used BitTorrent apps, are vulnerable to a host of easy-to-exploit vulnerabilities that allow attackers to execute code, access downloaded files, and snoop on download histories, a Google Project Zero researcher said. uTorrent developers are in the process of rolling out fixes for both the uTorrent desktop app for Windows and the newer uTorrent Web product.

The vulnerabilities, according to Project Zero, make it possible for any website a user visits to control key functions in both the uTorrent desktop app for Windows and in uTorrent Web, an alternative to desktop BitTorrent apps that uses a web interface and is controlled by a browser. The biggest threat is posed by malicious sites that could exploit the flaw to download malicious code into the Windows startup folder, where it will be automatically run the next time the computer boots up. Any site a user visits can also access downloaded files and browse download histories.

In an e-mail sent late Tuesday afternoon, Dave Rees, VP of Engineering at BitTorrent, the developer of the uTorrent apps, said the flaw has been fixed in a beta release of the uTorrent Windows desktop app, but has not yet been delivered to users who already have the production version of the app installed. The fixed version, uTorrent/BitTorrent 3.5.3.44352, is available here for download and will be automatically pushed out to users in the coming days. In a separate e-mail sent Tuesday evening, Rees said uTorrent Web had also been patched. “We highly encourage all uTorrent Web customers to update to the latest available build 0.12.0.502 available on our website and also via the in-application update notification,” he wrote.

Earlier Tuesday, Project Zero researcher Tavis Ormandy warned the flaws remained unfixed in uTorrent Web. Rees’s later e-mail indicated that’s no longer the case.

Ormandy’s proof-of-concept exploits include this one for uTorrent Web and this one and this one for uTorrent desktop. They use a technique known as domain name system rebinding to make an untrusted Internet domain resolve to the local IP address of the computer running a vulnerable uTorrent app. Ormandy’s exploit then funnels malicious commands through the domain to get them to execute on the computer. Last month, the researcher demonstrated similar critical vulnerabilities in the Transmission BitTorrent app.

Neither Ormandy nor Rees included any mitigation advice for vulnerable uTorrent versions. People who have either the uTorrent desktop app for Windows or uTorrent Web installed should promptly stop using them until updating to a version that fixes these critical vulnerabilities.

https://arstechnica.com/?p=1263289




Tesla cloud resources are hacked to run cryptocurrency-mining malware

Add Tesla to the legion of organizations that have been infected by cryptocurrency-mining malware.

In a report published Tuesday, researchers at security firm RedLock said hackers accessed one of Tesla’s Amazon cloud accounts and used it to run currency-mining software. The researchers said the breach in many ways resembled compromises suffered by Gemalto, the world’s biggest SIM card maker, and multinational insurance company Aviva. In October, RedLock said Amazon and Microsoft cloud accounts for both companies were breached to run currency-mining malware after hackers found access credentials that weren’t properly secured.

The initial point of entry for the Tesla cloud breach, Tuesday’s report said, was an unsecured administrative console for Kubernetes, an open source package used by companies to deploy and manage large numbers of cloud-based applications and resources.

“The hackers had infiltrated Tesla’s Kubernetes console which was not password protected,” RedLock researchers wrote. “Within one Kubernetes pod, access credentials were exposed to Tesla’s AWS environment which contained an Amazon S3 (Amazon Simple Storage Service) bucket that had sensitive data such as telemetry.”

Well concealed

The attackers hid the malware behind an IP address hosted by security firm Cloudflare. They also configured the mining software to use a non-standard port to reach the Internet and to connect to an unlisted or semi-public endpoint rather than well-known mining pools. The attackers also likely ratcheted down the amount of CPU resources used to mine the digital coin. The measures helped to make the illicit mining harder to detect and lower the chances of it being shut down.

Besides allowing attackers to run the mining malware, RedLock said the breach also exposed certain non-public Tesla data, including sensitive telemetry information related to Tesla cars. RedLock said it reported the breach to Tesla, and the systems were quickly disinfected.

In an email, a Tesla representative wrote: “We maintain a bug bounty program to encourage this type of research, and we addressed this vulnerability within hours of learning about it. The impact seems to be limited to internally-used engineering test cars only, and our initial investigation found no indication that customer privacy or vehicle safety or security was compromised in any way.”

The breach involving Tesla is only the latest example of companies that should know better than failing to properly secure their cloud accounts. Besides the Amazon and Microsoft Azure breaches of Gemalto and Aviva accounts, researchers recently found a mountain of sensitive Federal Express customer data exposed on a publicly accessible Amazon storage site, where it had remained available to anyone, possibly for years. Researchers are also reporting that cryptocurrency malware is rendering some companies unable to operate.https://arstechnica.com/?p=1263027




Apple Fixes Indian Character Crash Bug in iOS, macOS

Updates released by Apple on Monday for iOS, macOS, tvOS and watchOS patch a flaw that causes applications to crash when rendering specific strings of Indian characters.

Someone noticed recently that displaying a string written in India’s Telugu language (జ్ఞ‌ా) caused many apps on iOS and macOS to crash. The list of impacted apps includes Twitter, Firefox, Chrome, Safari, WhatsApp, Mail, Thunderbird, Instagram, Slack and others.

Apple became aware of the issue after news of the bug started to spread on social media networks and trolls and pranksters started exploiting it. One individual apparently showed how he could crash the Uber app on drivers’ phones by setting his name to the problematic string and requesting a ride.

SecurityWeek can confirm that conducting a search for the string in any web browser on macOS causes the applications to immediately crash. Attempting to send or receive an email using Mail or Thunderbird has the same effect.

Firefox crashes on macOS when displaying Indian characters

While initially only a certain Telugu string appeared to work, some later noticed that a specific string using characters of India’s Bengali language also caused apps on iOS and macOS to crash. There are several theories on what may be causing the crash, including from Mozilla research engineer Manish Goregaokar and Philippe Verdy of the Unicode Consortium.

Apple tracks the vulnerability as CVE-2018-4124 and describes it as a heap corruption triggered when processing a maliciously crafted string. “A memory corruption issue was addressed through improved input validation,” Apple said.

The company patched the flaw on Monday with the release of macOS High Sierra 10.13.3 Supplemental Update, iOS 11.2.6, watchOS 4.2.3 and tvOS 11.2.6. watchOS and tvOS are affected due to the fact that they are based on iOS. The latest operating system updates don’t fix any other vulnerabilities.

Related: Apple Working on Patch for New Year’s Eve macOS Flaw

Related: Apple Patches Critical Root Access Flaw in macOS

Related: Apple Patches Meltdown Flaw in Older Versions of macOS

view counter

Eduard Kovacs is a contributing editor at SecurityWeek. He worked as a high school IT teacher for two years before starting a career in journalism as Softpedia’s security news reporter. Eduard holds a bachelor’s degree in industrial informatics and a master’s degree in computer techniques applied in electrical engineering.

Previous Columns by Eduard Kovacs:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/daVZkuz0PIk/apple-fixes-indian-character-crash-bug-ios-macos




Several Vulnerabilities Patched in RubyGems

An update released last week for RubyGems includes several security improvements and patches for various types of vulnerabilities.

RubyGems 2.7.6 patches path traversal vulnerabilities that exist when writing to a symlinked basedir outside of the root and during gem installation. It also fixes a cross-site scripting (XSS) vulnerability in the homepage attribute when displayed via gem server, and a possible unsafe object deserialization flaw.

This was not the only deserialization issue patched recently in RubyGems. Back in October, developers informed users that an unsafe deserialization vulnerability could have been exploited for remote code execution.

The latest version of RubyGems also includes some security improvements, such as triggering a security error when a package contains duplicate files, enforcing URL validation on the spec homepage attribute, and strictly interpreting octal fields in tar headers.

Yasin Soliman, nmalkin and plover have each been credited for two of the vulnerabilities patched in RubyGems 2.7.6.

A total of five security holes were patched in RubyGems last year. The deserialization issue, tracked as CVE-2017-0903, and an ANSI escape sequence vulnerability identified as CVE-2017-0899 were the only ones rated “high severity” based on their CVSS score.

Other vulnerabilities fixed last year included a DNS request hijacking issue, a denial-of-service (DoS) flaw, and a weakness that could have been exploited by malicious gems to overwrite arbitrary files.

Five vulnerabilities were also patched last year in Ruby itself, including command injection and memory corruption issues.

Related: Critical Vulnerabilities Patched in Apache CouchDB

Related: Researchers Uncover Critical RubyGems Vulnerabilities

Related: GitHub Warns Developers When Using Vulnerable Libraries

view counter

Eduard Kovacs is a contributing editor at SecurityWeek. He worked as a high school IT teacher for two years before starting a career in journalism as Softpedia’s security news reporter. Eduard holds a bachelor’s degree in industrial informatics and a master’s degree in computer techniques applied in electrical engineering.

Previous Columns by Eduard Kovacs:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/5DCd9uHBA5o/several-vulnerabilities-patched-rubygems




NIST Working on Global IoT Cybersecurity Standards

NIST is Working Towards International Cybersecurity Standards for the Internet of Things With Draft Interagency Report (NISTIR) 8200

The Internet of Things (IoT) is here and growing. It has the potential to facilitate or obstruct the further evolution of the Fourth Industrial Revolution; largely depending upon whether it is used or abused. Its abusers will be the same criminal and aggressor state actors that currently abuse information systems. But while there are standards and frameworks for defending information networks against aggressors, there are no adequate international standards for securing the internet of things.

In April 2017, the Interagency International Cybersecurity Standardization Working Group (IICS WG) — established by the National Security Council’s Cyber Interagency Policy Committee (NSC Cyber IPC) — set up an Internet of Things (IoT) Task Group to determine the current state of international cybersecurity standards development for IoT.

NIST has now published the draft NISTIR document: The Status of International Cybersecurity Standardization for IoT. It is intended to assist the member agencies of the IICS WG Task Group “in their standards planning and to help to coordinate U.S. government participation in international cybersecurity standardization for IoT.” NIST is seeking feedback, especially on the information about the state of cybersecurity standardization for IoT, at [email protected] by April 18.

The scope of securing the IoT is a mammoth task. To aid the understanding of this scope, NIST describes the IoT in five separate functional areas: connected vehicles; consumer IoT; health and medical devices; smart buildings, and smart manufacturing (including ICS). There are nuanced differences between securing these functional areas and traditional cyber security. While security has traditionally prioritized confidentiality, integrity and availability (CIA) in that order of priority, for the most part ‘availability’ is the priority for IoT devices.

Consumer IoT is one area that may be different, with the traditional need for confidentiality (as in privacy) still dominant. Patient privacy is also a consideration for medical devices. But, “In addition to data privacy and patient safety”, comments Jun Du, Senior Director and Architect at ZingBox, “we must also put a heavy focus on ensuring uninterrupted service of medical devices. A cyber-attack can bring down the entire hospital by disrupting their service delivery, putting patient lives at risk.”

This is the fundamental difference between traditional information security and IoT security — it is closer to OT than to IT. “The objectives of confidentiality, integrity and availability altogether focus on information security rather than IoT security,” adds Du. “When it comes to IoT security, availability of the device is more relevant to business operations than just the security of information. We should focus on availability first, then look at confidentiality and integrity.”

Even in consumer IoT, there is an operational element. Many of the threat vectors are similar between IoT and information networks, but the effects of a successful attack could be more dramatic.

The biggest problem for IoT devices, comments Drew Koenig, security solutions architect at Magenic, “are IoT devices that limit or prevent updating and patching. That’s the killer; a zero day — and the only solution is to replace your fridge before someone hacks it and floods your kitchen.”

That metaphor traverses NIST’s five IoT functional areas: crashed cars, flooded kitchens and locked doors, malfunctioning heart pace makers, stuck elevators and power failures, and failing production lines.

To get the IICS WG Task Group started in its work to discover the current state of international IoT standardization, the NISTIR 8200 compiles a table of potentially relevant existing standards separated into eleven core cybersecurity areas. These areas range from cryptographic techniques and cyber incident management, through IAM and network security, to supply chain risk management to system security engineering.

Each one of these core cybersecurity areas will present its own IoT-specific difficulties. For example, Du comments, “While encryption is a highly recommended security trend, it isn’t without its drawbacks. Encryption can hide valuable details needed by various teams including security researchers, incident response teams, and security vendors in addition to hiding them from hackers. Insider threats may also attempt to leverage end-to-end encryption to evade detection. In order to protect against these risks, IoT vendors should provide limited visibility through exportation of logs, session stats and meta data information.”

A wide range of existing and potentially relevant standards are mapped against these core areas, providing links to the standard, the standard developing organization (SDO), and a description of the standard. It becomes the raw material for a gap analysis between existing and necessary standards. Such an analysis is also provided, mapping standards to the core areas across the five functions. Only ‘cryptographic techniques’ https://www.securityweek.com/review-nist-crypto-standards-and-developmen… and ‘IAM’ have available standards applicable to four of the five categories; but always with the rider that there is slow uptake of these standards. 

The fifth and missing category is medical IoT, which fares worst of all the five categories for existing applicable standards. However, the two core areas of ‘IT system security evaluation’ and ‘network security’ have no available standards applicable to any of the five IoT categories. In reality, the entire gap analysis makes depressing viewing: there are no core areas that have standards adequately adopted in any of the five IoT categories. Even where there are standards, uptake is slow.

Missing from this draft document is any standard that requires the ability for firmware updates within the IoT device build. This may be because there is no existing standard that attempts this. Where ‘patching’ is mentioned in the draft NISTIR document, it is solely for patch management, or remediation where patching is not possible.

“This document is a good start,” comments Koenig. The reality, however, is that it will be a long time before any serious benefit comes from the work. He sees two areas of primary concern. The first is a lack of regulation. NIST doesn’t regulate the private sector, although its recommendations can be required for the public sector. Even if this work eventually leads to IoT standards recommendations, it will require separate legislation to enforce the recommendations across the private sector. That still won’t necessarily address the manufacture of overseas-sourced devices, or the assembly of devices with multiple foreign components.

Without regulation over device manufacture and development, Koenig’s second big concern comes into play: “IoT devices that limit or prevent updating and patching. That’s the killer,” he says.

But even with regulation controlling the manufacture of IoT devices, that still won’t necessarily solve the problems. Steve Lentz, CSO and director information security at Samsung Research America has always believed that security teams need to do their own ‘due diligence’ on products and processes, and not rely on what they are told by vendors. He suspects that standards and regulations “will bring out vendors claiming to provide IoT security. Again, this is where security teams need to do their due diligence and really check/test out these claims,” he warns. “IoT is also Wi-Fi which is now everywhere. We need to ensure complete work infrastructure is secure just not the traditional network defenses.

“We need to ensure we thoroughly research solutions that fit our environments,” he continued. “The government can give oversight and make recommendations, but we need to find the solution that works best for us.”

Related: Improved IoT Security Starts with Liability for Companies, Not Just Legislation 

Related: New Legislation Could Force Security Into IoT 

Related: When It Comes to IoT Security, Consistency Is Key

Related: IoT Security Foundation Launches 

Related: IoT Security: Where There is Smoke, There is Fire 

view counter

Kevin Townsend is a Senior Contributor at SecurityWeek. He has been writing about high tech issues since before the birth of Microsoft. For the last 15 years he has specialized in information security; and has had many thousands of articles published in dozens of different magazines – from The Times and the Financial Times to current and long-gone computer magazines.

Previous Columns by Kevin Townsend:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/uoXzAF43Nz8/nist-working-global-iot-cybersecurity-standards




Oracle WebLogic Server Flaw Exploited to Deliver Crypto-Miners

Threat actors are exploiting a recently patched vulnerability in Oracle WebLogic Server to infect systems with crypto-currency mining malware, FireEye reports. 

Identified as CVE-2017-10271, the vulnerability resides in the WebLogic Server Security Service (WLS Security) in Oracle WebLogic Server versions 12.2.1.2.0 and older, and was addressed by Oracle it its October 2017 Critical Patch Update (CPU).

After proof-of-concept code exploiting the bug was made public in December, activity associated with the exploitation of this vulnerability increased in volume, FireEye’s researchers say. Successful exploitation of the flaw on unpatched systems allows attackers to remotely execute arbitrary code. 

“We saw evidence of organizations located in various countries – including the United States, Australia, Hong Kong, United Kingdom, India, Malaysia, and Spain, as well as those from nearly every industry vertical – being impacted by this activity,” FireEye reported. 

The crypto-currency market boomed recently, and cybercriminals have not been shy in their attempts to take advantage of the market. However, actors involved in crypto-currency mining operations don’t normally target specific organizations, but rather launch attacks that are opportunistic in nature. 

Attackers abusing CVE-2017-10271 to infect targeted systems with crypto-miners used various tactics to achieve their purpose, the researchers discovered. Some of the incidents, for example, used PowerShell to drop the miner directly onto the victim’s system and leveraged ShellExecute() for execution. 

In other attacks, PowerShell scripts were used to deliver the miner, instead of downloading the executable directly. In addition to downloading the miner, the script would also attempt to achieve persistence through scheduled tasks. 

The script would delete the tasks created by other crypto-miners and would kill processes associated with those programs, in addition to being able to connect to mining pools with wallet key. It would also limit CPU usage to avoid suspicion. 

Tactics employed in other attacks also involved the use of tools such as Mimikatz and EternalBlue for lateral movement across Windows environments. 

The malware would first determine whether the system is 32-bit or 64-bit, to fetch a specific PowerShell script from the command and control (C&C) server. Next, it checks all network adapters and attempts to connect to every system in the network using extracted credentials, to run a PowerShell to drop and run the malware on the targeted system. 

The malware uses WMI (Windows Management Instrumentation) for persistence and can perform a Pass-the-Hash attack using NTLM information derived from Mimikatz, to download and execute the malware on remote machines. It sends the stolen credentials to a remote server using an HTTP GET request. 

If it fails moving laterally, the malware uses the PingCastle MS17-010 scanner to determine whether the target is vulnerable to EternalBlue. 

In scenarios targeting Linux machines, the vulnerability would be exploited to deliver shell scripts that include functionality similar to that of PowerShell scripts. They would attempt to kill already running crypto-miners and then download and execute the malware, in addition to creating a cron job to maintain persistence. 

“Use of cryptocurrency mining malware is a popular tactic leveraged by financially-motivated cyber criminals to make money from victims. We’ve observed one threat actor mining around 1 XMR/day, demonstrating the potential profitability and reason behind the recent rise in such attacks,” FireEye says. 

Although they might be seen as less risky when compared to ransomware operations, crypto-currency mining malware does pose a variety of risks. Systems infected with crypto-miners might experience slowed performance, but such operations could also be hiding additional malware. 

Related: Crypto Mining Malware Infects Thousands of Websites

Related: Crypto-Mining Attack Targets Web Servers Globally

view counter

Ionut Arghire is an international correspondent for SecurityWeek.

Previous Columns by Ionut Arghire:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/p8If0EPj7eQ/oracle-weblogic-server-flaw-exploited-deliver-crypto-miners




BGP Flaws Patched in Quagga Routing Software

Several vulnerabilities that could lead to denial-of-service (DoS), information disclosure, and remote code execution have been patched this week in the Quagga routing software suite.

Quagga implements the Open Shortest Path First (OSPF), Routing Information Protocol (RIP), Border Gateway Protocol (BGP) and Intermediate System to Intermediate System (IS-IS) protocols for Unix-like platforms, particularly Linux, Solaris, FreeBSD and NetBSD.

Quagga developers and the CERT Coordination Center (CERT/CC) at Carnegie Mellon University announced this week that Quagga 1.2.3 patches several vulnerabilities affecting the BGP daemon (bpgd).

One of the more serious flaws, rated critical by CERT/CC based on its CVSS score, is CVE-2018-5379, a double-free memory corruption issue related to the processing of certain UPDATE messages containing cluster-list or unknown attributes.

“This issue can be triggered by an optional/transitive UPDATE attribute, that all conforming eBGP speakers should pass along. This means this may triggerable in many affected Quagga bgpd processes across a wide area of a network, because of just one UPDATE message,” Quagga developers explained. “This issue could result in a crash of bgpd, or even allow a remote attacker to gain control of an affected bgpd process.”

Another vulnerability, CVE-2018-5381, can be exploited to cause bgpd to enter an infinite loop and stop responding until it’s restarted. “BGP sessions will drop and not be reestablished,” developers said.

Quagga 1.2.3 also patches CVE-2018-5378, a security hole that can lead to sensitive data from the bgpd process being sent over the network to a configured peer. This can also cause the bgpd process to crash.

The last vulnerability patched by the latest Quagga release is CVE-2018-5378, which developers say has “very low” impact.

Linux distributions, including Ubuntu, Debian and Red Hat, have started publishing advisories describing these vulnerabilities. Regarding CVE-2018-5379, Red Hat said “Glibc’s heap protection mitigations render this issue more difficult to exploit, though bypasses may still be possible.”

Related: Google Finds Flaws in Dnsmasq Network Services Tool

Related: Many Vulnerabilities Found in Linux USB Subsystem

Related: Two-Year Old Vulnerability Patched in Linux Kernel

view counter

Eduard Kovacs is a contributing editor at SecurityWeek. He worked as a high school IT teacher for two years before starting a career in journalism as Softpedia’s security news reporter. Eduard holds a bachelor’s degree in industrial informatics and a master’s degree in computer techniques applied in electrical engineering.

Previous Columns by Eduard Kovacs:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/O1nWeJDyJv0/bgp-flaws-patched-quagga-routing-software




‘DoubleDoor’ IoT Botnet Uses Two Backdoor Exploits

A newly discovered Internet of Things (IoT) botnet is using two exploits to ensure it can not only bypass authentication on targeted devices, but also render additional protections useless, NewSky Security has discovered. 

Dubbed DoubleDoor, the botnet allows attackers to takeover devices even if the user has authentication enabled and has added a firewall for additional protection. Specifically, the malware abuses CVE-2015–7755, a Juniper Networks SmartScreen OS exploit, and CVE-2016–10401, a Zyxel modem backdoor exploit (also abused by the Hide ‘N Seek botnet).

What NewSky Security discovered was that the botnet first deploys the infamous Juniper Networks exploit, which essentially allows it to get past firewall authentication. The backdoor was initially discovered in the ScreenOS software running on NetScreen firewalls. 

Through this backdoor, the telnet and SSH daemons of Netscreen firewalls become accessible with the hardcoded password <<< %s(un=’%s’) = %u  and any username, regardless of whether a valid one or not. In the initial attack cycle of DoubleDoor, the attack was implemented using the username “netscreen,” NewSky’s researchers say. 

Next, the botnet attempts to deploy the backdoor for ZyXEL PK5001Z devices, which is pretty straight forward as well, using a hardcoded su password as zyad5001. This is a privilege escalation exploit, and the botnet’s operators were also observed performing a “password based attack to get a basic privilege account like admin:CenturyL1nk before going for the superuser,” the researchers say. 

The DoubleDoor botnet was also observed performing reconnaissance to ensure the attack was successful and control of the IoT device was achieved. 

“DoubleDoor botnet takes care of this, by using a randomized string in every attack. Lack of any standard string will make sure it is not very easy to classify the recon activity as malicious. The strings have one thing in common though, they are always 8 in length,” the security researchers note. 

The botnet is currently in a nascent phase, with attacks observed only between Jan. 18 and Jan. 27, 2018. Most of the attacks were observed originating from South Korean IPs. The botnet’s attacks are expected to remain low, mainly because they are only effective if the victim runs a specific unpatched version of Juniper ScreenOS firewall and uses unpatched Zyxel modems. 

“Double layer of IoT protection is more common in corporate environments, which don’t rely on built-in IoT authentication and like to protect it with another layer of firewall. Although such corporate devices can be lesser in number, getting control of corporate environment routers can be more valuable for an attacker as it can lead to targeted IoT attacks,” the researchers say. 

Related: Backdoor in Juniper Firewalls Enables Remote Access

view counter

Ionut Arghire is an international correspondent for SecurityWeek.

Previous Columns by Ionut Arghire:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/-uEUMJd41SI/doubledoor-iot-botnet-uses-two-backdoor-exploits