This week, SAP AG published a hot news item titled: “SAP Security Note 2067859 (Potential Exposure to Digital Signature Spoofing)”, which alerts users about a potential vulnerability in certain cryptographic libraries used in SAP NetWeaver Application Server ABAP and SAP HANA. By abusing these libraries, an attacker could potentially spoof (i.e., successfully masquerade as a legitimate user) Digital Signatures produced in vulnerable systems.
To ensure your SAP systems are not vulnerable, you should check that your crypto libraries versions are equal or higher than:
- SAPCRYPTOLIB version 5.555.38
- CommonCryptoLib version 8.4.30
SAPSECULIB has been deprecated, and must be replaced by the latest SAPCRYPTOLIB version.
Stack kernel 720 PL#700 already comes with the fixed CommonCryptoLib
Note: As stated in the SAP Security Note 2067859, you should replace the DSA PSEs on all the involved SAP NetWeaver Application Server ABAP and SAP HANA systems. Also, remember to replace the system public keys in their signature trusting systems as an additional security measure.
By now I am sure you have seen the public posting with details and a how-to guide regarding an exploitable SAP vulnerability in a major organizations’ internet facing website. It is always disheartening to see a company exposed in this way. It is a cliché (though truth be told I tend to think clichés have an element of truth to them) but when I read about this type of event and the recent Target breach I look for the teachable moment or lessons I can learn. Good security is an ounce of prevention and a dash of luck, and the more you can learn about appropriate preventions the less luck you will need.
When thinking about this event I actually thought of five teachable elements I can use to provide support for my security approach and philosophy. I wanted to start a discussion about SAP and security, something which has only recently been discussed, and review the silent points from what has occurred thanks to the Full Disclosure posting and WooYun report from the Chinese hacker known as Finger.
This event touches on a couple important areas:
- Responsible disclosure
In the posting they cite the date 2013-11-21 as when they submitted a report to the vendor and 2014-01-05 as the date they published the details of the vulnerability and how to exploit it on NVIDIA’s servers, despite the vulnerability not having been addressed, due to a lack of a response. This is less than two months (during a busy holiday season) and it is unclear how many times they attempted to contact the security team. While I agree that it is important to get vulnerability information public so issues can be addressed I think it is more important to do so responsibly. Typically attackers/cyber criminals have less change control processes to go through and can weaponize and take advantage of this information long before organizations have been able to test and apply the remediation across their environment. In fact Mariano Nunez, Onapsis CEO, has said “It is critical when you have information that could cause harm to companies effected that you make best efforts to ensure that information is communicated to those companies along with the information needed to remediate those issues before making that information publicly known.”