VMSA-2021-0028 | Workaround in vRealize Operations 8.x (87076)

By Lerpong Intaraworrapath | January 17th ,2022

Workaround instructions to address CVE-2021-44228 and CVE-2021-45046 in vRealize Operations 8.x (87076)

ในบทความนี้ เราจะมาทำ workaround ในการแก้ปัญหา instructions to address CVE-2021-44228 and CVE-2021-45046 in VMware vRealize Operations Manager 8.x โดยจะ followup วิธีการ จาก KB87076.

https://kb.vmware.com/s/article/87076

Note: ในส่วนของ Product อื่นของ VMware และ ข้อมูล CVE-2021-44228 and CVE-2021-45046 ให้ อ่านได้จาก VMSA-2021-0028.

Impact / Risks

  • Recommended ให้ take snapshots vRealize Operations ทุก nodes ก่อน apply workaroundโดยสามารถ ทำตามได้จาก link How to take a Snapshot of vRealize Operations.
  • Mitigation จะยังคงเกิดขึ้นอยู่ ถ้ามีการ installed management pack หรือ activated หลังจาก apply patch. แนะนำให้ installed หรือ activated ให้เรียบร้อยก่อน แล้วถึงจะทำการ apply workaround.
  • การ appy workaround แนะนำให้ reapplied หลังจากมีการ deploying หรือ updating new vRealize Operations nodes or Cloud Proxies ที่ไม่มี bug fixed.
  • Mitigation ของ WAR files จะยังคงเกิดขึ้นอยู่ ถ้ามีการ redeployed vRealize Operations.

Resolution

This issue is resolved in the following releases:

Workaround ในบทความนี้เป็น Temporary solution เท่านั้น แนะนำ.

Workaround

Notice: The below content has been updated as of 12/15/2021 to add workaround steps for the related CVE-2021-45046 as noted above.  Please re-run all of the below steps even if you have already implemented the original CVE-2021-44228 workaround steps by running the data-rc-witness-log4j-fix.sh and cp-log4j-fix.sh scripts.

ในบทความนี้เราจะทำการ apply workaround สำหรับ “vRealize Operations Manager version 8.4.0” โดยจะประกอบ ด้วย
-Analytic (Primary, Replica, Data), Remote Collector 2 nodes จำนวนทั้งหมด 5 nodes (จะไม่มี Cloud Proxies).

โดยเราจะ ใช้ 2 scripts ด้วยกัน data-rc-witness-log4j-fix.sh and vrops-log4j-fix.sh โดย download ได้จาก KB87076

1.ทำการ Log in to the vRealize Operations Manager Admin UI โดยใช้ local admin user (https://vROPs-Name or vROPs-IP/admin).

2.ทำการ Click “TAKE CLUSTER OFFLINE” under Cluster Status.

Note: Wait for Cluster Status to show as Offline.
ถ้าเราพบว่าหน้า vROPs admin จะไม่สามารถ access ได้ ให้เรา access โดยตรงไป ที่ vROPs Master node IP address (https://vROPs-Master node name or IP address/admin).

3.ทำการ take snapshots vRealize Operations nodes ทั้ง 5 nodes [Analytic (Primary, Replica, Data), Remote Collector 2 nodes] ก่อนจะ apply workaround (How to take a Snapshot of vRealize Operations.).

4.ทำการ copy file data-rc-witness-log4j-fix.sh และ vrops-log4j-fix.sh ไปที่ path /tmp ของ vROPs ทั้ง 5 nodes [Analytic (Primary, Replica, Data), Remote Collector 2 nodes] โดยอาจจะใช้ SCP หรือ Tools ที่สามารถ copy file ได้.

5.เราจะ เริ่มทำที่ Master nodes เป็นตัวแรกก่อน.

6.ให้เรา SSH หรือ Console โดยใช้ root login account ในการ access.

7.ทำการ cd ไปที่ patch /tmp แล้วทำการตรวจสอบ ดูว่าทั้ง 2 files ปรากฏ อยู่ใน path ครบไหม.

8.ทำการ run command เพื่อสามารถจะ execute scripts data-rc-witness-log4j-fix.shได้.
chmod +x data-rc-witness-log4j-fix.sh

9.ทำการ run command เพื่อสามารถจะ execute scripts vrops-log4j-fix.shได้.
chmod +x vrops-log4j-fix.sh

10.ทำการ run command execute scripts “data-rc-witness-log4j-fix.sh“.
./data-rc-witness-log4j-fix.sh

Note: ให้ตรวจสอบให้แน่ใจหลังจาก run command จะต้องไม่มี ERROR (NO ERROR).

11.ทำการ run command execute scripts “./vrops-log4j-fix.sh“.
./vrops-log4j-fix.sh

Note: ให้ตรวจสอบให้แน่ใจหลังจาก run command จะต้องไม่มี ERROR (NO ERROR).

12.ทำการ restart the “CaSA service”:
service vmware-casa restart

Verify the change

ทำการ verify the workaround for CVE-2021-44228 ที่เราทำการ applied to vRealize Operations ว่าถูกต้องไหม ตาม step ด้านล่าง.

1.ทำการ run command สำหรับ verify ถ้า the data-rc-witness-log4j-fix.sh script สำเร็จ:
ps axf | grep --color log4j2.formatMsgNoLookups | grep -v grep

Note: โดยหลังจาก run command จะต้องมี output ออกมา; ถ้าไม่มี output ออกมาแสดงว่า applied workaround ไม่สำเร็จ.

2.ทำการ run command สำหรับ verify ถ้า the vrops-log4j-fix.sh script สำเร็จ:
./tmp/vrops-log4j-fix.sh

Note: ผลลัพธ์ ที่ได้จาก run command
Searching for impacted .jar files. Please wait…
No impacted .jar files found

Next step

ให้ทำการ Repeat Workaround step ตั้งแต่ข้อ 6 จนถึง Verify the change สำหรับ node ที่เหลือ อีก 4 nodes [Analytic (Replica, Data), Remote Collector 2 nodes].

Remark

โดยถ้า ท่านมี Cloud Proxies ก็ให้ทำ Cloud Proxies เพิ่มเติมจากใน KB87076 โดยใช้ script “cp-log4j-fix.sh” เพิ่มเติม.

Last step

หลังจากเราทำการ apply script ครบทุก node (ให้ตรวจสอบ ให้แน่ใจ ว่าเราทำครบทุก node).

1.ทำการ Log in to the vRealize Operations Manager Admin UI โดยใช้ local admin user (https://vROPs-Master node or vROPs-IP Master node/admin).

2.เราจะพบว่า cluster จะยังเป็น status offline.

3.ให้เราทำการ click “BRING CLUSTER ONLINE“.

4.ให้รอจน cluster status “ONLINE“.

5.แล้วหลังจากนั้นให้ login vROPs UI console.
https://vrops name or ip address/ui

Conclusion

ในบทความนี้จะเป็น workaround สำหรับ VMware vRealize Operations Manager 8.x เท่านั้น โดย fix version สามารถเข้าไป download และ apply ตาม version ที่ท่านใช้งานอยู่ โดย ให้ทุกท่านติดตาม VMSA-2021-0028 ในการทำ workaround หรือ fix version รวมถึง Product อื่นๆ ของ VMware ที่ได้รับผลกระทบ เช่นกัน.

VMSA-2021-0028 | Workaround in vCenter Server virtual appliance (87081, 87088)

By Lerpong Intaraworrapath | January 6th, 2022

Workaround instructions to address CVE-2021-44228 and CVE-2021-45046 in vCenter Server and vCenter Cloud Gateway (87081)

ในบทความนี้ เราจะมาทำ workaround ในการแก้ปัญหา instructions to address CVE-2021-44228 and CVE-2021-45046 in vCenter Server virtual appliance 7.x, 6.7.x, 6.5.x โดยจะ followup วิธีการ จาก KB87081 และ KB87088

https://kb.vmware.com/s/article/87081?lang=en_US
https://kb.vmware.com/s/article/87088

Note: ในส่วนของ Product อื่นของ VMware และ ข้อมูล CVE-2021-44228 and CVE-2021-45046 ให้ อ่านได้จาก VMSA-2021-0028

Impact / Risks

  • ให้ทำการ remove VCHA ก่อนทำการ run script.
  • environment ที่มี external PSCs จะต้องทำการ run script ทั้ง vCenter และ PSC appliances.
  • Restore จาก File-Based Backup จะทำให้ environment กลับสู่ vulnerable. ให้ใช้ vc_log4j_mitigator.py หลังจาก restore.
  • อัปเกรด vCenter Appliance จะทำให้ environment กลายเป็น vulnerable. ให้ใช้ vc_log4j_mitigator.py หลังจาก อัปเกรด vCenter Appliance.

Resolution

Workaround ในบทความนี้เป็น Temporary solution เท่านั้น.

Completed remediation scenarios:

จะมี 3 วิธีในการทำ workaround สำหรับ vCenter server virtual appliance. ให้เลือกทำ วิธีใดวิธีหนึ่งเท่านั้น

  1. Used vc_log4j_mitigator.py from KB87081.
  2. Used vmsa-2021-0028-kb87081.py script from KB 87088 and remove_log4j_class.py from this KB87081.
  3. Used the manual workaround steps in KB87081 and remove_log4j_class.py.

Note: ในบทความนี้ จะใช้ วิธีที่ 2Used vmsa-2021-0028-kb87081.py script from KB 87088 and remove_log4j_class.py from this KB87081.
โดยจะเป็น vCenter server virtual appliance version 7.0.1.00301

Workaround

Automated Workaround (Recommended)

  1. ทำการ take snapshot “vCenter server virtual appliance”.
  2. ทำการ check disk space available by command “df-h” (capture screen ไว้ด้วย).
  3. ทำการ check vCenter server service by command “service-control –status –all” (capture screen ไว้ด้วย).
  4. Download the script attached this KB 87088 (vmsa-2021-0028-kb87081.py )

5. Login to the vCSA using an SSH Client (using Putty.exe or any similar SSH Client)

6. Login to the vCSA using an SSH Client (using Putty.exe or any similar SSH Client)

7. Transfer the file to /tmp folder on vCenter Server Appliance using WinSCP
Note: It’s necessary to enable the bash shell before WinSCP will work

8. Provide the root user name and password when prompted.

9. Run this command to enable the Bash shell:
shell.set --enable True

10. Run this command to access the Bash shell:
shell

11. In the Bash shell, run this command to change the default shell to Bash:
chsh -s /bin/bash root

12. ทำการ copy ไฟล์ vmsa-2021-0028-kb87081.py และ remove_log4j_class.py โดยใช้ WinSCP ไปเก็บไว้ที่ /tmp

13. ทำการ Login to the vCSA using an SSH Client (using Putty.exe or any similar SSH Client) แล้วเข้าไปที่ path /tmp ใช้ “ls” command ทำการตรวจสอบไฟล์ ที่เราทำการ upload เข้าไป

14. ทำการ run script vmsa-2021-0028-kb87081.py
root@xxxx[/tmp]#python vmsa-2021-0028-kb87081.py

15. พิมพ์ Y แล้วกด Enter

16. Script ก็จะทำการ run process เพื่อจะทำ workaround เกี่ยวกับ CVE-2021-44228 and CVE-2021-45046 (ใช้เวลา10 นาที โดยประมาณ).
โดย script ก็จะแสดง status ของแต่ละ process และที่สำคัญจะต้องแสดงผล “SUCCESS”
-vMON Config files
-VMware Update Manager Config files
-Analytics service Config files
-DBCC Utility Config files

17. เมื่อทำการ run script แรก เสร็จเรียบร้อยแล้วให้ เรา run script ตัวที่ 2 คือ remove_log4j_class.py from this KB87081.
root@xxxx[/tmp]#python remove_log4j_class.py

18. พิมพ์ Y แล้วกด Enter

19. Script ก็จะทำการ run process เพื่อจะทำ workaround เกี่ยวกับ CVE-2021-44228 and CVE-2021-45046 (ใช้เวลา10 นาที โดยประมาณ).โดย script ก็จะแสดง status ของแต่ละ process

Verify the changes

เมื่อเราทำการ run script ทั้ง 2 scripts completed แล้วให้เราทำ การ ตรวจสอบให้แน่ใจว่า script ที่เรา run นั้นถูกต้อง

  1. Verify if the stsd, idmd, and vMon controlled services were started with the new -Dlog4j2.formatMsgNoLookups=true parameter:
    ps auxww | grep formatMsgNoLookups

โดย จะแสดง ผล -Dlog4j2.formatMsgNoLookups=true

2. Verify the Update Manager changes are shown under “System Properties” in the output of the following two commands:
cd /usr/lib/vmware-updatemgr/bin/jetty/
java -jar start.jar --list-config
system properties:
log4j2.formatMsgNoLookups = true (/usr/lib/vmware-updatemgr/bin/jetty/start.ini)

3. Verify the Analytics Service changes:
grep -i jndilookup /usr/lib/vmware/common-jars/log4j-core-2.8.2.jar | wc -l
โดย จะแสดงค่า “0

4. Verify the script successfully removed JndiLookup.class from all java files with the following command:
python remove_log4j_class.py -r

จะได้ผลลัพธ์ ดังนี้
2021-12-18T00:04:38 INFO main: Running in dryrun mode
2021-12-18T00:05:04 INFO main:
===== Summary =====
List of vulnerable files:
2021-12-18T00:05:04 INFO main: Done.

Remark

หลังจาก เราทำการ run script เสร็จเมื่อกลับที่ vSphere client browser ของ vCenter server จะพบว่า ที่ Tab -> Monitor ในหน้า Skyline Health จะ show warning “Online health checks execution” (ถ้าไม่เจอแบบนี้ก็ไม่เป็นไร นะครับ)
!!!warning ที่แสดง จะหายไป เอง นะครับ!!!

Conclusion

ในบทความนี้จะเป็น workaround สำหรับ vCenter server virtual appliance 7.x เท่านั้น โดย fix version ยังไม่มีออกมาในส่วน version อื่น ให้ทุกท่านติดตาม VMSA-2021-0028 ในการทำ workaround หรือ fix version รวมถึง Product อื่นๆ ของ VMware ที่ได้รับผลกระทบ เช่นกัน.

VMSA-2021-0020 | Workarounds by KB85717

By Lerpong Intaraworrapath | October 4th, 2021

Security
Security

Workaround for VMSA-2021-0020

จากการที่ VMware ได้ประกาศ เกี่ยวกับ Security Advisory Critical issues สำหรับ vCenter Server VMSA-0021-0020

สำหรับลูกค้าท่านใด ที่ยังไม่สามารถทำการ upgrade vCenter server ตาม version ที่ระบุใน VMSA-0021-0021 เราแนะนำให้ ทำตาม KB85717 ก่อนเพื่อป้องกัน Critical issues (CVE-2021-22005) เท่านั้น ซึ่ง ในส่วน CVE อื่นต้องทำการ upgrade ไม่มี workarounds

Note: KB85717 จะเป็นแค่ workarounds แนะนำให้ทำการ upgrade vCenter Sever จะเป็นการป้องกันที่ดีสุด

(ขั้นตอนต่อไปนี้จะเป็นการทำ Workarounds บน vCenter Server version 7.0.1.00301)

ขั้นตอนการทำ Workarounds สำหรับ KB85717

  1. ทำการ SSH ไปที่ vCenter Server ที่เราต้องการ ด้วย account “root”
  2. ทดสอบ ทำการ Curl command ก่อนทำ workarounds

curl -X POST “http://localhost:15080/analytics/telemetry/ph/api/hyper/send?_c&_i=test” -d “Test_Workaround” -H “Content-Type: application/json” -v 2>&1 | grep HTTP

ก็จะได้ผลลัพธ์

< HTTP/1.1 201

Curl before execute
Curl before execute

3. ทำการ Backup ไฟล์ ph-web.xml จาก path vmware-analytics

 cp /etc/vmware-analytics/ph-web.xml /etc/vmware-analytics/ph-web.xml.backup

4. ทำการแก้ไขไฟล์ ph-web.xml จาก text editor

vi /etc/vmware-analytics/ph-web.xml

5. โดยเราจะใส่ tags comments “<!–” และ “–>” ใน ไฟล์ ph-web.xml

  • For 6.7 U1b (Build 11726888) and earlier, there is 1 endpoint, phTelemetryServlet” that needs to be commented
  • For 6.7U2 (Build 13010631) and later, and all versions of 7.0, there are 3 impacted endpoints, the “phTelemetryServlet“, “phPhApiServlet” and “phPhStgApiServlet” endpoints.

Note: ในบทความนี้ จะเป็น vvCenter Server version 7.0.1.00301 จะใส่ครอบคลุม ค่า 3 endpoints

6. รูปแบบ content ในไฟล์ ph-web.xml

ph-web.xml
ph-web.xml

7. ทำการกด “I” เผื่อเข้าสู่จะ Insert mode.

8. ทำการค้นหาคำว่า <list> ตามรูปในข้อ 6.

9. กด Enter

10. ทำการพิมพ์ “<!–” ใต้คำว่า <list>

11. ทำการค้นหาคำว่า </bean> ใต้บรรทัด “<property name=”servlet” ref=”phPhStgApiServlet”/>

12. กด Enter แล้ว พิมพ์ “–>” จะได้ผลลัพธ์ ตามรูปด้านล่าง

Enter tags
Enter tags

13. กด ESC เพื่อออกจาก Insert mode

14. ทำการ Save และ Exit โดยพิมพ์ “:wq” แล้วกด Enter

15. ทำการ restart “vmware-analytics” service โดยพิมพ์

service-control –restart vmware-analytics

16. ทำการตรวจสอบ ว่า workarounds ที่เราทำการ apply ไปมีผลหรือไม่ ทำการตรวจสอบ โดยใช้คำสั่งด้านล่าง

curl -X POST “http://localhost:15080/analytics/telemetry/ph/api/hyper/send?_c&_i=test” -d “Test_Workaround” -H “Content-Type: application/json” -v 2>&1 | grep HTTP

โดยจะได้ผลลัพธ์

HTTP Status 404 – Not Found

Curl after executed
Curl after executed

***Note: กรณีที่มี vCenter Server หลายตัว เชื่อมต่อกันแบบ Enhanced Linked Mode จะต้องทำทุก vCenter Server ทั้งหมด

สรุป คำสั่งที่ต้องใช้สำหรับ Workaround KB85717

  • cp /etc/vmware-analytics/ph-web.xml /etc/vmware-analytics/ph-web.xml.backup
  • vi /etc/vmware-analytics/ph-web.xml
  • service-control –restart vmware-analytics
  • curl -X POST “http://localhost:15080/analytics/telemetry/ph/api/hyper/send?_c&_i=test” -d “Test_Workaround” -H “Content-Type: application/json” -v 2>&1 | grep HTTP

!!!บทความนี้จะเป็น Workarounds เท่านั้น แนะนำให้ทำ การ Upgrade vCenter Server จะเป็นทางแก้ที่ดีที่สุดนะครับ!!!

Reference:

VMSA-2021-0020

By Lerpong Intaraworrapath | September 24th ,2021

Critical severity

VMware ออกอัปเดต VMware Security Advisory แจ้งเตือนช่องโหว่ ร้ายแรง ระดับ Critical บน vCenter Server 6.5, 6.7, 7.0 (รวมถึงระบบ vCenter บนระบบ VCF 3.x, 4.X)

Impacted Products
  • VMware vCenter Server (vCenter Server)
  • VMware Cloud Foundation (Cloud Foundation)

ซึ่งเป็น Security ที่มีหลากหลาย CVE (Common Vulnerabilities and Exposures) ปรากฏ อยู่ ถึง 19 CVEs

  • CVE-2021-21991 Local privilege escalation vulnerability
  • CVE-2021-21992 XLM parsing Denial of Service vulnerability
  • CVE-2021-21993 SSRF vulnerability
  • CVE-2021-22005 File upload vulnerability Critical (score 9.8)
  • CVE-2021-22006 Reverse proxy bypass vulnerability
  • CVE-2021-22007 Local information disclosure vulnerability
  • CVE-2021-22008 Information disclosure vulnerability
  • CVE-2021-22009 VAPI multiple denial of service vulnerabilities
  • CVE-2021-22010 VPXD denial of service vulnerability
  • CVE-2021-22011 Unauthenticated API endpoint vulnerability
  • CVE-2021-22012 Unauthenticated API information disclosure vulnerability
  • CVE-2021-22013 File path traversal vulnerability
  • CVE-2021-22014 Authenticated code execution vulnerability
  • CVE-2021-22015 Improper permission local privilege escalation vulnerabilities
  • CVE-2021-22016 Reflected XSS vulnerability
  • CVE-2021-22017 rhttpproxy Bypass vulnerability
  • CVE-2021-22018 File deletion vulnerability
  • CVE-2021-22019 Denial of Service vulnerability
  • CVE-2021-22020 Analytics service denial of service vulnerability

โดย CVE-2021-2205 (9.8) เป็น CVE ที่เป็น Critical severity (vCenter server 6.7, 7.0)โดย เป็นช่องโหว่ร้ายแรง ใน Analytics service.

ในการเข้าถึง ช่องโหว่ นี้ Attacker จะเข้าผ่าน port 443 ของ vCenter server แล้วทำการ upload ไฟล์ที่สร้างขึ้นพิเศษ แล้วทำการ รัน โค้ดบน vCenter server.

!!!แนะนำให้ อ่าน VMSA-2021-0020 และ FAQ ให้เข้าใจก่อนนะครับ!!!

สิ่งที่สำคัญคือ การ Hardening ระบบเพื่อให้มี Security เพิ่มมากขึ้น ซึ่งจะ ช่วยป้องกันภัยคุกคามจาก Attacker หรือผู้ไม่หวังดี เข้ามาในระบบ ด้วยนะครับ

About the fix

สำหรับ vCenter server ทำการ upgrade version ตามข้อมูลด้านล่าง

สำหรับ VCF

About workarounds

ถ้าไม่สามารถทำการ upgrade vCenter server ให้ follow VMware KB ด้านล่าง

  • For vCenter Server 7.0, KB85717 *There are no workarounds for some CVEs.
  • For vCenter Server 6.7, KB85717 *There are no workarounds for some CVEs.
  • For vCenter Server 6.5, There are no workarounds.

Addional inforamation