Der har været en del snak på nettet om sårbarheden i Log4J, der tillader en angriber at udløse vilkårlig kodekørsel eksternt hvis du har mulighed for at sende data til et program, der bruger log4j-biblioteket til at logge hændelsen.
Dette angreb kan gøres uden at blive godkendtFor eksempel ved at udnytte en godkendelsesside, der logger godkendelsesfejl.
Denne fejl har sat virksomheder med speciale i cybersikkerhed til at arbejde på begivenheden og indikerer, at antallet af angreb, der udnytter denne fejl, er stigende.
Medlemmerne af Apache Software Foundation har udviklet en patch for at rette op på sårbarheden og det er version 2.15.0, udover at der også er gjort kendte mulige løsninger til at mindske risiciene.
Hvad er Apache Log4j? Hvor alvorlig er fejlen?
For dem, der stadig ikke ved, hvor alvorligt problemet er, kan jeg fortælle dig det Den 9. december blev der opdaget en sårbarhed i lat optage bibliotek log4j Apache.
Dette bibliotek meget brugt i applikationsudviklingsprojekter Java / J2EE samt Java / J2EE-baserede udbydere af standardsoftwareløsninger.
log4j indeholder en søgemekanisme, der kan bruges til at forespørge via speciel syntaks i en formatstreng. For eksempel kan den bruges til at anmode om forskellige parametre såsom versionen af Java-miljøet via $ {java: version} osv.
Angiv derefter jndi-nøglen i strengen, søgemekanismen bruge JNDI API. Som standard foretages alle anmodninger med præfikset java: comp / env / *; dog implementerede forfatterne muligheden for at bruge et tilpasset præfiks ved hjælp af et kolon i nøglen.
Det er her sårbarheden ligger: sijndi: ldap: // bruges som nøglen, anmodningen går til den angivne LDAP-server. Andre kommunikationsprotokoller såsom LDAPS, DNS og RMI kan også bruges.
Derfor kan en fjernserver styret af en angriber returnere et objekt til en sårbar server, hvilket kan føre til vilkårlig kodekørsel på systemet eller fortrolig datalækage.
Alt en angriber skal gøre er at sende en speciel streng Gennem mekanismen, der skriver denne streng til en logfil og derfor administreres af Log4j-biblioteket.
Dette kan gøres med simple HTTP-anmodninger, for eksempel dem, der sendes via webformularer, datafelter osv., eller med enhver anden form for interaktion ved hjælp af registrering på serversiden.
Tenable karakteriserede sårbarheden som "den vigtigste og mest kritiske sårbarhed i det sidste årti."
proof of concept er allerede blevet offentliggjort. Denne sårbarhed udnyttes nu aktivt.
Sværhedsgraden af sårbarheden er Maks 10 på CVSS-skalaen.
Her er listen over berørte systemer:
- Apache Log4j versioner 2.0 til 2.14.1
- Apache Log4j versioner 1.x (forældede versioner) er underlagt speciel konfiguration.
- Produkter, der bruger en sårbar version af Apache Log4j - europæiske nationale CERT'er opretholder en komplet liste over produkter og deres sårbarhedsstatus
CERT-FR anbefaler at foretage en grundig analyse af netværksloggene. Følgende årsager kan bruges til at identificere et forsøg på at udnytte denne sårbarhed, når det bruges i URL'er eller visse HTTP-headere som brugeragent
Til sidst er det værd at nævne det det anbefales kraftigt at bruge log2.15.0j version 4 så hurtigt som muligt.
Men i tilfælde af problemer med at migrere til denne version, kan følgende løsninger blive anvendt midlertidigt:
For applikationer, der bruger version 2.7.0 og nyere af log4j-biblioteket, er det muligt at beskytte mod ethvert angreb ved at ændre formatet på de hændelser, der vil blive logget med syntaksen% m {nolookups} for de data, som brugeren vil levere .
Denne ændring kræver ændring af log4j-konfigurationsfilen for at producere en ny version af applikationen. Derfor kræver dette, at de tekniske og funktionelle valideringstrin gentages, før denne nye version implementeres.
For applikationer, der bruger version 2.10.0 og nyere af log4j-biblioteket, er det også muligt at beskytte mod ethvert angreb ved at ændre konfigurationsparameteren log4j2.formatMsgNoLo