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.

May
04
2020
--

Decrypted: Chegg’s third time unlucky, Okta’s new CSO, Rapid7 beefs up cloud security

Ransomware is getting sneakier and smarter.

The latest example comes from ExecuPharm, a little-known but major outsourced pharmaceutical company that confirmed it was hit by a new type of ransomware last month. The incursion not only encrypted the company’s network and files, hackers also exfiltrated vast amounts of data from the network. The company was handed a two-for-one threat: pay the ransom and get your files back or don’t pay and the hackers will post the files to the internet.

This new tactic is shifting how organizations think of ransomware attacks: it’s no longer just a data-recovery mission; it’s also now a data breach. Now companies are torn between taking the FBI’s advice of not paying the ransom or the fear their intellectual property (or other sensitive internal files) are published online.

Because millions are now working from home, the surface area for attackers to get in is far greater than it was, making the threat of ransomware higher than ever before.

That’s just one of the stories from the week. Here’s what else you need to know.


THE BIG PICTURE

Chegg hacked for the third time in three years

Education giant Chegg confirmed its third data breach in as many years. The latest break-in affected past and present staff after a hacker made off with 700 names and Social Security numbers. It’s a drop in the ocean when compared to the 40 million records stolen in 2018 and an undisclosed number of passwords taken in a breach at Thinkful, which Chegg had just acquired in 2019.

Those 700 names account for about half of its 1,400 full-time employees, per a filing with the Securities and Exchange Commission. But Chegg’s refusal to disclose further details about the breach — beyond a state-mandated notice to the California attorney general’s office — makes it tough to know exactly went wrong this time.

Sep
05
2017
--

Revenge of Ransomware! MongoDB Security in the News Again . . .

MongoDB Security

MongoDB SecurityA new set of MongoDB attacks and data breaches struck businesses this weekend, mirroring the attacks that hit back in January and putting MongoDB security back into the spotlight.

Like the last set, this new attack strategy focused on ransomware that demanded a paid ransom to unlock hijacked data. As with many security breaches, the attack was preventable – if you correctly configured your MongoDB databases to prevent security vulnerabilities.

From the ZDNet article above:

“So these attackers simply scan the entire IPv4 internet for a MongoDB running on port 271017,” Gevers told ZDNet. “When they detect these, they then simply try to get access to it with a script that automatically deletes the database and creates a similar one with only one record holding the ransom note.

“The databases that get hacked were running with default settings and were completely exposed to the internet.”

If you rely on databases to run your business, you need to guarantee database security and performance. Your administrators must protect you from situations like the one mentioned above.

Ultimately, database security comes down to two things: identifying core areas of MongoDB security and knowing exactly what to monitor. For MongoDB to work as expected, you need to correctly setup up your databases and monitor them regularly.

Percona experts have addressed many of these issues already on our blog and in our webinars. Here are some links to existing resources that can help you secure your MongoDB databases, and prevent security disasters:

Jul
18
2017
--

Corelight closes $9.2M Series A to help enterprises battle ransomware

 It’s already been a year of multiple high profile ransomware attacks and now cybersecurity startup Corelight has bagged a $9.2 million Series A round, led by Accel Partners. Read More

May
15
2017
--

Top six tips to help avoid ransomware

Binary field with Ransomware in the middle of it. Here are some amazing tips to help you and those you love (and the National Health Service) avoid ransomware. Read More

Feb
27
2017
--

MySQL Ransomware: Open Source Database Security Part 3

MySQL Ransomware

MySQL RansomwareThis blog post examines the recent MySQL® ransomware attacks, and what open source database security best practices could have prevented them.

Unless you’ve been living under a rock, you know that there has been an uptick in ransomware for MongoDB and Elasticsearch deployments. Recently, we’re seeing the same for MySQL.

Let’s look and see if this is MySQL’s fault.

Other Ransomware Targets

Let’s briefly touch on how Elasticsearch and MongoDB became easy targets…

Elasticsearch

Elasticsearch® does not implement any access control: neither authentication nor authorization. For this, you need to deploy the Elastic’s shield offering. As such, if you have an Elasticsearch deployment that is addressable from the Internet, you’re asking for trouble. We see many deployments have some authentication around their access, such as HTTP Basic Auth – though sadly, some don’t employ authentication or network isolation. We already wrote a blog about this here.

MongoDB

MongoDB (< 2.6.0) does allow for access control through account creation. It binds to

0.0.0.0

 by default (allowing access from anywhere). This is now changed in /etc/mongod.conf in versions >= 2.6.0. Often administrators don’t realize or don’t know to look for this. (Using MongoDB? My colleague David Murphy wrote a post on this issue here).

We began to see incidents where both Elasticsearch and MongoDB had their datasets removed and replaced with a

README/note

 instructing the user to pay a ransom of 0.2BTC (Bitcoin) to the specified wallet address (if they wanted their data back).

MySQL

So is this latest (and similar) attack on MySQL MySQL’s fault? We don’t think so. MySQL and Percona Server® for MySQL by default do not accept authentication from everywhere without a password for the 

root

 user.

Let’s go over the various security options MySQL has, and describe some other best practices in order to protect your environment.

Default

bind_address=127.0.0.1

 in Percona Server for MySQL

MySQL currently still binds to

0.0.0.0

 (listen to all network interfaces) by default. However, Percona Server for MySQL and Percona XtraDB Cluster have different defaults, and only bind on

127.0.0.1:3306

 in its default configuration (Github pull request).

Recall, if you will, CVE-2012-2122. This ALONE should be enough to ensure that you as the administrator use best practices, and ONLY allow access to the MySQL service from known good sources. Do not setup root level or equivalent access from any host (

%

 indicates any host is allowed). Ideally, you should only allow root access from

127.0.0.1

 – or if you must, from a subset of a secured network (e.g., 

10.10.0.%

 would only allow access to

10.10.0.0/24

).

Prevent Access

Also, does the MySQL database really need a publicly accessible IP address? If you do have a valid reason for this, then you should firewall port 3306 and whitelist access only from hosts that need to access the database directly. You can easily use 

iptables

 for this.

Default Users

MySQL DOES NOT by default create accounts that can be exploited for access. This comes later through an administrator’s lack of understanding, sadly. More often than not, the grant will look something like the following.

GRANT ALL PRIVILEGES TO 'root'@'%' IDENTIFIED BY '123456' WITH GRANT OPTION;

You may scoff at the above (and rightly so). However, don’t discount this just yet: “123456” was the MOST USED password in 2016! So it’s reasonable to assume that somewhere out there this is a reality.

Max Connection Errors

You can deploy max_connection_errors with a suitably low value to help mitigate a direct attack. This will not prevent a distributed attack, where many thousands of hosts are used. Network isolation is the only way to ensure your mitigation against this attack vector.

MySQL 5.7 Improvements on Security

Default Root Password

Since MySQL 5.7, a random password is generated for the only root user (

root@localhost

) when you install MySQL for the first time. That password is then written in the error log and has to be changed. Miguel Ángel blogged about this before.

Connection Control Plugin

MySQL 5.7.17 introduced a new open source plugin called Connection Control. When enabled, it delays the authentication of users that failed to login by default more than three times. This is also part as of Percona Server for MySQL 5.7.17.

Here’s an example where the 4th consecutive try caused a one-second delay (default settings were used):

$ time mysql -u bleh2 -pbleh
ERROR 1045 (28000): Access denied for user 'bleh2'@'localhost' (using password: YES)
real	0m0.009s
$ time mysql -u bleh2 -pbleh
ERROR 1045 (28000): Access denied for user 'bleh2'@'localhost' (using password: YES)
real	0m0.008s
$ time mysql -u bleh2 -pbleh
ERROR 1045 (28000): Access denied for user 'bleh2'@'localhost' (using password: YES)
real	0m0.008s
$ time mysql -u bleh2 -pbleh
ERROR 1045 (28000): Access denied for user 'bleh2'@'localhost' (using password: YES)
real	0m1.008s
mysql> SELECT * FROM INFORMATION_SCHEMA.CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS;
+---------------------+-----------------+
| USERHOST            | FAILED_ATTEMPTS |
+---------------------+-----------------+
| 'bleh2'@'localhost' |               4 |
+---------------------+-----------------+
1 row in set (0.01 sec)

Password Validation Plugin

MySQL 5.6.6 and later versions also ship with a password validation plugin, which prevents creating users with unsafe passwords (such as 

123456

) by ensuring passwords meet certain criteria: https://dev.mysql.com/doc/refman/5.7/en/validate-password-plugin.html

Summary

In order to get stung, one must ignore the best practices mentioned above (which in today’s world, should take some effort). These best practices include:

  1. Don’t use a publicly accessible IP address with no firewall configured
  2. Don’t use a 
    root@%

     account, or other equally privileged access account, with poor MySQL isolation

  3. Don’t configure those privileged users with a weak password, allowing for brute force attacks against the MySQL service

Hopefully, these are helpful security tips for MySQL users. Comment below!

Feb
13
2017
--

Researchers simulate a ransomware attack on industrial controls

Aerial shot of wastewater treatment facility in Houston, Texas (Photo: Getty Images/Jupiterimages/Photolibrary) Researchers at the Georgia Institute of Technology have created a form of ransomware that can hit us where it really counts: the water supply. Their program installed itself in a model water plant and allowed the researchers to change chlorine levels, shut down water valves, and send false readings to monitoring systems.
“We are expecting ransomware to go one step farther, beyond the… Read More

Feb
07
2017
--

Druva’s latest feature helps protect data stored on its service from ransomware

Binary field with Ransomware in the middle of it. Over the years, Druva has developed services for protecting and managing data and tools for governance and compliance. Today, it took that idea one step further when it added ransomware and anomaly detection. The company decided to develop a ransomware detection tool after finding that customers were using Druva to help manage the ransomware recovery process. Restoring data has always been… Read More

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