»Værste sårbarhed i mindst 10 år« udløser kapløb mellem hackere og it-sikkerhedsfolk

13. december 2021 kl. 10:136
»Værste sårbarhed i mindst 10 år« udløser kapløb mellem hackere og it-sikkerhedsfolk
Illustration: Rasmus Meisler.
En fejl i Log4j-softwaren har udløst et kapløb mellem it-sikkerhedsansvarlige og hackere. »Værste sikkerhedssårbarhed i mindst 10 år,« siger CTO i stort cybersikkerhedsfirma.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

En fejl i Log4j-softwaren kan give hackere uhindret adgang til mange systemer og har udløst en presserende advarsel fra den amerikanske regerings cybersikkerhedsagentur. Fordi den fejlbehæftede computerkode er indbygget i mange forskellige typer software, er det en omhyggelig proces at opdatere den.

Det skriver Bloomberg.

»For at være klar, udgør denne sårbarhed en alvorlig risiko,« siger Jen Easterly, der er direktør for US Cybersecurity and Infrastructure Security Agency, i en pressemeddelelse. Leverandører »skal straks identificere, afbøde og lappe den brede vifte af produkter, der bruger denne software.«

»Det er sandsynligvis den værste sikkerhedssårbarhed i mindst 10 år – måske længere,« siger Charles Carmakal, der er CTO for cybersikkerhedsfirmaet Mandiant.

Artiklen fortsætter efter annoncen

Blandt andre it-virksomheden Cisco har offentliggjort en vejledning om fejlen, og softwareudviklere udgav en rettelse i slutningen af sidste uge. Men en løsning afhænger af, at tusindvis af virksomheder implementerer rettelsen, før hackere udnytter den.

Det er nonprofit-organisationen Apache Software Foundation, der vedligeholder Log4j-softwaren, og som blev gjort opmærksom på fejlen af kinesiske Alibaba.

6 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
6
15. december 2021 kl. 15:33

Det er selvfølgelig ene gode principper I opremser men vi ved jo alle godt at de fleste servere faktisk er direkte på nettet (gennem nat/firewall) for let at kan administreres, kan køre Windows Update, kan snakke med licensservere osv..

Joo ... men jeg vil gerne at virksomheder ændrer opførsel fordi de er urimeligt udsatte sådan som det er nu.

Derfor er opgaven at indkøbe en eller flere kraftige firewalls sådan at man kan begrænse traffikken mellem servere. At lukke alle porte på de enkelte servere der ikke er krævet. At flytte management trafikken over på et seperat netværk. At sikre at administratorer ikke sidder på management netværket men fx. bruger en jump server når de skal den vej.

Med hensyn til Windows Update så kan man ganske rigtigt køre sin egen server men hvis det er uoverkommeligt for en virksomhed, så kan man begrænse trafikken til de IP adresser som DNS giver for de relevante domæner. Og så skal man lige sikre at DNS i dette tilfælde ikke spoofes. Men det er et mere generelt issue.

5
15. december 2021 kl. 09:00

Og så ender det med serveren bare kører på netværket, i bedste fald et dedikeret servernetværk.

Ingen har foreslået at servere ikke er forbundet til netværket. HVIS de kører en service der skal kunne nås fra internettet - skal den selvfølgelig udstilles igennem f.ex. en loadbalancer - men så må man putte sine sikkerhedslag omkring serveren (og processerne der kører denne service).. Så servicen f.ex. IKKE kører som administrator/root.. Så den måske er lukket ind i en "docker".. og begrænse hvad serveren kan nå rent netværksmæssigt osv.

Windows update - kan jo bare bruge din egen WSUS server - så behøver den ikke adgang til internettet - og det er den bedste måde at styre opdateringer til windows på alligevel.

Hvis man vælger at ignorere de manglende sikkerhedslag - så ligger man jo som man har redt - og har forhåbentlig de risici med i sine forretningsmæssige overvejelser - pris * sandsynlighed for at "uheldet" sker.. (+ GDPR bøde hvis der er persondata på serveren - eller noget den har fri adgang til) osv.

Alle bør lave en økonomisk afvejning af dette - og sætte deres sikkerhedsniveau derefter.

Det er de færreste der "har styr på det hele" - men hvis ikke man konstant arbejder sig i mod de mål man sætter sig her - så er der noget helt galt. Det gode her, er at så kan ledelsen jo også se at de ikke har nok ansatte til at sikre virksomhedens IT underlag tilstrækkeligt. Listen af firmaer der er gået under fordi de ikke havde styr på deres IT (og noget gik galt der lagde dem i graven) bliver længere og længere.. og med cryptolocker angreb vokser den bare yderligere.

4
14. december 2021 kl. 19:46

Det er selvfølgelig ene gode principper I opremser men vi ved jo alle godt at de fleste servere faktisk er direkte på nettet (gennem nat/firewall) for let at kan administreres, kan køre Windows Update, kan snakke med licensservere osv..

Og så ender det med serveren bare kører på netværket, i bedste fald et dedikeret servernetværk.

Så at tro at alle servere selvfølgelig er komplet galvanisk afkoblet fra nettet er vist naivt.

3
13. december 2021 kl. 18:07

Det kan strammes endnu mere: Det viser værdien af filtrering af alt ikke eksplicit tilladt trafik til og fra servere. Uanset om den anden ende er intern eller ekstern.

Principle of least priviledge er bestemt altid relevant.. herunder egress filtrering, men jeg formoder at man også har ingress filtrering, begrænsning af rettigheder (f.ex. at applikation ikke kører som root bruger osv. osv.). Sikkerhed har mange lag :)

2
13. december 2021 kl. 17:02

Men det er en meget grel sårbarhed - og viser bare (endnu en gang) - værdien af egress filtrering - ingen trafik tilladt ud per default.

Det kan strammes endnu mere: Det viser værdien af filtrering af alt ikke eksplicit tilladt trafik til og fra servere. Uanset om den anden ende er intern eller ekstern.

I den specifikke sammenhæng: for de fleste servere vil det absolut ikke give mening at lave HTTP requests mod hverken de fleste interne eller eksterne IP adresser.

1
13. december 2021 kl. 11:53

De fleste har forhåbentlig spærret for internetadgang fra deres servere - og så er det heldigvis ikke så nemt at udnytte sårbarheden til noget (da den skal kunne nå en url som den kan downloade fra).

Men det er en meget grel sårbarhed - og viser bare (endnu en gang) - værdien af egress filtrering - ingen trafik tilladt ud per default.