Bài liên quan
Nhà mật mã học nổi tiếng Bruce Schneier đã nói về
điểm yếu Heartbleed như sau: “Nếu theo thang điểm từ 0 tới 10 tôi sẽ
đánh giá tính nguy hiểm của điểm yếu này là 11”.
Theo
các bằng chứng thu được cho thấy, việc quét bộ nhớ của các máy chủ bị
nhiễm thì điểm yếu này đã xuất hiện từ năm 2013, có nghĩa là ai đó đã
biết đến điểm yếu này từ trước đó.
Chuyên gia lập trình người Đức Robin Seggelmann đã nói, trong đề xuất
mã mở rộng Hearbeat cho giao thức TLS (RFC 6520 - Transport Layer
Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat
Extension) vào ngày 01/01/2012, có một trong các tiến trình của nó đã
không thực hiện việc kiểm tra ranh giới cần thiết. Từ đó, có thể thực
hiện các yêu cầu (request) tới máy chủ và nhận được các phân đoạn của
bộ nhớ (RAM) với kích thước tới 64 KB cho mỗi yêu cầu. Việc bỏ sót lỗi
này trong mã là do không xem xét kỹ cả ở khâu phản biện, điều này vi
phạm các nguyên tắc xây dựng Open Source. Seggelmann đã đánh giá, lỗi
“tương đối tầm thường” nhưng quả thật nó đã gây ra một hậu quả nghiêm
trọng; “Tôi đã làm việc để OpenSSL tốt hơn, tôi đã gửi rất nhiều các vá
lỗi và thực hiện các hàm mới. Thật đáng tiếc một hàm trong số các hàm
mới tôi đã bỏ qua việc kiểm tra độ dài thay đổi”. 1. Hoạt động bảo về website ở trạng thái bình thường
Khi kết nối với website được bảo vệ (giao thức https), đầu tiên việc thỏa thuận cấu hình phiên an toàn được thực hiện. Web browser hỏi và kiểm tra chứng chỉ của website, sinh khóa mã hóa cho phiên an toàn và mã hóa dữ liệu thông qua khóa công khai của website. Website giải mã thông tin bằng khóa bí mật của mình và có thể nói là phiên được bắt đầu thực hiện.
HTTP ở dạng đơn giản thực hiện tuần tự các sự kiện không liên quan tới nhau. Browser gửi các yêu cầu dữ liệu từ nguồn tài nguyên, website trả về các dữ liệu này, sau đó các yêu cầu được tiếp tục, … Đối với trường hợp kết nối được bảo vệ cũng sử dụng đúng cơ chế như vậy. Heartbeat Extension (Heartbeat mở rộng) cho TLS đơn giản cho phép một thiết bị biết được sự tồn tại của thiết bị còn lại thông qua việc gửi các thông tin nhất định và nhận được các thông tin đó ngược lại.
2. Lỗi Heartbleed
Tấn công Heartbleed dựa trên việc thay đổi độ dài dữ liệu. Định dạng dữ liệu sai Heartbeat sẽ thông báo rằng độ dài là 64KB – kích thước lớn nhất có thể. Khi đó Server sẽ nhận được gói này và chuyển đúng lượng dữ liệu sao chép từ bộ nhớ cho câu trả lời. Dữ liệu trong bộ nhớ RAM sẽ chứa rất nhiều thông tin: từ khóa mã hóa, tài khoản đăng nhập và những thông tin nhạy cảm khác. Điều này có thể bị sửa chữa khi hacker biết rằng phía gửi không thông báo độ dài gói sai.
Cách lợi dụng điểm yếu này được mô tả qua các hình dưới.
3. Heartleech: Chương trình tìm kiếm và lấy khóa mật SSL
Điểm yếu Heartbleed trong OpenSSL (trong lịch sử đây là lỗi đầu tiên có tên gọi riêng) cho phép lấy được các khóa mật SSL từ bộ nhớ của máy chủ.
Dùng công cụ Heartleech có thể tự động hóa việc quét bộ nhớ động (RAM) và lấy thông tin khóa. Khác với các bộ dò quét khác nó có chế độ autopwn (với tham số -a) cho phép thực hiện tuần tự tất cả các bước đọc bộ nhớ và khôi phục khóa.
Chương trình cũng đặc biệt ở chế độ làm việc ẩn: trao đổi các gói dữ liệu Heartbeats được thực hiện không phải ở thời điểm “bắt tay” mà sau đó ở dạng mã hóa sử dụng hàm ssl3_write_bytes(). Thực tế để sử dụng được hàm này cần thực hiện export từ OpenSSL hoặc nếu không tải mã nguồn OpenSSL và kết nối chương trình heartleech.c với các thư viện libcrypto.a và libssl.a của bộ OpenSSL.
git clone git://git.openssl.org/openssl.git
cd openssl
./config
make depend
make
gcc ../heartleech/heartleech.c libcrypto.a libssl.a -ldl -o heartleech
#Cygwin compile string, order matters:
gcc ../heartleech/heartleech.c libcrypto.a libssl.a -ldl -o heartleech
Chương trình Heartleech hỗ trợ IPv4 và IPv6, vượt được Snort IDS, làm việc với các gói đầy đủ 64KB và có thể lưu dữ liệu nhị phân vào tệp (với tham số -f ).
Ví dụ, lệnh sau gửi hàng triệu yêu cầu tới server chỉ định và ghi lại các câu trả lời vào tệp. Kích thước tệp lên tới 64 GB.
./heartleech www.cloudflarechallenge.com -f challenge.bin
Sau đó có thể sử dụng chương trình grep đối với tệp này để tìm khóa, cookies và mật khẩu. Một trong các phương án đó là có thể chạy Heartleech với tham số -a, khi đó việc tìm kiếm các số nguyên tố của khóa RSA sẽ được bắt đầu một cách tự động sau khi ghi vào tệp, sau đó chương trình sẽ sinh khóa bí mật sử dụng các số nguyên tố đã tìm được. Phương pháp này chỉ hiệu quả đối với các khóa RSA.
Cuộc thi lấy khóa SSL của CloudFlare
Công ty CloudFlare đã đưa ra cuộc thi Heartbleed Challenge và đưa ra giải thưởng 10.000 USD bất kỳ ai có thể lấy được khóa mật trên máy chủ ginx-1.5.13 với điểm yếu của phiên bản OpenSSL 1.0.1.f với hệ điều hành Ubuntu 13.10x86_64.
Có thể nói, cuộc thi đã có lời giải ngay lập tức. Trong vòng 3h đồng hồ, hai hacker độc lập với nhau đã lấy được khóa SSL từ máy chủ sử dụng Exploit Heartbleed.
Đầu tiên (16:22:01 ngày 11/04) là lập trình viên Fedor Indutny ở Matscova, một trong những lập trình viên chính của Node.js. Để lấy được khóa Fedor đã gửi tới máy chủ hơn 2,5 triệu yêu cầu để lấy các đoạn bộ nhớ.
Người thứ hai (17:12:19 ngày 11/04) là Ilkka Mattila của NCSC-FI đã tìm ra khóa sau khoảng 100 nghìn yêu cầu gửi tới Server.
Sau vài tiếng còn có thêm các chuyên gia khác tìm ra khóa trên máy chủ này: Rubin Xu (04:11:09 ngày 12/04) – nghiên cứu sinh trong nhóm Security group của Cambridge University và Ben Murphy (7:28:50 ngày 12/04)- Security Researcher.
Từ đây các chuyên gia của CloudFlare đã nhận xét rằng:
Việc lấy khóa bí mật SSL từ bộ nhớ động của máy chủ là tương đối dễ dàng, thậm chí chỉ cần đọc các đoạn RAM với kích thước nhỏ.
Không nên đánh giá thấp sức mạnh của số đông và tính chất nguy hiểm của lỗi này.
Nguyễn Viết Phan (tổng hợp)
Post a Comment