WAS | WebSphere 전체 Log4j 보안 취약점 관련 내용 정리

WebSphere 전체 Log4j 보안 취약점 관련 내용 정리

Security Bulletin: Multiple vulnerabilities in Apache log4j affect the IBM WebSphere Application Server and IBM WebSphere Application Server Liberty (CVE-2021-4104, CVE-2021-45046)

---

Affected Products and Versions

Affected Product(s)	Version(s)
WebSphere Application Server Liberty	Continuous delivery
WebSphere Application Server	9.0
WebSphere Application Server	8.5
WebSphere Application Server	8.0
WebSphere Application Server	7.0

관련 취약점 내용

아래의 이슈 사항을 확인 해보면 되지만 간략하게 정리 했습니다. 전체 플랫폼의 이슈되는 APP는 UDDI.ear 이면 기본적으로 구성을 위해 별도의 설치가 필요합니다.(미 사용중이라 영향도 없음)

결국 9.x kc.war 문제가 되며 해당 APP 경우 관리콘솔 도움말에 사용중 인 것으로 보이며, 문제가 되는 클래스 제거하거나 라이브러리를 제거 하는 식으로 임시 조치를 취하고 있습니다.

1. WebSphere Application Server traditional release 9.0 only:

Remove <WAS_HOME>/systemApps/isclite.ear/kc.war/WEB-INF/lib/log4j*.jar from any system running the WebSphere admin console and restart the application server.
Note: If any future service (prior to 8.5.5.21 or or 9.0.5.11) is applied to the install the log4j files will be restored without warning.
If the kc.war application has been installed then uninstall it. For instructions on how to determine if kc.war is installed see question Q9 in our Log4Shell (CVE-2021-44228) FAQ.
Remove <WAS_HOME>/installableApps/kc.war

2. All WebSphere Application Server traditional releases:

Users of the UDDI Registry Application: Remove log4j*.jar from within the <WAS_HOME>/installableApps/uddi.ear
archive and update (redeploy) any installed (deployed) copies of the UDDI Registry application.
Users who do not use the UDDI Registry Application should remove <WAS_HOME>/installableApps/uddi.ear

IBM 보고된 내용 링크
https://www.ibm.com/support/pages/node/6526750

3. Log4j 1.x 추가 사항

웹스피어의 경우 이경우가 UDDI.ear 따로 해당 기능을 사용하지 않으면 추가적인 조치가 필요 없음)

Is Log4j 1.x vulnerable

There is still a lot of information coming out surrounding Log4Shell. At the time this blog was published, Apache said that Log4j 1.2 is vulnerable in a similar way when Log4j is configured to use JMSAppender, which is not part of the default configuration, but is not specifically vulnerable to CVE-2021-44228. This vulnerability in Log4j 1.2 has been assigned CVE-2021-4104.

Is there a patch available for Log4j 1.2?

No, Log4j branch 1.x has reached end of life (EOL) status, and therefore does not receive security updates. Users are instructed to upgrade to Log4j 2.12.2 (for Java 7) or 2.16.0 or greater.

How do I address CVE-2021-4104?

There are a few mitigation options that can be used to prevent exploitation of CVE-2021-4104.

• Do not use the JMSAppender in the Log4j configuration
• Remove the JMSAppender class file (org/apache/log4j/net/JMSAppender.class)
• Limit OS user access to prevent an attacker from being able to modify the Log4j configuration

WAS | WebSphere 보안 취약점 관련 access Log 설정

WebSphere 보안 취약점 관련 access Log 설정

---

Test Environment

• Test Version : WebSphere v8.5

---

NCSA access Log and HTTP error log set up

HTTP Access

1. 전체 로그 설정

• Click Servers > Server Types > WebSphere application servers > server_name > NCSA access and HTTP error logging.
• Select Enable logging service at server start-up.
• Ensure that Enable access logging is selected.

2. 컨테이너별 로그 설정 part 1

• Application servers > server1 > Web container transport chains > HttpQueueInboundDefault > HTTP inbound channel (HTTP_2)
• Select Enable logging.

3. 컨테이버별 로그 설정 part 2

• Application servers > server1 > Web container transport chains > WCInboundDefault > HTTP inbound channel (HTTP_2)
  

로그 포맷 변경시

참조 링크

https://www.ibm.com/support/knowledgecenter/ko/SSEQTP_8.5.5/com.ibm.websphere.base.doc/ae/ttrb_access_logging.html

설정 위치

• Go to the custom properties page for the wanted transport chain. Click Servers > Server Types > WebSphere application servers > server_name > Web Container Settings > Web container transport chains > chain_name > HTTP_channel_name > Custom properties.

• Costum properties

  • key

  accessLogFormat

  • value

  %h %u %t "%r" %s %b %D "%{Referer}i" "%{User-agent}I" %{JESSIONID}C
  %h %i %u %t "%r" %s %b %D

WAS | How to disable server name header

WebSphere - How to disable server name header

Test Version

• Test OS : CentOS 7.2
• Test WAS : WebSphere v8.5

X-Powered-By disable setting

• 보안 취약점 사항

• IBM HTTPServer (apache)
  This can be mitigated by adding (httpd.conf):

AddServerHeader Off
ServerTokens Prod
ServerSignature Off

• WebSphere
  v8.5.0.2 이하 버전에서는 두가지 옵션으로 server version 노출을 방지.

• ServerHeaderValue :
  Use the ServerHeaderValue property to replace the default value of the Server header that is added to all outgoing HTTP responses by server if a Server header does not already exist. The default value for the Server header is WebSphere Application Server v/x.x, where x.x is the version of WebSphere Application Server that is running on your system.

• RemoveServerHeader :
  Use the RemoveServerHeader property to force the removal of any server header from HTTP responses that the application server sends, thereby hiding the identity of the server program.

setting link : https://www.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.base.doc/ae/rrun_chain_httpcustom.html

Starting with Version 8.5.0.2, a Server header is no longer automatically added to all outgoing HTTP responses if a Server header does not already exist. If you add this property with a value, that value is included in the Server header that appears in the response. If you specify the value DefaultServerValue, WebSphere Application Server v/x.x is used as the Server header value.

WebSphere - How to disable X-Powered-By header

WebSphere - How to disable X-Powered-By header

Test Version

• Test OS : CentOS 7.2
• Test WAS : WebSphere v.8.5

X-Powered-By disable setting

• 보안 취약점 사항

You can set the property 'com.ibm.ws.webcontainer.disablexPoweredBy' to true as described in the section

setting link : https://www.ibm.com/support/knowledgecenter/ko/SSAW57_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/rweb_custom_props.html#com.ibm.ws.webcontainer.DisableXPoweredByHeader

설정 이후 서버 재 기동 필요.