Liên tiếp phát hiện Những lỗ hổng trong TLS/SSL

Cặp giao thức TLS/SSL (giao thức TLS được phát triển từ giao thức SSLv3 và được dùng chung với giao thức SSL để đảm bảo tính tương thích ngược) khá phức tạp và khó sử dụng, nên có rất nhiều điểm yếu có thể bị tin tặc khai thác. Gần đây nhất, vào đầu tháng 3/2016, lỗ hổng DROWN (Decrypting RSA with Obsolete and Weakened eNcryption) mới được phát hiện và công bố. Hơn 11 triệu website và dịch vụ thư điện tử bị ảnh hưởng bởi lỗ hổng này, theo đó các thông tin nhạy cảm trao đổi qua giao thức TLS có thể bị giải mã chỉ trong vài giờ, thậm chí là ngay lập tức, với chi phí rất nhỏ. Hơn 81 nghìn trong số 1 triệu website phổ biến nhất có lỗ hổng này. Lỗ hổng cho phép kẻ tấn công giải mã các kết nối TLS bị theo dõi bằng cách liên tục tạo kết nối SSLv2 tới máy chủ. Trong quá trình đó, kẻ tấn công xác định được vài bit của khoá mã hoá mỗi kết nối.

Kết quả dò quét gần đây cho thấy, hơn 5,9 triệu máy chủ web (chiếm 17% số máy chủ được bảo vệ bởi giao thức HTTPS) trực tiếp hỗ trợ SSLv2 và ít nhất 936 nghìn máy chủ thư điện tử được bảo vệ bằng giao thức TLS cũng hỗ trợ giao thức không an toàn đó. Phát hiện này rất đáng lo ngại vì những khuyến cáo về việc loại bỏ SSLv2 đã được đề xuất nhiều trong thời gian qua. Một máy chủ không chấp nhận các kết nối SSLv2 vẫn có thể bị tấn công nếu cặp khoá RSA dùng cho nó được dùng lại trên một máy chủ khác có hỗ trợ SSLv2. Chẳng hạn như máy chủ web cấm dùng SSLv2 có thể bị lộ khoá nếu khoá đó được dùng trên một máy chủ thư điện tử chấp nhận SSLv2.

Phương thức triển khai TLS được sử dụng phổ biến nhất có thể bị tấn công DROWN là OpenSSL. Tuy các phiên bản hiện tại của nó không cho phép sử dụng các kết nối SSLv2, nhưng những người quản trị hệ thống có thể vô tình thay đổi các thiết lập đó khi cố gắng tối ưu hoá các ứng dụng như Apache, Nginx hay Sendmail và Postfix.

Do DROWN là kiểu tấn công lợi dụng lỗ hổng ở phía máy chủ, nên người dùng cuối không thể làm gì để ngăn chặn thảm họa. Kiểu tấn công DROWN phổ biến nhất là lợi dụng những thuật toán mã hoá đối xứng 40 bit yếu được đưa vào phần mềm để đảm bảo tuân thủ quy định hạn chế xuất khẩu của chính phủ Mỹ. Kẻ tấn công chỉ cần giữ khoảng 1000 lượt trao đổi khoá RSA giữa người dùng cuối với một máy chủ TLS chưa được vá và các kết nối có thể dùng bất kỳ phiên bản nào của giao thức SSL hay TLS, kể cả phiên bản TLS 1.2 hiện thời. Sau đó, chúng dùng các bản mã RSA thu giữ được để khởi tạo hàng ngàn kết nối SSLv2 trong đó chứa lệnh buộc máy chủ dùng thuật toán mã hoá 40 bit. Tiếp đó, chúng so sánh bản mã với toàn bộ 240 khả năng.Việc giải mã kết nối TLS theo cách này chỉ mất tối đa 8 giờ. Ngoài ra, còn có một phương pháp giải mã khác với một cụm các card đồ hoạ và thực hiện trong khoảng 18 tiếng.

Một dạng nguy hiểm hơn của lỗ hổng DROWN có trong các máy chủ chạy những phiên bản OpenSSL chưa được vá từ tháng 3/2015, cho phép những kẻ tấn công giải mã được “premaster secret” (giá trị bí mật được client mã hóa bằng khóa công khai của máy chủ rồi gửi đi trong quá trình bắt tay theo chuẩn SSL) trong khoảng 1 phút chỉ với 1 CPU đơn (single core). Kẻ tấn công có thể dùng kỹ thuật thực hiện kiểu tấn công “người đứng giữa” để giả mạo một máy chủ có lỗ hổng. Các nhà nghiên cứu lỗ hổng đã dò quét và đưa ra một tỷ lệ đáng kể các máy chủ có lỗ hổng DROWN có thể bị ảnh hưởng bởi dạng tấn công nguy hiểm hơn này, điều đó cho thấy một số lớn người dùng vẫn chưa áp dụng bản vá tháng 3/2015.

DROWN là bản mở rộng của kiểu tấn công Bleichenbacher (đặt theo tên của Daniel Bleichenbacher, nhà mật mã học người Thuỵ Sỹ, đã phát hiện ra điểm yếu của hàm mã hoá PKCS#1 v1 vào năm 1998). Mặc dù tấn công Bleichenbacher được coi là yếu về phương diện toán học, điểm yếu này không thực sự có tính thực tiễn vì kẻ tấn công phải tạo hàng trăm ngàn hay thậm chí hàng triệu kết nối tới máy chủ để dò được một khoá phiên. Một số biện pháp phòng chống tấn công Bleichenbacher lại tạo ra lỗ hổng mới trong TLS 1.0 và các phiên bản tiếp theo. Còn bản mở rộng DROWN đáng lưu ý không chỉ vì nó cần ít truy vấn tới máy chủ hơn mà còn do tính “xuyên giao thức” của nó, cho phép kẻ tấn công lợi dụng những điểm yếu của SSLv2 để “đánh bại” những phiên bản TLS khác. Hơn thế, nghiên cứu về DROWN còn là công trình đầu tiên xác định sự không hiệu quả của các biện pháp phòng chống điểm yếu Bleichenbacher sau gần hai thập kỷ, từ khi chúng được bổ sung vào SSLv2.

Để ngăn ngừa, các máy chủ dựa vào thư viện OpenSSL cần nâng cấp lên phiên bản 1.0.2g hay 1.0.1s càng sớm càng tốt. IIS phiên bản 7.0 hay lớn hơn và các phiên bản từ 3.13 trở đi của thư viện NSS đều đã vô hiệu SSLv2 theo mặc định, vì vậy cần nâng cấp ngay. Các nhà nghiên cứu khuyến cáo rằng, ngay cả những người đang sử dụng các phiên bản được cho là an toàn cũng nên kiểm tra xem các dịch vụ dựa trên TLS của họ có thể bị tấn công hay không thông qua trang web https://test.drownattack.com/. Với những máy chủ không thể cập nhật ngay, có thể tạm thời ứng phó bằng cách dùng tường lửa để lọc các kết nối SSLv2, dù điều này có thể ngăn các dịch vụ kiểm tra phát hiện ra máy chủ có lỗ hổng. Những người quản trị muốn biết hệ thống của tổ chức mình đã bị tấn công DROWN hay không, có thể phát hiện bằng cách kiểm tra log và tìm số lớn các kết nối SSLv2.

DROWN chỉ là kiểu tấn công mới nhất đối với những điểm yếu của giao thức bảo mật phổ biến nhất trên Internet. Trước đó đã có khá nhiều kiểu tấn công khác nhau như: BEAST năm 2011, CRIME năm 2012, TIME, Lucky 13, BREACH năm 2013, POODLE năm 2014 và năm 2015 là FREAK, Logjam. Theo Australian Communications and Media Authority, kết quả dò quét mới đây của một bên thứ ba cho thấy có tới 180 ngàn máy chủ tại Australia bị POODLE tấn công. Các nước khác trên thế giới có lẽ cũng ở vào tình trạng tương tự.

Các tấn công vào giao thức TLS/SSL

Tuy có rất nhiều lỗ hổng bảo mật trong cặp giao thức TLS/SSL, nhưng kẻ xấu có thể đọc thông tin trao đổi của người dùng mà không cần hiểu sâu về mã hóa và giải mã. Chẳng hạn như tấn công một CA (Certificate Authority) bất kỳ hay ứng dụng web cung cấp thông tin đầu vào cho chúng. Theo dự án SSL Observatory, có hơn 600 CA được các trình duyệt tin tưởng, tin tặc chỉ cần tìm được một cá thể yếu (dễ tấn công) trong hơn 600 CA đó.

Một cách khác là sửa đổi một máy chủ DNS đệm được dùng bởi một CA hay làm giả DNS của tên miền cần tấn công. Để phòng ngừa vấn đề này, người ta đưa ra DNSSEC (hiện nay Việt Nam mới bắt đầu triển khai hệ thống DNSSEC thay cho DNS thông thường).

Ở mức cao hơn, chính quyền sở tại có thể yêu cầu các CA thuộc quyền tạo ra chứng thư số giả cho bất kỳ tên miền nào. Đã có những chứng cứ xác thực về khả năng này. Vì các CA hiện nằm tại hơn 52 quốc gia khác nhau, nên có rất nhiều chính phủ có thể làm được điều này.

Nhưng mọi chuyện không chỉ dừng ở đó. Các trình duyệt đều có một danh sách các CA được tin cậy theo mặc định và danh sách này có thể được chỉnh sửa. Chúng ta đã chứng kiến những vụ việc như phần mềm gián điệp Superfish trong máy tính của Lenovo và tiếp đó là chứng thư eDellRoot trong máy tính của Dell. Trong cả hai vụ việc, một CA gốc theo lẽ thường phải lưu khóa bí mật trong một thiết bị có khả năng chống can thiệp tại một trung tâm dữ liệu an toàn. Nhưng thực tế chúng lại được lưu trong vô số máy tính khác nhau trên toàn thế giới. Bất kỳ ai cũng có thể dùng khóa bí mật đó để giả mạo bất kỳ website nào.

Để ngăn ngừa những vấn đề bảo mật phát sinh từ các CA không đáng tin được cài sẵn trong hệ thống và những chứng thư giả có thể bị đưa vào một cách trái phép, chúng ta cần xóa các chứng thư số không đáng tin cậy khỏi kho lưu trữ. Như thế, khi truy cập các website dùng chứng thư do các CA đó phát hành, trình duyệt sẽ hiển thị cảnh báo. Hình dưới đây thể hiện 4 “kho chứng thư gốc” chính của các trình duyệt: Apple, Microsoft, Mozilla, và Android.

Lưu ý khi sử dụng giao thức TLS/SSL

Mã hóa tất cả các kết nối giữa website và người dùng (Always on SSL)

Chúng ta đều biết rằng cần sử dụng giao thức HTTPS để mã hóa, bảo vệ mật khẩu, số thẻ tín dụng và các thông tin nhạy cảm của người dùng. Nhưng không phải HTTPS chỉ cần đưa ra những màn hình kiểm tra mật khẩu là xong. Kẻ xấu không cần biết mật khẩu để đóng giả người dùng, nếu ứng dụng web chỉ dùng HTTPS khi xác thực rồi quay lại dùng HTTP sai khi đăng nhập, thì quyền riêng tư và định danh tạm thời của người dùng không thể được bảo vệ. Các trang web giao tiếp với trình duyệt và không thể biết người ngồi trước máy tính là người dùng thực hay giả. Tên tài khoản và mật khẩu được gõ ở màn hình đăng nhập chỉ để chứng minh danh tính của người dùng. Sau khi đăng nhập, trang web gán cho trình duyệt một đoạn mã định danh lưu trong cookie. Cookie định danh là một bí mật được chia sẻ giữa trình duyệt và trang web. Khi quay lại sử dụng giao thức HTTP, cookie định danh đó có thể bị lợi dụng để giả danh người dùng. Chính vì thế, một số nhà cung cấp dịch vụ đã đưa ra thiết lập để đảm bảo người dùng luôn truy cập website bằng giao thức HTTPS. Tuy nhiên, các ứng dụng thứ ba sử dụng API của Twitter chưa chắc đã thiết lập như thế. Trong khi mật khẩu của người dùng vẫn được giữ bí mật, thì ứng dụng web đã quay lại giao thức HTTP cùng với toàn bộ các thông tin trao đổi, kể cả cookie dùng để định danh người dùng. Vì thế, cần lưu ý mã hóa tất cả các kết nối giữa trang web và người dùng, kể cả các kết nối thông qua ứng dụng (chẳng hạn như ứng dụng điện thoại).

Lý do thứ hai cho việc luôn luôn sử dụng giao thức HTTPS là mọi thông tin trao đổi đều có thể tiết lộ hành vi và định danh của người dùng. Những người theo dõi các kết nối HTTP có thể thông qua lịch sử lướt web của người dùng để xác định hành vi, ý định và từ đó xác định danh tính của họ. Hơn thế nữa, kẻ xấu có thể sửa đổi thông tin gửi tới người đọc để chèn thêm quảng cáo, các liên kết trỏ tới nơi chứa mã độc hay đơn giản là trang giả mạo dịch vụ internet banking của ngân hàng. Chỉ cần một trong những điều đó xảy ra, an toàn của khách hàng và uy tín của tổ chức đã bị ảnh hưởng nghiêm trọng.

Chứng thư kiểm tra mở rộng giúp người dùng nhận biết và tin tưởng hơn vào trang web

Chứng thư kiểm tra mở rộng (Extended Validation Certificate) là chứng thư số đặc biệt, chỉ được cấp sau khi CA kiểm tra định danh một cách kỹ lưỡng, theo những quy định khắt khe. Khi phát hành chứng thư EV, CA phải kiểm tra: sự tồn tại của tổ chức xin cấp chứng thư về mặt pháp lý, định danh chính xác của tổ chức xin cấp chứng thư và các thông tin liên quan, mã số đăng ký tại các tổ chức chính phủ (ví dụ số giấy phép đăng ký kinh doanh), quyền sử dụng tên miền, thẩm quyền của cá nhân đứng ra xin cấp chứng thư cho tổ chức. Hơn thế, chỉ những CA đã vượt qua cuộc kiểm toán độc lập trong chương trình đánh giá WebTrust (hoặc tương đương) mới có quyền cấp chứng thư EV. Khác biệt rõ nhất đối với người dùng sử dụng trình duyệt hỗ trợ chứng thư EV là thanh địa chỉ chuyển thành màu xanh lục khi vào một website có chứng thư EV. Chứng thư EV đắt hơn nhiều so với các chứng thư số thông thường nhưng có tác dụng lớn trong việc giúp người dùng an tâm, tin tưởng rằng họ đã truy cập đúng trang web “chính chủ”.

Sử dụng chứng thư đa tên miền hay chứng thư wildcard?

Các tổ chức nên chọn chứng thư nào nếu muốn sử dụng nhiều tên miền khác nhau? Thực tế có hai lựa chọn: chứng thư đa tên miền (multi-domain certificate) và chứng thư wildcard. Chứng thư đa tên miền (Multi-domain) là loại chứng thư có thể dùng cho nhiều tên miền khác nhau hay nhiều hostname trong một domain. Chúng thường được gọi là các chứng thư truyền thông hợp nhất (Unified Communications Certificates, viết tắt là UCC) vì có thể dùng để bảo vệ một tên miền chính và nhiều tên miền khác hợp nhất bằng một chứng thư số duy nhất Subject Alternative Names (SAN), rất phù hợp cho Microsoft® Exchange Server 2007, Exchange Server 2010 và Microsoft Live® Communications Server. Ngoài ra, loại chứng thư này còn thích hợp cho môi trường dùng chung máy chủ, khi số địa chỉ IP hạn chế (chẳng hạn như đám mây Amazon EC2 hay Rackspace).

Chứng thư wildcard có thể dùng cho nhiều tên miền con của một tên miền nhưng chỉ hỗ trợ một tầng subdomain. Các tên miền bỏ phần www, ví dụ vietcombank.com.vn không thể được bảo vệ bằng chứng thư wildcard *.vietcombank.com.vn vì không khớp. Hơn nữa không thể lấy chứng thư kiểm tra mở rộng (EVCertificate) cho các loại chứng thư wildcard. RFC 6125 cũng khuyên không nên dùng chứng thư wildcard vì lý do an ninh. Với những thông tin trên, người dùng nên chọn chứng thư đa tên miền.

Nên ngừng sử dụng chứng thư SGC để tiết kiệm và tăng cường bảo mật

Các chứng thư Server-Gated Cryptography (SGC) cho phép các trình duyệt cũ kết nối với máy chủ web qua kênh mã hóa 128 bit thay vì 40 bit. Sử dụng chứng thư SGC thường đắt hơn nhiều so với sử dụng chứng thư số thông thường. Các CA vẫn cố gắng bán chúng với lý do giúp doanh nghiệp tăng cường bảo mật cho mọi đối tượng khách hàng. Tuy nhiên, có hai lý do nên bỏ việc sử dụng các chứng thư loại này: thứ nhất, tỷ lệ sử dụng các trình duyệt cũ là rất thấp (các trình duyệt mới không còn chịu giới hạn xuất khẩu sản phẩm mã hóa với khóa trên 40 bit); lý do thứ hai quan trọng hơn là việc cho phép sử dụng các trình duyệt cũ thường là khuyến khích, điều này làm gia tăng nhiều kiểu tấn công bảo mật hơn (nhắm tới những lỗ hổng không được vá do hết thời hạn hỗ trợ). Thay vì sử dụng chứng thư SGC, các tổ chức nên chỉnh sửa trang web để phát hiện và ngừng dịch vụ trên các trình duyệt cũ, yêu cầu người dùng nâng cấp lên phiên bản mới.