Cisco Can Now Sniff Out Malware Inside Encrypted Traffic (theregister.co.uk) 97
Simon Sharwood, writing for The Register: Cisco has switched on latent features in its recent routers and switches, plus a cloud service, that together make it possible to detect the fingerprints of malware in encrypted traffic. Switchzilla has not made a dent in transport layer security (TLS) to make this possible. Instead, as we reported in July 2016, Cisco researchers found that malware leaves recognisable traces even in encrypted traffic. The company announced its intention to productise that research last year and this week exited trials to make the service -- now known as Encrypted Traffic Analytics (ETA) -- available to purchasers of its 4000 Series Integrated Service Routers, the 1000-series Aggregation Services Router and the model 1000V Cloud Services Router 1000V. Those devices can't do the job alone: users need to sign up for Cisco's StealthWatch service and let traffic from their kit flow to a cloud-based analytics service that inspects traffic and uses self-improving machine learning algorithms to spot dodgy traffic.
And obviously ... (Score:5, Interesting)
...malware is torrents.
Re: (Score:2)
Not analyzing payload (Score:5, Informative)
Re:Not analyzing payload (Score:5, Insightful)
"Sign up for" means "pay monthly for". It sounds like they are analyzing forwarded flow data and looking for flows to/from a particular port/IPs. It would catch malware that uses C&C to known rogue IPs, etc.
Re: (Score:2)
the C level believe in magic, and cisco sells them magic... so they buy it.
if you try to explain to them technical things... then the product is no good.
i have been in so many meetings where the term "magic sauce" is used to explain things from the vendor. and no one cares what that is...
Re: (Score:2)
so would using free service like opendns...
Re:Not analyzing payload (Score:5, Informative)
So how?
According to TFA they look for "dodgy destinations" and self-signed certificates.
So no, they aren't looking at the actual contents of the encrypted traffic at all, and they aren't "sniffing" anything.
Re:Not analyzing payload (Score:5, Insightful)
The amount of bycatch will be nontrivial. This will inevitably result either in a lot of valid traffic being blocked, or no meaningful blocking of malware.
Except this time they slapped AI label on the service, so it's very modern and cool and costs more money.
We've seen this before.
Re: (Score:2)
Re: (Score:2)
Not to mention that most decent security products already do "dodgy destinations". One of the common methods is to intercept the DNS calls and re-inject them with an internal IP address, thus blocking attempts to hit the remote baddie but also allowing further capture of data.
Hell, I can (and have) do this with a raspberry pi for a select number of machines.
Re: (Score:1)
So how?
According to TFA they look for "dodgy destinations" and self-signed certificates.
So no, they aren't looking at the actual contents of the encrypted traffic at all, and they aren't "sniffing" anything.
Then the article is wrong. I was at Cisco Live in Vegas in 2016 and attended a workshop in their developers zone where one of the engineers/researchers behind this technology made a presentation. They are looking at the encrypted data itself without decrypting it and just finds patterns. I probably still have the presentation somewhere.
Re: (Score:3)
So how?
According to TFA they look for "dodgy destinations" and self-signed certificates.
So no, they aren't looking at the actual contents of the encrypted traffic at all, and they aren't "sniffing" anything.
Then the article is wrong. I was at Cisco Live in Vegas in 2016 and attended a workshop in their developers zone where one of the engineers/researchers behind this technology made a presentation. They are looking at the encrypted data itself without decrypting it and just finds patterns. I probably still have the presentation somewhere.
If there are patterns in the encrypted data, then encryption is leaking information. I highly doubt they found a vulnerability in AES and decided to commercialize it.
They can look at the destination, they can look at handshakes, they can look at timing, they can look at frequency of communication. Am I forgetting something else?
Re: (Score:1)
Re: Not analyzing payload (Score:2)
Sounds like homegrown crypto, to avert signature detection.
when AES instructions first appeared. I thought it seemed a wasted opportunity. not to create some means of ring protection. Sure, malware can encrypt normally. but legitimate use should be access controlled, enabling audit and identification of unauthorized crypto generally by ser/des sampling for random data patterns. I want a log from a standard interface across CPU and offload NICs. coprocessors. iI want to view every crypto endpoint. and know
Re: Not analyzing payload (Score:2)
Re: (Score:3)
Then the article is wrong. I was at Cisco Live in Vegas in 2016 and attended a workshop in their developers zone where one of the engineers/researchers behind this technology made a presentation.
Or the presenter was wrong.
Or you misunderstood what was said.
They are looking at the encrypted data itself without decrypting it and just finds patterns. I probably still have the presentation somewhere.
That is implausible. Extraordinary claims require extraordinary evidence, and so far there is none.
Re: (Score:1)
devices can't do the job alone: users need to sign up [...] and let traffic [..] flow to a cloud-based analytics service
Then use TLA-provided stolen/coerced root certs to peer into the data stream, in exchange for "data sharing" with the TLA.
Oh, and they will "flag malware for you", sometimes. Maybe.
Re: (Score:2)
They are not analyzing metadata, as most malware C&C now pretends to be web traffic.
They could look at the IP addresses of the connections (Check against blacklist of malicious IPs); SSL Metadata, e.g. the SNI hostname from TLS, then look at reputation data regarding the hostname; certificate and public key information, common crypto parameters (Maybe some malware configures a HTTPS client uniquely). They can detect whether the SSL connection "Looks like" a normal web connection, or whether
Re:Not analyzing payload (Score:5, Interesting)
Packet sizes and frequency, along with metadata. I saw a similar analysis of encrypted video streams being used to detect drone video:
https://www.wired.com/story/a-... [wired.com]
Looks like the next big thing in cryptography will be data padding...
Re: (Score:2)
Seems near (Score:4, Interesting)
But what happens when they detect something?
Re: (Score:2)
But what happens when they detect something?
This is what I was going to ask. Do they block traffic (risking false positives) or merely alert you to the fact that some thing(s) on your LAN are acting suspiciously?
Re: (Score:2)
More technical info it feeds the information into pxGrid using Cisco Identity Services Engine (ISE) with Cisco TrustSec and Software-Defined Access (SDAccess). From the marketing info.
Evil bit (Score:5, Funny)
Great for now (Score:4, Interesting)
That's wonderful news. I wonder how long it will be until Cisco caves to NSA pressure and starts looking for other "mal"traffic as well. And then how long until Russia learns how to do it as well.
Re: (Score:1)
Why certainly. My newsletter is here http://viz.co.uk/2015/04/11/se... [viz.co.uk]
I'm still working on my manifesto, there are a lot of pictures to colorize.
Re: Great for now (Score:1)
How long? You're kidding right?
This is -already- happening, beyond the shadow of a doubt.
Re: (Score:2)
I wonder how long it will be until Cisco caves to NSA pressure
I assume you are young. The NSA already examines all traffic. This "offering" from Cisco has no potential to be of use to the NSA.
It will also not be of interest to Russia, China, or any other state actor.
At best, this might of interest to medium sized or smaller businesses looking to "spy" on their competition. Any major corporation has better methods for spying available than revealing their intentions to Cisco. Medium sized businesses can not bully Cisco into doing something unethical and illegal.
kind of like... (Score:5, Insightful)
Other surveillance? (Score:3, Insightful)
"Malware" can't be the only thing... Can the same algorithms not be used to detect bomb-making instructions, racism, and counter-revolutionary activities?
No they can't (Score:5, Informative)
They can recognize traffic patterns in TLS streams, created by malware on IP connected devices.
They can't detect the malware itself in the stream.
Re: (Score:3)
It is trivial to distinguish between random noise and malware in TLS. Just look at packet sizes and timing.
Even worse, if the adversary has access to the same static web pages, it can't be much trouble to detect which pages the victim is trying to access.
It is ridiculous that neither IPSEC nor TLS do anything to mitigate against that type of attacks. The least they could do was to put everything into predictable full-MTU packets as far as possible. The only tunnelling protocol that attempts anything like th
Snake Oil?!? (Score:1)
Re: (Score:1)
I agree with you; if there is recognizable patterns, that means that current encryption methods are not strong enough....
Re: (Score:1)
Re: (Score:2)
With the certificates it is looking for self-signed or known bad fields. With the netflow you can look for patterns, for example a n internal clients connects to an external server every hour and exchanges just a few bytes.
This software goes a little further by linking those all together from all the sites running this.
Smells like BS (Score:1)
You can sniff packets without decrypting them and tell the difference between "regular" data and "malicious" data? Smells like BS to me.
smells like shit (Score:3)
"switched on latent features in its recent routers and switches"
and
"users need to sign up for Cisco's StealthWatch service and let traffic from their kit flow to a cloud-based analytics service that inspects traffic and uses self-improving machine learning algorithms to spot dodgy traffic"
it's what is NOT being revealed that truly is scary
Encrypted Traffic Analytics Whitepaper (Score:1)
https://www.cisco.com/c/dam/en... [cisco.com]
"Encrypted Traffic Analytics extracts four main data elements: the sequence of packet lengths and times, the byte distribution, TLS-specific features and the initial data packet."
okay... yeah... and? (Score:2)
This seems somewhat "old news" certain applications still have fingerprints on packets that can be detected even if you can't read the data being exchanged.
Our Sophos XG firewall does this with many different torrent applications, and it ends up blocking non-VPNed, but still encrypted connections.
I'm a little sketchy about the "upload your traffic to us" part, but I guess that allows for more analysis across more hsots
SV
Wrong title (Score:2)
What they actually can do is recognize TLS tunnels created and used my malware. They cannot detect anything in the encrypted stream of data. The way this works is carefully observing how exactly the TLS tunnel was established. This apparently differs enough between different implementations, that typical code used by malware for this purpose becomes identifiable.
Of course, as soon as the malware-makers just use more standard code, their tunnels become unrecognizable as well.
Caveat: I read the abstract, but
Calling BS on this one (Score:1)
That's so 2013 (Score:1)
False positives (Score:2)
I predict that this concept will ring alarm bells for a lot of normal traffic.
My company uses Trend Antivirus. In their wisdom, they turned on the "heuristic" behavior detection mode. Now, every time our software team writes software that renames a file, it has to be excluded from Trend's scanners. Apparently, ransomware does a lot of file renaming, therefore, any software that renames a lot of files is suspect.
So far, anti-malware isn't very good at detecting "suspicious" patterns, in my experience.