Latest News

A New Way to Secure SSL/TLS Traffic

Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS), are the primary means of securing traffic between web browsers and web servers. Organizations need to detect and prevent network-based compromises that can be carried through SSL/TLS traffic, but many legacy solutions present problems. SSL/TLS interception is usually achieved by proxying the encrypted sessions through an in-line security device or software daemon which terminates the SSL/TLS session, decrypts the content and re-encrypts it before communicating with the intended recipient. Some issues associated with such in-line architecture include the need for an in-line device and the related cost, latency increases, decreased network availability and potential security exposure. In this article, we’ll look at a new way to inspect SSL/TLS traffic that does not require an in-line device and thus overcomes traditional challenges.

The SSL/TLS Attack Vector
Any exploit that can be carried out in regular traffic can be carried out over SSL/TLS. Because the session is encrypted, it makes exploits harder to detect. Sometimes, the same exploit can be carried out over SSL and non-SSL. SSL can hide applications that the enterprise doesn’t want, such as peer-to-peer systems or instant messaging apps. Most organizations have policies in place that prevent certain content from being posted to public sites, and they want to be able to enforce these policies about what can travel on the network. But SSL-encrypted traffic makes it difficult to enforce those policies.

In terms of malware, a network analyst can’t find virus exploits or other attacks that use SSL/TLS to communicate. The alternative is to monitor endpoint addresses, but endpoint addresses change frequently, leading to false positives and false negatives. In addition, users may use SSL/TLS to download executables, and it’s difficult to block that traffic if it can’t be detected. For example, most phishing and pharming attacks occur in SSL/TLS traffic.

Traditional SSL/TLS Monitoring
The traditional method of dealing with this challenge is to buy an in-line device that decrypts SSL/TLS traffic, inspects it, and then re-encrypts it. There are two key issues with this approach:

Increased latency – because there’s a box in the middle of the traffic that has to decrypt, inspect, and encrypt the data stream before passing it onto the server, the user will experience higher latency in the connection. SSL/TLS inspection device manufacturers try to mitigate latency by adding processing power to their systems, but this increases the cost of the device. In-line inspection devices can cost from $20,000 to $150,000, depending on processing capacity.

Reliability – If the in-line device fails, so does access to the network. And the in-line device needn’t fail to interrupt network access. Browser-server configurations change frequently, and these devices aren’t always up to date, so they can deny legitimate traffic. In addition, the in-line device is responsible for the cryptographic keys that enforce security on the connection. These cryptographic keys may not be configured correctly, and misconfigurations can also interfere with network access.

In virtualized networks, users could implement SSL/TLS interception functionality with in-line software appliances. This approach compounds the problems mentioned above because virtual software appliances have limited CPU capacity to handle multiple real-time traffic flows between the clients and the servers. Public key decryption and encryption are very CPU-intensive, and the traffic can easily overwhelm the in-line software system when the software is inspecting traffic from multiple endpoints to multiple servers. The need for decentralizing this in-line approach in virtual environments would significantly increase costs and compound the reduced availability and security concerns of this architecture.

Endpoint SSL/TLS Monitoring
Here’s another approach: Passive SSL/TLS inspection. Instead of running the inspection capability in the network, it can be run in the endpoints. This is accomplished by running an agent on each endpoint to collect traffic in clear text (before/after it is encrypted/decrypted for transmission/reception over the network), and by sending those results to a server-based or virtual machine-based sensor for inspection and correlation.

Basically, the agent is a transparent tap into the endpoint’s traffic, and it makes a memory copy. This passive SSL/TLS inspection occurs on the endpoints before the traffic is encrypted and sent to the server, so it doesn’t interfere with traffic between the client and server at all.

This approach has several advantages. There’s no increased latency because the agent doesn’t interfere with the network traffic. If the agent stops working for some reason, it doesn’t interfere with the endpoint user’s activity. The agent also has nothing to do with the cryptographic keys, so there are no security or configuration issues.

Passive SSL/TLS inspection addresses the major problems of in-line inspection, maintains the one-to-one relationship between the endpoint and the server, and enables network analysts to see what’s being transmitted over secure sessions. As networks become increasingly virtualized, endpoint SSL/TLS inspection will be the only way to see and react to network exploits conducted via encrypted tunnels between browsers and web servers. Passive TLS/SSL is available today as a software subscription service from MetaFlows Inc. for any Linux distribution, Windows 10 and Windows Server 2016.

MineMeld Support

MineMeld is an open source threat feed management system that gathers IP addresses, URLs, and domains which pose a significant network security threat. The threat feed sources can either be free, subscription-based or proprietary. MineMeld re-scans the feeds at regular time intervals and continuously aggregates and updates the set of all threat indicators to be consumed by fierwalls, IDS/IPS, or any other security device.

MetaFlows now includes MineMeld public threat feeds to augment our existing intelligence sources. The public threat feeds amount to about 200,000 additional indicators updated every few hours. Users also have the ability to add site-specific (either subscription-based or private) MimeMeld sources.

IPv4 and URL/Domain indicators are treated differently.

IPv4 feeds

The default MineMeld IPv4 feeds processed by MetaFlows are below:

Source	Current Number of Indicators
https://lists.blocklist.de/lists/all.txt	56953
https://feodotracker.abuse.ch/blocklist.php?download=badips	61
https://www.binarydefense.com/banlist.txt	4098
http://osint.bambenekconsulting.com/feeds/c2-ipmasterlist.txt	459
https://rules.emergingthreats.net/open/suricata/rules/compromised-ips.txt	2473
https://www.dshield.org/block.txt	20
http://malc0de.com/bl/IP_Blacklist.txt	105
http://www.malwaredomainlist.com/hostslist/ip.txt	1001
http://reputation.alienvault.com/reputation.data	70666
https://ransomwaretracker.abuse.ch/downloads/RW_IPBL.txt	315
https://www.spamhaus.org/drop/drop.txt	770
https://www.spamhaus.org/drop/edrop.txt	113
https://sslbl.abuse.ch/blacklist/sslipblacklist.csv	136

MineMeld IPv4 addresses are compiled in a set of IDS/IPS rules designed to alert or block communications to blacklisted addresses. MetaFlows uses a proprietary technique to quickly look through this huge list of addresses (140,000+) and therefore does not require specialized hardware for hi-speed networks.

The MineMeld IPv4 feeds are in the mmreputation.rules configuration file that can be accessed through the existing IDS rule management UI. The feeds are not activated by default but users can activate them in IDS or IPS mode with just a few clicks. If enabled, these rules can be very useful to detect and/or prevent communication to questionable hosts on the Internet.

All the IP addresses are reduced to approximately 40 separate signatures. Each signature corresponds to a specific feed source (for example blocklist_de) or intersections of sources where the IPv4 address is present in more than one source (for example blocklist_de_alienvault.reputation). This decomposition provides additional operational awareness that can be used to prioritize which set of IPs to alert on or block. Enabling or blocking individual signatures therefore affects a dynamically changing set of potentially thousands of IPs updated every few hours that map to a single threat feed or the intersection of multiple threat feeds.

Users also have the option of adding site-specify MineMeld IPv4 feeds to enable additional commercial MineMeld subscriptions independently purchased or other proprietary feeds.

Entering the URL as shown above, will automatically add the custom MineMeld reputation feed into the customer’s configuration and the local rule corresponding to the feed can then be managed as the other public MineMeld feeds.

URL and Domain FeedS

The MineMeld domain and URL feeds processed by MetaFlows are below:

Source	Current Number of Indicators
https://www.badips.com/get/list/any/3?age=2w	33593
http://osint.bambenekconsulting.com/feeds/c2-dommasterlist.txt	719
http://malc0de.com/bl/BOOT	111
https://ransomwaretracker.abuse.ch/downloads/RW_DOMBL.txt	1903
https://ransomwaretracker.abuse.ch/downloads/RW_URLBL.txt	11567
https://ransomwaretracker.abuse.ch/downloads/TC_DS_URLBL.txt	271
https://urlhaus.abuse.ch/downloads/text/	102880
http://vxvault.net/URL_List.php	101

These feeds are used to detect when:

A user issues an HTTP request to a URL or domain deemed to be malicious or
A user receives an email containing a malicious URL or link to a malicious domain whether or not the user clicks on the links.

When either of these two conditions occur, a high priority even is generated that can be used to block those specific communications.

There is also a an additional option to enable real time email notification. When bad emails are detected, users also get a warning email instructing them to discard the email.

MineMeld support will automatically be added next time your system self updates or if the sensor software is restarted.

Qradar Support

The MSS now fully supports the Qradar SIEM from IBM in CEF log format. Qradar is an excellent SIEM but requires classifying and mapping every event type it sees to an internal category. Qradar comes with a large number of common IDS rules (~50,000) already classified but not mapped. Besides having to manually map all these rules Qradar-MSS users would also need to continuously create additional Qradar IDs (Qids) to map to the much larger rule set used by the MSS (which changes daily). All this required a mechanism to update Qradar dynamically as new rules are published. With this update released today, no manual classification or mapping operations are necessary.

The MetaFlowsCEF log source automatically parses the 13 event types generated by the MSS and presents them in the Qradar default view. All MSS events are automatically mapped to new or existing Qids without any user manual operations. This makes the Qradar SIEM much easier to use.

To setup Qradar for the MSS perform the following steps:

1. Download the MetaFlowsCEF log source https://nsm.metaflows.com/sensordevicetype-search-ContentExport-20180809173340.zip to the Qradar box
2. Import it with the command /opt/qradar/bin/contentManagement.pl -action import -f sensordevicetype-search-ContentExport-20180809173340.zip
3. Verify the import was successful and assign the MetaFlows sensors to this log source. Also make a note of the log source ID assigned by Qradar to the MetaFlowsCEF log source (something like 400[1-9]).
4. Edit the file mss.sh of all sensors and add the line export QRADAR=1.
5. On one of the sensors you designate as the main Qradar updater, create the file /nsm/etc/qradar.ini to allow the sensor to communicate to the Qradar server (see an example below). Also add the line export QRADARLOGSOURCEID=<logsourceid>; where <logsourceid> is the number you noted in step 3. Probably something like 4001, or 4002, etc..
6. Restart the sensors

Sample qradar.ini:

[DEFAULT]
certificate_file = /nsm/etc/qradar.pem
auth_token = f3f1201b-3562-46d1-9b8b-9a1623870000
server_ip = 123.52.215.20
Where:
/nsm/etc/qradar.pem is a copy of the file located at /etc/httpd/conf/certs/cert.cert on your Qradar box
auth_token is obtained from your QRADAR application
server_ip is the IP address of your Qradar box.

The Qradar updater sensor will automatically add to Qradar new IDS rules added by the sensor’s rule update (which will be the same across all your sensors). This will happen through the Qradar API in the background as the sensor is running. The first time, the updater is run, it will have to catch up with about 50,000 definitions; so it will take many hours. Subsequent updates will take less time.

After each Qradar update, the email associated with the sensor owner will receive a summary of the update process.

Qradar integration is a bit complex; so do not hesitate to contact support@metaflows.com for any questions.

Splunk App

We have developed a Splunk network security app available at https://splunkbase.splunk.com/app/3603

or https://nsm.metaflows.com/SplunkforMetaFlows.tgz.

It receives events generated by the MetaFlows sensors and breaks them down by the following types:

Multisession Analysis
High Priority Events
IDS Events
Network Logs (3rd party logs sent to the sensors)
File Transmission Analysis
User Discovery
Service Discovery
Host Discovery
Mac Discovery
Suspicious URL Transmission Analysis
IPS Notifications
User Rankings
Modsecurity

From the app you can either drill down on Splunk itself or jump to the MetaFlows console to gather more forensic information like packet payloads.

You can install the app by using the Splunk application management tools. In order to send event to Splunk you need to add a configuration line in your /nsm/etc/mss.sh startup script of your sensors. The SSL-encrypted syslog messages are sent to the MetaFlows Splunk App through TCP port 3015 (please make sure you sensor can communicate on this port).

It is a early beat version, please let us know how you like it.

Please see more details at https://docs.metaflows.com/Log_Management#Splunk_App

Happy Hunting!

The MetaFlows Team.

Got MAC?

We recently added the MAC addresses to the event messages. The system gets the MAC addresses in two orthogonal ways:

We sniff the MAC headers from the passive tap. If the MSS sees more than 5 IP addresses with the same MAC, it stops recording because it means you are mirroring the connection between the switch and the next routing hop (probably the firewall) where the MAC addresses are not available.
We sniff DHCP lease messages when the IP is assigned dynamically. In order to do this, you probably need to instruct the switch to specifically mirror DHCP traffic in order for the sensor to process it. The sensor expects DHCP UDP traffic using the pcap expression udp and (port 68 or port 67).

Please contact us at support@metaflows.com if you need help in setting up DHCP traffic monitoring.

Websockets Are Here

Adobe Flash is one of the original sins. It is everywhere and yet it is a huge security risk. Websockets is an HTML5 standard that, for us, provided an alternative to Adobe Flash.

For now we support both. The browser will try to use Adobe Flash first, and if it is not present or it is disabled, it will try using Websockets (which are hard-coded in your Browser). I you want to keep using Adobe Flash, you do not have to do anything; things should keep working as before.

If your sensors are configured as clients, and you do not want to use Flash anymore, just disable it and the Browser will do the rest. You will be using MetaFlows SSL certificate.

If your sensors are configured as servers, and you do not want to use Flash anymore, well, it’s a bit of work to use Websockets because current Browser implementations do not allow self-signed SSL certificates (this is probably a good thing). To use Websockets on sensors configured as servers:

Add your sensors’ static IPs to the DNS (like: <sensorname1>@mydomain.com)
Generate a valid SSL certificates that matches the DNS name in step 1 (cannot be self-signed). If you do not want to generate a separate certificate for each sensor, you can also buy a *.mysensordomain.com certificate to share by all your sensors.
Bundle the certificates with the command:

# cat my_certificate.crt my_certificate.key bundle_certificate.crt > sensorcert

Copy sensorcert to /usr/local/etc/ntop/sensor-server.pem on your sensors’ hard disk.
Go to nsm.metaflows.com and replace the static IP address of your sensors as a server with the names you setup in step 1
Make sure your browser can reach the sensors on ports 3009 and 3010
Restart your sensors as a server with the command:

#/nsm/etc/mss.sh restart

Adding Websockets support was a fairly extensive change in our system; so there could still be some issues. As always feel free to contact us if you have any questions or you see any problems.

Thank you for exploring the unknown with us!

The MetaFlows Team.

Product Update: Reconsider Event Classifications

Recently, the engineers at MetaFlows have improved the Event Classification Menu within the MetaFlows software, allowing each user to further customize events through actions and event views. This introduces four key features to the Event Classification Menu that users will find helpful in employing the MetaFlows IDS.

The first improvement allows users to see a comprehensive list of their classifications. Now, users can access a new classification interface that breaks the classifications down by action. There are seven action types: Highlight, Block, E-mail, Ignore, Delete, Rank, and Disabled. The Highlight function matches the records in the Real-Time, Historical, and Reports with the selected color. The Block action triggers the Soft IPS for matching records, causing connections matching the classification to be blocked. The E-mail function produces a PDF report of matching records that will be sent every ten minutes, or as frequently as possible. The Ignore action ignores events that match the classification. The Delete function removes matching records from the browser in order to free up memory. The Rank action increases the priority/rank of the records that match the classification. The Disable function allows a user to disable a classification without deleting it.

The Search functionality of the classification interface now allows users to search against a classifications’ name, category, IP address, IDS alerts, service alerts, and log message values. All a user has to do is type a value into the Search field to find classifications to match that query. The search will match against values in the classification name, category, addresses, and events field.

Once upon a time, deleting a classification was an irreversible action. Now, that can be undone. If the user deletes a classification only to realize later that they need it, they can restore the classification from the Trashed Classifications list.

Transferring classifications is now much easier. By employing the Upload Classifications feature, a user can transfer classifications in bulk between two different domains. The option is listed as the Upload Classifications button and selecting this opens the uploader. Classifications must be in JSON format and contain all the required information for the classification.

More information regarding the recent improvements in the Event Classification menu can be viewed on the MetaFlows User Manual. If using any of the four new features causes any confusion, or if there are any questions, do not hesitate to contact the MetaFlows team for assistance.

Uncovering True Positives

MetaFlows is now using our sandbox results as an intelligence feed for ranking events. This method of using the sandbox as an intelligence source for ranking signatures allows us to catch infections or high-risk behavior, even if we only see one piece of the traditional malware life cycle. The picture below illustrates a sandbox report that shows where the signature was first observed in association with malware.

How It Works

Individual IDS signatures can now be ranked as a priority threat if they have been triggering inside the MetaFlows sandbox in association with malware. These signatures are only considered for special ranking if they are statistically rare among events across all MetaFlows monitored networks. Given their nature, these events are likely to missed by an analyst among the many other events that may be normally low ranked. The image below displays a ranked event on the user’s dashboard showing an alert identified with the new threat category.

You can see what kinds of events are triggering in the MetaFlows sandbox by visiting our statistics page.

The Skinny on CVE-2015-7547

While the DNS exploit CVE-2015-7547 was discovered a week ago, the code containing the flaw has been in use since May, 2008. CVE-2015-7547 works by allowing arbitrary code to execute on any system reliant on glibc by way of a malformed query response. As discovered by Redhat Linux and Google, there are flaws in GNU C Library. The GNU C Library connects to DNS to resolve names. This problematic code effects all versions of glbc since 2.9 and allows for remote code execution.

We have seven signatures, the first of which was released the day after the exploit was discovered. We were able to push the beta version of the rule to our research partners immediately, and to all sensors during the normal daily signature update.

2022531 || ET EXPLOIT Possible 2015-7547 Malformed Server response || cve,2015-7547

2022542 || ET EXPLOIT Possible 2015-7547 PoC Server Response || cve,2015-7547

2022543 || ET EXPLOIT Possible CVE-2015-7547 Long Response to A lookup || cve,2015-7547

2022544 || ET EXPLOIT Possible CVE-2015-7547 Long Response to AAAA lookup || cve,2015-7547

2022545 || ET EXPLOIT Possible CVE-2015-7547 Malformed Server Response A/AAAA || cve,2015-7547

2022546 || ET EXPLOIT Possible CVE-2015-7547 A/AAAA Record Lookup Possible Forced FallBack(fb set) || cve,2015-7547

2022547 || ET EXPLOIT Possible CVE-2015-7547 Large Response to A/AAAA query || cve,2015-7547

Signature 2022547 is currently triggering on multiple customer sites, but at least for now it is in low volume. However, according to Dan Kaminsky, this is a threat that could swiftly escalate as more and more adversaries improve their attack strategies to increase the damage made possible by CVE-2015-7547. Patching this particular bug is paramount, as well as continually monitoring your system for the exploit.

Measured Antivirus Effectiveness

I wanted to share with you some insight from the data that originated from our customers’ networks last week. This time, we wanted to provide some information on how different antivirus vendors perform on the .exe, .dll, .pdf, and .zip files seen around the world.

This table shows the relative hit ratio of all the antivirus vendors hosted by Virus Total on 697 confirmed bad files. You will notice that 43% of the time none of the antivirus products detected anything. The top performer is McAfee-GW-Edition with a 37% detection rate.

Looking at the types of samples detected, one can also consider which Antivirus Vendors were able catch the worst malicious code. We assigned an Average Priority of 1 to spyware or unwanted software and an Average Priority of 100 to known Trojans or unclassified malware. Then, we multiplyed the Average Priority by the Detection Rate, giving rise to the Severity column. This column shows which Antivirus Vendors found the most dangerous code. This week Arcabit wins with a Detection Rate of 29%, an Average Priority of 30.17, and a Severity of 8.96.

Antivirus Vendor	True Positives	Average Priority	Detection Rate	Severity
None	300	–	0.430416 (mss)	–
Arcabit	207	30.17	0.296987	8.96
F-Secure	192	28.84	0.275466	7.95
ESET-NOD32	205	24.18	0.294118	7.11
AVG	129	37.07	0.185079	6.86
Avast	200	23.77	0.286944	6.82
Qihoo-360	207	22.52	0.296987	6.69
GData	223	20.09	0.319943	6.43
McAfee-GW-Edition	264	16.75	0.378766	6.34
CAT-QuickHeal	162	27.28	0.232425	6.34
VIPRE	172	23.45	0.246772	5.79
Cyren	201	19.72	0.288379	5.69
Panda	85	46.42	0.121951	5.66
F-Prot	160	24.51	0.229555	5.63
ClamAV	62	63.27	0.088953	5.63
Fortinet	105	29.29	0.150646	4.41
McAfee	117	25.54	0.167862	4.29
Avira	210	12.79	0.301291	3.85
Bkav	83	30.82	0.119082	3.67
MicroWorld-eScan	162	15.06	0.232425	3.50
BitDefender	161	15.14	0.230990	3.50
Emsisoft	160	15.23	0.229555	3.50
CMC	24	100.00	0.034433	3.44
Kaspersky	86	27.48	0.123386	3.39
TrendMicro	63	37.14	0.090387	3.36
Ad-Aware	140	16.56	0.200861	3.33
Ikarus	209	10.95	0.299857	3.28
AVware	95	23.93	0.136298	3.26
Comodo	69	26.83	0.098996	2.66
Sophos	77	20.29	0.110473	2.24
Rising	195	7.09	0.279770	1.98
Tencent	50	24.76	0.071736	1.78
ALYac	108	9.25	0.154950	1.43
Microsoft	25	36.64	0.035868	1.31
K7AntiVirus	109	5.54	0.156385	0.87
DrWeb	134	3.96	0.192253	0.76
Malwarebytes	222	1.89	0.318508	0.60
K7GW	120	3.48	0.172166	0.60
Antiy-AVL	74	5.01	0.106169	0.53
Symantec	161	1.61	0.230990	0.37
VBA32	53	4.74	0.076040	0.36
nProtect	16	13.38	0.022956	0.31
NANO-Antivirus	76	2.30	0.109039	0.25
SUPERAntiSpyware	38	3.61	0.054519	0.20
Jiangmin	38	3.61	0.054519	0.20
Zillya	131	1.00	0.187948	0.19
ByteHero	4	25.75	0.005739	0.15
Baidu-International	83	1.00	0.119082	0.12
AhnLab-V3	80	1.00	0.114778	0.11
Agnitum	57	1.00	0.081779	0.08
ViRobot	12	1.00	0.017217	0.02
AegisLab	9	1.00	0.012912	0.01
TotalDefense	2	1.00	0.002869	0.00
Zoner	1	1.00	0.001435	0.00
Alibaba	1	1.00	0.001435	0.00

Our sandbox was able to detect the remaining samples (the missing 43%).

antivirus

The bubble graph above illusrates the Severity (Detection Rate * Average Priority) verses the Prevalence (Detection Rate * Total Priority). The detection rate is encoded in color and the size of the bubble is proportional to how many customers saw the malware.

If you are curious about more statistics like this, you can visit https://www.metaflows.com/stats/ (best viewed on a desktop) for a ton of additional information. If you want a quick fix, watch some of our videos at https://www.metaflows.com/saas/.