cPanel là một phần mềm bảng điều khiển lưu trữ web được triển khai rộng rãi trên internet. Chính xác, có khoảng ~ 1,4 triệu cài đặt cPanel được hiển thị trên internet bên ngoài tại thời điểm viết bài đăng trên blog này.
Chúng tôi đã phát hiện ra một lỗ hổng cross-site scripting được phản ánh có thể bị khai thác mà không cần bất kỳ xác thực nào. Thêm vào đó, lỗ hổng XSS có thể bị khai thác bất kể các cổng quản lý cPanel (2080, 2082, 2083, 2086) có bị lộ ra bên ngoài hay không. Điều này có nghĩa là trang web của bạn trên cổng 80 và 443 cũng dễ bị tổn thương bởi lỗ hổng cross-site scripting nếu nó đang được quản lý bởi cPanel.
Đối với những người lo lắng rằng trang web của họ bị ảnh hưởng bởi lỗ hổng này, xin đừng căng thẳng. Rất nhiều cài đặt cPanel trên internet đã bật chức năng tự động cập nhật của cPanel, có nghĩa là bạn có thể không còn dễ bị tổn thương mà không phải tự vá. Nếu bạn chưa thiết lập tính năng này, vui lòng đọc này để biết hướng dẫn về cách bật tính năng này.
Như mọi khi, khách hàng của nền tảng của chúng tôi là những người đầu tiên biết khi nào lỗ hổng này ảnh hưởng đến họ. Chúng tôi tiếp tục thực hiện nghiên cứu bảo mật ban đầu trong nỗ lực thông báo cho khách hàng về các lỗ hổng zero-day.
Bạn có thể đọc tư vấn chính thức của cPanel .
cPanel đã tồn tại lâu như tôi có trong thế giới này (được thiết kế vào năm 1996), chỉ hơn 27 năm. Đây có lẽ là một trong những phần mềm lâu đời nhất mà chúng tôi từng kiểm toán tại Assetnote. Để thực hiện thử nghiệm của mình, chúng tôi đã tạo ra một giọt DigitalOcean với hình ảnh thị trường cho cPanel trên Ubuntu. Điều này cực kỳ thuận tiện và dễ dàng, cắt giảm đáng kể thời gian thiết lập của chúng tôi.
Bản chất lịch sử của cPanel có nghĩa là có một số mô hình và công nghệ mà nó tận dụng mà không nhất thiết phải hiện đại. Cụ thể, hầu hết cPanel được viết bằng Perl với một số bề mặt tấn công được Perl biên dịch thành nhị phân.
Khi chúng tôi lần đầu tiên xem xét cPanel vào giữa năm ngoái, chúng tôi tập trung rất nhiều vào các tệp nhị phân có thể được truy cập trong thư mục trên các cổng quản lý của cPanel. Các tệp nhị phân này là mã Perl đã được biên dịch thành các tệp nhị phân được cố ý cho là được gọi từ xa thông qua các yêu cầu HTTP. Hiểu logic của các tệp nhị phân này rất khó khăn và trong khi chúng tôi tìm thấy một số con đường để khai thác, chúng tôi thấy rằng các biện pháp giảm thiểu đã được xây dựng ngăn cản chúng tôi khai thác thành công những vấn đề tiềm ẩn này./cgi-sys/
Bên ngoài các tệp nhị phân bên trong thư mục này, chúng tôi cũng nhận thấy rằng các chức năng cốt lõi và ứng dụng web của cPanel được phục vụ thông qua tệp nhị phân. Nhị phân này đang lắng nghe trên các cổng sau:cpsrvd
root@vm:~# lsof -Pi | grep cpsrvd
cpsrvd 43328 root 3u IPv4 218993 0t0 TCP *:2082 (LISTEN)
cpsrvd 43328 root 4u IPv4 218994 0t0 TCP *:2086 (LISTEN)
cpsrvd 43328 root 5u IPv4 218995 0t0 TCP *:2083 (LISTEN)
cpsrvd 43328 root 6u IPv4 218996 0t0 TCP *:2087 (LISTEN)
cPanel tận dụng các chức năng proxy ngược của Apache và cấu hình cho điều này có thể được tìm thấy ở đây: . Tệp này cung cấp cho chúng tôi rất nhiều manh mối và ngữ cảnh xung quanh những gì cần tìm kiếm bên trong cơ sở mã cPanel vì có rất nhiều bí danh proxy và tập lệnh xác định bề mặt tấn công thú vị:/etc/apache2/conf/httpd.conf
ProxyPass /cpanelwebcall/ max=1 retry=0
... omitted for brevity ...
ScriptAlias /.cpanel/dcv /usr/local/cpanel/cgi-priv/get_local.cgi
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/\.well-known/acme-challenge/[0-9a-zA-Z_-]+$ [OR]
RewriteCond %{REQUEST_URI} ^/\.well-known/cpanel-dcv/[0-9a-zA-Z_-]+$ [OR]
RewriteCond %{REQUEST_URI} ^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Sectigo\ DCV)?$ [OR]
RewriteCond %{REQUEST_URI} ^/\.well-known/pki-validation/(?:\ Ballot169)?
RewriteRule ^ /.cpanel/dcv [passthrough]
Trên đây chỉ là một đoạn trích nhỏ của tập tin. Nếu bạn đang xem xét kiểm tra cPanel, chúng tôi khuyên bạn nên xem qua tất cả các quy tắc proxy khác nhau bên trong tệp này làm điểm khởi đầu.httpd.conf
Rất may, cPanel xuất xưởng với một lượng lớn mã nguồn của nó, có thể được lấy từ phiên bản cPanel sau cài đặt tại vị trí . Mặc dù đây cũng là nơi hầu hết các tệp nhị phân tồn tại, bạn vẫn có thể hiểu một số logic của cPanel thông qua việc đọc các thư viện và mã perl từ thư mục này./usr/local/cpanel/
Mặc dù mã perl bên trong thư mục đó chứa một số lượng lớn manh mối về cách định tuyến hoạt động, nguồn gốc của sự thật vẫn là nhị phân, cuối cùng là phiên bản được biên dịch của tất cả các perl. Mã nguồn được tìm thấy trong thư mục dường như không phải là một bức tranh hoàn chỉnh về các chức năng thực sự được cung cấp bởi cPanel. Tuy nhiên, chúng tôi rất biết ơn vì nó đã cho chúng tôi đủ bối cảnh để tìm ra lỗ hổng XSS.cpsrvd/usr/local/cpanel
Trong khi cố gắng hiểu định tuyến của cPanel, chúng tôi đã bắt gặp trong đó có một số cách xử lý rất cụ thể đối với các đường dẫn nhất định. Logic này cho phép chúng tôi lập bản đồ và hiểu một số bề mặt tấn công trước khi xác thực mà không cần phải hiểu các tệp nhị phân.Cpanel/Server/Handlers/Httpd.pm
Các nhận xét ở đầu tệp đã cho chúng tôi một cái nhìn tổng quan tốt về những gì điều này xử lý:
=head1 DESCRIPTION
This module implements a tiny HTTP server in cpsrvd that executes a
whitelist of functionality.
This is useful for contexts where no other service is running on the standard
HTTP and HTTPS ports.
It implements the following behaviors:
=over
=item * Any request whose path is under F</.well-known> is served as a
static file. The path on disk that’s loaded is the same as under Apache.
=item * Any other request whose C<Host> header starts with one of the
following is served as appropriate: C<cpcalendars.>, C<cpcontacts.>,
C<autodiscover.>, C<autoconfig.>. The latter two are only served if
they are enabled in the server configuration.
Note that C<cpanel.>, C<whm.>, and C<webmail.> are NOT handled here.
This is largely because the relevant applications are under base cpsrvd
and thus not (readily) callable from this module, so we have to handle
those applications separately.
Các chức năng sau đây đã được tìm thấy bên trong mã Perl này:
Ngoài , chúng tôi cũng dành một lượng thời gian đáng kể để xử lý các tin nhắn websocket. Có rất nhiều chức năng thú vị có vẻ như nó có thể dẫn đến việc ghi tệp tùy ý, nhưng trong thời gian chúng tôi phân bổ cho nghiên cứu cPanel, chúng tôi đã không thành công trong việc tìm kiếm một bồn rửa với bất kỳ điều khiển có ý nghĩa nào.Httpd.pmCpanel/Server/Handlers/comet.pm
Bên trong , chúng ta có thể thấy đoạn mã sau:Httpd.pm
elsif ( 0 == rindex( $doc_path, '/cpanelwebcall/', 0 ) ) {
# First 15 chars are “/cpanelwebcall/”
_serve_cpanelwebcall(
$self->get_server_obj(),
substr( $doc_path, 15 ),
);
}
Điều này có nghĩa là bất kỳ đường dẫn nào bắt đầu bằng sẽ được định tuyến đến , cùng với các ký tự sau tên thư mục./cpanelwebcall/_serve_cpanelwebcall
Chức năng trông như thế này:_serve_cpanelwebcall
sub _serve_cpanelwebcall ( $server_obj, $webcall_uri_piece ) {
require Cpanel::Server::WebCalls;
my $out = Cpanel::Server::WebCalls::handle($webcall_uri_piece);
$server_obj->respond_200_ok_text($out);
return;
}
Điều này dẫn chúng tôi đến chức năng như bồn rửa:Cpanel::Server::WebCalls::handle
sub handle ($request) {
my $id = extract_id_from_request($request);
substr( $request, 0, length $id ) = q<>;
Cpanel::WebCalls:?:is_valid($id) or do {
die _http_invalid_params_err("Invalid webcall ID: $id");
};
Điều này dẫn đến:
sub _http_invalid_params_err ($why) {
return Cpanel::Exception::create_raw( 'cpsrvd::BadRequest', $why );
}
Chúng ta có thể theo dõi điều này trở lại . Đây là nơi con đường mòn trở nên lạnh lẽo. Mặc dù chúng tôi có rất nhiều mã nguồn Perl có sẵn, toàn bộ chuỗi này không thể được theo dõi từ đầu đến cuối vì chúng tôi đã bỏ lỡ cuộc gọi đến .Cpanel/Exception/cpsrvd/BadRequest.pmHttpd::ErrorPage
Chúng tôi đã tìm ra rằng bồn rửa là nơi chúng tôi có nguồn, nhưng chúng tôi không thể tìm thấy mã nguồn khởi tạo mã Perl này. Chúng tôi nghi ngờ rằng điều này được nhúng trong tệp nhị phân cPanel và do đó tại sao chúng tôi không thể xác định nơi mã này được gọi.Cpanel::Server::Handlers::Httpd::ErrorPage
Đi sâu vào code, chúng ta có thể thấy rằng nó có một biến gọi là sink cho lỗ hổng này. Biến này không được vệ sinh theo bất kỳ cách nào trong các phiên bản cPanel dễ bị tấn công.Httpd::ErrorPagemessage_html
Nhìn vào bản vá khác với phiên bản mới nhất của cPanel đã giải quyết lỗ hổng này, chúng ta có thể thấy rằng hai dòng sau đã được thêm vào :Cpanel/Server/Handlers/Httpd/ErrorPage.pm
++ use Cpanel::Encoder::Tiny ();
... omitted for brevity ...
++ $var{message_html} = Cpanel::Encoder::Tiny::safe_html_encode_str( $var{message_html} );
Đặt mọi thứ chúng ta đã học ở trên lại với nhau, chúng ta có thể đưa ra một bằng chứng khái niệm đơn giản như dưới đây:
<img%20src=x%20onerror="prompt(1)">aaaaaaaaaaaa
<img%20src=x%20onerror="prompt(1)">aaaaaaaaaaaa
<img%20src=x%20onerror="prompt(1)">aaaaaaaaaaaa
<img%20src=x%20onerror="prompt(1)">aaaaaaaaaaaa
... potentially other ports ...
Tác động của lỗ hổng này là chúng tôi có thể thực thi JavaScript tùy ý, xác thực trước, trên hầu hết mọi cổng của máy chủ web bằng cPanel trong thiết lập mặc định của nó.
Điều này là do các quy tắc proxy được thảo luận trước đó trong bài đăng trên blog. Ngay cả trên cổng 80 và 443, chúng tôi có thể truy cập thư mục vì nó đang được Apache ủy quyền cho các cổng quản lý cPanel./cpanelwebcall/
Bởi vì điều này, kẻ tấn công không chỉ có thể tấn công các cổng quản lý của cPanel mà còn cả các ứng dụng đang chạy trên cổng 80 và 443.
Do thực tế là các cổng quản lý cPanel dễ bị tấn công kịch bản chéo trang web này, kẻ tấn công có thể tận dụng lỗ hổng này để chiếm quyền điều khiển phiên cPanel của người dùng hợp pháp.
Sau khi hành động thay mặt cho người dùng cPanel được xác thực, việc tải lên trình bao web và thực thi lệnh thường là chuyện nhỏ.
Lỗ hổng này có thể được khắc phục bằng cách nâng cấp lên bất kỳ phiên bản cPanel nào sau đây:
Lịch trình tiết lộ có thể được tìm thấy dưới đây:
cPanel rất tuyệt vời để làm việc và khắc phục sự cố này trong một khung thời gian hợp lý sau khi chúng tôi tiết lộ lỗ hổng này cho họ.
cPanel có bề mặt tấn công rộng lớn và nó cần sự quan tâm nhiều hơn từ cộng đồng các nhà nghiên cứu bảo mật. Một trong những rào cản lớn trong quá trình nghiên cứu cPanel của chúng tôi là các tệp nhị phân đã được biên dịch thành Perl. Chúng tôi tin rằng có nhiều lỗi nghiêm trọng hơn chưa được tìm thấy trong các tệp nhị phân này, mặc dù, chúng khá đau đớn khi làm việc từ góc độ kỹ thuật đảo ngược.
Phân tích của chúng tôi về nhị phân nhận thấy rằng hầu hết các điểm cuối không thể truy cập được xác thực trước, tuy nhiên, có rất nhiều tệp nhị phân bên trong thư mục có thể sử dụng nhiều sự chú ý hơn.cpsrvd/cgi-sys/
Đây là một trong những trường hợp đầu tiên chúng tôi báo cáo lỗi cho nhà cung cấp có triển khai tự động cập nhật tự động hoạt động và chủ yếu là mặc định cho phần mềm của họ. Chỉ riêng việc giảm thiểu này đã bảo vệ phần lớn các trang web cPanel khỏi lỗ hổng này trong tự nhiên.
Điều đó đang được nói, vẫn có thể tìm thấy một số lượng lớn các trang web cPanel vẫn dễ bị tổn thương vì chúng không bật tính năng tự động cập nhật.
Chúng tôi đã phát hiện ra một lỗ hổng cross-site scripting được phản ánh có thể bị khai thác mà không cần bất kỳ xác thực nào. Thêm vào đó, lỗ hổng XSS có thể bị khai thác bất kể các cổng quản lý cPanel (2080, 2082, 2083, 2086) có bị lộ ra bên ngoài hay không. Điều này có nghĩa là trang web của bạn trên cổng 80 và 443 cũng dễ bị tổn thương bởi lỗ hổng cross-site scripting nếu nó đang được quản lý bởi cPanel.
Đối với những người lo lắng rằng trang web của họ bị ảnh hưởng bởi lỗ hổng này, xin đừng căng thẳng. Rất nhiều cài đặt cPanel trên internet đã bật chức năng tự động cập nhật của cPanel, có nghĩa là bạn có thể không còn dễ bị tổn thương mà không phải tự vá. Nếu bạn chưa thiết lập tính năng này, vui lòng đọc này để biết hướng dẫn về cách bật tính năng này.
Như mọi khi, khách hàng của nền tảng của chúng tôi là những người đầu tiên biết khi nào lỗ hổng này ảnh hưởng đến họ. Chúng tôi tiếp tục thực hiện nghiên cứu bảo mật ban đầu trong nỗ lực thông báo cho khách hàng về các lỗ hổng zero-day.
Bạn có thể đọc tư vấn chính thức của cPanel .
Làm quen với codebase của cPanel
cPanel đã tồn tại lâu như tôi có trong thế giới này (được thiết kế vào năm 1996), chỉ hơn 27 năm. Đây có lẽ là một trong những phần mềm lâu đời nhất mà chúng tôi từng kiểm toán tại Assetnote. Để thực hiện thử nghiệm của mình, chúng tôi đã tạo ra một giọt DigitalOcean với hình ảnh thị trường cho cPanel trên Ubuntu. Điều này cực kỳ thuận tiện và dễ dàng, cắt giảm đáng kể thời gian thiết lập của chúng tôi.
Bản chất lịch sử của cPanel có nghĩa là có một số mô hình và công nghệ mà nó tận dụng mà không nhất thiết phải hiện đại. Cụ thể, hầu hết cPanel được viết bằng Perl với một số bề mặt tấn công được Perl biên dịch thành nhị phân.
Khi chúng tôi lần đầu tiên xem xét cPanel vào giữa năm ngoái, chúng tôi tập trung rất nhiều vào các tệp nhị phân có thể được truy cập trong thư mục trên các cổng quản lý của cPanel. Các tệp nhị phân này là mã Perl đã được biên dịch thành các tệp nhị phân được cố ý cho là được gọi từ xa thông qua các yêu cầu HTTP. Hiểu logic của các tệp nhị phân này rất khó khăn và trong khi chúng tôi tìm thấy một số con đường để khai thác, chúng tôi thấy rằng các biện pháp giảm thiểu đã được xây dựng ngăn cản chúng tôi khai thác thành công những vấn đề tiềm ẩn này./cgi-sys/
Bên ngoài các tệp nhị phân bên trong thư mục này, chúng tôi cũng nhận thấy rằng các chức năng cốt lõi và ứng dụng web của cPanel được phục vụ thông qua tệp nhị phân. Nhị phân này đang lắng nghe trên các cổng sau:cpsrvd
root@vm:~# lsof -Pi | grep cpsrvd
cpsrvd 43328 root 3u IPv4 218993 0t0 TCP *:2082 (LISTEN)
cpsrvd 43328 root 4u IPv4 218994 0t0 TCP *:2086 (LISTEN)
cpsrvd 43328 root 5u IPv4 218995 0t0 TCP *:2083 (LISTEN)
cpsrvd 43328 root 6u IPv4 218996 0t0 TCP *:2087 (LISTEN)
cPanel tận dụng các chức năng proxy ngược của Apache và cấu hình cho điều này có thể được tìm thấy ở đây: . Tệp này cung cấp cho chúng tôi rất nhiều manh mối và ngữ cảnh xung quanh những gì cần tìm kiếm bên trong cơ sở mã cPanel vì có rất nhiều bí danh proxy và tập lệnh xác định bề mặt tấn công thú vị:/etc/apache2/conf/httpd.conf
ProxyPass /cpanelwebcall/ max=1 retry=0
... omitted for brevity ...
ScriptAlias /.cpanel/dcv /usr/local/cpanel/cgi-priv/get_local.cgi
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/\.well-known/acme-challenge/[0-9a-zA-Z_-]+$ [OR]
RewriteCond %{REQUEST_URI} ^/\.well-known/cpanel-dcv/[0-9a-zA-Z_-]+$ [OR]
RewriteCond %{REQUEST_URI} ^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Sectigo\ DCV)?$ [OR]
RewriteCond %{REQUEST_URI} ^/\.well-known/pki-validation/(?:\ Ballot169)?
RewriteRule ^ /.cpanel/dcv [passthrough]
Trên đây chỉ là một đoạn trích nhỏ của tập tin. Nếu bạn đang xem xét kiểm tra cPanel, chúng tôi khuyên bạn nên xem qua tất cả các quy tắc proxy khác nhau bên trong tệp này làm điểm khởi đầu.httpd.conf
Rất may, cPanel xuất xưởng với một lượng lớn mã nguồn của nó, có thể được lấy từ phiên bản cPanel sau cài đặt tại vị trí . Mặc dù đây cũng là nơi hầu hết các tệp nhị phân tồn tại, bạn vẫn có thể hiểu một số logic của cPanel thông qua việc đọc các thư viện và mã perl từ thư mục này./usr/local/cpanel/
Mặc dù mã perl bên trong thư mục đó chứa một số lượng lớn manh mối về cách định tuyến hoạt động, nguồn gốc của sự thật vẫn là nhị phân, cuối cùng là phiên bản được biên dịch của tất cả các perl. Mã nguồn được tìm thấy trong thư mục dường như không phải là một bức tranh hoàn chỉnh về các chức năng thực sự được cung cấp bởi cPanel. Tuy nhiên, chúng tôi rất biết ơn vì nó đã cho chúng tôi đủ bối cảnh để tìm ra lỗ hổng XSS.cpsrvd/usr/local/cpanel
Giải mã Httpd.pm
Trong khi cố gắng hiểu định tuyến của cPanel, chúng tôi đã bắt gặp trong đó có một số cách xử lý rất cụ thể đối với các đường dẫn nhất định. Logic này cho phép chúng tôi lập bản đồ và hiểu một số bề mặt tấn công trước khi xác thực mà không cần phải hiểu các tệp nhị phân.Cpanel/Server/Handlers/Httpd.pm
Các nhận xét ở đầu tệp đã cho chúng tôi một cái nhìn tổng quan tốt về những gì điều này xử lý:
=head1 DESCRIPTION
This module implements a tiny HTTP server in cpsrvd that executes a
whitelist of functionality.
This is useful for contexts where no other service is running on the standard
HTTP and HTTPS ports.
It implements the following behaviors:
=over
=item * Any request whose path is under F</.well-known> is served as a
static file. The path on disk that’s loaded is the same as under Apache.
=item * Any other request whose C<Host> header starts with one of the
following is served as appropriate: C<cpcalendars.>, C<cpcontacts.>,
C<autodiscover.>, C<autoconfig.>. The latter two are only served if
they are enabled in the server configuration.
Note that C<cpanel.>, C<whm.>, and C<webmail.> are NOT handled here.
This is largely because the relevant applications are under base cpsrvd
and thus not (readily) callable from this module, so we have to handle
those applications separately.
Các chức năng sau đây đã được tìm thấy bên trong mã Perl này:
- Xử lý định tuyến dựa trên tên miền phụ / tên máy chủ đến một số dịch vụ nhất định
- cpcalendars => 'proxy_cpcalendars_cpcontacts'
- cpcontacts => 'proxy_cpcalendars_cpcontacts'
- autodiscover => 'autodiscover'
- autoconfig => 'autoconfig'
- Xử lý đường dẫn tĩnh
- /img-sys/
- /sys_cpanel/
- Xử lý chuyển hướng cho , , /cpanel/whm/webmail
- Xử lý các yêu cầu /cgi-sys/bxd.cgi
- Xử lý chức năng liên quan đến DNS động, cụ thể là các cuộc gọi đến /cpanelwebcall/
Ngoài , chúng tôi cũng dành một lượng thời gian đáng kể để xử lý các tin nhắn websocket. Có rất nhiều chức năng thú vị có vẻ như nó có thể dẫn đến việc ghi tệp tùy ý, nhưng trong thời gian chúng tôi phân bổ cho nghiên cứu cPanel, chúng tôi đã không thành công trong việc tìm kiếm một bồn rửa với bất kỳ điều khiển có ý nghĩa nào.Httpd.pmCpanel/Server/Handlers/comet.pm
Tìm tập lệnh chéo trang web
Bên trong , chúng ta có thể thấy đoạn mã sau:Httpd.pm
elsif ( 0 == rindex( $doc_path, '/cpanelwebcall/', 0 ) ) {
# First 15 chars are “/cpanelwebcall/”
_serve_cpanelwebcall(
$self->get_server_obj(),
substr( $doc_path, 15 ),
);
}
Điều này có nghĩa là bất kỳ đường dẫn nào bắt đầu bằng sẽ được định tuyến đến , cùng với các ký tự sau tên thư mục./cpanelwebcall/_serve_cpanelwebcall
Chức năng trông như thế này:_serve_cpanelwebcall
sub _serve_cpanelwebcall ( $server_obj, $webcall_uri_piece ) {
require Cpanel::Server::WebCalls;
my $out = Cpanel::Server::WebCalls::handle($webcall_uri_piece);
$server_obj->respond_200_ok_text($out);
return;
}
Điều này dẫn chúng tôi đến chức năng như bồn rửa:Cpanel::Server::WebCalls::handle
sub handle ($request) {
my $id = extract_id_from_request($request);
substr( $request, 0, length $id ) = q<>;
Cpanel::WebCalls:?:is_valid($id) or do {
die _http_invalid_params_err("Invalid webcall ID: $id");
};
Điều này dẫn đến:
sub _http_invalid_params_err ($why) {
return Cpanel::Exception::create_raw( 'cpsrvd::BadRequest', $why );
}
Chúng ta có thể theo dõi điều này trở lại . Đây là nơi con đường mòn trở nên lạnh lẽo. Mặc dù chúng tôi có rất nhiều mã nguồn Perl có sẵn, toàn bộ chuỗi này không thể được theo dõi từ đầu đến cuối vì chúng tôi đã bỏ lỡ cuộc gọi đến .Cpanel/Exception/cpsrvd/BadRequest.pmHttpd::ErrorPage
Chúng tôi đã tìm ra rằng bồn rửa là nơi chúng tôi có nguồn, nhưng chúng tôi không thể tìm thấy mã nguồn khởi tạo mã Perl này. Chúng tôi nghi ngờ rằng điều này được nhúng trong tệp nhị phân cPanel và do đó tại sao chúng tôi không thể xác định nơi mã này được gọi.Cpanel::Server::Handlers::Httpd::ErrorPage
Đi sâu vào code, chúng ta có thể thấy rằng nó có một biến gọi là sink cho lỗ hổng này. Biến này không được vệ sinh theo bất kỳ cách nào trong các phiên bản cPanel dễ bị tấn công.Httpd::ErrorPagemessage_html
Nhìn vào bản vá khác với phiên bản mới nhất của cPanel đã giải quyết lỗ hổng này, chúng ta có thể thấy rằng hai dòng sau đã được thêm vào :Cpanel/Server/Handlers/Httpd/ErrorPage.pm
++ use Cpanel::Encoder::Tiny ();
... omitted for brevity ...
++ $var{message_html} = Cpanel::Encoder::Tiny::safe_html_encode_str( $var{message_html} );
Bằng chứng về khái niệm
Đặt mọi thứ chúng ta đã học ở trên lại với nhau, chúng ta có thể đưa ra một bằng chứng khái niệm đơn giản như dưới đây:
<img%20src=x%20onerror="prompt(1)">aaaaaaaaaaaa
<img%20src=x%20onerror="prompt(1)">aaaaaaaaaaaa
<img%20src=x%20onerror="prompt(1)">aaaaaaaaaaaa
<img%20src=x%20onerror="prompt(1)">aaaaaaaaaaaa
... potentially other ports ...
|
|---|
Tác động
Tác động của lỗ hổng này là chúng tôi có thể thực thi JavaScript tùy ý, xác thực trước, trên hầu hết mọi cổng của máy chủ web bằng cPanel trong thiết lập mặc định của nó.
Điều này là do các quy tắc proxy được thảo luận trước đó trong bài đăng trên blog. Ngay cả trên cổng 80 và 443, chúng tôi có thể truy cập thư mục vì nó đang được Apache ủy quyền cho các cổng quản lý cPanel./cpanelwebcall/
Bởi vì điều này, kẻ tấn công không chỉ có thể tấn công các cổng quản lý của cPanel mà còn cả các ứng dụng đang chạy trên cổng 80 và 443.
Do thực tế là các cổng quản lý cPanel dễ bị tấn công kịch bản chéo trang web này, kẻ tấn công có thể tận dụng lỗ hổng này để chiếm quyền điều khiển phiên cPanel của người dùng hợp pháp.
Sau khi hành động thay mặt cho người dùng cPanel được xác thực, việc tải lên trình bao web và thực thi lệnh thường là chuyện nhỏ.
Khắc phục hậu quả và các mốc thời gian
Lỗ hổng này có thể được khắc phục bằng cách nâng cấp lên bất kỳ phiên bản cPanel nào sau đây:
- 11.109.9999.116
- 11.108.0.13
- 11.106.0.18
- 11.102.0.31
Lịch trình tiết lộ có thể được tìm thấy dưới đây:
- Jan 23rd, 2023: Tiết lộ lỗ hổng XSS cho cPanel thông qua .security@cpanel.net
- Ngày 23/2023/<>: Xác nhận từ cPanel rằng họ đã nhận được lỗ hổng và đang điều tra thêm.
- Feb 12th, 2023: Yêu cầu cập nhật từ phía Assetnote
- Ngày 13/2023/<>: Lỗ hổng được cPanel xác nhận và gán . Bản phát hành bản sửa lỗi bảo mật được nhắm mục tiêu sẽ theo dõi trong một vài tuần.SEC-669
- Ngày 1 tháng 2023 năm <>: Lỗ hổng được khắc phục và .
cPanel rất tuyệt vời để làm việc và khắc phục sự cố này trong một khung thời gian hợp lý sau khi chúng tôi tiết lộ lỗ hổng này cho họ.
Kết thúc
cPanel có bề mặt tấn công rộng lớn và nó cần sự quan tâm nhiều hơn từ cộng đồng các nhà nghiên cứu bảo mật. Một trong những rào cản lớn trong quá trình nghiên cứu cPanel của chúng tôi là các tệp nhị phân đã được biên dịch thành Perl. Chúng tôi tin rằng có nhiều lỗi nghiêm trọng hơn chưa được tìm thấy trong các tệp nhị phân này, mặc dù, chúng khá đau đớn khi làm việc từ góc độ kỹ thuật đảo ngược.
Phân tích của chúng tôi về nhị phân nhận thấy rằng hầu hết các điểm cuối không thể truy cập được xác thực trước, tuy nhiên, có rất nhiều tệp nhị phân bên trong thư mục có thể sử dụng nhiều sự chú ý hơn.cpsrvd/cgi-sys/
Đây là một trong những trường hợp đầu tiên chúng tôi báo cáo lỗi cho nhà cung cấp có triển khai tự động cập nhật tự động hoạt động và chủ yếu là mặc định cho phần mềm của họ. Chỉ riêng việc giảm thiểu này đã bảo vệ phần lớn các trang web cPanel khỏi lỗ hổng này trong tự nhiên.
Điều đó đang được nói, vẫn có thể tìm thấy một số lượng lớn các trang web cPanel vẫn dễ bị tổn thương vì chúng không bật tính năng tự động cập nhật.
