Trái Tim Rĩ Máu Heartbleed

Tổng hợp các phân tích về điểm yếu Heartbleed (phần 1)

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)

Tổng hợp các phân tích về điểm yếu Heartbleed (phần 2)

Chuyện gì sẽ xảy ra nếu thực tế phía yêu cầu không gửi lượng payload byte? Nếu pl trong thực tế chỉ chứa 1 byte? Khi đó memcpy sẽ đọc từ bộ nhớ tất cả những gì ở gần với bản ghi SSLv3.

4. Tấn công “Heartbleed ngược”: đọc bộ nhớ của các máy tính client.

Trong quá trình update máy chủ để khắc phục điểm yếu Heartbleed, công ty Meldium đã phát hiện ra một điều đặc biệt: đối với một số website (trong số đó có cả những website rất nổi tiếng) vẫn còn điểm yếu kể cả sau khi update. Đó chính là một cách tấn công đặc biệt – tấn công “Heartbleed ngược”.
Theo cách tấn công thông thường: đối tượng xấu sử dụng các máy client để tấn công máy chủ HTTPS, sao chép cookies, mật khẩu và các Chứng thư từ bộ nhớ động (RAM). Còn một kịch bản tấn công ngược cũng được tiến hành theo đúng logic khai thác điểm yếu Heartbleed như vậy khi các máy chủ cấu hình gửi các gói heartbeat theo TLS và đọc nội dung RAM của máy  khách (clients). Điều này là thực tế bởi vì TLS Heartbeat là giao thức đối xứng cho phép sinh gói từ cả hai phía.
Các điểm yếu của máy khách có thể kể đến: các web browser thông thường và các ứng dụng sử dụng HTTP API (tất cả từ Dropbox cho đến Microsoft Office) cũng như các ứng dụng di động trên nền tảng Android, IOS và các nền tảng khác. Để tấn công, cách đơn giản chỉ cần điều hướng ngược các yêu cầu từ máy client tới máy chủ và như thế có thể sử dụng phương pháp MiTM đối với Hotspot công khai, mạng cục bộ hoặc bộ định tuyến.

5. Tính chất nguy hiểm của lỗi Heartbleed
Phân tích lỗi Heartbleed trong OpenSSL
Lỗi bắt đầu trong ssl/d1_both.c:
int           
dtls1_process_heartbeat(SSL *s)
    {         
    unsigned char *p = &s->s3->rrec.data[0], *pl;
    unsigned short hbtype;
    unsigned int payload;
    unsigned int padding = 16; /* Use minimum padding */

Như vậy có thể thấy đầu tiên sẽ nhận được con trỏ tới dữ liệu trong bản ghi SSLv3 như sau:
typedef struct ssl3_record_st
    {
        int type;               /* type of record */
        unsigned int length;    /* How many bytes available */
        unsigned int off;       /* read/write offset into 'buf' */
        unsigned char *data;    /* pointer to the record data */
        unsigned char *input;   /* where the decode bytes are */
        unsigned char *comp;    /* only used with decompression - malloc()ed */
        unsigned long epoch;    /* epoch number, needed by DTLS1 */
        unsigned char seq_num[8]; /* sequence number, needed by DTLS1 */
    } SSL3_RECORD;

Cấu trúc mô tả bản ghi này có chứa loại, độ dài và dữ liệu. Quay lại với hàm dtls1_process_heartbeat:
/* Read type and payload length first */
hbtype = *p++;
n2s(p, payload);
pl = p;

Chú thích:
#define n2s(c,s)     ((s=(((unsigned int)(c[0]))<< 8)| \
                (((unsigned int)(c[1]))    )),c+=2)

Byte đầu tiên của bản ghi SSLv3 – thể hiện loại Heartbeats. Macro n2s lấy 2 byte từ p và chuyển chúng vào payload. Thực tế đây chính là độ dài (length) của dữ liệu. Để ý có thể thấy rằng độ dài thực tế trong bản ghi SSLv3 không được kiểm tra.Sau đó biến pl nhận dữ liệu heartbeat chuyển cho bên hỏi.
Tiếp theo:
unsigned char *buffer, *bp;
int r;
/* Allocate memory for the response, size is 1 byte
 * message type, plus 2 bytes payload length, plus
 * payload, plus padding
 */
buffer = OPENSSL_malloc(1 + 2 + payload + padding);
bp = buffer;

Lấy số lượng bộ nhớ cần thiết cho bên hỏi: tới 65535+1+2+16. Biến bp – con trỏ sử dụng để truy cập tới bộ nhớ này.
Tiếp theo:
/* Enter response type, length and copy payload */
*bp++ = TLS1_HB_RESPONSE;
s2n(payload, bp);
memcpy(bp, pl, payload);

Macro s2n sẽ thực hiện ngược với macro n2s: lấy giá trị 16 bit và chuyển nó vào 2 byte. Sau đó thiết lập chính độ dài được yêu cầu cho phần payload.
Sau đó chép payload byte từ pl vào trong mảng bp. Sau đó tất cả sẽ gửi ngược cho người dùng.

Như vậy lỗi ở chỗ nào?
Người dùng điều khiển payload và pl
Chuyện gì sẽ xảy ra nếu thực tế phía yêu cầu không gửi lượng payload byte? Nếu pl trong thực tế chỉ chứa 1 byte? Khi đó memcpy sẽ đọc từ bộ nhớ tất cả những gì ở gần với bản ghi SSLv3.
Tồn tại hai phương pháp mà bộ nhớ được phân chia động qua lệnh malloc (ít nhất là trong Linux): lệnh sbrk() và lệnh mmap(). Nếu bộ nhớ được phân chia theo sbrk thì các qui tắc cữ heap-grows-up được sử dụng và do đó sẽ hạn chế những gì có thể tìm được thông qua lệnh tuy nhiên có thể dùng nhiều yêu cầu (request) (đặc biệt là nhiều yêu cầu đồng thời) vẫn có thể tìm được những giá trị cần thiết.
Nếu như sử dụng mmap thì đối với mmap có thể được phân chia bất kì phần bộ nhớ chưa sử dụng nào và đây là mục đích chính của tấn công. Và quan trọng hơn cả càng nhiều yêu cầu thì xác suất rằng các yêu cầu đó được phục vụ bởi mmap càng cao chứ không phải sbrk.
Các hệ thống không sử dụng mmap để thực hiện malloc thì có vẻ như bớt nguy hiểm hơn.
Vị trí của bp nói chung không có ý nghĩa thực tế nhiều còn vị trí của pl ngược lại có ý nghĩa giá trị lớn. Phần bộ nhớ dưới nó hầu như được phân bố thông qua sbrk() vì giới hạn của mmap trong malloc(). Tuy nhiên phần bộ nhớ với thông tin hữu ích (ví dụ như các thông tin người dùng, …) với xác suất cao lại được phân chia bởi mmap() và có thể truy cập từ pl. Một vài yêu cầu đồng thời sẽ cho phép truy cập được các dữ liệu cần thiết.
Từ đó có thể nói rằng mô hình phân chia bộ nhớ cho pl cho phép chúng ta có thể đọc được các dữ liệu. Một trong những người phát hiện ra điều này đã nói: Các mô hình phân chia bộ nhớ trong cache cho phép tấn công khóa bí mật với xác suất thấp.
6. Cách khắc phục
Một trong những điểm chính cần khắc phục như sau:
/* Read type and payload length first */
if (1 + 2 + 16 > s->s3->rrec.length)
    return 0; /* silently discard */
hbtype = *p++;
n2s(p, payload);
if (1 + 2 + payload + 16 > s->s3->rrec.length)
    return 0; /* silently discard per RFC 6520 sec. 4 */
pl = p;

Đoạn mã này sẽ làm hai việc: kiểm tra thứ nhất ngăn chặn các heartbeats độ dài bằng 0. Kiểm tra thứ hai (if) thực hiện cảnh báo và loại bỏ nếu độ dài thực tế của bản ghi lớn.
Chính vì vậy, các chuyên gia đưa ra một vài nhận xét như sau:

• Cần quan tâm tới audit an toàn các thành phần của cơ sở hạ tầng an toàn quan trọng như OpenSSL.
• Viết nhiều unit và các test tích hợp cho các thư viện này.
• Có thể xây dựng các phương án thực thi khác trên các ngôn ngữ khác ngoài C.

Nguyễn Viết Phan (tổng hợp)

HEARTBLEED BUG : PHÂN TÍCH SƠ BỘ

Heartbleed Bug đang là lỗ hổng bảo mật hot nhất kể từ đầu năm tới nay, lỗ hổng cho phép dump từng phần memory của đối tượng bị tấn công khi sử dụng OpenSSL.

Đây là một lỗ hổng rất nghiêm trọng, do rất nhiều các website yêu cầu bảo mật cao hiện nay đều sử dụng thư viên này.

Lỗ hổng tấn công vào thành phần TLS/DTLS Heartbeat Handler:

Hàm: dtls1_process_heartbeat/dtls1_process_heartbeat
Lib: ssl/t1_lib.c

Khi người tấn công gửi một gói tin request nhất định để exploit thì phía server sẽ trả về một gói tin là dump một đoạn trên memory.

Tổng quan dễ hiểu lỗi này bạn có thể xem một mẫu truyện tranh sau đây:

Nguồn: http://xkcd.com

Trong bài viết này sẽ đi sâu vào phân tích kỹ thuật lỗ hổng này.

—

Tôi sẽ phân tích chi tiết vấn đề theo các phần:

• Parse và memcpy, đây là 2 bước xuất hiện lỗi
• Fix : cách thức fix mà OpenSSL đã update
• Code sample: mô phỏng lại phần code gây ra lỗi
• Ảnh hưởng và cách phòng chống

I. Bug: Phân tích bug

1. Parse
Quan sát hàm bị lỗi:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

int dtls1_process_heartbeat(SSL *s)          {          unsigned char *p = &s->s3->rrec.data[0], *pl;          unsigned short hbtype;          unsigned int payload;          unsigned int padding = 16; /* Use minimum padding */            /* Read type and payload length first */          hbtype = *p++;          n2s(p, payload);          pl = p;            ...            if (hbtype == TLS1_HB_REQUEST)                  {                  unsigned char *buffer, *bp;                  int r;                    /* Allocate memory for the response, size is 1 byte                   * message type, plus 2 bytes payload length, plus                   * payload, plus padding                   */                  buffer = OPENSSL_malloc(1 + 2 + payload + padding);                  bp = buffer;                    /* Enter response type, length and copy payload */                  *bp++ = TLS1_HB_RESPONSE;                  s2n(payload, bp);                  memcpy(bp, pl, payload);                  bp += payload;                  /* Random padding */                  RAND_pseudo_bytes(bp, padding);                    r = dtls1_write_bytes(s, TLS1_RT_HEARTBEAT, buffer, 3 + payload + padding);                    if (r >= 0 && s->msg_callback)                          s->msg_callback(1, s->version, TLS1_RT_HEARTBEAT,                                  buffer, 3 + payload + padding,                                  s, s->msg_callback_arg);                    OPENSSL_free(buffer);                    if (r < 0)                          return r;                  }          ...

Ta xem cấu trúc:

1 2 3 4 5 6 7 8 9 10

typedef struct ssl3_record_st {     int type; /* type of record */     unsigned int length; /* How many bytes available */     unsigned int off; /* read/write offset into 'buf' */     unsigned char *data; /* pointer to the record data */     unsigned char *input; /* where the decode bytes are */     unsigned char *comp; /* only used with decompression - malloc()ed */     unsigned long epoch; /* epoch number, needed by DTLS1 */     unsigned char seq_num[8]; /* sequence number, needed by DTLS1 */ } SSL3_RECORD;

Thành phần dữ liệu mà heartbeat sử dụng là thành phần data trong struct ssl3_record_st này

Dữ liệu lưu trữ trong data có cấu trúc như sau:

1 2 3

|-------|-------------|--------------------- 1 byte      2 byte            n byte   code    payload len         begin_data

Đoạn code parse:

1 2 3

hbtype = *p++; n2s(p, payload); pl = p;

Sau khi thực hiện đoạn code này, các giá trị được gán sẽ như sau

1 2 3

|-------|-------------|--------------------- 1 byte      2 byte   ^         n byte   hbtype    payload   pl

Đoạn code này sẽ chưa gây ra vấn đề gì nếu không có bước tiếp theo.

2. Memcpy

Sau khi parse, chúng ta xem xét đoạn code bên dưới

1 2 3 4 5 6 7

buffer = OPENSSL_malloc(1 + 2 + payload + padding); bp = buffer;   /* Enter response type, length and copy payload */ *bp++ = TLS1_HB_RESPONSE; s2n(payload, bp); memcpy(bp, pl, payload);

Đoạn code này thực hiện quá trình đưa cấu trúc heartbeat vào buffer

Và vấn đề đã xảy ra tại hàm memcpy, ở đây do không kiểm tra độ dài payload nên buffer sẽ được malloc tùy ý size theo payload truyền lên (nhỏ hơn 0xFFFF), và payload được copy vào sẽ có độ dài tương ứng, với vị trí bắt đầu từ vị trí của pl (cần nói thêm là do pl là con trỏ đến vị trí thuộc data nên chỉ có thể dump vị trí bộ nhớ hiện nay mà ssl3_record_st đang ở chứ không theo ‘yêu cầu người dùng’ được :3, và tất nhiên nó chỉ lòng vòng trong bộ nhớ process đó).

Vậy cấu trúc buffer sau khi copy sẽ như sau:

1 2 3

|-------|-------------|---------------------+ 1 byte      2 byte   ^      payload byte   hbtype    payload   pl    ----------------+ leak data here

Và như vậy, chúng ta sẽ có buffer trả về là dump một đoạn memory kể từ vị trí pl này.

Server sẽ response buff này với dòng lệnh

1 2 3 4

if (r >= 0 && s->msg_callback)     s->msg_callback(1, s->version, TLS1_RT_HEARTBEAT,                     buffer, 3 + payload + padding,                     s, s->msg_callback_arg);

II. Fix:

Mọi chuyện sẽ thật tốt lành nếu chúng ta limit lại, không cho độ dài copy nó một cục to như vậy nữa.

Vậy nên đoạn code fix là đoạn kiểm lại độ dài payload để nó không vượt length.

1 2 3 4 5

if (1 + 2 + 16 > s->s3->rrec.length) return 0; /* silently discard */ ... if (1 + 2 + payload + 16 > s->s3->rrec.length) return 0; /* silently discard per RFC 6520 sec. 4 */

Và kỹ lưỡng hơn, thêm một lớp lọc nữa được viết ra

1 2	if (write_length > SSL3_RT_MAX_PLAIN_LENGTH) return 0;

Điều này đảm bảo lần tiếp theo rủi có bị lỗi ngay chỗ này thì phần data leak ra sẽ ít hơn tý :3

1	#define SSL3_RT_MAX_PLAIN_LENGTH             16384

III. Code sample

Ta dựng lại một đoạn code C cơ bản mô phỏng lại lỗi như sau:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69

#include <stdio.h> #include <stdlib.h>   typedef struct ssl3_record_st {     int type; /* type of record */     unsigned int length; /* How many bytes available */     unsigned int off; /* read/write offset into 'buf' */     unsigned char *data; /* pointer to the record data */     unsigned char *input; /* where the decode bytes are */     unsigned char *comp; /* only used with decompression - malloc()ed */     unsigned long epoch; /* epoch number, needed by DTLS1 */     unsigned char seq_num[8]; /* sequence number, needed by DTLS1 */ } SSL3_RECORD;   #define TLS1_HB_RESPONSE 0x12   #define IDEA_INT unsigned int #define s2n(l,c) (*((c)++)=(unsigned char)(((l)     )&0xff), \ *((c)++)=(unsigned char)(((l)>> 8L)&0xff)) #define n2s(c,l) (l =((IDEA_INT)(*((c)++)))<< 8L, \ l|=((IDEA_INT)(*((c)++)))      )   #define BUFFER_SIZE 0x1000   int main(int argc, char** argv) {     struct ssl3_record_st ssl;// = malloc(sizeof (ssl3_record_st));       // stuff     unsigned char *p, *pl;     unsigned short hbtype;     unsigned int payload;     unsigned int padding = 16; /* Use minimum padding */     unsigned int write_length = 0;     unsigned char *buffer, *bp;       //--- init     ssl.data = malloc(BUFFER_SIZE);     memset(ssl.data, 0x01, 1);          // heartbeat byte     memset(ssl.data + 1, 0xFFFF, 2);    // payload len -> exploit at this     strcpy(ssl.data + 3, "bing");       // data       // use     p = &ssl.data[0];     hbtype = *p++;     n2s(p, payload);     pl = p;       write_length = 1 /* heartbeat type */ +             2 /* heartbeat length */ +             payload + padding;       buffer = malloc(write_length);     bp = buffer;       /* Enter response type, length and copy payload */     *bp++ = TLS1_HB_RESPONSE;     s2n(payload, bp);     memcpy(bp, pl, payload);     bp += payload;       // repsponse data     printf("buff: 0x%x -> len: 0x%x\n", buffer, write_length);     printf("data: %s n", buffer);       free(buffer);       //free(ssl);     return (EXIT_SUCCESS); }

Kết quả chạy:

1 2	buff: 0x603020 -> len: 0x10012 data: ��bing n....

Với phần bing là phần dữ liệu bắt đầu bị leak

Hình ảnh thực chiến khi tấn công:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

00d0: 10 00 11 00 23 00 00 00 0F 00 01 01 41 70 70 6C  ....#.......Appl   00e0: 65 57 65 62 4B 69 74 2F 35 33 37 2E 33 36 20 28  eWebKit/537.36 (   00f0: 4B 48 54 4D 4C 2C 20 6C 69 6B 65 20 47 65 63 6B  KHTML, like Geck   0100: 6F 29 20 43 68 72 6F 6D 65 2F 33 33 2E 30 2E 31  o) Chrome/33.0.1   0110: 37 35 30 2E 31 35 32 20 53 61 66 61 72 69 2F 35  750.152 Safari/5   0120: 33 37 2E 33 36 0D 0A 58 2D 43 53 52 46 54 6F 6B  37.36..X-CSRFTok   0130: 65 6E 3A 20 34 6F 45 58 6A 6F 38 58 38 46 50 79  en: 4oEXjo8X8FPy   0140: 44 38 4E 45 4B 73 61 34 79 43 67 64 64 43 6B 6C  D8NEKsa4yCgddCkl   0150: 68 74 62 31 0D 0A 43 6F 6E 74 65 6E 74 2D 54 79  htb1..Content-Ty   0160: 70 65 3A 20 61 70 70 6C 69 63 61 74 69 6F 6E 2F  pe: application/   0170: 78 2D 77 77 77 2D 66 6F 72 6D 2D 75 72 6C 65 6E  x-www-form-urlen   0180: 63 6F 64 65 64 3B 20 63 68 61 72 73 65 74 3D 55  coded; charset=U   0190: 54 46 2D 38 0D 0A 52 65 66 65 72 65 72 3A 20 68  TF-8..Referer: h   01a0: 74 74 70 73 3A 2F 2F 70 6C 6F 74 2E 6C 79 2F 70  ttps://plot.ly/p   01b0: 6C 6F 74 0D 0A 41 63 63 65 70 74 2D 45 6E 63 6F  lot..Accept-Enco   01c0: 64 69 6E 67 3A 20 67 7A 69 70 2C 64 65 66 6C 61  ding: gzip,defla   01d0: 74 65 2C 73 64 63 68 0D 0A 41 63 63 65 70 74 2D  te,sdch..Accept-   01e0: 4C 61 6E 67 75 61 67 65 3A 20 65 6E 2D 55 53 2C  Language: en-US,   01f0: 65 6E 3B 71 3D 30 2E 38 0D 0A 43 6F 6F 6B 69 65  en;q=0.8..Cookie   0200: 3A 20 67 72 61 70 68 74 69 70 73 3D 74 72 75 65  : graphtips=true   0210: 3B 20 63 73 72 66 74 6F 6B 65 6E 3D 34 6F 45 58  ; csrftoken=4oEX   0220: 6A 6F 38 58 38 46 50 79 44 38 4E 45 4B 73 61 34  jo8X8FPyD8NEKsa4   0230: 79 43 67 64 64 43 6B 6C 68 74 62 31 3B 20 5F 5F  yCgddCklhtb1; __   0240: 75 74 6D 61 3D 32 30 34 36 32 31 31 33 37 2E 31  utma=204621137.1   0250: 34 30 33 33 33 36 30 35 35 2E 31 33 39 32 39 32  403336055.139292   0260: 32 39 39 37 2E 31 33 39 35 38 37 38 35 34 35 2E  2997.1395878545.   0270: 31 33 39 37 30 32 32 30 30 34 2E 31 30 3B 20 5F  1397022004.10; _   0280: 5F 75 74 6D 63 3D 32 30 34 36 32 31 31 33 37 3B  _utmc=204621137;   0290: 20 5F 5F 75 74 6D 7A 3D 32 30 34 36 32 31 31 33   __utmz=20462113   02a0: 37 2E 31 33 39 32 39 32 32 39 39 37 2E 31 2E 31  7.1392922997.1.1   02b0: 2E 75 74 6D 63 73 72 3D 28 64 69 72 65 63 74 29  .utmcsr=(direct)   02c0: 7C 75 74 6D 63 63 6E 3D 28 64 69 72 65 63 74 29  |utmccn=(direct)   02d0: 7C 75 74 6D 63 6D 64 3D 28 6E 6F 6E 65 29 3B 20  |utmcmd=(none);   02e0: 73 65 73 73 69 6F 6E 69 64 3D 32 30 65 32 32 36  sessionid=20e226   02f0: 62 63 65 33 36 34 35 66 65 37 36 38 63 32 38 66  bce3645fe768c28f   0300: 32 30 61 34 38 34 38 34 65 31 3B 20 6D 70 5F 61  20a48484e1; mp_a

IV. Ảnh hưởng và cách phòng chống

- Vùng leak memory nằm ngẫu nhiên theo vị trí lưu trữ ssl3_record_st, nên các thông tin có thể bị leak khá rộng, gồm trọn vẹn các thông tin request, response, mà những thứ này thường có cookie, user, password, nhưng nếu toàn là thế thì khác gì mơ, nhưng đời không là mơ bạn à, thầy mình đồn vậy :’( … Các thứ chủ yếu mà bạn nhận được sẽ là mớ data ngẫu nhiên từ bộ nhớ :’(, các thứ này không khác mấy với mớ rác thải công nghiệp 

- Như vậy việc bạn nhận được gì khi tấn công cũng giống như kết quả chơi xổ số vậy :”>, xác suất sẽ cao nếu bạn mua nhiều vé số.

- Để bảo vệ website bạn, bạn có thể dùng trang web scan ở đây:  http://filippo.io/Heartbleed/ , nếu có bị cảnh báo thì hãy nhanh chống update OpenSSL ngay và luôn :3

Tham khảo:

Bài viết tham khảo tại đây: http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html

Với tham khảo diff code update tại đây
Code sau khi update
Exploit code

Trang web scan lỗ hổng: http://filippo.io/Heartbleed/

Source http://blog.botbie.com

Cơ chế hoạt động và cách phòng tránh lỗ hổng Heartbleed

Symantec mới đây đã đăng tải một bài viết trên blog về ảnh hưởng của mối đe dọa bảo mật Heartbleed đối với các thiết bị của người dùng và đối với kỷ nguyên “mọi thứ đều kết nối Internet”.

Symantec mới đây đã đăng tải một bài viết trên blog về ảnh hưởng của mối đe dọa bảo mật Heartbleed đối với các thiết bị của người dùng và đối với kỷ nguyên “mọi thứ đều kết nối Internet” (IoT - The Internet of Things). Mặc dù đã có rất nhiều bài viết đề cập tới mối đe dọa bảo mật Heartbleed, bài viết trên blog của Symantec đưa ra một góc độ phân tích mới về mức độ ảnh hưởng của Heartbleed đối với người dùng cá nhân và doanh nghiệp trong tương lai gần.

Khi hầu hết những thông tin liên quan tới Heartbleed đã được công bố rộng rãi trên nhiều trang web, mối đe dọa bảo mật này thực sự gây ra hậu quả nhiều hơn thế. Mặc dù hầu hết các trang web phổ biến đã khắc phục được lỗi, điều này không có nghĩa là người dùng có thể lơ là cảnh giác.

Heartbleed làm ảnh hưởng tới các phần mềm ở máy khách (client software) như trình duyệt web, chương trình quản lý email, chat, chia sẻ dữ liệu FTP, các ứng dụng di động, kết nối VPN, các chương trình cập nhật phần mềm - đây chỉ là một số nhỏ những ứng dụng bị ảnh hưởng. Nói tóm lại, bất kỳ chương trình nào tương tác thông qua các giao thức bảo mật SSL/TLS sử dụng phiên bản OpenSSL chứa lỗ hổng bảo mật đều có thể bị tấn công.

Hơn nữa, Heartbleed ảnh hưởng tới rất nhiều máy chủ khác ngoài những máy chủ web, trong đó có máy chủ proxies, máy chủ media, máy chủ game, máy chủ cơ sở dữ liệu, máy chủ chat và máy chủ FTP.

Các thiết bị phần cứng cũng không miễn nhiễm với mối đe dọa bảo mật này. Nó có thể ảnh hưởng tới các bộ định tuyến routers, các hệ thống điện thoại doanh nghiệp (FBXes) và nhiều nhiều thiết bị khác nữa trong kỷ nguyên “mọi thứ đều kết nối Internet”.

Việc tấn công những máy chủ phần mềm và phần cứng này thông qua lỗ hổng bảo mật Heartbleed được thực hiện theo cách tương tự như tấn công vào một trang web có chứa lỗ hổng bảo mật. Tuy nhiên, những tấn công vào các phần mềm máy khách, về cơ bản có thể được thực hiện theo phương thức ngược lại.

Thông thường, việc khai thác lỗ hổng Heartbleed được mô tả là tấn công bằng cách gửi một thông điệp có chứa Heartbleed độc hại tới máy chủ có lỗ hổng. Sau đó máy chủ sẽ để lộ những dữ liệu cá nhân. Tuy nhiên, phương thức ngược lại cũng khả thi.

Một chương trình trên máy khách chứa lỗ hổng có thể kết nối tới một máy chủ, và máy chủ này có thể gửi thông điệp kèm Heartbleed độc hại tới trình khách. Sau đó, chương trình trên máy khách sẽ phản hồi lại với những dữ liệu phụ được tìm thấy trong bộ nhớ của nó, điều này tiềm ẩn nguy cơ lộ thông tin cá nhân và các dữ liệu cá nhân khác.  

Minh họa một trình khách có chứa lỗ hổng bị tấn công theo phương thức ngược lại với tấn công vào một máy chủ.

May mắn thay, dù các trình khách có chứa lỗ hổng thì việc khai thác lỗ hổng cũng khó thực hiện ngoài đời thực. Hai thủ thuật tấn công chủ đạo là hướng dẫn khách hàng truy nhập vào một máy chủ SSL/TLS độc hại và/hoặc lấy cắp một kết nối qua một điểm yếu không liên quan. Cả hai phương pháp đều thực sự khá phức tạp đối với những kẻ tấn công.

Hướng khách hàng tới một máy chủ độc hại

Ví dụ đơn giản nhất về việc làm thế nào một khách hàng có thể bị khai thác đó là thông qua một trình duyệt web có chứa lỗ hổng. Kẻ tấn công chỉ cần thuyết phục nạn nhân truy nhập vào một liên kết URL độc hại để cho phép máy chủ tấn công đạt quyền truy nhập vào bộ nhớ của trình duyệt web. Điều này khiến các nội dung đứng trước nguy cơ bị rò rỉ, như cookie của các phiên trước, các trang web đã xem, dữ liệu và những thông tin cá nhân người dùng đều có thể bị lộ.

Hầu hết các trang web phổ biến không sử dụng OpenSSL, và các thư viện dịch vụ bảo mật mạng (NSS  libraries) là không có lỗ hổng bảo mật để Heartbleed có thể khai thác được. Tuy nhiên, nhiều dòng lệnh trên trình khách web có sử dụng OpenSSL (giả dụ dòng lệnh wget và curl) - đây chính là các lỗ hổng có thể bị tận dụng.

Kẻ tấn công cần phải lừa phỉnh người dùng truy nhập vào một trang web độc hại, rằng vào trang web đó có thể giúp họ loại bỏ một số rủi ro. Tuy nhiên, điều này không phải lúc nào cũng cần thiết. Thử tưởng tượng một dịch vụ dịch thuật trực tuyến mà ở đó người ta cung cấp dịch vụ tự động với đường liên kết URL tới một trang web tiếng Pháp và dịch vụ này sẽ tự động chuyển nội dung sang tiếng Anh.

Đằng sau đó, dịch vụ này sẽ lấy toàn bộ nội dung của trang web tiếng Pháp sử dụng trình khách phụ trợ riêng của nó. Nếu bạn cung cấp đường dẫn URL tới một máy chủ độc hại, trình khách phụ trợ này có thể bị khai thác và kẻ tấn công có thể lấy được những thông tin nhạy cảm, như mã nguồn và những thông tin truy nhập từ trang web dịch thuật này.      

Lấy cắp một kết nối

Như mô tả ở trên, việc chuyển hướng trình khách tới một máy chủ độc hại đòi hỏi trình khách đó phải được hướng dẫn truy nhập vào các máy chủ chỉ định. Tuy nhiên, nhiều trình khách sẽ chỉ kết nối với một tên miền được cài đặt sẵn hoặc được thiết lập sẵn. Trong những trường hợp  này, trình khách sẽ vẫn có thể bị khai thác.

Trong các mạng chia sẻ mở như các mạng Wi-Fi công cộng, lưu lượng mạng có thể được xem và điều chỉnh bởi những người lạ, điều này cho phép các kẻ tấn công chuyển hướng các trình khách chứa lỗ hổng.

Thông thường, các công nghệ bảo mật SSL/TLS (giả dụ HTTPS, duyệt web mã hóa) là một trong những giải pháp cho vấn đề này, bởi vì việc mã hóa ngăn chặn bị xem lén và chuyển hướng. Tuy nhiên, một kẻ tấn công có thể gửi nhiều thông điệp Heartbleed độc hại trước khi các phiên SSL/TLS được thiết lập hoàn chỉnh.

Một kẻ tấn công có thể tham gia vào một mạng công cộng và xem lén thông tin của các nạn nhân tiềm năng. Khi một nạn nhân tiềm năng sử dụng một trình khách có chứa lỗ hổng để thiết lập một kết nối SSL/TLS tới một máy chủ chính thống, kẻ tấn công sẽ chuyển hướng kết nối tới một máy chủ độc hại.

Trước khi kết nối SSL/TLS được thiết lập hoàn chỉnh và có khả năng ngăn chặn mọi sự chuyển hướng, kẻ tấn công đã có thể gửi nhiều thông điệp Heartbleed độc hại để trích xuất những nội dung nằm trong bộ nhớ máy tính của nạn nhân.

Lời khuyên cho các doanh nghiệp

- Đây là một lỗ hổng bảo mật thuộc thư viện OpenSSL và không phải là lỗi nằm trong SSL/TLS hay những chứng nhận được Symantec đưa ra. Bất kỳ ai đang sử dụng OpenSSL 1.0.1 tới 1.0.1f nên cập nhật bản vá mới nhất của phần mềm (1.0.1g) hoặc thiết lập lại OpenSSL để loại bỏ Heartbleed.

- Sau khi nâng cấp lên phiên bản OpenSSL vá lỗi, nếu bạn nghi ngờ rằng chứng nhận trên máy chủ web của bạn có thể đã bị lộ, lấy cắp hoặc bị khai thác, hãy liên hệ với đơn vị cấp chứng nhận để thay thế.

- Cuối cùng, các doanh nghiệp cũng nên cân nhắc thiết lập lại mật khẩu của người dùng cuối - có thể đã bị lộ trên bộ nhớ máy chủ.

Lời khuyên cho người dùng cuối

- Người dùng cuối nên cảnh giác rằng dữ liệu của mình có thể đã bị lộ cho một bên thứ ba vì sử dụng nhà cung cấp dịch vụ có chứa lỗ hổng bảo mật.

- Theo dõi để biết bất kỳ thông báo nào từ nhà cung cấp dịch vụ bạn sử dụng. Khi nhà cung cấp dịch vụ liên hệ và thông báo với người dùng rằng nên thay mật khẩu, người dùng nên làm như vậy.

- Tránh những email lừa đảo từ những kẻ tấn công yêu cầu bạn cập nhật mật khẩu, tránh truy nhập vào những website lạ, chỉ nên truy nhập vào những tên miền chính thống.

- Sử dụng các dịch vụ và website uy tín bởi họ sẽ là những người đầu tiên vá lỗ hổng bảo mật này.

- Theo dõi tài khoản ngân hàng và thẻ tín dụng để phát hiện những khoản chi tiêu bất thường nào.

Lời khuyên khác

- Tránh truy nhập vào những tên miền lạ với bất kỳ phần mềm trình khách nào.

- Ngừng sử dụng các dịch vụ proxy chưa được vá lỗi.

- Cập nhật phần cứng và phần mềm ngay khi nhà sản xuất công bố bản vá.

- Sử dụng một trình khách VPN và những dịch vụ được đảm bảo không bị ảnh hưởng bởi Heartbleed khi truy nhập trên các mạng công cộng.

Ngoài ra, đoạn video sau đây cung cấp những thông tin tổng quan nhất về mối đe dọa Heartbleed, cùng với những mẹo cho người dùng cuối.

24h.com.vn

NHẤN ĐỂ XEM NGAY

3

Video: Nên làm gì khi đứng trước lỗ hổng bảo mật Heartbleed?

Bảo vệ mình trước lỗi bảo mật Heartbleed

Một lỗ hổng bảo mật mới được phát hiện hồi đầu tuần có tên Heartbleed đang gieo rắc nỗi kinh hoàng cho thế giới internet. Heartbleed là một lỗi trong chuẩn bảo mật OpenSSL được rất nhiều website sử dụng, và lổ hổng trong OpenSSL mới được phát hiện này có thể giúp hacker truy cập vào bộ nhớ của các máy chủ web, nơi lưu trữ các dữ liệu của người dùng, trong đó có các dữ liệu nhạy cảm như tên tài khoản, mật khẩu, số thẻ tín dụng. Đây là một lỗi bảo mật nghiêm trọng, thậm chí được đánh giá là lỗ hổng bảo mật lớn nhất trên web.

Theo các nhà nghiên cứu tại Netcraft, Heartbleed ảnh hưởng tới 500.000 máy chủ toàn thế giới. Bởi vậy, trước khi giới bảo mật tìm được cách khắc phục được triệt để, người dùng cần tự bảo vệ mình.

Không đăng nhập vào các website bị ảnh hưởng

Đây là việc mà bạn cần tránh đầu tiên. Bạn không nên đăng nhập vào các trang web bị ảnh hưởng cho đến khi chắc chắn rằng trang web đó đã khắc phục được lỗi Heartbleed (thông qua các thông báo của website đó tới bạn). Nếu cần, bạn nên liên lạc với đội ngũ dịch vụ khách hàng của họ để cập nhật thông tin.

Hiện nay, một số website có vẻ như đã bị ảnh hưởng bởi Heartbleed bao gồm Yahoo! và trang web về dịch vụ hẹn hò OKCupid, mặc dù các công ty này cho biết họ đã khắc phục được "toàn bộ", hoặc "1 phần". Bạn cũng có thể kiểm tra tính an toàn của trang web tại đây, xem danh sách các trang bị nghi là dính lỗi Heartbleed tại đây. Tuy nhiên, ngay cả khi công cụ này báo website đã "an toàn", bạn cũng nên thận trọng; còn trong trường hợp công cụ trên báo dấu đỏ, bạn nên tránh xe site đó.

Tại Việt Nam, phần lớn các site thanh toán trực tuyến đều bị lỗi Heartbleed, do các site này đều sử dụng công nghệ bảo mật OpenSSL. Duy chỉ có cổng thanh toán Soha không bị ảnh hưởng nhờ sử dụng chuẩn bảo mật PCI DSS - chuẩn bảo mật cao nhất được Master Card bảo chứng. Theo tìm hiểu, một số cổng thanh toán dính lỗi Heartbleed cũng đã kịp thời khắc phục để đảm bảo an toàn.

Với các lỗi bảo mật, thì người dùng thường nghĩ tới việc đổi mật khẩu, tuy nhiên trong trường hợp này, các chuyên gia bảo mật khuyên bạn nên chờ webite bị ảnh hưởng sửa xong lỗi Heartbleed trước, bởi việc đổi mật khẩu lúc ngay không mang lại hiệu quả thậm chí còn làm trầm trọng thêm vấn đề.

Đổi mật khẩu

Như vừa nói ở trên, khi các website bị lỗi xác nhận rằng họ đã khắc phục được lỗ hổng bảo mật, bạn nên ngay lập tức đổi mật khẩu cũng như các thông tin cá nhân nhạy cảm khác của mình. Ngay cả khi các dịch vụ bạn sử dụng có áp dụng bảo mật 2 lớp (xác nhận giao dịch thông qua tin nhắn điện thoại), thì việc đổi mật khẩu lúc này cũng là việc nên làm.

Theo dõi các giao dịch trong thời gian gần đây

Khi mà lỗ hổng Heartbleed cho phép hacker truy cập được vào bộ nhớ của các máy chủ, thì nguy cơ các thông tin nhạy cảm của bạn, như số thẻ tín dụng... đã nằm trong tay chúng. Bởi vậy, bạn cần theo dõi các giao dịch tài chính của mình trong thời gian gần đây để xem có điều gì bất thường xảy ra hay không.

Phòng tránh các nguy cơ khác

Ngay cả khi bạn đã làm theo các lời khuyên trên, thì điều đó cũng không đồng nghĩa với việc bạn đã được đảm bảo an toàn. Bởi theo các chuyên gia bảo mật, Heartbleed thậm chí còn ảnh hưởng tới cả cookies - 1 công cụ theo dõi các hoạt động của người dùng khi họ lướt web. Điều này đồng nghĩa với việc khi bạn truy cập vào 1 webite bị ảnh hưởng bởi Heartbleed, thì ngay cả khi bạn không đăng nhập vào website đó, bạn cũng có nguy cơ bị ăn cắp thông tin. Theo Tor Project - một hệ thống mạng phục vụ việc truy cập ẩn danh và bảo mật cao - thì người dùng nếu có thể hãy tránh xa khỏi Internet hoàn toàn trong ít ngày tới cho đến khi mọi lỗ hổng được khắc phục triệt để.

Trong số các dịch vụ web hiện nay, thì Yahoo! dường như là cái tên có nguy cơ dính lỗi cao nhất (các kiểm tra sơ bộ cho thấy phiên bản web của Facebook, Google, và Twitter, dường như đều an toàn). Yahoo! cho biết họ đã "thực hiện các biện pháp khắc phục hợp lý" cho các dịch vụ chính của mình gồm trang chủ Yahoo!, Search, Mail, Finance, Sports, Food, Tech, Flickr và Tumblr. Tuy nhiên vẫn còn nhiều site khác của Yahoo! chưa được sửa lỗi và hãng cho biết đang tích cực fix lỗi cho các site đó.

Jaime Blasco, Giám đốc của phòng nghiên cứu bảo mật AlienVault Labs, khuyến khích người dùng không đăng nhập vào Yahoo! và các dịch vụ bị ảnh hưởng khác, bởi các thông tin cá nhân nhạy cảm của họ có thể bị đánh cắp. Nhà nghiên cứu này cũng khuyên người dùng ngay lập tức thay mật khẩu ngay sau khi Yahoo! khắc phục xong lỗ hổng nói trên.

Không chỉ Yahoo! mà các công ty khác như Imgur và OKCupid cũng bị Heartbleed tấn công. Imgur, trang web chia sẻ ảnh rất phổ biến hiện nay cũng là 1 trong số đó. Tuy nhiên có vẻ như các công ty này đã nhanh chóng đưa ra các biện pháp khắc phục. Imgur cho biết họ đã "reset" các dữ liệu nhạy cảm như cookies và các session ID để đảm bảo an toàn; còn OKCupid cũng có phát biểu tương tự.

Giải pháp cho tương lai

Những trường hợp như Heartbleed hiện đang diễn ra ngày một nhiều và gây ra không ít băn khoăn về khả năng bảo mật của các công ty web hiện nay. Hiện tại một số hãng công nghệ lớn đang bắt đầu chuyển sang áp dụng công nghệ bảo mật Perfect Forward Secrecy (PFS) tuy nhiên việc áp dụng nó vẫn chưa triệt để. PFS là một công nghệ mã hóa mới trong đó key mã hóa không tồn tại mãi mãi như hiện nay, khiến cho hacker dù có key mã hóa cũng không thể ăn cắp được dữ liệu.

"Người dùng luôn muốn dữ liệu của mình được an toàn nhất có thể, và PFS là công cụ mà các công ty web cần áp dụng để phục vụ yêu cầu này", John Miller, Giám đốc hãng bảo mật TrustWave cho biết.