There have been reports of a new remote information disclosure vulnerability in Apache HTTP Server, when the HTTP "OPTIONS" method is enabled and a misconfiguration occurs. While the misconfiguration trigger seems rare in production environments, the Apache .htaccess file ability enables users of virtual hosting services to intentionally introduce the bug in a shared environment and thus be able to abuse the vulnerability condition.
The bug has been assigned CVE-2017-9798 and reportedly affects the latest Apache release. There is a proof of concept example available to trigger the fault, however after hours of testing at OSI Security we were unable to reproduce the information leak.
Reportedly, it only occurs in high traffic Apache websites and the examples used were from the Alexa Top 400 Global Websites, where the author noticed HTTP responses that included abnormal returned bytes of system memory outside of expected use, or HTTP server content destined for other website visitors / cached in memory.
OPTIONS /index.html HTTP/1.0
Example vulnerable response:
HTTP/1.0 200 OK
Allow: GET,HEAD,OPTIONS,,HEAD,,HEAD,,HEAD,, HEAD,,HEAD,,HEAD,,HEAD,POST,,HEAD,, HEAD,!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"
It is clear from the disclosed example, that the Allow header should only include GET, HEAD and OPTIONS (or others such as PUT and DELETE) however the server leaks information from other memory locations.
The vulnerability is reportedly triggered where the Apache server is used, with the OPTIONS request enabled, with a <Directory> definition (or a .htaccess file) which contains a e.g. <Limit GET> access control which contains an invalid method name. An example would be <Limit GETT>, as a system administrator introduced typo.
At this stage the vulnerability appears to be impractical and of low risk, however we suggest checking your Apache server configuration for Limit directives which may contain errors.
At the same time as this report, during a client penetration test we discovered a minimal risk/impact vulnerability in the latest release of Apache which we reported to the security team. The bug has since been patched in source code and should be included in the next stable release.
To test a HTTP/S server for weak Diffie-Hellman (DH) SSL / TLS ciphers, you may use the following command (Linux):
$ openssl s_client -connect [target]:443 -cipher "EDH"
EDH requires use of weak DH keys. If it connects, you may GET / HTTP/1.0 to confirm.
A secure host should not connect, e.g.
$ openssl s_client -connect www.gmail.com:443 -cipher "EDH"
139671352862352:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:770:
This is a quick email to bring your attention to a recently publicised OpenSSL security vulnerability known as "Heartbleed". The Common Vulnerabilities and Exposures list has assigned CVE-2014-0160 for this issue.
The vulnerability is currently being exploited in the wild on a small scale.
The vulnerability is a memory disclosure bug. That is, a malicious user can send a trigger packet to an HTTPS service with a vulnerable OpenSSL instance, and the server will respond with the raw memory contents of the HTTP server (such as Apache) or OpenSSL.
Am I vulnerable?
Only OpenSSL versions 1.0.1, 1.0.1a through to 1.0.1f are vulnerable. Version 1.0.1 was released March 2012. Version 1.0.1g was released today and is immune (many distributions have not yet released updates, but they should become available within 24 hours). Versions prior to 1.0.1, such as 1.0.0 and the 0.9.x variants do not include this specific vulnerability.
You can check what version you have by running openssl with the version switch:
# openssl version
OpenSSL 1.0.1f 6 Jan 2014 (vulnerable)
This bug is specific to OpenSSL only. Microsoft products may not be affected, however Windows products which utilise OpenSSL may be affected. Most Linux and unix variants utilise OpenSSL.
It is worth determining what risks this presents to your organisation. As the private key can be compromised and traffic decrypted, consider whether a new private key should be issued and signed by CA (once the server has been patched).
IT Management - Security Considerations when permitting corporate use of Facebook, YouTube, Twitter and other Social Media
Recently, a client of ours requested some information regarding security considerations should a corporation permit employees to use social media such as Facebook, YouTube, Twitter and other sites.
It is a common problem. There are a few issues here which need to be considered;
1) Yes there are cross-site scripting issues with the websites. But the vulnerabilities are in the websites themselves, so youtube.com, facebook.com and twitter.com are managed by internal staff - if they are vulnerable then everybody is. It is really out of your control. The worms use to propagate, such as the recent Facebook worm which was posting adult images, abuse the [zero-day] vulnerability in the website... eventually the sysadmins discover the worm and close the gap.
4) There is the crossdomain.xml policy - http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html. This is dependent on the website.
5) Researchers occasionally uncover browser vulnerabilities which breach the internal browser cross-domain security policy... so the result may be a vulnerability despite proactive protections and hardened configuration.
6) Antivirus vendors such as TrendMicro provide browser add-ons which check and report all URLs accessed by clients world-wide. The Trend Micro Threat Intelligence cloud and other reputable AV companies will notice the worm after a handful of end-users report the malicious action of a site. In this case, a few users will be infected but after the cloud picks up on this, the URL will be blacklisted globally until the threat is eliminated, thus protecting end-users providing you're not the first few visitors to be infected.
7) Obviously if you have a HTTP AV / Content Filter proxy then this may detect some worms.
So to summarise, there are many different preventative measures you can take to avoid infection. Implementing all of the above may significantly reduce your risk, but after all is said and done, if the youtube.com / facebook.com / twitter.com domains are vulnerable, you are waiting on them to provide a fix.
If there is a known, unpatched worm spreading and the media has alerted users like the recent facebook adult photos and dead animals worm, you could temporarily ban access to those sites on the firewall until the worm is cleared to try and protect staff.
Another matter worth considering is whether there is a risk of staff seeing objectionable material such as pornography from the worm and the staff going on stress leave, workers compensation or suing for psychological damages etc etc.
Some organisations try to minimise law suits by implementing strict policies about what to do when someone sends you pornographic material and you unexpectedly open it. There is paper work to complete including who sent the email (they are permanently added to a blacklist), listing all who received the email, any 3rd parties that saw it on your screen, ensuring that email archive / data backup staff store the offending email if needed for court on tape, and email admin staff forcibly deleting copies from staff inboxes by conducting email audits.
Hopefully this gives you some insight into corporate considerations prior to blanket access of social media websites for staff.
The portal requires users submit a username and password to authenticate. This communication is not encrypted.
Check the HTML source code on the form page, and examine whether the FORM ACTION is GET/POST to a HTTPS:// URI.
1) Enable SSL and disable HTTP for the portal
2) Use two-factor tokens (one time password) for strong authentication.
3) Modify the HTML source to ensure the data is POST'ed to a HTTPS URL.