- Lessons Learned from ICS Attack
- Fukushima Radiation at Fatal Levels
- Ukrainian Man Sentenced in Hacking Case
- Hard Time for Hacking into GA Pacific
- Safety Systems Worked in CA Refinery Blast
- Connected Car: Start Thinking Security
- Rockwell Fixes Parser Buffer Overflow
- Oil and Gas Security ‘Not Keeping Pace’
Chemical Safety Incidents
Squid Attack Fixed
Wednesday, May 18, 2016 @ 12:05 PM gHale
The Squid proxy server, a Linux utility deployed by Internet providers as a transparent and/or caching proxy, is suffering from a bug.
At its roots, Squid is a proxy server that takes traffic from incoming ports and relays it to its destination by masking its IP address. In most cases, Squid sees use in transparent mode and does not alter the origin IP address, merely relaying traffic.
The reason behind deploying Squid is to gather more insights on Web traffic, but also for caching purposes. Small and large ISPs use this technique to speed up page loads by providing an already-cached Web page to their subscribers, but also for saving bandwidth.
For these reasons, unknown to many end users, at one point or another, much of their Web traffic passes through a Squid server.
Along those lines, a vulnerability exists in Squid 3.5.12 up to 3.5.17 and all 4.x versions up to 4.0.9, which allows attackers to poison a Squid proxy server’s cache with malicious content, said Jianjun Chen, a postgraduate student at Tsinghua University in China. Researchers called it the Squison attack.
The attack relies on the attacker being able to pass malicious traffic through the proxy and works only for HTTP connections.
The attacker must first access (through a Squid proxy) a site under their control, such as attack.com. The attack’s next stage moves to the attack.com server, where the attacker then requests any site with the following command: “GET http://victim.com/ HTTP/1.1 Host: attack.com.”
“When it inspects the destination IP address for consistency, however, it mistakenly checks it against the value of the Host header, ‘attack.com’, rather than ‘victim.com,'” Chen said. “Thus, the proxy directly passes the request to the ‘attack.com’ server, but caches the (malicious) reply the server returns as a resource of ‘victim.com’.”
This request leads to cache poisoning caused by inconsistent operation of route verification and cache modules.
Poisoning Web caches allows attackers to insert malicious content in the cached versions of websites considered secure and sometimes untouchable, such as Google, Facebook, or Twitter.
While this explanation might appear complicated, Chen said the attack is very easy to exploit in real-world scenarios because of the way the online advertising ecosystem works. A trivial Flash ad can be automated to carry out such attacks.
The Squid team released versions 4.0.10 and 3.5.18 to address this issue.