Vulnerabilities and gaps in an application's system are nothing unusual and can often be closed before any damage occurs or a widespread warning is even necessary. Those who occasionally follow changelogs and software updates might sometimes spot an entry noting that a potential security leak has been fixed—all clear, no worries, everything is under control, nothing happened.
The Log4j vulnerability is different.
When the Federal Office for Information Security raised the alert level to red, the situation became extremely critical.
This is because the security gap was discovered in server software used by many online services, companies, and government agencies whose server applications are based on JAVA. And that is a very, very large number. Even the Mars helicopter Ingenuity uses Log4j, which was mentioned as an interesting side note on Twitter back in June, though later disputed. The vulnerabilities, whether prominent or not, still exist. And honestly—if these can open doors for hackers even off-planet: Was this really necessary in the middle of a pandemic?
What damage can the Log4j problem cause to conference data?
Data that is not publicly accessible but stored securely on a server is always particularly attractive. This usually includes data on participants, speakers, or sometimes even scientific papers that must be reviewed and stored in the system prior to the conference. However, the applications themselves can also be affected and may become inaccessible after a successful attack. Virtual and hybrid conferences, where almost everything takes place digitally, are particularly at risk, because as soon as the conference software is compromised, nothing is secure anymore.
The danger in the Log4j case is even higher because it is not that difficult for attackers to access the server. With the help of this security gap, precautions like firewalls can now unfortunately be bypassed. To do this, attackers simply enter a string of characters that is then passed to the server, which initially does not recognize any malicious intent behind it.
This happens, for example, when someone enters a string of characters into a conference registration form instead of the requested name, which the server then innocently waves through. The problem is that this string is not just a meaningless sequence of letters, numbers, and special characters, but a specific command that the server then executes, granting access to someone who has no business being there and can now install malware or scrape conference data.
What does this mean for my conference specifically?
Unfortunately, organizers can do very little themselves if their conference data is managed by a software provider. In that case, it is primarily the provider's responsibility to take appropriate security measures.
Security updates are now available, but they must be installed by the provider themselves as quickly as possible for every application that is based on JAVA and uses the Log4j library.
To do this, a detailed inventory on the part of the conference software provider is necessary. Not all applications are automatically equipped with the latest updates. Often, it is even better to wait and see. Occasionally, updates can cause functional issues that are only observed over time, or the installation of updates is simply forgotten or delayed for other reasons.
As long as that is the case with Log4j, the door remains open—perhaps not immediately used by attackers, but they may be quietly making preparations to keep it open for as long as possible. The actual attack might not happen until months later, when no one is talking about the Log4j problem anymore.
Is Converia also at risk?
We also immediately asked ourselves to what extent Log4j could pose a danger to the conferences we manage and whether our system is vulnerable. However, our development department quickly gave the all-clear: Neither our conference software Converia nor our Virtual Venue solution for virtual and hybrid conferences are affected by the Log4j issues. Neither of these two products is based on JAVA, nor do we use individual JAVA components for them. While some of our supplementary products, such as our print server, are based on JAVA, they do not incorporate the Log4j library and therefore, like all our other components, do not pose such a security risk.
There is also an all-clear for conferences for which we handle the hosting. Our host has already taken appropriate measures and installed security updates. It also turned out that no components were directly affected. However, we continue to monitor and check the situation to identify and fix any potential vulnerabilities immediately, ensuring that systems and data remain secure and organizers have nothing to fear.
Do you have any further, perhaps more specific questions about Log4j and your conference? We are happy to help.
