Identifying your Internet exposed Centreon monitoring software

As cybercriminals are exploiting weaknesses in Centreon monitoring software and our customers may be at risk, we thought it would be a good idea to give some details on how to detect this software Internet exposure using our data. Let’s dive into different options for doing so.

Identifying Centreon patterns using the data field

The data field is a full-text search field. That means you can search using words or phrases within raw data responses from our application probes. This field is available in most of our different categories of information (see standard information categories and entreprise information categories). For this post, we will focus on the datascan category.

Centreon software has different patterns we can use to accurately identify it. We can use 2 different patterns for doing so:

category:datascan data:"<img src=\"img/centreon.png\" alt=\"Centreon Logo\" title=\"Centreon Logo\" />"
category:datascan data:"<a href=\"mailto:contact@centreon.com\">Centreon</a>"

If you use this query with our beta Web site, you will have such a result:

 

With this pattern, we identify 570 exposed devices. Using the second pattern, we identify 400 devices.

Another way is using app.http.title field

The app.http.title field is also a full-text search field. But we can use it to match against a complete phrase if we want to. This is the data you get in the title HTML tag:

category:datascan app.http.title:"Centreon - IT & Network Monitoring"

This time, we identify 601 devices. But as we have analyzed our data, we know that the “Centreon” string may differ as it may be customized. So let’s rewrite our search using less words like this:

category:datascan app.http.title:"IT & Network Monitoring"

612 devices are now found.

Using an OR query to combine them all

Now, that would be great to perform an OR query. It is, in fact, a new feature of our language currently in beta and only available on https://beta.onyphe.io. This is part of our advanced query language functions available to Lion View” and “Eagle View (unlimited)” subscriptions. The OR query is usable by preceding the wanted field by a question mark (? character).

The new language performs a search against datascan category by default, so you can skip the category:datascan part:

?app.http.title:"Centreon - IT & Network Monitoring" ?data:"<a href=\"mailto:contact@centreon.com\">Centreon</a>" ?data:"<img src=\"img/centreon.png\" alt=\"Centreon Logo\" title=\"Centreon Logo\" />"

Which gives us 623 results.

 

But there are more ways of finding them

Maybe these patterns are not enough as the patterns were not available at the time of scanning, for instance. So we can search against 2 more fields: url and host.

A standard way of exposing a software on a Web site is to give it a base URL with the name of the software you want to give access to. By using a wildcard query against the url field, you can find potentially more exposed devices:

-wildcard:url,*centreon*

More than 1,400 devices exposed.

When we perform DNS resolutions (forward and reverse), we split the fields into different other fields to make it easy to search using them. These fields are not subject to full-text searches, we can only use them in wildcard queries or exact match queries.

When we take a fully-qualified domain name (FQDN), we split it into the following new fields:

  • host: the hostname part
  • domain: the domain name
  • subdomains: one or more subdomains
  • tld: the top-level domain

Another standard practice is to name a computer based on its usage. For Centreon software, we could find exposed devices by using a host:centreon filter:

This yields us 2,276 devices.

Of course, you can combine all these filters and adding an orwildcard function to also match optionally against URLs:

?host:centreon -orwildcard:url,*centreon* ?app.http.title:"IT & Network Monitoring" ?data:"<a href=\"mailto:contact@centreon.com\">Centreon</a>" ?data:"<img src=\"img/centreon.png\" alt=\"Centreon Logo\" title=\"Centreon Logo\" />"

We have a grand final result of 3,653 exposed devices.

Identification of assets made even easier

Of course, as data patterns are now identified, we have added them to our identification patterns to make it easier to search for next times. That is, we have added the Centreon product to assets we identify using others specific fields: device.class and app.http.component.product.

We believe asset categorization is a must have on any Internet exposed devices scanner and we use the device.class field for doing so. Knowing you have “VPN Server” or “Monitoring” device classes exposed is something you should really pay attention to.

device.class:Monitoring app.http.component.product:Centreon

Conclusion

As we have seen, we have accurate data and many specific fields to make it easy for you to find your Internet exposed devices. We hope you won’t be the next to fall for an unpatched system. Subscribe to one of our offers and quickly dive into your exposed devices.

1,100 Oracle Weblogic servers vulnerable to CVE-2020-14882 can be easily compromised

Back in August 2020, we alerted that many global500 or fortune500 companies could be easily compromised by exploitation of known trivial vulnerabilities.

Now, we added a new check to our vulnscan category of information about an unauthenticated remote code execution on Oracle Weblogic servers. This vulnerability is named CVE-2020-14882. Here follows our test results.

 

  1. Searching for potentially vulnerable systems

The first thing we have to do before checking for vulnerable systems is to find potentially vulnerable systems. Fortunately, there is a specific filter to use to query ONYPHE in order to fetch this list:

category:datascan app.http.component.product:”Weblogic server” app.http.component.productvendor:”Oracle”

We found more than 14,000 exposed devices. But being exposed does not mean being exploitable. As we have developed our own non-intrusive check, we are able to verify in an innocuous way if they are vulnerable or not. Our checker just fetches Operating System and its version. Thus, we also have details about which kind of systems are used to host Weblogic servers.

As we don’t want to help cybercriminals and as there is already enough proof-of-concept codes available out there, we are not going to release our checker.

2. Count of vulnerable systems

By using a simple filter on our vulnscan category of information, we are able to know how many unique IP addresses are vulnerable, or how many unique domains and the count of unique fortune500/global500 companies. The filter is simply “cve:CVE-2020-14882“:

category:vulnscan cve:CVE-2020-14882

Beware, 2,000 is a misleading number as it does not return unique IP addresses result. Here are some screenshots from our back-end that allows to access the good numbers:

3. Operating System used to host Oracle Weblogic servers

As we fetch Operating System (OS) and their version information and set a specific field in our data, we are able to perform statistics based on these values:

top used operating systems

Linux is the most used OS with 76.2% followed by Windows Server 2012 R2 with 11.1% and Windows Server 2016 with 8.4%. Interestingly, we also find SunOS and AIX OSes, even though they are not wildly used at all.

4. Conclusion

More than 1,100 unique IP addresses are impacted, accounting for 231 unique domains and at least 5 unique big companies.

This check will be executed every week from now on, so we will have updated information available for our Eagle View customers.

Patches are available, so apply them as quickly as possible as this vulnerability may end up in the next NSA’s TOP25 most exploited vulnerabilities by cybercriminals.

Many global500 and fortune500 companies still vulnerable to known critical vulnerabilities

Since a few months now, cyber criminals are targeting vulnerabilities in VPN appliances from major brands to compromise and deploy ransomware on affected companies.

As we spoke about in a previous blog post, we are checking those vulnerabilities at Internet scale to help our customers find and fix their assets before the bad guys exploit them, eventually costing millions to recover.

In this blog post, we will introduce our new tagging capability which allows us the find all vulnerable global500 and fortune500 companies in a matter of an API query.

 

  1. Vulnerabilities we are able to detect

Today, we are checking 7 critical vulnerabilities. These vulnerabilities are exploitable remotely from the network with no user interaction and without any authentication required. They allow to perform remote code execution on affected targets and that is why cyber crooks love them.

Here is the list of CVE we are checking for:

Proportion of impacted devices by CVE

 

2. Introducing the fortune500 and global500 tags

Since August 22nd, we added lookup capabilities to our scanning engine. We have built a comprehensive inventory of fortune500 and global500 companies. Each time we receive an application response with a domain name set (example: adobe.com), we add tags when a match is found.

Searching using tag:global500 filter within category:vulnscan
Tag cloud for vulnerable companies

As you can see from the tag cloud, the most prevalent vulnerability found on big companies is the one impacting Cisco ASA (CVE-2020-3452). But what is worrying to us is the fact that some companies still have critical vulnerabilities on their Citrix Gateway, FortiNet FortiGate, SAP Netweaver Application Server or PulseSecure Pulse Connect Secure devices.

Also, you may note that no company is impacted by the #ghostcat or F5 Networks BIGIP vulnerabilities.

3. How many of these companies are impacted?

To count how many of them are vulnerable is not a direct and unique query. We can count either on the number of unique IP addresses or on the number of unique domains. However, a company can have multiple domains. According to our datasets, a correct guess is around 2 domains per company.

Furthermore, a company can use multiple device brands and thus may be counted multiple times when you do the math by counting on the below figures. So, from the following figures, simply divide by 2 to have an estimated guess of how many fortune500 and global500 companies are impacted for each vulnerability.

 

3.1. Cisco ASA devices

Around 180 companies impacted

3.2. SAP Netweaver Application Server

Around 30 companies impacted

3.3. Citrix Gateway

Around 8 companies impacted

3.4. PulseSecure Pulse Connect Secure

Around 3 companies impacted

3.5. Fortinet FortiGate

Only 1 company impacted

As our data shows, around 200 of the biggest companies are still impacted by critical known vulnerabilities with patches available. When you remove duplicates between fortune500 and global500, there is a total of 881 companies.

In the end, it is more than 20% of big companies which have known critical vulnerabilities, that is more than 1 company out of 5.

 

4. How to verify you are not impacted

Customers having an “Eagle View” subscription can check by themselves. This is the only subscription-level that allows querying the vulnscan category of information. Other Entreprise-level subscriptions do not give access to such data.

To avoid our online payment service to be exploited by malicious actors to fetch this sensitive information, we only sell Eagle Views after proper human interaction and validation that a true legitimate company lies behind the subscription request.

To check you are not vulnerable is as easy as running an API query against the current week if executed on Thursdays (scans are launched every Wednesdays) or querying against the previous week when executed on Mondays:

category:vulnscan -exists:cve domain:onyphe.io -weekago:0

Of course, you can also use the Alert API or script your queries using the Search API.

Conclusion

These vulnerabilities are massively exploited on the Internet. You don’t want to be the next big company falling for an unpatched VPN endpoint, losing millions, and losing your CEO job too. Contact us at sales[at]onyphe dot io for a demo.

Coronavirus pandemic – hospitals are targets for cyber criminals

Source: https://www.youtube.com/watch?v=8GsLEmZTgFo 

At ONYPHE, we are very concerned about cyber-criminals taking advantage of the current worldwide coronavirus crisis. At our scale, we want to give a hand to hospitals by giving them free information about vulnerabilities we have discovered on their Internet borders. We are willing to share this data with hospitals or any state agency that could deliver information to them. In fact, we already provided some data to a few of them. But it is far from enough in regards to our results.

We already know many hospitals were compromised, before the crisis or even now. Specific critical vulnerabilities were exploited and ransomware were deployed to extort those hospitals. We are checking those vulnerabilities too. Hospitals are already under pressure because they are (or will be) overwhelmed by sick people that need medication and care, they don’t need a cyber-security crisis added on top.

This blog post describes what we check, how we check, and which kind of information we currently have. We also describe what we need to cooperate with hospitals and state agencies. But make no mistake, cyber-criminals probably already have the same information at their disposal, so we must take quick action.

Critical vulnerabilities we are currently checking

This week, we worked on writing checking codes in order to detect, in a non-intrusive manner, critical vulnerabilities we know are exploited against hospitals worldwide. Those vulnerabilities are exploited to deploy ransomware. They may have names (or not), but in all cases, they are intrusive and you must fix them as soon as possible. Here is our current list:

We currently have 74,166 unique IP addresses vulnerable to one of these 4 critical vulnerabilities. Fortunately, they are not all hospitals.

Around 63% are about CVE-2020-1938, 20% about CVE-2018-13379, 14% about CVE-2019-19781 and finally 3% for CVE-2019-11510.

How do we check these vulnerabilities?

Exploit codes are available for all these critical vulnerabilities. We developed our own checking methodology based on that information. We verify the existence (or lack thereof) of these vulnerabilities by connecting to an innocuous URL and verifying the response. We are not relying solely on versions discovered by banner grabbing for these specific vulnerabilities.

What do we need from hospitals or state agencies?

If you are a hospital or a state agency in search for vulnerable hospitals in your country, we are willing to give you free information on impacted devices. To do so, what we need from you is the list of domain names or host names for your country’s hospitals. With this list, we are able to correlate with our vulnscan data to extract the needed information.

For instance, we did that for hospitals in some countries. We were provided a CSV file with a list of domain names. We won’t communicate any result or numbers because we don’t want to help cyber-criminals. We communicated our results to some state agencies and hospitals (we won’t communicate their name either). We hate saying that, but trust us, we have to take action.

How do we correlate data?

We feed our tool with a CSV file as input. Each line is the domain name or host name of an hospital. For instance:

cat hospital-domains.csv
domain
hospital1.com
hospital2.com

Then we simply launch our tool (publicy available, but you require an Eagle View subscription for querying) as the following to get full JSON information as output (example JSON output can be found in this blog post):

onyphe -export 'category:vulnscan -exists:cve -weekago:0 | whitelist hospital-domains.csv'

This query scrolls every information we have in vulnscan category of information with an existing CVE field for the current week results. Each week, we scan for described vulnerabilities on a list of potentially vulnerable devices we build by continuously scouting the Internet and applying pattern matching to identify devices and known brands.

For instance, we are able to list all Fortinet FortiGate products connected on the Internet by entering the following query:

category:datascan device.productvendor:Fortinet device.product:FortiGate

Note: this request requires en Entreprise subscription.

During the execution of this scrolled query, we apply the white listing by using values taken from the CSV file and comparing against each result we found. For each line in the CSV, the tool checks if the vulnerable entry has a field named “domain” and a corresponding value in the file.

Conclusion

We are willing to help. We do monitor the Internet to discover vulnerabilities and weaknesses so our customers can act before cyber-criminals exploit them.

We want to share freely this information with hospitals and state agencies worldwide. You may contact us by sending an email at contact at onyphe dot com so we can help you.

Analyzing Mirai-FBot infected devices found by MalwareMustDie

Following a blog post from MalwareMustDie (MMD) and some tweets related to an increase in Mirai-FBot detections, we decided to demonstrate the power of our new Bulk Summary API using data published on pastebin.

UPDATE-20200305: a new list of infected devices has been put online by MMD so we have updated the JSON file from Bulk queries against 1429 unique IP addresses resulting in around 17,000 entries from our data.

Get IP list of infected hosts from MMD’s pastebin

By using standard command line tools, we can fetch the list of IPs made freely available by MMD on their pastebin:

curl -XGET 'https://pastebin.com/raw/8n9G964c' |grep -v "Infected IP of the New FBot" | dos2unix > /tmp/fbot.txt

# How many results do we have?
wc -l /tmp/fbot.txt
582

Execute Bulk Summary API request for each IP address

Now that we have a list in the correct format (1 IP address per line), we can query using the Bulk Summary API to fetch last 10 entries we have for each category of information for every IP address in this list.

The goal will be to load that data into a local Elasticsearch database and perform some analytics to learn which kind of device is actually compromised.

curl -XPOST -H 'Authorization: apikey YOUR_API_KEY' -H 'Content-Type: application/json' --data-binary @/tmp/fbot.txt 'https://www.onyphe.io/api/v2/bulk/summary/ip' > /tmp/fbot.json

# How many results do we have?
wc -l /tmp/fbot.json
8227

Loading the data into Elasticsearch

You will have to install Elasticsearch and Kibana. You can follow our training guide you can find on GitHub to easily install them. Or if you are lazy enough to not click and follow our guide, here is how to do it:

wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.6.0-linux-x86_64.tar.gz 
wget https://artifacts.elastic.co/downloads/kibana/kibana-7.6.0-linux-x86_64.tar.gz 
wget https://artifacts.elastic.co/downloads/logstash/logstash-7.6.0.tar.gz
tar zxvf elasticsearch-7.6.0-linux-x86_64.tar.gz 
./elasticsearch-7.6.0/bin/elasticsearch
tar zxvf kibana-7.6.0-linux-x86_64.tar.gz
./kibana-7.6.0-linux-x86_64/bin/kibana
tar zxvf logstash-7.6.0.tar.gz

Once they are installed, you can load JSON data by using Logstash. Just create the configuration file named load.conf as follows:

# We use plain codec then json filter to avoid json code adding its host field
# as we are using host field in ONYPHE data.
input {
  stdin {
    codec => plain { charset => "UTF-8" }
  }
}

filter {
  json {
    source => "message" 
  }
  mutate {
    remove_field => [ "message" ] 
  }
}

output {
  elasticsearch {
    hosts => [ "http://localhost:9200" ]
    index => "fbot"
  }
}

And you can load the data:

cat /tmp/fbot.json | ./logstash-7.6.0/bin/logstash -f load.conf

Preparing Kibana

Before you can play with the data you just loaded, you have to create the Kibana index pattern. First, launch your Web browser and connect to http://localhost:5601/ then follow these steps:

Click on “settings” application at the bottom of left menu (application menu):

Click on “Index Patterns” menu:

Click on “Create index pattern”:

Enter “fbot” as the pattern name and click “Next step”:

Select “@timestamp” as the timestamp field and click on “Create index pattern”. You’re set.

 

Ready to analyze

One of the first question one may ask is: which kind of device is compromised? We have all heard about Internet of Things (IoT), but is it the case for this botnet?

Let’s first search with the device.class filter in datascan category of information. We will create a wonderful Pie Chart visualization with the top 10 device.class. To make it better for our demonstration, we will put appart the generic devices (like Web Server, Telnet Server and all other kind of servers).

To do so, create a Pie Chart like this:

Click on “Visualize” application in the application menu:

Then click on “Create new visualization”:

Chose “fbot” index as the source. Select the last 30 days timerange, as our Bulk export covers that timerange (actually, range is between 2nd of february and 2nd of march). And write the following filter:

@category:datascan AND NOT device.class:*Server

Now, we want the top 10 device classes. So click “Add” to create buckets based on different values of device.class field:

Chose the “Terms” aggregation and the device.class.keyword field. Also set to 5 the size of your top visualization:

To refine things, also chose to display “Unique Count” of ip.keyword field:

Click the “Play” button, and you should have the wonderful following Pie Chart:

 

 

And the top 5 infected IoT devices are:

  • Android (~ 53%)
  • TV Box (~ 18%)
  • Camera (~17%)
  • Router (~11%)
  • NAS (~1%)

Conclusion

As you have seen, it is easy to analyze data using Elasticsearch+Kibana and our brand new Bulk Summary API. Of course, we have other wonderful APIs as documented on our Web site.

Another question could be: how those devices were infected? And we are sur you have many other questions. Furthermore, as you have seen, we just analyzed the value of one field within the datascan category of information. What can be found in other categories of information?

As we love our community, we decided to release for free the data we spoke about in this blog post. Download it, play with it, and let us know about your findings 🙂

Find your exposed Microsoft RDP services

CVE-2019-0708 exploits an unauthenticated remote code execution vulnerability in Microsoft RDP service. As the patch is out, you should apply it as quickly as possible before bad guys start to exploit it.

But what if you don’t know where are your servers to patch?

Most companies have hard time locating and keeping an inventory of all their assets. Especially those exposed on the Internet. Another cause is the explosion of shadow IT or shadow cloud. In this blog post, we will describe how to locate them by querying our data.

Identify your network blocks

If you are a mature company, you probably already have a list of all your subnets (being your own datacenters or some possibly outsourced). That’s great. But what if you don’t?

You could use our inetnum category of data to first build your list of subnets you will be able to use afterwards to search for open RDP services. The subnet field is the way to go for such a use case. Another possibility, if you are a big company, is to get the list of your own AS numbers by listing asn field values.

Some requests you can enter in our search engine (or via our API) to achieve this goal:

category:inetnum netname:"your netname"
category:inetnum organization:"your organization"
category:inetnum domain:your_domain.com
category:inetnum asn:ASyour_number
category:inetnum ip:some_of_your_ips

Note: search filters are only available when you have access to the Search API. These APIs are available starting from “Dragonfly View” [1].

As a customer of our solution, you could also use the new (currently BETA) function called -wildcard:

category:inetnum -wildcard:netname,*your_organization*
category:inetnum -wildcard:organization,*your_organization*

What will most interest you is the value of the field subnet. By listing all of them, you will be able to go to the next step to find open RDP services.

Note: search functions are only available for “Entreprise Views” [1]. The -wildcard function searches only on the previous day of results by default. To search from older times, use the -dayago function like: -dayago:4 to search 4 days ago.

Sample result for inetnum category:

Search by using the synscan category of information

While performing SYN scans over the full IPv4 address space, we also perform reliable remote Operating System (OS) identification. You may base your following searches on such data to identify open ports 3389/tcp with Windows OS running on your subnets as identified during the previous step.

category:synscan ip:93.184.216.0/24 os:Windows port:3389
category:synscan asn:ASyour_number os:Windows port:3389
category:synscan organization:"your organization" os:Windows port:3389

Note: the CIDR search (like the Search API, which allows the use of these search filters) is available only starting from the “Dragonfly View” as described at [1].

Note2: values are case sensitive in all searches, so be sure to write Windows with a capital W and not windows. That would yeld no result.

Sample result for synscan category:

Search by using the datascan category of information

The previous method will eventually return matches, but the best way is to leverage the datascan category. synscan entries don’t have information about the application layer, while datascan entries do. In fact, we are identifying the application layer protocol and you can perform searches directly using the protocol field:

category:datascan protocol:rdp ip:93.184.216.0/24 os:Windows
category:datascan protocol:rdp asn:ASyour_number os:Windows
category:datascan protocol:rdp organization:"your organization" os:Windows

Note: we may have some results for RDP services not listening on usual port 3389/tcp thanks to that protocol identification.

Now that you have a complete list of all your subnets and AS numbers, you can refine the search to discover your Internet exposed assets.

Search using DNS resolution enrichments within the datascan category of information

As we perform numerous DNS resolutions to enrich our data, you may also search your exposed assets by querying related fields like:

  • domain: the domain name with only one “.” character;
  • subdomains: one of your subdomains, those with multiple “.” characters;
  • hostname: the fully qualified domain name;
  • reverse: or use the reverse fully qualified domain name.
category:datascan protocol:rdp domain:your_domain.com
category:datascan protocol:rdp subdomains:sub.your_domain.com
category:datascan protocol:rdp hostname:www.sub.your_domain.com
category:datascan protocol:rdp reverse:ptr.your_domain.com

Sample result:

The admin tag

And if you want to put such kind of surveillance into practice, you may also directly use tag:admin filter. It will match for any remote admin protocols used to perform administrative tasks like RDP, SSH or telnet (list not complete).

And sometimes, administrative interfaces are vulnerable to some CVEs…

Sample result:

Conclusion

As the CVE-2019-0708 is claimed to be wormable, we urge our customers to perform described searches. If you are not yet a customer, take a look at our pricing page [1] and don’t hesitate to contact us at sales[at]onyphe.io for any enquiry.

[1] https://www.onyphe.io/pricing/