# Phân Tích 5 CVE Trong Các Ứng Dụng Web: WordPress, Joomla, Roundcube và SQLAlchemy
Trong bài viết này, chúng ta sẽ phân tích kỹ thuật 5 lỗ hổng bảo mật (CVE) trong các ứng dụng web phổ biến: **WordPress**, **Joomla**, **Roundcube** và **SQLAlchemy**. Bài viết nhằm cung cấp cái nhìn cơ bản về nguyên nhân gốc rễ (root cause), phương thức khai thác (PoC) và cách phòng chống.
## 📚 Mục Lục
1. [WordPress – CVE-2024-4439](#CVE-2024-4439)
2. [WordPress – CVE-2023-2745](#CVE-2023-2745)
3. [Joomla – CVE-2023-23752](#CVE-2023-23752)
4. [Roundcube – CVE-2024-42008](#CVE-2024-42008)
5. [SQLAlchemy – CVE-2019-7164](#CVE-2019-7164)
6. [Tổng Kết](#Tổng-Kết)
---
## CVE-2024-4439
### 1. Thông Tin Chung
- **CVE**: CVE-2024-4439
- **Ngày công bố**: 05/03/2024
- **Phiên bản bị ảnh hưởng**: <= 6.5.2
- **Mức độ nghiêm trọng**: 7.2
### 2. Mô Tả Lỗ Hổng
WordPress Core (<= 6.5.2) tồn tại lỗ hổng **Stored XSS** do không thực hiện escaping đúng cách với tên hiển thị của người dùng trong block **Avatar**.
Lỗ hổng cho phép:
- **Người dùng đã xác thực** (quyền Contributor trở lên) chèn mã JavaScript vào trang sử dụng block Avatar.
- **Người dùng chưa xác thực** chèn được mã độc nếu trang có block **Comment** và hiển thị avatar người bình luận.
Mã độc sẽ được thực thi khi người dùng truy cập các trang bị chèn payload.
### 3. Phân Tích Patch/Diff
Cả hai commit [r57951](https://core.trac.wordpress.org/changeset/57951/branches/6.4/src/wp-includes/blocks/avatar.php) và [r57950](https://core.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&old=57950%40%2F&new=57950%40%2F&sfp_email=&sfph_mail=#file3) đều chỉ ra hai dòng bị lỗi là dòng 52 và 79 trong file `wp-includes/blocks/avatar.php`.
Cụ thể, giá trị của thuộc tính `aria-label` được tạo bằng:
```php
sprintf( esc_attr__( ... ), $author_name )
```
Cách làm này sai vì `esc_attr__()` sẽ không escape được giá trị `$author_name` hoặc `$comment->comment_author` trước khi chèn vào `%s`. Điều này mở ra khả năng chèn mã độc (XSS) vào biến `$author_name` hoặc `$comment->comment_author`.
Vì vậy, bản patch đã sửa bằng cách chèn dữ liệu vào `%s` trước, rồi mới dùng `esc_attr()` để escape chuỗi:
```php
esc_attr( sprintf( __( ... ), $author_name ) )
```
### 4. Nguyên Nhân Gốc Rễ
Trong file `wp-includes/blocks/avatar.php`, `$author_name` được lấy từ trường `display_name` thông qua hàm `get_the_author_meta()` (dòng 35), tương ứng với ID tác giả của bài viết hiện tại. Sau đó, chèn giá trị `$author_name` vào chuỗi giá trị của thuộc tính `aria-label` (dòng 52). Từ đó, kẻ tấn công có thể trigger XSS qua việc chèn một payload như:
```javascript
"onmouseover="alert(origin)"
```
Giá trị của trường `display_name` được set tại endpoint `/wp-admin/profile.php` thông qua cài đặt tên hiển thị (Display name publicly as). Giá trị của `Display name publicly as` có thể lấy từ một trong ba trường (First Name, Last Name, Nickname). Kẻ tấn công có thể chèn một trong ba vị trí bất kì rồi tùy chọn của `Display name publicly as` với payload XSS và nhấn vào nút `Update Profile`.
Để trigger được dòng 52 thì cần set 2 giá trị biến `$attributes['isLink']` và `$attributes['linkTarget']` thành `true`. Bằng cách tạo hoặc sửa một bài viết để set lại giá trị của hai biến `$attributes['isLink']` và `$attributes['linkTarget']` thành `true` với đoạn nội dung sau:
```text
<!-- wp:avatar {"isLink":true,"linkTarget":"_blank"} /-->
```
Khi user bất kì truy cập vào bài viết và di chuyển chuột đến bên dưới `Avatar` của chủ sở hữu bài viết thì payload XSS lập tức kích hoạt thuộc tính `onmouseover` và thực thi đoạn mã `Javascript` bên trong.
Tương tự, tại dòng 79, `$comment->comment_author` được chèn trực tiếp vào thuộc tính `aria-label` mà không được escape phù hợp. Để dòng này được thực thi, bình luận phải chứa trong block `comment-template` và thẻ avatar có thuộc tính `isLink` và `linkTarget`.
```text
<!-- wp:comment-template -->
<!-- wp:avatar {"isLink":true,"linkTarget":"_blank"} /-->
<!-- /wp:comment-template -->
```
Sau đó, user bất kì bình luận vào bài viết với nội dung tùy ý như `hello`. Lúc này, dòng 79 đã được thực thi và chèn payload XSS vào giá trị thuộc tính `aria-label` trong HTML response. Khi user bất kì truy cập vào bài viết và di chuyển chuột đến bên dưới Avatar của chủ sở hữu bài viết thì payload XSS lập tức kích hoạt thuộc tính onmouseover và thực thi đoạn mã Javascript bên trong.
### 5. Kịch Bản Khai Thác (PoC)
- Bước 1: Tạo một bài viết mới hoặc chỉnh sửa bài viết đã có với nội dung HTML như sau:
```
<!-- wp:avatar {"isLink":true,"linkTarget":"_blank"} /-->
```
- Bước 2: Chọn một trong ba trường (First Name, Last Name, Nickname) để chứa payload (có cấu trúc: `"onmouseover="[Javascript code]"`) và tùy chọn lại giá trị của trường `Display name publicly as` thành payload XSS. Click `Update Profile` để lưu dữ liệu.
- Bước 3: di chuyển chuột đến khối Avatar của tác giả.
### 6. Khắc Phục
- Cập nhật WordPress lên phiên bản mới nhất
- Cấu hình chính sách bảo mật nội dung (CSP) để giảm rủi ro khai thác XSS
- Sử dụng hàm esc_attr__() đúng cách để encoding dữ liệu đầu vào
### 7. Tham khảo
- https://nvd.nist.gov/vuln/detail/cve-2024-4439
- https://owasp.org/www-community/attacks/xss/
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
---
## CVE-2023-2745
### 1. Thông Tin Chung
- **CVE**: CVE-2023-2745
- **Ngày công bố**: 05/17/2023
- **Phiên bản bị ảnh hưởng**: <= 6.2
- **Mức độ nghiêm trọng**: 6.1
### 2. Mô tả lỗ hổng
Lỗ hổng `Directory Traversal` tồn tại trong WordPress Core (<= 6.2) thông qua tham số `wp_lang`. Lỗi này cho phép kẻ tấn công chưa xác thực truy cập và tải các tệp dịch (translation files) tùy ý. Nếu kẻ tấn công có thể tải lên một tệp dịch độc hại, lỗ hổng này có thể được khai thác để thực hiện tấn công Cross-Site Scripting (XSS).
### 3. Phân Tích Patch/Diff
Commit [r55765](https://core.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&old=55765%40%2F&new=55765%40%2F&sfp_email=&sfph_mail=) chỉ ra hai dòng bị gây ra lỗi là 152 và 154 trong file `wp-includes/l10n.php`. Kẻ tấn công có thể kiểm soát biến `$_GET['wp_lang']` và `$_COOKIE['wp_lang']`.
### 4. Nguyên Nhân Gốc Rễ
Lỗ hổng bắt nguồn từ hàm `determine_locale()` trong file `wp-includes/l10n.php`. Hàm này chịu trách nhiệm xác định ngôn ngữ hiện hành để hiển thị trên trang web. Mặc dù ở dòng 152 và 154, biến `$wp_lang` được sanitize bằng hàm `sanitize_text_field()` nhưng đây không phải là biện pháp đủ an toàn để ngăn chặn `Directory Traversal`. Cuối cùng, trả về chuỗi đại diện cho ngôn ngữ tương ứng (ví dụ: Tiếng Việt -> vi).
Tiếp theo, kết quả trả về của hàm `determine_locale()` được dùng làm đường dẫn đến file `.mo` (tham số thứ hai) cho hàm `load_textdomain()`
Dòng 772, hàm `import_from_file()` load nội dung file `.mo` có đường dẫn là `C:\xampp\htdocs/wp-content/languages/vi.mo`. Nếu kẻ tấn công có thể upload một file `.mo` đã chỉnh sửa nội dung như `Username or Email Address` trên trang login thành payload XSS như `<script>alert(document.domain)</script>` thì khi truy cập vào trang login đoạn mã Javascript sẽ tự động kích hoạt.
### 5. Kịch Bản Khai Thác (PoC)
- Bước 1: Tạo một file `malicious.mo` với nội dung của file `wp-content/languages/vi.po` và sửa phần `msgstr` thành payload XSS.
- Bước 2: Sử dụng lệnh `msgfmt malicious.po -o malicious.mo` để biên dịch thành file `malicious.mo`.
- Bước 3: Truy cập endpoint `/wp-login.php` với tham số `wp_lang=malicious` hoặc thêm/sửa giá trị của cookie `wp_lang` thành `malicious`.
### 6. Khắc Phục
- Cập nhật WordPress lên phiên bản mới nhất
- Cấu hình chính sách bảo mật nội dung (CSP) để giảm rủi ro khai thác XSS
### 7. Tham khảo
- https://nvd.nist.gov/vuln/detail/cve-2023-2745
- https://owasp.org/www-community/attacks/xss/
- https://owasp.org/www-community/attacks/Path_Traversal
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
---
## CVE-2023-23752
### 1. Thông Tin Chung
- **CVE**: CVE-2023-23752
- **Ngày công bố**: 02/16/2023
- **Phiên bản bị ảnh hưởng**: 4.0.0 - 4.2.7
- **Mức độ nghiêm trọng**: 5.3
### 2. Mô Tả Lỗ Hổng
CVE-2023-23752 ảnh hưởng đến Joomla! từ bản 4.0.0 đến 4.2.7. Lỗi xuất phát từ việc thiếu kiểm tra quyền truy cập tại các web service endpoint, cho phép kẻ tấn công chưa xác thực có thể truy cập trái phép vào API.
### 3. Phân tích Patch/Diff
Diff hai version 4.2.7 và 4.2.8, đây là [commit](https://github.com/joomla/joomla-cms/commit/5897df8ee39056fbd37624eeeeff1b81e24d84ef) để fix lỗi. Đoạn mã vá đã bổ sung logic (dòng 104 đến 108) trong file `libraries/src/Rounter/ApiRouter.php` để loại bỏ tham số public khỏi truy vấn (query) nếu nó được gửi từ phía client -> Khi thêm tham số `public` thì server cho phép truy cập vào các API vốn không được phép truy cập.
### 4. Nguyên Nhân Gốc Rễ
Lỗ hổng bắt nguồn từ lớp xử lý route API trong Joomla!, cụ thể là trong file `libraries/src/Router/ApiRouter.php`. Biến `$query` (dòng 102) là một mảng chứa các tham số GET theo dạng key-value khi truy cập đến các API có dạng `/api/index.php`. Khi đó, kẻ tấn công có thể chèn vào tham số `public` để biến `$query` chứa phần tử có key `public`.
Hàm `parseApiRoute()` trả về mảng bao gồm phần tử có key `vars` và giá trị chứa các tham số GET.
Kết trả trả về của hàm `parseApiRoute()` được gán vào biến `$route` ở dòng 238 trong file `libraries/src/Application/ApiApplication.php`.
Sau đó, kiểm tra nếu không chứa tham số `public` hoặc giá trị của tham số `public` bằng `false` thì trả về thông báo Forbidden và không cho truy cập vào api. Ngược lại, trả về dữ liệu tương ứng với từng API cụ thể.
Một số các api sau có thể truy cập khi thêm tham số `public` mà không cần phải xác thực:
- `/api/index.php/v1/users`
- `/api/index.php/v1/messages`
- `/api/index.php/v1/menus/administrator`
- ...
### 5. Kịch Bản Khai Thác (PoC)
Truy cập `/api/index.php/v1/users?public`
### 6. Khắc Phục
- Cập nhật Joomla! lên phiên bản mới nhất
### 7. Tham khảo
- https://nvd.nist.gov/vuln/detail/cve-2023-23752
- https://owasp.org/www-community/Broken_Access_Control
- https://github.com/joomla/joomla-cms/releases
---
## CVE-2024-42008
### 1. Thông Tin Chung
- **CVE**: CVE-2024-42008
- **Ngày công bố**: 08/05/2024
- **Phiên bản bị ảnh hưởng**: <= 1.5.7, 1.6.x - 1.6.7
- **Mức độ nghiêm trọng**: 9.3
### 2. Mô Tả Lỗ Hổng
Lỗ hổng XSS trong hàm `rcmail_action_mail_get->run()` của `Roundcube` cho phép kẻ tấn công gửi email chứa file đính kèm với `Content-Type` độc hại. Khi nạn nhân mở đính kèm, mã JavaScript có thể thực thi, dẫn đến đánh cắp các email.
### 3. Phân tích Patch/Diff
Diff hai version 1.6.7 và 1.6.8, đây là [commit](https://github.com/roundcube/roundcubemail/commit/c222ea8b99448ead20ab3864fcc29c84ed17403a) để fix lỗi. Bản vá của file `program/lib/Roundcube/rcube_output.php` cho thấy developer đã thêm lớp kiểm soát nội dung trả về (dòng 245 đến 251) nhằm ngăn việc trình duyệt thực thi nội dung nguy hiểm, đặc biệt là khi `Content-Disposition: inline` được sử dụng để hiển thị trực tiếp nội dung file trong trình duyệt.
### 4. Nguyên Nhân Gốc Rễ
Hàm `download_headers()` trong file `program/lib/Roundcube/rcube_output.php` được gọi khi người dùng click vào một trong hai nút Open/Download với file đính kèm.
Khi người dùng yêu cầu hiển thị file đính kèm (Open) thì url như sau:
```
http://localhost:81/webmail/?_task=mail&_frame=1&_mbox=INBOX&_uid=2&_part=2&_action=get&_extwin=1
```
Tương tự, khi tải file đính kèm (Download) thì url như sau:
```
http://localhost:81/webmail/?_task=mail&_mbox=INBOX&_uid=2&_part=2&_download=1&_action=get&_token=3iSW7JJwAGgVAPJCZ55gPGcOiDsjO8gN
```
Còn một cách để hiển thị file đính kèm là set tham số `_download=0` hoặc xóa đi tham số `_download` của trên route trên.
Dòng 274 trong file `program/actions/mail/get.php`, tham số thứ hai dùng để truyền vào khi gọi hàm `download_headers()` là một mảng có ba phần tử. Nếu URL chứa tham số `_download` thì set giá trị của phần tử có key `disposition` là `attachment` và ngược lại là `inline`.
Dòng 242 trong file `program/lib/Roundcube/rcube_output.php`, biến `$ctype` sẽ lấy ra giá trị `Content-Type` của file đính kèm trong HTTP request. Kẻ tấn công có thể gửi một file đính kèm với `Content-Type: text/xml` và body là `<x:script xmlns:x="http://www.w3.org/1999/xhtml">alert(origin)</x:script>`.
Dòng 270 và 271, thực hiện set giá trị cho hai header `Content-Disposition` và `Content-Type`.
Khi nạn nhân truy cập vào đường link download file đính kèm nhưng đã bị set tham số `_download=0` hoặc xóa đi tham số `_download` thì kích hoạt payload XSS trong nội dung tệp XML.
### 5. Kịch Bản Khai Thác (PoC)
Bước 1: Chạy đoạn script sau để gửi file đính kèm độc hại cho nạn nhân.
```python
import smtplib
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart
from email.mime.base import MIMEBase
class EmailSender:
def __init__(self, server, port, user, pw):
self.server, self.port, self.user, self.pw = server, port, user, pw
def send(self, to, subject, body, attachment):
msg = MIMEMultipart()
msg['From'], msg['To'], msg['Subject'] = self.user, to, subject
msg.attach(MIMEText(body, 'plain'))
part = MIMEBase(*attachment['type'].split('/'))
part.set_payload(attachment['content'])
part.add_header('Content-Disposition', f'attachment; filename="{attachment["filename"]}"')
part.add_header('Content-Type', attachment['type'])
msg.attach(part)
with smtplib.SMTP(self.server, self.port) as s:
s.starttls()
s.login(self.user, self.pw)
s.send_message(msg)
if __name__ == "__main__":
smtp_conf = {
"server": "localhost",
"port": 587,
"user": "attacker@gmail.com",
"pw": "attacker"
}
payload = {
"filename": "hello.xml",
"content": '<x:script xmlns:x="http://www.w3.org/1999/xhtml">alert(origin)</x:script>',
"type": "text/xml"
}
EmailSender(**smtp_conf).send("victim@gmail.com", "CVE-2024-42008", "Please download the attachment.", payload)
```
Bước 2: Tìm cách rò rỉ ra `UID` của email độc hại vừa gửi đến nạn nhân và tùy chỉnh URL để hiển thị file đính kèm độc hại rồi gửi lại cho nạn nhân URL đó.
Bước 3: Chờ nạn nhân click vào URL để kích hoạt payload XSS.
### 6. Khắc Phục
- Cập nhật Roundcube lên phiên bản mới nhất
- Giới hạn để ngăn các `Content-Type` nguy hiểm.
- Cấu hình chính sách bảo mật nội dung (CSP) để giảm rủi ro khai thác XSS
### 7. Tham khảo
- https://nvd.nist.gov/vuln/detail/cve-2024-42008
- https://owasp.org/www-community/attacks/xss/
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
---
## CVE-2019-7164
### 1. Thông Tin Chung
- **CVE**: CVE-2019-7164
- **Ngày công bố**: 02/19/2019
- **Phiên bản bị ảnh hưởng**: 1.2.17, 1.3.x - 1.3.0b2
- **Mức độ nghiêm trọng**: 9.8
### 2. Mô Tả Lỗ Hổng
SQLAlchemy phiên bản <= 1.2.17 và 1.3.x - 1.3.0b2 cho phép `SQL Injection` thông qua tham số `order_by`.
### 3. Setup Môi Trường
Bước 1: Chuẩn bị file `app.py` và file `requirements.txt`:
app.py
```python
from flask import Flask, request
from flask_sqlalchemy import SQLAlchemy
app = Flask(__name__)
app.config.update({'SQLALCHEMY_DATABASE_URI': 'mysql://root:@localhost/cve-2019-7164'})
db = SQLAlchemy(app)
class Product(db.Model):
id = db.Column(db.Integer, primary_key=True)
name = db.Column(db.String(255))
price = db.Column(db.Float)
@app.route('/api/cart')
def list_cart():
order_by = request.args.get('order_by', 'id')
try:
rows = Product.query.order_by(order_by).all()
return "<table border='1' cellpadding='5'><tr><th>ID</th><th>Name</th><th>Price</th></tr>" + \
"".join(f"<tr><td>{p.id}</td><td>{p.name}</td><td>{p.price}</td></tr>" for p in rows) + "</table>"
except:
return 'Bad Request', 400
def seed_data():
db.create_all()
if not Product.query.first():
db.session.bulk_save_objects([
Product(name="iPhone 13", price=999.99),
Product(name="MacBook Pro", price=1999.99),
Product(name="AirPods Pro", price=249.99),
])
db.session.commit()
if __name__ == '__main__':
with app.app_context():
seed_data()
app.run(port=8080,debug=True)
```
requirements.txt
```
Flask==1.0.4
Flask_SQLAlchemy==2.3.2
SQLAlchemy==1.2.19
jinja2==2.10
itsdangerous==0.24
Werkzeug==0.14.1
markupsafe==1.1.1
```
Bước 2: Bật module `Apache` và `MySQL` rồi truy cập `http://localhost/phpmyadmin/`. Tạo database có tên là `cve-2019-7164`
Bước 3: Chạy hai lệnh `pip install -r requirements.txt` và `python app.py`. Truy cập `http://localhost:8080/api/cart` ra giao diện sau:
### 4. Phân tích
Ở dòng 16, biến `order_by` được sử dụng để lấy ra giá trị của tham số `order_by` trong URL. Tiếp theo, đưa vào hàm `order_by()` (dòng 18) để truy vấn dữ liệu. Lúc này, tham số `order_by` sẽ nằm sau phần `ORDER BY` trong câu query.
Khi tham số `order_by=3;` thì nó vẫn sắp xếp theo cột thứ 3 (price) mà không bị lỗi.
Tiếp theo, khi tham số `order_by=sleep(5)` thì server bị delay hơn 5 giây. Từ đó, kẻ tấn công có thể dùng các kỹ thuật như `Boolean-based` hoặc `Time-based` để rò rỉ dữ liệu trong database.
### 5. Khắc Phục
- Cập nhật SQLAlchemy lên phiên bản mới nhất.
### 6. Tham khảo
- https://nvd.nist.gov/vuln/detail/CVE-2019-7164
- https://owasp.org/www-community/attacks/SQL_Injection
- https://github.com/sqlalchemy/sqlalchemy/releases
---
## Tổng Kết
Qua việc phân tích 5 lỗ hổng bảo mật (CVE) trên các nền tảng phổ biến như WordPress, Joomla, Roundcube và SQLAlchemy, có thể rút ra một số bài học quan trọng sau:
### 1. **SQL Injection khi sử dụng ORM**
- Sử dụng ORM không đồng nghĩa với việc hoàn toàn an toàn trước SQL Injection.
### 2. **Kiểm tra quyền truy cập và xác thực**
- Cần kiểm tra kỹ các endpoint API, không dựa vào các tham số client-side để xác định quyền truy cập.
### 3. **Cập nhật phần mềm thường xuyên**
- Các lỗ hổng đều đã được vá ở các phiên bản mới. Việc cập nhật phần mềm định kỳ là biện pháp phòng ngừa hiệu quả nhất.
### 4. **Cấu hình chính sách bảo mật nội dung (CSP)**
- Nên cấu hình CSP giúp giảm thiểu rủi ro XSS bằng cách hạn chế nguồn thực thi script trên trình duyệt.
### 5. **Kiểm soát đầu vào và encoding dữ liệu**
- Hầu hết các lỗ hổng XSS và SQL Injection đều xuất phát từ việc không kiểm soát hoặc encode dữ liệu đầu vào đúng cách.
---
**Tóm lại:**
Bảo mật ứng dụng web là quá trình liên tục, đòi hỏi sự phối hợp giữa cập nhật công nghệ, kiểm soát đầu vào, kiểm tra quyền truy cập và đánh giá bảo mật thường xuyên. Việc học hỏi từ các lỗ hổng thực tế giúp nâng cao nhận thức và kỹ năng phòng chống các mối đe dọa mới trong tương lai.
Sign in with Wallet
Connect another wallet