Vulnerabilities and gaps in an application’s system are nothing unusual and can often be resolved before any damage is done or a large-scale warning is issued. If you follow changelogs and software updates from time to time, you may sometimes find an entry stating that a potential security leak has been fixed – all-clear, don’t worry, everything is under control, no harm done.
With the vulnerability in Log4j, things are different.
The European Union Agency for Cybersecurity published a statement on December 15, 2021 which confirms that the situation is extremely critical.
That’s because the vulnerability was discovered in server software used by many online services, businesses and federal agencies whose server applications are based on JAVA. And that’s really a very, very large number. Even the Mars robotic helicopter Ingenuity uses Log4j, which was announced as an interesting side note on Twitter as recently as June, and has suddenly opened doors to hackers as the first prominent vulnerability outside of Earth. Let’s be honest: Did it need to happen in the middle of Covid, too?
How can the Log4j problem harm your conference data?
Data that is not publicly accessible but is protected on a server is always particularly attractive to an attack. This is usually data on participants, speakers, or sometimes also the scientific contributions that have to be reviewed in advance of the conference and stored in the system for this purpose. However, the applications themselves can also be affected, as they may no longer be accessible after a successful attack. Virtual and hybrid conferences, in which almost everything takes place digitally, are particularly at risk, because as soon as the conference software is affected, nothing is safe anymore.
The danger level is even higher in the Log4j case because it is not that difficult for attackers to get onto the server. Due to the security hole in the programming, precautions such as firewalls can now unfortunately be bypassed. To do this, attackers first enter a string of characters that is then passed to the server, which does not recognize any malicious intent behind it.
This happens, for example, when someone enters a string of characters in the registration form for a conference instead of the name that is actually required, and the server simply waves it through. The only difference is that the string is not a meaningless series of letters, numbers and special characters, but a specific command that the server then executes, giving access to someone who has no business being there, but who can now install malware or access conference data.
What does this mean for my conference in concrete terms?
Unfortunately, organizers can hardly do anything themselves if the conference data is managed by a software provider. In this case, it is primarily the provider’s responsibility to take appropriate security measures.
Security updates are now available, but they have to be installed by the vendor itself, as soon as possible and for every application that is based on JAVA and uses the Log4j library.
To be able to do this, a detailed inventory on the conference software vendor’s site is necessary. Not all applications are always automatically provided with the latest updates. In normal circumstanes, it can be even better to wait to install updates because from time to time it happens that updates bring problems with regard to certain functions, which are only observed once a problem arises.
As long as this is the case with Log4j, the door is still open, which may not be used immediately by attackers, but for which they are already quietly taking precautions to keep it open as long as possible. The actual attack may not take place until a few months from now, when no one is talking about the Log4j problem anymore.
Is Converia also at risk?
We immediately asked ourselves to what extent Log4j could be dangerous for the conferences we support and to what extent our system is now vulnerable. However, the all-clear came from the development department: Neither our classic conference management software Converia nor our Virtual Venue are affected by the Log4j problems. Neither of the two products are based on JAVA, nor do we use individual JAVA components for them. Among our complementary products there are some, such as our print server, which is based on JAVA. However, this does not integrate the Log4j library and therefore does not pose such an attack risk, like other components.
There is also an all-clear for conferences for which we provide hosting. Our host server has already initiated appropriate measures and installed security updates. This also revealed that no components have been directly affected so far. However, we are still checking and monitoring in order to be able to identify and rectify any vulnerabilities immediately, so that the systems and data remain secure and event organizers have nothing to fear.
Do you have additional, perhaps more specific questions about Log4j and your conference? We are happy to help.