Last weekend, a critical vulnerability has been found in Apache Log4j, also named Log4Shell (formally known as CVE-2021-44228). Many web applications and other systems globally use this software which could cause serious damage in a very short timeframe.
What is Log4J?
Log4J is a widely used component in all kinds of environments. It has recently become known that a serious vulnerability exists that impacts many other products, applications and systems, because it is embedded in many software solutions. So, we would like to suggest some steps that you can take to lessen the risk and mitigate this issue.
How does Log4Shell work?
But first it is important to understand the problem. It works like this: if an attacker can get a specific attack string logged through log4j, this string will trigger log4j to make a connection to an attacker-controlled host, and download a piece of attacker-provided code and execute that. So what kinds of things are logged? Quite a lot, it turns out! Could be a username, an email header, a website cookie, really anything could get logged somewhere along the way.
The point is, an attacker can spray the strings around and hope it will find vulnerable components at some time. At the time of this writing, vulnerable products include many mainstream solutions: Jira, Confluence, Splunk, Elastic, VMWare vCenter and many more.
Luckily the Dutch NCSC is tracking known vulnerable software. They are also providing IOCs and mitigations. So instead of providing these here, we will redirect everyone to their repository.
Steps to Take
- Figure out where you are using log4j or a vulnerable product that uses log4j. Check the list regularly because it is updated continuously!
- Patch your software, or apply one of the mitigations mentioned in the link to the NCSC GitHub repo. Don’t forget: it’s not just internet-facing systems that can be attacked.
- If you can’t patch or mitigate, make sure that a vulnerable server cannot make an internet connection as a temporary solution.
- Configure your IDS and SIEM to block the IOCs and implement detection rules, again we refer to https://github.com/NCSC-NL/log4shell for this information (and keep it up to date because there are also many ways to bypass the detection rules).
- If you have indications of compromise of a server, take standard incident response and forensic measures: isolate, contain and investigate.
Frequently Asked Questions about our Products
Q: Is one of our products, like SafeSign IC, BlueX or ConsentID hit by the Log4j Vulnerability (CVE-2021-44228)?
A: No, this vulnerability does not hit our software. But could be affect other components in the environment of our customers.
Q: How can I be sure my CA has not been hit?
A: The CAs known to us have not been affected, but if in doubt you can consult your supplier.
Q: If my CA is vulnerable, what should I do?
A: Invalidate the certificate signed by the CA and apply the necessary patches or bypass the logging (available from AET).
Q: What should I check afterwards?
A: After deploying the patch, it is best to revoke and reissue the issued certificates from a week ago. AET can help you with that.
Further Updates
We will update this page when new developments or information become relevant. For our customers, please contact us if you have any questions concerning this vulnerability.
Fonte: A.E.T.Europe B.V.
AET Europe é líder global na área de soluções de segurança digital.
Fundada em 1998, é especializa na criação de soluções seguras em identificação, autenticação, assinatura digital, consentimento e gerenciamento de credenciais
Fornecemos soluções de segurança para identificação de usuários, autenticação e assinaturas digitais. Outras informações https://aeteurope.com
Leia outros excelentes artigos da AET Europe aqui!
INTERNATIONAL NEWS
Crypto ID publishes international articles about information security, digital transformation, cyber security, encryption and related topics.
Please check here!
