24/06/2020

Khắc phục lỗi Windows tự động Shutdown/Restart khi hết hạn Trail


Microsoft cho phép người dùng trải nghiệm Evaluation Edition of Windows Server 2016 or 2012 trong khoảng thời gian 180 ngày. Tuy nhiên, sau 180 ngày này, Windows sẻ tự ý Shutdown/Reboot mà không có bất kỳ cảnh báo nào cho người dùng cả. Việc này sẻ khiến chúng ta không biết lý do tại sao, đôi khi sẻ làm cho các chương trình đang chạy bị tắt đột ngột và mất dữ liệu.
Có 02 biện pháp để xử lý lỗi này:
Cách 1: Mua License bản quyền và Active Windows - Tất nhiên là không rồi!
Cách 2. Reset Trial bằng dòng lệnh trong CMD - Để thử xem nào!
Để thực hiện reset Trial, chúng ta thực hiện như sau:
1. Mở CMD bằng quyền Administrator.

- Nếu bạn đang dùng Standard Editions thì gõ lệnh sau: slmgr.vbs -ato

reset-trial-windows-01- Nếu bạn đang dùng Datacenter Edition hoặc các bản khác thì gõ lệnh: slmgr.vbs -rearm
reset-trial-windows-022. Kết quả hiện ra, sau đó tiến hành reboot lại để hệ điều hành cập nhật lại thông tin:
reset-trial-windows-03
3. Mỗi lần reset trial sẽ được dùng trong vòng 180 ngày - Số lần reset tối đa là 6 lần, tức là thời gian dùng thử tối đa là 3 năm (180 days * 6 = 3 years).
ThaoPT - Tham khảo thêm: Tại đây

16/05/2020

Hãng bảo mật tuyên bố dừng mua lỗ hổng trong iOS vì quá thừa thãi

Năm ngoái hãng Zerodium cũng từng chứng kiến số lượng lỗ hổng khai thác iOS được gửi đến nhiều đến mức giá của nó giảm đi so với Android.


Một công ty chuyên lùng mua các lỗ hổng bảo mật và cách khai thác từ các hacker cho biết, họ đã sẽ ngừng mua lại các loại lỗi khai thác trên iOS bởi vì đang có quá nhiều "các mặt hàng" này.

Zerodium vốn là một công ty an ninh mạng nổi tiếng khi trả tiền cho các nhà phát triển để có được các lỗ hổng và cách khai thác phần mềm mà họ tìm ra được. Đặc biệt trong nhiều trường hợp, số tiền mà Zerodium trả cho các nhà phát triển còn cao hơn nhiều so với chương trình tiền thưởng tìm lỗ hổng của Apple.
Dòng tweet thông báo dừng mua các loại lỗ hổng khai thác iOS của Zerodium
Thế nhưng vào thứ Tư vừa qua, công ty cho biết sẽ dừng việc mua lại bất kỳ cách khai thác chiếm quyền ưu tiên, đoạn mã thực thi từ xa hay cách vượt qua sandbox của iOS "trong vòng 2 đến 3 tháng tới do có quá nhiều người gửi lên." Bên cạnh đó, công ty cũng cho biết mức giá cho nhiều loại lỗ hổng nhất định trong Safari trên iOS cũng sẽ sụt giảm mạnh trong tương lai gần.

Trong dòng tweet gần đây, nhà sáng lập Zerodium, Chaouki Bekrar cho biết khả năng bảo mật iOS là đáng "vứt đi". Ông còn bổ sung thêm rằng việc thiếu tính thống nhất và một cơ chế bảo mật có tên gọi PAC (pointer authentication codes) là hai yếu tố khiến khả năng bảo mật của iOS "đang gần như không có."


Lời chê bai của Chaouki Bekrar, nhà sáng lập Zerodium, đối với khả năng bảo mật của iOS.
Có thể một phần của điều này là thế giới vẫn đang trong giai đoạn phong tỏa trên quy mô lớn và do vậy, các nhà nghiên cứu bảo mật có nhiều thời gian hơn để mày mò những lỗ hổng này. Một yếu tố khác có thể là iOS 13 quả thật đang có nhiều lỗi đến mức đáng kinh ngạc – một thực tế đã khiến Giám đốc phần mềm Apple, ông Craig Federighi phải cải tổ lại toàn bộ quá trình phát triển iOS phiên bản kế tiếp.

Do vậy, Bekrar cho biết: "Hãy hy vọng iOS 14 sẽ tốt hơn."

Đây không phải lần đầu Zerodium chứng kiến cảnh thừa mứa các lỗ hổng khai thác iOS đến vậy. Vào tháng Chín năm 2019, công ty từng cho biết, lần đầu tiên họ phải trả cho các lỗ hổng khai thác Android nhiều tiền hơn iOS do dư thừa nguồn cung.


Tham khảo Apple Insider - Dịch GenK

16/04/2020

VMware plugs critical flaw in vCenter Server, patch ASAP! - CVE-2020-3952

VMware has fixed a critical vulnerability (CVE-2020-3952) affecting vCenter Server, which can be exploited to extract highly sensitive information that could be used to compromise vCenter Server or other services which depend on the VMware Directory Service (vmdir) for authentication.

About CVE-2020-3952

VMware vSphere is VMware’s cloud computing virtualization platform. vCenter Server is server management software for controlling VMware vSphere environments.
“Under certain conditions vmdir that ships with VMware vCenter Server, as part of an embedded or external Platform Services Controller (PSC), does not correctly implement access controls. VMware has evaluated the severity of this issue to be in the Critical severity range with a maximum CVSSv3 base score of 10.0,” the company noted in an advisory published last week.
The vulnerability exists in vCenter Server 6.7, running on Windows or a virtual appliance, only if the installations were upgraded from a previous release line such as 6.0 or 6.5. It can be exploited by a malicious actor with network access to an affected vmdir deployment.
“Clean installations of vCenter Server 6.7 (embedded or external PSC) are not affected. vCenter Server versions 6.5. and 7.0 are unaffected,” the company pointed out.

How to fix the problem?

Administrators are advised to check whether their deployments are affected (here is how) and, if they are, update them to version 6.7u3f or 7.0.
There are no effective workarounds for this problem, though there are compensating controls admins can implement to minimize/mitigate the risk associated with it.
Bob Plankers, who works in the Cloud Platforms group at VMware, provided additional insight on those controls, on why it’s better to patch, and answered a number of questions admins may have regarding this flaw and the implementation of the fix.
CVE-2020-3952 was privately reported to VMware and there are currently no public PoC exploits for it. The company did not mention whether the flaw is being exploited in the wild, so it’s likely that it isn’t (yet).
Source: UG

24/03/2020

Hướng dẫn cài đặt và sử dụng ClamAV để check malware trên Linux


NextSec xin giới thiệu đến các bạn một phần mềm Kiểm tra và diệt Malware chạy trên một số hệ điều hành của nền tảng Linux có tên gọi là "ClamAV"

1. Cách cài đặt: Về việc cài đặt ClamAV tương đối đơn giản, bạn có thể sử dụng lệnh sau để cài đặt



- Đối với Ubuntu, Debian:


sudo apt-get install clamav clamav-daemon -y

- Đối với Centos:

yum install -y clamav-server clamav-server-systemd clamav-scanner-systemd clamav-data clamav-update clamav-filesystem clamav clamav-devel clamav-lib

Sau khi cài đặt xong các bạn có thể sử dụng lệnh sau để quét trên hệ thống

clamscan -r <đường dẫn các bạn muốn quyét>

Ví dụ: #clamscan -r /home


Mình cũng xin hướng dẫn thêm cho các bạn một số tùy chọn kèm theo để tiện cho cách bạn tham khảo:

--log=<đường dẫn đến file> : option giúp bạn lưu lại phần report vào một file các bạn phải tạo file trước khi chạy để tránh phát sinh lỗi.
--remove=[yes/no] : option này giúp bị xóa hoặc không xóa file clamav scan được.
--move=<đường dẫn lưu trữ>: di chuyển tất cả các file có nội dung malware sang một đường dẫn khác để cách ly.
--copy=<đường dẫn lưu trữ>: tạo ra một nhân bản để lưu trữ lại.
--help: hướng dẫn.
Ngoài ra, các bạn có thể dùng script sau để đặt lịch quét và gửi mail:

https://github.com/wisoez/ClamAV/blob/master/ClamAV.sh

Chúc các bạn thành công!


05/03/2020

Lỗ hổng "GhostCat" trên Webserver Apache Tomcat cho phép chiếm quyền điều khiển server !

Tất cả các phiên bản (9.x/8.x/7.x/6.x) của Apache Tomcat được phát hành trong suốt 13 năm qua được phát hiện tồn tại lỗ hổng ‘file read and inclusion’ (đọc và truy cập trái phép vào tệp tin nhạy cảm trên máy chủ web) nghiêm trọng, có thể bị khai thác nếu sử dụng cấu hình mặc định.

Điều đáng ngại là một số PoC của lỗ hổng này đã xuất hiện trên mạng nên ai cũng có thể xâm nhập vào các máy chủ web dính lỗ hổng.


Lỗ hổng GhostCat (CVE-2020-1938) có điểm CVSS 9.8 cho phép kẻ tấn công trái phép từ xa đọc nội dung file bất kỳ trên các máy chủ web tồn tại lỗ hổng, truy cập các file cấu hình nhạy cảm hoặc mã nguồn, hay thực thi mã tùy ý nếu máy chủ cho phép tải file.

Lỗ hổng Ghostcat và cách thức khai thác
Theo hãng bảo mật Chaitin Tech, lỗ hổng lợi dụng cách giao thức AJP của Apache Tomcat để xử lý các thuộc tính.

“Nếu trang cho phép người dùng tải file lên, trước hết kẻ tấn công có thể tải file chứa đoạn code JSP script độc hại lên máy chủ (ảnh, text ...), sau đó khai thác Ghostcat, để thực thi mã từ xa”.
Giao thức Apache JServ Protocol (AJP) về cơ bản là một phiên bản được tối ưu hóa của giao thức HTTP cho phép Tomcat giao tiếp với máy chủ web Apache.

Dù giao thức AJP được bật mặc định và lắng nghe tại cổng TCP 8009, nhưng lại bị gắn với địa chỉ IP 0.0.0.0 và chỉ có thể bị khai thác từ xa khi nếu truy cập đến các máy Client không đáng tin cậy.
Theo tìm kiếm từ onyphe, một công cụ tra cứu mã nguồn mở và dữ liệu về các mối đe doạ, hiện có trên 170.000 thiết bị có kết nối AJP Connector trên Internet.

Cập nhật bản vá ngay lập tức
Lỗ hổng đã được báo cáo cho đội ngũ Apache Tomcat và hãng này phát hành phiên bản Apache 9.0.31, 8.5.51 và 7.0.100 để xử lý.
Các phiên bản mới nhất này cũng vá hai lỗi CVE-2020-1935 và CVE-2019-17569 ở mức độ nghiêm trọng thấp.
Các nhà quản trị web được khuyến cáo cập nhật bản vá ngay lập tức và không bao giờ mở cổng AJP đến các máy Client không đáng tin cậy.
Đội ngũ của Tomcat cho biết: “Người dùng nên lưu ý một thay đổi đã được thực hiện trong cấu hình AJP Connector mặc định phiên bản 9.0.31. Do vậy người dùng cập nhật lên phiên bản 9.0.31 hoặc cao hơn sẽ cần phải thực hiện những thay đổi nhỏ trong cấu hình của mình”.
Tuy nhiên, nếu vì lý do nào đó, người dùng không thể nâng cấp phiên bản máy chủ bị ảnh hưởng ngay lập tức, thì có thể khắc phục tạm thời bằng cách tắt AJP Connector.

Theo THN - Dịch WH

03/01/2020

Cần bao nhiêu thời gian để... đánh sập hệ thống ngân hàng Việt Nam?

Mỗi năm (nhưng có vài năm bị gián đoạn vì... thiếu kinh phí), trường Harvard Kennedy mời một vị lãnh đạo cấp cao của Việt Nam và bộ sậu của họ đến nghe giáo sư, chuyên gia Harvard, Fulbright giảng dạy, thảo luận về chính sách quản trị quốc gia. Khách mời năm 2019 là ông Nguyễn Văn Bình và chủ đề là “Đổi mới sáng tạo, Mở cửa và An ninh số”.

Vì có nhiều người trong đoàn đến từ các ngân hàng, tôi bắt đầu bằng câu hỏi trên. Kinh nghiệm cá nhân của tôi cho thấy chỉ cần 1 hacker và 2 tuần.

Đầu năm 2017, một ngân hàng ở Việt Nam nhờ tôi kiểm tra an ninh cho app Mobile Banking. Từ nhiều năm nay đây là công việc hàng ngày của tôi, nhưng đây cũng là lần đầu tiên tôi đánh giá một sản phẩm của VIệt Nam.

Tôi mất gần 2 tuần để tìm hiểu cách thức hoạt động của app Mobile Banking này. Tôi tìm được nhiều lỗ hổng, nhưng nghiêm trọng hơn hết là tôi tìm được cách trộm tiền từ bất kỳ tài khoản nào. Đối với một app Mobile Banking thì dân trong nghề gọi một lỗ hổng như vầy là game over, không còn gì để mà hack nữa. Sau đó tôi còn phát hiện ra khoảng 3-4 ngân hàng thuộc hàng top của Việt Nam cũng có lỗ hổng tương tự, vì họ sử dụng chung giải pháp Mobile Banking.

Thử nghĩ chuyện gì sẽ xảy ra nếu một ai đó tự động chuyển tiền và khóa tài khoản của hàng triệu người dùng trên hệ thống 4-5 ngân hàng lớn nhất cả nước? Trong phút chốc, niềm tin, vốn đã dễ bị lung lay, của người dân vào hệ thống ngân hàng sẽ sụp đổ và tôi không thể tưởng tượng được hậu quả sẽ như thế nào cho kinh tế Việt Nam.

Không phải tôi có tài năng gì đặc biệt, mà bất kỳ bạn sinh viên chán học nào cũng có thể tìm được những lỗ hổng này, chỉ cần mất một thời gian huấn luyện. Ngay cả quý vị ngồi đây, nếu muốn học, tôi nghĩ chỉ cần huấn luyện 2-3 năm.

Làm việc với các bên liên quan để sửa lỗi, tôi nhận ra rằng vấn đề không phải họ không quan tâm đến bảo mật, mà là họ không biết nên làm sao  và không có người để làm. Mặc dù rất muốn làm cho đúng, cho tốt, rất cầu thị và sẵn sàng đầu tư, nhưng họ thường làm những việc không cần và không làm những việc cần.

Đã 3 năm kể từ ngày tôi thực hiện dự án này, nhưng tôi không thấy có nhiều hy vọng tình hình đã tốt hơn. Những dữ kiện mà tôi thu thập được trong quá trình chuẩn bị bài nói chuyện này cho thấy dường như mọi chuyện vẫn như cũ.

Xem tiếp tại đây! - theo ThaiDN  VNHacker.

09/12/2019

New Linux Bug Lets Attackers Hijack Encrypted VPN Connections


A team of cybersecurity researchers has disclosed a new severe vulnerability affecting most Linux and Unix-like operating systems, including FreeBSD, OpenBSD, macOS, iOS, and Android, that could allow remote 'network adjacent attackers' to spy on and tamper with encrypted VPN connections.
The vulnerability, tracked as CVE-2019-14899, resides in the networking stack of various operating systems and can be exploited against both IPv4 and IPv6 TCP streams.

Since the vulnerability does not rely on the VPN technology used, the attack works against widely implemented virtual private network protocols like OpenVPN, WireGuard, IKEv2/IPSec, and more, the researchers confirmed.

This vulnerability can be exploited by a network attacker — controlling an access point or connected to the victim's network — just by sending unsolicited network packets to a targeted device and observing replies, even if they are encrypted.

As explained by the researchers, though there are variations for each of the impacted operating systems, the vulnerability allows attackers to:

  • determine the virtual IP address of a victim assigned by the VPN server,
  • determine if there is an active connection to a given website,
  • determine the exact seq and ack numbers by counting encrypted packets and/or examining their size, and
  • inject data into the TCP stream and hijack connections.

"The access point can then determine the virtual IP of the victim by sending SYN-ACK packets to the victim device across the entire virtual IP space," the team said in its advisory.

"When a SYN-ACK is sent to the correct virtual IP on the victim device, the device responds with a RST; when the SYN-ACK is sent to the incorrect virtual IP, nothing is received by the attacker."

While explaining variations in the behavior of different operating systems, as an example, researchers said the attack does not work against macOS/iOS devices as described.

Instead, an attacker needs to "use an open port on the Apple machine to determine the virtual IP address." In their testing, the researchers use "port 5223, which is used for iCloud, iMessage, FaceTime, Game Center, Photo Stream, and push notifications, etc."

The researchers tested and successfully exploited the vulnerability against the following operating systems and the init systems, but they believe this list could go long as researchers test the flaw on more systems.
  • Ubuntu 19.10 (systemd)
  • Fedora (systemd)
  • Debian 10.2 (systemd)
  • Arch 2019.05 (systemd)
  • Manjaro 18.1.1 (systemd)
  • Devuan (sysV init)
  • MX Linux 19 (Mepis+antiX)
  • Void Linux (runit)
  • Slackware 14.2 (rc.d)
  • Deepin (rc.d)
  • FreeBSD (rc.d)
  • OpenBSD (rc.d)
"Most of the Linux distributions we tested were vulnerable, especially Linux distributions that use a version of systemd pulled after November 28th of last year, which turned reverse path filtering off," the researchers said.

"However, we recently discovered that the attack also works against IPv6, so turning reverse path filtering on isn't a reasonable solution."

As possible mitigation, researchers suggested to turn on reverse path filtering, implement bogon filtering, and encrypt packet size and timing to prevent attackers from making any inference.
While the researchers have not yet revealed technical details of the vulnerability, they are planning to publish an in-depth analysis of this flaw and its related implications, after affected vendors, including Systemd, Google, Apple, OpenVPN, WireGuard, and different Linux distros issue satisfactory workarounds and patches.

Source: THN

29/10/2019

So sánh giấy phép mã nguồn mở Apache, MIT, GPL

Mã nguồn mở ngày nay đã và đang trở nên phổ biến hơn bao giờ hết, những dự án mã nguồn mở có thể được tìm thấy hầu như ở bất kì đâu trên không gian mạng rộng lớn này. Tuy nhiên dù có “mở” đi chăng nữa thì những phần mềm mã nguồn mở phải tuân theo những giấy phép nhất định. Điển hình là 3 loại giấy phép phổ biến nhất là Apache, MIT và GPL. Vậy, giữa chúng có gì khác nhau.


Trước hết, giấy phép mã nguồn mở là một loại giấy phép được sử dụng cho các phần mềm mã nguồn mở. Giấy phép này cho phép bất kì cá nhân hay tổ chức nào cũng có thể nghiên cứu, thay đổi, chỉnh sửa và cải tiến phần mềm, và phân phối ở các dạng khác nhau như thay đổi hoặc chưa thay đổi.

Giấy phép Apache
Giấy phép Apache ra đời bởi Quỹ Phần mềm Apache (Apache Software Foundation - ASF). Đây là một giấy phép phần mềm tự do, không có copyleft, bắt buộc trong việc thông báo bản quyển và lời phủ nhận. Giấy phép này hoạt động như các giấy phép phần mềm mã nguồn mở khác, trao cho người sử dụng phần mềm quyền tự do trong bất kỳ mục đích nào, từ chỉnh sửa, thay đổi, phân phối hoặc phân phối bản có sửa đổi của phần mềm theo các điều khoản đã ghi của giấy phép mà không lo lắng tới phí bản quyền.
Được phần đông người dùng đánh giá là giấy phép không có nhiều ràng buộc nên Apache là một giấy phép được sử dụng rộng rãi. Theo số liệu đã được thống kê, đến tháng 10 năm 2012, đã có đến 8708 dự án đặt tại SourceForge.net được cấp phép theo các điều khoản của Giấy phép Apache. Sự phổ biến này đã được trình bày rõ ràng trong một bài viết trên blog vào tháng 5 năm 2008, Google đã liệt kê đến hơn 25000 trong tổng số 100000 dự án đặt trên Google Code đang sử dụng giấy phép này. 

Các điều khoản giấy phép Apache
Trong mỗi tập tin được cấp phép, bất kỳ bản quyền, bằng sáng chế hay thương hiệu và thông báo ghi công phải được giữ nguyên trong các đoạn mã khi phát hành và phải thông báo các tập tin đã thay đổi trong source code.

Nếu có một tập tin NOTICE trong bản phân phối gốc thì các phiên bản sau chỉnh sửa phải kèm theo nội dung của tập tin nêu trên bên trong phần mềm, hoặc tài liệu hướng dẫn sử dụng, hoặc trong một giao diện của phiên bản hiện hành. 
Trừ khi có thông báo đặc biệt nào khác từ ASF thì bất kỳ đóng góp chỉnh sửa nào gửi cho người cấp phép đều sẽ tuân theo các điều khoản của giấy phép mà không cần thông qua bất cứ điều kiện gì nhưng vẫn giữ được sự hợp tác thỏa thuận giữa các bên trong phần đóng góp này.

Giấy phép MIT
Giấy phép MIT được tạo ra bởi Viện Công nghệ Massachusetts (MIT) danh tiếng. Là một loại giấy phép cấp phép, không có copyleft và c rất ít hạn chế trong việc sử dụng, trở thành một trong những giấy phép lý tưởng trong việc phát triển phần mềm. Sự phổ biến của giấy phép này đã được minh chứng bằng việc GitHub, trang web lưu trữ source code nổi tiếng, đã xác nhận rằng đây là giấy phép phổ biến nhất trên dịch vụ của họ, vượt xa các biến thể giấy phép GPL( sẽ đề cập sau) và các giấy phép phần mềm tự do nguồn mở (FOSS) khác. MIT đã tạo tiền để cho các dự án mà ắt hẳn bạn đã nghe qua một lần như: Ruby on Rails, Node.js, jQuery và X11 hay X.

Các điều khoản giấy phép MIT
Các điều khoản của giấy phép MIT được gói gọn rằng: "Quyền hạn sử dụng được trao cho người sử dụng với không hạn chế nào, kể cả quyền sử dụng, sao chép, chỉnh sửa, kết hợp, xuất bản, phân phối, hay phân phối dưới các dạng phiên bản sửa đổi khác nhau, và bán bản sao chép của phần mềm nhưng với điều kiện như: những file ghi về tác giả, người có công (như file NOTICE), file ghi về quyền hạn sử dụng phải được bao gồm trong các phiên bản sử dụng giấy phép này".

Giấy phép GPL
Giấy phép GPL hay còn được biết đến với cái tên GNU General Public License (GNU GPL/GPL) là một giấy phép mã nguồn mở có copyleft được sử dụng rộng rãi, đảm bảo cho người dùng khả năng chạy, nghiên cứu, tùy biển về phần mềm, là sản phẩm trí tuệ của Richard Stallman của Quỹ Phần mềm Tự do (FSF) cho dự án GNU, hỗ trợ cấp cho người nhận chương trình máy tính quyền của Định nghĩa Phần mềm Tự do.

Nhờ có copyleft mà GPL đã trở thành Giấy phép mã nguồn mở phổ biến nhất trong lĩnh vực phầm mềm tự do và nguồn mở. Các sản phẩm tiêu biểu được tạo ra theo giấy phép GPL có thể kể đến như nhân Linux và Bộ biên dịch GNU hay GCC. Nhờ giấy phép này mà nhân Linux đã có những thành công rực rỡ trên con đường phát triển của mình. 

Các điều khoản của giấy phép GPL
GNU GPL cho đến nay đã trải qua 3 phiên bản gồm 17 điều khoản như được tự do chạy chương trình dưới bất cứ mục đích nào, tự do tìm hiểu các hoạt động của chương trình và tự do thực hiện các thay đổi, chỉnh sửa lên nó và quyền truy cập mã nguồn là điều kiện bắt buộc cho quyền tự do này, tự do tái phân phối bản sao, tự do trong việc cải tiến, phát hành cải tiến ra công cộng, tạo điều kiện thuận lợi cho kỹ thuật phân tích ngược (reverse engineeing).

Kết luận
Có thể thấy rằng nhờ có các giấy phép mã nguồn mở mà ngành phần mềm đã và đang trở nên phát triển mạnh hơn bao giờ hết. Các giấy phép tuy khác nhau nhưng đều có điểm chung trong việc tạo điều kiện chỉnh sửa cho nhà phát triển, tạo cơ hội cải tiến chương trình, làm đa dạng hóa chương trình gốc, giúp từng byte, từng bit người sử dụng tương tác trở nên hoàn hảo hơn bao giờ hết.

Theo: TKT

28/10/2019

New Cache Poisoning Attack Lets Attackers Target CDN Protected Sites


A team of German cybersecurity researchers has discovered a new cache poisoning attack against web caching systems that could be used by an attacker to force a targeted website into delivering error pages to most of its visitors instead of legitimate content or resources.

The issue could affect sites running behind reverse proxy cache systems like Varnish and some widely-used Content Distribution Networks (CDNs) services, including Amazon CloudFront, Cloudflare, Fastly, Akamai, and CDN77.

In brief, a Content Distribution Network (CDN) is a geographically distributed group of servers that sit between the origin server of a website and its visitors to optimize the performance of the website.

A CDN service simply stores/caches static files—including HTML pages, JavaScript files, stylesheets, images, and videos—from the origin server and delivers them to visitors more quickly without going back to the originating server again and again.

Each of the geographically distributed CDN server, known as edge nodes, then also shares the exact copy of the cache files and serve them to visitors based on their locations.

Generally, after a defined time or when manually purged, the CDN servers refresh the cache by retrieving a new updated copy of each web page from the origin server and store them for future requests.

How Does CPDoS Attack Work Against CDNs?

Dubbed CPDoS, short for Cache Poisoned Denial of Service, the attack resides in the way intermediate CDN servers are incorrectly configured to cache web resources or pages with error responses returned by the origin server.

The CPDoS attack threatens the availability of the web resources of a website just by sending a single HTTP request containing a malformed header, according to three German academics, Hoai Viet Nguyen, Luigi Lo Iacono, and Hannes Federrath.

"The problem arises when an attacker can generate an HTTP request for a cacheable resource where the request contains inaccurate fields that are ignored by the caching system but raise an error while processed by the origin server."

Here's how the CPDoS attack works:
- A remote attacker requests a web page of a target website by sending an HTTP request containing a malformed header.
- If the intermediate CDN server doesn't have a copy of the requested resource, it will forward the request to the origin web server, which will get crash due to the malformed header.
- As a consequence, the origin server then returns an error page, which eventually gets stored by the caching server instead of the requested resource.
- Now, whenever legitimate visitors try to obtain the target resource, they will be served the cached error page instead of the original content.
- The CDN server will also spread the same error page to other edge nodes of the CDN's network as well, rendering targeted resources of the victim's website unavailable.

"It is worth noting that one simple request is sufficient to replace the genuine content in the cache by an error page. This means that such a request remains below the detection threshold of web application firewalls (WAFs) and DDoS protection means, in particular, as they scan for large amounts of irregular network traffic."

"Moreover, CPDoS can be exploited to block, e.g., patches or firmware updates distributed via caches, preventing vulnerabilities in devices and software from being fixed. Attackers can also disable important security alerts or messages on mission-critical websites such as online banking or official governmental websites."

3 Ways to Launch CPDoS Attacks

CDN Services Vulnerable to CPDoS Attacks
Researchers carried out three attacks against different combinations of web caching systems and HTTP implementations and found that Amazon's CloudFront CDN is the most vulnerable to the CPDoS attack.

"We analyze the caching behavior of error pages of fifteen web caching solutions and contrast them to the HTTP specifications. We identify one proxy cache product and five CDN services that are vulnerable to CPDoS."

The complete results of their tests are as follows:

To be noted, sites running behind some of the listed CDN services are vulnerable because of their own misconfiguration that doesn’t prevent caching servers from storing error pages, and due any weakness in the respective CDN service.

Theo: THN

23/10/2019

Website giả mạo Cổng thông tin điện tử của Bộ Công an, phát tán mã độc

Trang web có địa chỉ http://113113vn.com không thuộc hệ thống tên miền của các tổ chức Chính phủ tại Việt Nam, giả mạo Cổng thông tin điện tử của Bộ Công an.

Sáng 23-10, Công an Đà Nẵng vừa phát cảnh báo về website mạo danh http://113113vn.com, địa chỉ IP 45.76.234.141, được các đối tượng lập nên để phát tán mã độc.


Cụ thể, khi truy cập "Phần mềm giám sát an toàn" tại website mạo danh trên, người dùng có nguy cơ tải về tệp "vn.apk". Đây là tệp chứa mã độc, có thể chiếm quyền điều khiển thiết bị của người truy cập, đánh cắp toàn bộ thông tin, dữ liệu quan trọng như định vị, giám sát cuộc gọi, đọc trộm tin nhắn, kết nối internet…cũng như các dữ liệu lưu trữ trong thiết bị.

Quan sát nhanh, website được thiết kế theo giao diện cho thiết bị cầm tay, phần dưới cùng ghi địa chỉ của Công an TP Đà Nẵng (80 Lê Lợi, phường Thạch Thang, quận Hải Châu), máy chủ của website đặt tại Mỹ.

Công an Đà Nẵng khuyến cáo người dân, tổ chức không truy cập vào trang web này. Trường hợp đã tải tệp tin "vn.apk" trên thiết bị di động thì nhanh chóng gỡ bỏ, xóa tệp tin để tránh bị cài mã độc.

Theo: NLĐ