Dec
01
2020
--

Ivanti has acquired security firms MobileIron and Pulse Secure

IT security software company Ivanti has acquired two security companies: enterprise mobile security firm MobileIron, and corporate virtual network provider Pulse Secure.

In a statement on Tuesday, Ivanti said it bought MobileIron for $872 million in stock, with 91% of the shareholders voting in favor of the deal; and acquired Pulse Secure from its parent company Siris Capital Group, but did not disclose the buying price.

The deals have now closed.

Ivanti was founded in 2017 after Clearlake Capital, which owned Heat Software, bought Landesk from private equity firm Thoma Bravo, and merged the two companies to form Ivanti. The combined company, headquartered in Salt Lake City, focuses largely on enterprise IT security, including endpoint, asset, and supply chain management. Since its founding, Ivanti went on to acquire several other companies, including U.K.-based Concorde Solutions and RES Software.

If MobileIron and Pulse Secure seem familiar, both companies have faced their fair share of headlines this year after hackers began exploiting vulnerabilities found in their technologies.

Just last month, the U.K. government’s National Cyber Security Center published an alert that warned of a remotely executable bug in MobileIron, patched in June, allowing hackers to break into enterprise networks. U.S. Homeland Security’s cybersecurity advisory unit CISA said that the bug was being actively used by advanced persistent threat (APT) groups, typically associated with state-backed hackers.

Meanwhile, CISA also warned that Pulse Secure was one of several corporate VPN providers with vulnerabilities that have since become a favorite among hackers, particularly ransomware actors, who abuse the bugs to gain access to a network and deploy the file-encrypting ransomware.

Sep
02
2020
--

A SonicWall cloud bug exposed corporate networks to hackers

A newly discovered bug in a cloud system used to manage SonicWall firewalls could have allowed hackers to break into thousands of corporate networks.

Enterprise firewalls and virtual private network appliances are vital gatekeepers tasked with protecting corporate networks from hackers and cyberattacks while still letting in employees working from home during the pandemic. Even though most offices are empty, hackers frequently look for bugs in critical network gear in order to break into company networks to steal data or plant malware.

Vangelis Stykas, a researcher at security firm Pen Test Partners, found the new bug in SonicWall’s Global Management System (GMS), a web app that lets IT departments remotely configure their SonicWall devices across the network.

But the bug, if exploited, meant any existing user with access to SonicWall’s GMS could create a user account with access to any other company’s network without permission.

From there, the newly created account could remotely manage the SonicWall gear of that company.

In a blog post shared with TechCrunch, Stykas said there were two barriers to entry. Firstly, a would-be attacker would need an existing SonicWall GMS user account. The easiest way — and what Stykas did to independently test the bug — was to buy a SonicWall device.

The second issue was that the would-be attacker would also need to guess a unique seven-digit number associated with another company’s network. But Stykas said that this number appeared to be sequential and could be easily enumerated, one after the other.

Once inside a company’s network, the attacker could deliver ransomware directly to the internal systems of their victims, an increasingly popular tactic for financially driven hackers.

SonicWall confirmed the bug is now fixed. But Stykas criticized the company for taking more than two weeks to patch the vulnerability, which he described as “trivial” to exploit.

“Even car alarm vendors have fixed similar issues inside three days of us reporting,” he wrote.

A SonicWall spokesperson defended the decision to subject the fix to a “full” quality check before it was rolled out, and said it is “not aware” of any exploitation of the vulnerability.

Jan
18
2017
--

Elasticsearch Ransomware: Open Source Database Security Part 2

Elasticsearch Ransomware

Elasticsearch RansomwareIn this blog post, we’ll look at a new Elasticsearch ransomware outbreak and what you can do to prevent it happening to you.

Mere weeks after reports of MongoDB servers getting hacked and infected with ransomware, Elasticsearch clusters are experiencing the same difficulties. David Murphy’s blog discussed the situation and the solution for MongoDB servers. In this blog post, we look at how you can prevent ransomware attacks on your Elasticsearch clusters.

First off, what is Elasticsearch? Elasticsearch is an open source distributed index based on Apache Lucene. It provides a full-text search with an HTTP API, using schemaless JSON documents. By its nature, it is also distributed and redundant. Companies use Elasticsearch with logging via the ELK stack and data-gathering software, to assist with data analytics and visualizations. It is also used to back search functionality in a number of popular apps and web services.

In this new scenario, the ransomware completed wiped away the cluster data, and replaced it with the following warning index:

“SEND 0.2 BTC TO THIS WALLET: 1DAsGY4Kt1a4LCTPMH5vm5PqX32eZmot4r IF YOU WANT RECOVER YOUR DATABASE! SEND TO THIS EMAIL YOUR SERVER IP AFTER SENDING THE BITCOINS.”

As with the MongoDB situation, this isn’t a flaw in the Elasticsearch software. This vulnerability stems from not correctly using the security settings provided by Elasticsearch. As the PCWorld article sums up:

According to experts, there is no reason to expose Elasticsearch clusters to the internet. In response to these recent attacks, search technologies and distributed systems architect Itamar Syn-Hershko has published a blog post with recommendations for securing Elasticsearch deployments.

The blog post they reference has excellent advice and examples of how to protect your Elasticsearch installations from exploitation. To summarize its advice (from the post itself):

Whatever you do, never expose your cluster nodes to the web directly.

So how do you prevent hackers from getting into your Elasticsearch cluster? Using the advice from Syn-Hershko’s blog, here are some bullet points for shoring up your Elasticsearch security:

  • HTTP-enabled nodes should only listen to private IPs. You can configure what IPs Elasticsearch listens to: localhost, private IPs, public IPs or several of these options.
    network.bind_host

     and 

    network.host

     control the IP types (manual). Never set Elasticsearch to listen to a public IP or a publicly accessible DNS name.

  • Use proxies to communicate with clients. You should pass any application queries to Elasticsearch through some sort of software that can filter requests, perform audit-logging and password-protect the data. Your client-side javascript shouldn’t talk to Elastic directly, and should only communicate with your server-side software. That software can translate all client-side requests to Elasticsearch DSL, execute the query, and then send the response in a format the clients expect.
  • Don’t use default ports. Once again for clarity: DON’T USE DEFAULT PORTS. You can easily change Elasticsearch’s default ports by modifying the .YML file. The relevant parameters are
    http.port

     and

    transport.tcp.port

     (manual).

  • Disable HTTP if you don’t need it. Only Elasticsearch client nodes should enable HTTP, and your private network applications should be the only ones with access to them. You can completely disable the HTTP module by setting
    http.enabled

     to

    false

     (manual).

  • Secure publicly available client nodes. You should protect your Elasticsearch client and any UI it communicates with (such as Kibana and Kopf) behind a VPN. If you choose to allow some nodes access to the public network, use HTTPS and don’t transmit data and credentials as plain-text. You can use plugins like Elastic’s Shield or SearchGuard to secure your cluster.
  • Disable scripting (pre-5.x). Malicious scripts can hack clusters via the Search API. Earlier versions of Elasticscript allowed unsecured scripts to access the software. If you are using an older version (pre-5.x), upgrade to a newer version or disable dynamic scripting completely.

Go to Syn-Hershko’s blog for more details.

This should get you started on correctly protecting yourself against Elasticsearch ransomware (and other security threats). If you want to have someone review your security, please contact us.

Powered by WordPress | Theme: Aeros 2.0 by TheBuckmaker.com