CAMP was presented in February 2013 at the Network and Distributed System Security Symposium and was explained in a research paper
"CAMP consists of a client component built into Google Chrome and a server component responsible for maintaining a reputation system that predicts the likelihood that a downloaded binary is malicious"
After six-month deployment with more than 200 million Google Chrome users and approximately five million intentional malware downloads per month detected, Google Researchers say that they have developed an Antivirus able to detect the 99% of all malicious downloads in less than 130 ms on average using a reputation-based detection .
The current Security Systems Weakness
The document says the major Antivirus engines detect only 35% to 70% of modern malware. Antivirus are signature-based detection to identify variants of a known malware. Because of this, they cannot protect againts sophisticated techniques like packing, polymorphism and unknown malware. Additionally, some Antivirus has created a CloudAV. CloudAV upload the binaries files to a third-party cloud which implies loss privacy for the users.
Blacklist from Google’s Safe Browsing API , McAfee’s Site Advisor or Symantec’s Safe Web are useful when the compromised or malware distribution websites tend to be a long live but they are unuseful when the malware distribution frequently changing the domain.
Whitelist can be effective in an enterprise environment but they are very restrictive.
CAMP, a different approach
CAMP protects users from malware binaries without requiring (a-priori) knowledge of the binary augmenting whitelists and blacklists with a content-agnostic reputation system.
CAMP is composed of two parts: client (Google Chrome Web Browser) and Google Servers where client connect to download blacklist, whitelist and sends a request to CAMP's reputation service.
How the client works
- The browser tries to determine if a download came from a malicious site by checking the download URL against a list of URLs known as "malware distribution" using Google's SafeBrowsing API.
- The browser checks locally against a dynamically updated list of trusted domains and trusted binary signers to determine if the downloads are benign.
- The browser extracts content-agnostic features from the download and sends a request to CAMP's reputation service for downloads that don't match any of the local lists.
- If a malicious download is requested and detected, Google Chrome warning the users giving her two options: Block or Pass the download.
- The URL and IP of the server hosting the download.
- Any referrer URL and IP encountered when starting the download.
- The size of the download and her hash.
- The signature attached to the download including the signer and any certificate chain leading to it.
- The browser will never send the binary itself reducing the privacy impact.
The reputation system makes a decision based if either the URL or the content hash is known to be malicious for each client request.
"The reputation verdict is computed by a reputation metric calculated by a binary circuit from the client request and any reputation data that is referenced by the reputation system, , e.g. how many known benign or malicious binaries are hosted on a given IP address, etc"
Evaluation
Google selected 2200 binaries unknown by VirusTotal and were processed on a single day. As you know, VirusTotal can check a file with more than 40 antivirus solutions.
Of these 2200, 1100 were labeled malicious on a single day. They submitted the binaries to VirusTotal, and they waited 10 days.
After 10 days, 99% of the binaries detected by CAMP were detected by 20% or more of AV engines on VirusTotal. Only 12% of the binaries that they detected as clean were also detected by 20% or more of the AV engines.
"The URL classification services mostly disagreed with CAMP when presented with the set of malicious URLs. Trend-Micro identified about 11% as malicious, Safe Browsing about 8.5%, Symantec about 8% and Site Advisor about 2.5%. The Malware Domain List did not flag any of them as malicious. However, as with the benign URLs, many of the malicious URLs were not known to the web services. For example, TrendMicro did not know 65% of the URLs that CAMP found to be malicious."
Our personal conclusion
In our opinion, CAMP is a really interesting project and has a new approach to fight with malware but we think it is not an Antivirus as we know it. Camp cannot avoid infection from malicious attachments send by mails, USB infections, frontal attacks using exploits...
Only works with Google Chrome... What's happen if we use Mozilla, Internet Explorer or Safari in our companies or our homes?
Despite this, we believe it is a great achievement to get prevent millions of infections and it is a step forward in the fight against malware
This a great view of what is really happening as we all browse the web. The approaches that most technology uses is attempting to react to threats as they come into the environment. What's required is to say the old reactive way doesn't work with all the new threats that appear daily. By shifting the focus from reactive protection to proactive prevention of all browser-borne malware we need to look for new technology that interacts with the internet outside the firewall protecting client devices and keeping the 1% to 80% of undetected malware outside the network. Spikes Security is one company that has introduced such a malware prevention technology www.spikes.com.
ReplyDeleteI agree with you. We can see how the based-signature Antivirus have less sense... An inline sandbox is a great idea to run the files which have been downloaded by the network users in order to look at their behaviour but we can check how the malware developers are making a great effort using evasion techniques to detect the sandbox's virtual machines to not be detected... They are packing and ciphering their malware and even in a custom attack, the malware could not run if for example the language of the virtual machine is not the corporative... We have seen logic boms, etc...
DeleteWe still need to protect our DMZ but the hackers behaviour have changed... Now they are focused in attacking the end-users and then, pivoting from the infected computer to the internal servers instead of frontal attack them...
And how are the users infected? Through their browser exploiting it or getting advantage of some Adobe or Flash Player vulnerabilities...
Thanks for your comment.