Featured

Why we won’t scan /0 for log4shell issue

Apache log4j logging system is affected by a critical issue impacting billions of devices or software stacks. That issue is described as CVE-2021-44228. After careful considerations, ONYPHE has decided not to scan the full IPv4 address space for this vulnerability. Here is our communication to explain our position.

UPDATE: 2021-12-15: added more dorks to detect other impacted products, scroll to the end of this blog post for the list.

On blind HTTP scanning with billions of requests

There are some technical issues surrounding scanning for this vulnerability at scale. The first one is the number of requests required to check all potentially affected assets. According to our data, there are currently more than 183M+ services responding to HTTP requests, and that’s only for direct IP scanning (without using a virtual host HTTP header). By counting the number of unique domains known to our solution, we could add 160M+ domain names. To check to the maximum extent possible, we would have to send 2 requests for domain names: one with HTTP (port 80/tcp) and another one with HTTPS (port 443/tcp). In the end, this is 500M+ requests to send. By considering there are currently roughly 400M+ domain names registered, we should end up sending 1B+ requests. That’s not sustainable in a reasonable amount of time, and that is only by considering the HTTP protocol (other protocols are impacted as well).
Added to that, different applications will have a different path to exploitation, as we have to send the check to the correct target field (for instance, a login field, as the field has to be logged by the library to be exploitable). This 1B+ requests could end up being in the multi billion level. By not correctly checking for that issue, we could simply fail to effectively check for the existence or absence of this issue and finally give a false sense of patching, being totally counter productive. The gain for our customers is questionable.
Another aspect is the load implied with such scanning for cyber defense. Today, most companies have deployed methods to detect exploitation attempts. Sending billions of requests would generated a huge amount of alerts, putting unneeded pressure on cyber defense teams, and they don’t need that extra hassle now. We want to contribute in a positive way to the infosec ecosystem, not in a negative one.

Large scale vulnerability scanning considerations

We have always put forward our ethical way of doing active Internet scanning by using fixed IP addresses for all our scanners, publishing this list, setting a reverse DNS pointing to probe.onyphe.net domain name and answering all abuse requests by blocklisting networks when requested by legitimate owners. We want to be identified so as to let network owners know our intent, and give them tools to opt-out in the simplest way for them. Furthermore, by sending billions of requests, we will receive a huge amount of abuse requests, we will put pressure on cyber defense teams, and we will eventually have our scanners blocked by many entities, including our customers. That’s not a good thing to do neither for us, nor for our customers.
We have our ethical checklist considerations to decide when to include a test in our vulnscan category of information. We have created a simple checklist to help us decide, in a repeatable way, when to include (or not include) a check for a specific vulnerability. Our checklist is currently as follows:
  1. Targeted checking: potentially vulnerable assets are tested, we don’t want to engage in the blind checking approach;
  2. Innocuous tests: we don’t want to take the risk to crash or impact targets;
  3. Least intrusive possible: usually checking by just connecting to a specific URL and analyzing HTTP response body;
  4. Critical vulnerabilities: those exploited by cyber criminals to make profits.
The log4shell issue doesn’t meet point 1. However, specific product testing methods may pass our checklist and we could, in the future, write specific tests.

What we could do regarding that issue

With time, a more targeted list of products will emerge, with specific exploitation details. For instance, we know VMware vCenter (and some other VMware products) are impacted by this issue. That is more sustainable to only check these identified products as it then results in targeted checking, increasing the balance benefit/risk for our customers and the infosec ecosystem at large. As a security researcher pointed out:
Let’s wait patiently for real unauthenticated RCEs targeting specific products.”
— Felix Aimé.
The best resource currently available to identify impacted products is the list from SwitHak researcher available at the following link:
Another great resource is the one from NCSC NL:
We will update this blog post with ONYPHE dorks to allow our customers to identify their potentially impacted products. Once they have this list for their perimeter, they will be able to check the issue by themselves. That’s what we consider, today, the best way forward with this critical vulnerability that needs remediation as soon as possible.

Don’t hesitate to contact us at support[at]onyphe dot com should you have any question or suggestion regarding this matter.

 

ONYPHE dorks

VMware products:
category:datascan ?productvendor:vmware ?app.http.component.productvendor:vmware ?device.productvendor:vmware

Cisco products:

category:datascan ?productvendor:cisco ?app.http.component.productvendor:cisco ?device.productvendor:cisco

Apache products:

category:datascan ?productvendor:apache ?app.http.component.productvendor:apache ?device.productvendor:apache

Apache solr:

category:datascan app.http.component.product:solr

James SMTP server:

category:datascan data:"JAMES SMTP Server"

Redhat OpenShift:

category:datascan app.http.component.product:openshift

Oracle Java:

category:datascan app.http.component.product:java

SonicWall email security:

category:datascan ?productvendor:sonicwall ?app.http.component.productvendor:sonicwall ?device.productvendor:sonicwall protocol:smtp

Zimbra Collaboration Suite:

category:datascan ?productvendor:zimbra ?app.http.component.productvendor:zimbra ?device.productvendor:zimbra

Grafana:

category:datascan app.http.component.product:grafana

Mobile Iron:

category:datascan app.http.component.productvendor:mobileiron

VMware Horizon View:

category:datascan app.http.component.product:"horizon view"

Featured

Finding exposed OWA servers vulnerable to proxyshell

A new set of critical vulnerabilities popped-up at this year’s BlackHat edition regarding Microsoft Exchange exploitable via Outlook Web Access. This set of vulnerabilities has been dubbed #proxyshell (aka CVE-2021-34473). GossiTheDog has made available an Nmap script to test for this issue. We have added our own check based on his tool so our customers can detect its existence (or absence) against their own perimeters. But how to find its own perimeter? Let’s dig into that.

 

Identifying datacenters for a given company

If you are a company having its own datacenter(s), this is for you. We do collect whois information into our category:whois dataset. The goal here is to list all subnets belonging to your datacenter(s), then switching to category:vulnscan to identify vulnerable assets.

You can query category:whois in multiple ways: based on netname, organization, full-text search with data field, or, even simpler, starting from a domain name:

category:whois domain:uber.com

For this article, we will only show the first result. We have multiple patterns here which we can use to continue listing all subnets belonging to Uber’s datacenters. The following pivot points can be used: domain (as we already have seen), netname or organization. The ultimate goal is to build a full list of subnet distinct values.

By enumerating all subnet values from the filter domain:uber.com, we already have a few subnets (around 20 according to our data). You can also enumerate different values for the organization field. We have at least two distinct values:

category:whois organization:"Uber Inc"
category:whois organization:"Uber Technologies, Inc"

We can do the same with the netname field. Some sample queries:

category:whois netname:"UBERINC-CN"
category:whois netname:"UTPRODUCTION"

The rational to enumerating different subnets from these different fields is that we may find netnames or organizations bound to Uber but not bound to their domain name. You may also use wildcards to search for matching strings:

category:whois -wildcard:netname,*UBER*
category:whois -wildcard:netname,UT*
category:whois -wildcard:organization,*uber*

And for full-text search:

category:whois data:uber

Once you have built your complete list of subnets, you can switch to category:vulnscan and use an OR query to fetch results to all subnets belonging to targeted organization. Please note that with such wildcards, you may need to filter results a little bit as you may end up finding subnets belonging to some other companies.

Identifying proxyshell vulnerability and all other critical ones

We are currently testing for 13 critical vulnerabilities. No real need to know all of them, you simply have to know how to use the -exists function to check if you are impacted by one of them:

category:vulnscan -exists:cve ?ip:SUBNET1 ?ip:SUBNET2 ?ip:SUBNET3 ?domain:YOURDOMAIN.COM

But if you want to know specifically for proxyshell, just use the tag:proxyshell filter:

category:vulnscan tag:proxyshell ?ip:SUBNET1 ?ip:SUBNET2 ?ip:SUBNET3

And that’s it.

Conclusion

As our data shows, it is easy to enumerate datacenters for a given company. Once you have built this asset inventory, we can just use it in an OR query and add additional filters to identify specific issues.

Another possibility is to use our CLI tool which supports correlation. This one-liner achieves the same goal as we have described at the start of this post:

onyphe -export 'category:whois ?domain:uber.com -orwildcard:netname,UBERINC-* -orwildcard:organization,"Uber *" | uniq subnet | search category:vulnscan ip:$subnet -fields:ip,port,forward,domain,cve,tag -exists:cve'

And no, we don’t have any critical vulnerability using this query for Uber datacenters.

And as for statistics related to proxyshell vulnerability more specifically, maybe you want to know how many potential victims there are. Out of around 240,000 scanned Microsoft Exchange servers, we identified more than 36,000 vulnerable unique IP addresses accounting for more than 48,000 unique domains. 16 unique companies means there are 16 Fortune500, Global500 or CAC40 companies impacted by this issue.

 

 

Featured

ONYPHE vs Shodan dorks – part 1

We stumbled upon an article written by ESTEBAN BORGES from SecurityTrails. This article shows how to query our main competitor Shodan with a TOP40 of best search requests. We thought it was a good start to perform some form of benchmarking by showing how you can achieve the same results, in even better and easier ways in order to find the most relevant information in your own context. Let’s dig into this TOP40 dorks by comparing Shodan results against ONYPHE results.

1. ONYPHE capabilities

We scan the full IPv4 Internet for roughly 200 ports on a monthly basis. Our goal is not only to identify assets with high precision, but also to give our customers the capability to find devices that belong to their organization in an easy and convenient way. Our approach is to first perform a cartography by starting from a domain name and pivoting around different values (or filters) that show clear ownership to a given organization.

For instance, when you have a domain name like example.com (filter domain:example.com), you may found some new fields belonging the subject organization from an X.509 certificate. Thus, we just pivot on this new value (filter subject.organization:”Bitnami”) to find more assets linked to the given domain. Also, when a device is hosting more than one domain name, you can pivot on these new domains and create your organization’s owned domain list.

Also, we don’t just gather raw application responses, we do perform device identification. Our goal is to directly give the classification of the device: be it a VPN server, a database, or any of the other 60 device classifications we have in room. For instance, to get access to all exposed databases simply execute the filter device.class:database. Let’s show some examples based on the TOP40 dorks from SecurityTrails.

 

2. Free View vs Dragonfly View vs Entreprise Views

With Free View, you won’t be able to use search filters. You can just paste some strings or IP addresses and you will get a subset of available results we have within our search engine.

With Dragonfly View, you will have access to search filters, but not to device classification or tags. Dragonfly View is a good start if you want to test some of the dorks we will describe in this blog post.

With Entreprise Views, you have access to all filters and all information categories.

That’s a short comparison of our three licensing models, you will have more details at the pricing page.

 

3. Databases

SecurityTrails article shows some way to find databases exposed on the Internet with or without authentication. That’s an excellent start to demonstrate our capabilities.

The first dork searches for open MongoDB instances with no authentication activated with Shodan:

"MongoDB Server Information" port:27017 -authentication

With ONYPHE and an Entreprise license, you can achieve the same objective without knowing the raw application response format, and, even better, without knowing the well-known port behind MongoDB. In fact, our solution performs protocol identification from the ground up. Of course, listening ports can be customized, but not really application responses. Here is the ONYPHE version of the previous query:

protocol:mongo tag:open

With a Dragonfly View, you will only be able to search with the protocol filter part, which is kind of a good start.

We see that we have identified 8,116 open MongoDB instances vs 8,409 from our competitor. Please also note that we have other tags in red in the screenshot, for instance the fact that the database has been compromised and a ransomware note has been deployed.

Other interesting fields are the one with “Company pivot(s)” and “Analytic pivot(s)”  sections. That’s where the magic happen: if you identify a pattern giving clear evidence the value is bound to a given organization, you can just pivot on that value and find other exposed devices for your target.

But this search is too limitative to us. The author wanted to find open databases exposed on the Internet. MongoDB is one if this kind, but there are also Elasticsearch, Kibana, Redis, Memcached, CouchDB and many others.

All of these applications are classified as databases within our solution. Just use the following filter to identify all of them:

device.class:database tag:open -monthago:1

 

This time, we identified nearly 48,000 open databases for last month data. Yes, because we do also have historical records for the last 7 months.

But you could also search by raw application responses if you are that kind. For instance, the following dork:

"Set-Cookie: mongo-express=" "200 OK"

Can be taken right away and pasted within our search engine:

"Set-Cookie: mongo-express=" "200 OK"

For MySQL & PostgreSQL related databases, simply search with a protocol filter:

protocol:mysql
protocol:pgsql

To search for Elasticsearch databases with their list of indices:

app.http.component.product:elasticsearch -exists:summary

The summary field contains a subset of raw application responses: just the most important patterns. You can search the summary field like the data field, that is by using keywords like any full-text search engine. Example to identify private information:

device.class:database summary:private

That’s some easy ways to search databases, right?

 

4. Exposed ports

As we said at the start of this article, we are currently scanning for roughly 200 ports on a per month basis. Of course, you can search by port if you will. But we strongly encourage you to adopt the described by protocol approach instead. SSH is not always on port 22.

The first query shown in SecurityTrails article is to search for exposed ProFTPD products. We also identify products, whatever the port they listen to. The following search:

proftpd port:21

Becomes:

product:proftpd protocol:ftp

It appears the author wanted to search for anonymous accesses using the following search:

"220" "230 Login successful." port:21

Well, we do have a specific protocol filter for such kind of searches:

app.ftp.anonymous:true

That’s a nice comparison: our competitor has found 93,204 anonymous FTP servers while we found 443,501.

Now you probably got the point what is the difference between our competitor and our search engine. We want to simplify analysts work by giving them directly the information they need, and to get that, they don’t have to know which strings they want to search for.

So, the following dorks:

openssh port:22
port:"23"
port:"25" product:"exim"
port:"11211" product:"Memcached"

Become:

product:openssh protocol:ssh
protocol:telnet
protocol:smtp product:exim
product:memcached

Simple as that. Don’t bother with port numbers anymore.

As for the last Jenkins dork:

"X-Jenkins" "Set-Cookie: JSESSIONID" http.title:"Dashboard"

You can perform the following search with ONYPHE:

"X-Jenkins" "Set-Cookie: JSESSIONID" app.http.title:"Dashboard"

Notice the change between http.title vs app.http.title with our solution. You could also have searched with the following filter to avoid putting your own strings in the search:

app.http.component.product:jenkins app.http.title:"Dashboard"

Which yields even more results than the first query from our solution: 1,727 vs 2,779.

Conclusion

We are done with this first part from a few articles related to benchmarking our solution versus our competitor Shodan. We showed how easy it is to find open databases for a given organization thanks to our domain filter.

Our goal is simply to always have a domain filter related to data we gather to make it easy to map a target Internet exposure.

In next parts, we will continue this benchmark to see where it leads us to. We are sure you will like it as much as this part 🙂 we take the time here to thank SecurityTrails as they allow us to, to our best extent possible, make an impartial comparison to our major competitor.

Interested in our solution? Just send us an email to contact_at_onyphe_dot_com if you want a demo.

 

Featured

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.

Featured

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.

Featured

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.

Featured

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.

Featured

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 🙂

Newsletter 2020#1 – APIv2, new pricing and new Web search features

Dear customers and free users,

it is with great pleasure that we announce the general availability of APIv2, a new pricing and new Web search features allowing better and easier navigation with just a mouse click to go deeper into data we collect.

1. APIv2 main changes

We have reviewed completely our APIs. We updated older APIs to make them easier to understand and added many more APIs which are now split into different categories as follows:

  • Simple API
  • Summary API
  • Alert API
  • Bulk API
  • Export API

Simple and Summary APIs are available starting from Free View. Alert API is available starting from Dragonfly View, and Bulk and Export starting from Entreprise Views.

Be aware that Summary APIs are querying multiple categories of information. From now on, using these APIs may cost more than just 1 credit as they may return up to 100 results (so they may consume up to 10 credits). Other APIs continue to consume only 1 credit. But wait, we have changed our pricing for the better as you will see.

For the most complete API (the Search API), just pass in a query string using the OQL (ONYPHE Query Language) and you simply get your results. Search API is available starting from Dragonfly View. For instance, to search within new information category vulnscan (vulnscan category available only starting from Eagle View):

https://www.onyphe.io/api/v2/search/category:vulnscan%20cve:CVE-2019-19871?k=YOUR_API_KEY

This is the exact same syntax as in the Web search engine, so you now just have to copy/paste your Web query into your API query.

The Bulk API allows to execute Summary queries on a batch of IP, domain or hostname. It returns results in raw JSON format. More on that in a next post.

The Export API allows to execute a Search query and return all results in a streaming manner in raw JSON format. Again, more on that in a next post.

Documentation is not ready yet on how to use those APIs, but it will come very soon. We will update you as soon as it is available. In the meantime, APIv1 is still available and will continue for a few more months. We speak about important dates at the end of this newsletter.

2. New categories of information

 

  • topsite: information about top hostnames and domains, those generating the most trafic on the Internet. Information is taken from Alexa TOP-1M, Cisco Umbrella and Majestic Million. As usual, data is updated once a month.
  • vulnscan: beginning of the year, we started scanning for most critical vulnerabilities on identified assets thanks to our identification engine. For instance, we are able to list all Citrix Gateways available on the Internet, thus we launched some vulnerability scans against #Shitrix #CVE-2019-19781. As this data is very sensitive, only customers with Eagle View subscription can access its content. We will add more specific vulnerability checks in the future.

Topsite category is available to all Entrerprise Views and vulnscan category to Eagle Views.

3. New pricing and rate limiting

But we have more cool news for you, dear customers and users. We have reviewed our pricing and decided to give you more query credits by a factor of 10. Yes, 10 times more credits to use for every View. Even better for Eagle View subscriptions: there is no more limits, you have unlimited credits. Along with increasing the number of credits, we now allow to perform 30 requests per minute instead of 20 requests previously.

Along with this new pricing, Eagle View subscriptions will have access to the new vulnscan category of information, on-demand scansExport API and premium support. Still not convinced? Try our service with the Dragonfly View. Only 59 Euros one-shot with perpetual validity, and up to 10,000 results per month.

Regarding the calendar, here are important dates:

  • 2020-03-01: deployment of APIv2, new pricing and new Web frontend. APIv2 becomes the default for Web queries;
  • 2020-04-01: APIv2 becomes the default for API queries;
  • 2020-07-01: removal of legacy APIv1 endpoints.

For any question, contact sales(at)onyphe(dot)com.

Best regards,

Open-source projects with ONYPHE integration

In this blogpost, we provide a mostly complete list of open-source projects or libraries that enable you to integrate our data directly within your daily tasks.

Libraries

Open-source projects

Browser plugins

SIEM