Good Enough Security is Actually Not | By Christopher Louie

Good Enough Security is Actually Not

sandbox all files.png

Many organizations I talk to believe that DNS-based or reputation-based solutions are good enough to protect their users against attack. One security professional once asked to me “If I am driving to work and a Ferrari will get me there and a Honda will also get me there, why would I pay more to buy, operate, and maintain the Ferrari?” This is an obvious oversimplification of the topic of Information Security and protecting users, but also underscores a theme in Information Security where security teams are asked to do more protection with less budget and personnel. These demands often lead to solutions that are only good enough to please the regulators, corporate governance, legal teams, and auditors.

Good enough solutions necessarily make tradeoffs between security, performance, budget, and user experience. In the context of protecting users from internet-based threats, typical compromises include relying on a website's reputation or only looking at DNS to decide if a website is benign or malicious. Attacks against reputation-based solutions are well documented and easily executed. Well known and well respected websites with benign reputations were used to bypass reputation-based controls to attack and infect users. 

Visitors to YouTube unknowingly and unwittingly began mining cryptocurrency due to malicious advertisements being served on the video hosting site’s videos. After the well-known Equifax breach, a third party vendor serving content on Equifax’s site became compromised and visitors to Equifax’s web site to get updates on the breach or to apply for a credit freeze were presented with a malicious Adobe Flash downloader. Reputation-based filtering solutions may protect users from going to www.evil[.]com, but does little to protect users from getting malware from compromised high reputation websites.

DNS-based filtering solutions will rely on DNS resolution to prevent users from visiting prohibited websites (due to HR, compliance, or security reasons). These solutions are typically advertised as being high-speed, easy to deploy, and a good solution for budget constrained organizations. By design, DNS-based filtering solutions will not prevent users from accessing a website directly by IP address. Further, there is little a DNS-based filtering solution can do when users are tricked into downloading malware from normally permitted websites such as Google Drive or DropBox. Worse yet, some security solutions combine both of these techniques and only perform DNS-bsaed filtering on the top 1000 or 10,000websites in order to improve performance by sacrificing security.

A recent alleged state sponsored espionage campaign would have easily defeated these two web security protections. New research by human rights advocacy organization Citizen Lab have uncovered attacks against citizens of Egypt, Syria, and Turkey. Local ISPs in these countries used sophisticated surveillance equipment to launch man-in-the-middle attacks in order to distribute FinFisher and StrongPity spyware. Victims of FinFisher would allow a remote attacker to log keystrokes, turn on the microphone and webcam, or steal files on the local computer. Reported victims of these state sponsored attacks were identified by their IP address and included lawyers, journalists, human rights activists, and political dissidents.

Local ISPs used Sandvine "PacketLogic” devices to replace installers of legitimate software with infected versions even when downloading from official sources. Redirection and replacement of the legitimate software was made possible because vendors of popular software such as WhatsApp, Skype, Opera Browser, CCleaner, Avast, WinRAR, and VLC Player host their download pages using secure HTTPS, while the actual download of the installer file is conducted over plain HTTP. HTTP does not guarantee confidentiality, integrity, or authentication. While it would have been possible to detect that the switch had been made, it would have required the user to compare the MD5 or SHA hash of the file to the hash of the known good copy posted on the website. This practice is not often observed by standard users or even security professionals

Since the attack took place at the ISP level and users originated the software download from a legitimate website, reputation and DNS-filter based security solutions would not have identified or blocked the infected versions of the installers. In order to detect and block ISP-level attacks, a full security proxy solution with a zero-trust model is needed in order to fully scan the payload after it is delivered by the ISP. Bad actors and surveillance states recognize that users are the weakest link in security and a security solution needs to sit between the user and the internet and protect users no matter where they are.

Further Reading:

Originally posted here:

November 28, 2018
Notify of
Inline Feedbacks
View all comments
© HAKIN9 MEDIA SP. Z O.O. SP. K. 2013