- Jul 27, 2015
Got Fortigate or Pulse Secure? Now would be a good time to make sure they're patched. Hackers are actively unleashing attacks that attempt to steal encryption keys, passwords, and other sensitive data from servers that have failed to apply critical fixes for two widely used virtual private network (VPN) products, researchers said.
The vulnerabilities can be exploited by sending unpatched servers Web requests that contain a special sequence of characters, researchers at the Black Hat security conference in Las Vegas said earlier this month. The pre-authorization file-reading vulnerabilities resided in the Fortigate SSL VPN, installed on about 480,000 servers, and the competing Pulse Secure SSL VPN, installed on about 50,000 machines, researchers from Devcore Security Consulting reported. The Devcore researchers discovered other critical vulnerabilities in both products. These make it possible for attackers to, among other things, remotely execute malicious code and change passwords. Patches for the Fortigate VPN became available in May and in April for Pulse Secure. But installing the patches can often cause service disruptions that prevent businesses from carrying out essential tasks.
Internet scans performed on Saturday by security intelligence service Bad Packets show there are 2,658 Pulse Secure VPN endpoints vulnerable to flaw currently being exploited. The scans found that vulnerable endpoints belonged to a variety of sensitive organizations, including:
- US military, federal, state, and local governments agencies
- Public universities and schools
- Hospitals and health care providers
- Major financial institutions
- Other Fortune 500 companies
Over the past 36 hours, hackers have started spraying the Internet with code that attempts to opportunistically exploit that difficulty, independent researcher Kevin Beaumont said. He said he found attacks against Fortigate servers coming from 126.96.36.199, an IP address that has a history of previous misconduct. A scan on Friday using the BinaryEdge search engine showed a new IP address, 188.8.131.52, had also begun spraying exploits for the same vulnerability.