Chứng thực SSL và “mã nguồn nguy hiểm nhất thế giới”

26October 2012, 10:21

Theo:http://www.h-online.com/security/news/item/SSL-certificates-and-the-most-dangerous-code-in-the-world-1737168.html

Bàiđược đưa lên Internet ngày: 26/10/2012

Lờingười dịch: Người sử dụng sẽ tin cậy hơn vàocác ứng dụng được mã hóa. Tuy nhiên, các nhà nghiêncứu tại Đại học Texas ởAustin và Đại học Stanford đã phát hiện ra rằng rấtnhiều ứng dụng mà không viết cho trình duyệt và có sửdụng mã hóa SSL lại rất không an ninh mà lý do chính nằmở các thư viện được sử dụng cho mã hóa.“Các nhà nghiên cứu đã thấy rằng một số lượng cácứng dụng web thương mại điện tử, cáctrình thông điệp tức thì nổi tiếng như Trillian và AIM,và một danh sách dài các dịch vụ đám mây sử dụng mãhóa không hiệu quả.Họ nói rằng các thư viện được sử dụng cho mã hóalà thủ phạm chính... Cácnhà nghiên cứu đã thấy những lỗi đó trong hầu hếttất cả các dạng ứng dụng, từ phần mềm thông điệpmáy trạm tới các ứng dụng nghiệp vụ sống còn truyềncác dữ liệu nhạy cảm của các khách hàng thông qua cácdịch vụ như PayPal và Amazon Flexible Payments Service – FPS(Dịch vụ thanh toán mềm dẻo của Amazon)...họ kêu gọi các tác giả của các thư viện, đặc biệtcung cấp các giao diện báo cáo lỗi đơn giản và phù hợphơn”.

Nhiềuchương trình sử dụng mã hóa là không an ninh, theo cácnhà nghiên cứu tại Đại học Texas ở Austin và Đại họcStanford. Các nhà nghiên cứu đã thấyrằng một số lượng các ứng dụng web thương mại điệntử, các trình thông điệp tức thì nổi tiếng nhưTrillian và AIM, và một danh sách dài các dịch vụ đámmây sử dụng mã hóa không hiệu quả. Họ nói rằng cácthư viện được sử dụng cho mã hóa là thủ phạm chính.

SSL,là chuẩn de facto cho an ninh, các kết nối Internet đượcmã hóa, nhưng an ninh đó đòi hỏi rằng một chương trìnhkiểm tra tính hợp lệ cho nhận diện của người sửdụng, đặc biệt cho chứng thực SSL của nó. Điều nàylà chính xác nơi mà các nhà nghiên cứu thấy một vấnđề: trong nghiên cứu của họ: “Mã nguồn nguy hiểmnhất trên thế giới: việc kiểm tra tính hợp lệ cácchứng thực SSL trong các phần mềm không phải là trìnhduyệt”, họ nói rằng “sự hợp lệ của chứng thựcSSL hoàn toàn bị gãy trong nhiều ứng dụng và thư việnan ninh - sống còn”.

Trongcác ứng dụng mà không được viết cho các trình duyệt,SSL thường được triển khai bằng việc sử dụng cácthư viện SSL như JSSE, OpenSSL và GnuTLS; các thư việntruyền dữ liệu như cURL cũng có thể được sử dụngđôi khi. Nhưng, các nhà nghiên cứu nói, các giao diện củanhững thư viện đó “được thiết kế tồi tệ” vàđưa ra một sự lúng túng về các lựa chọn và thiếtlập mà rõ ràng lấn át nhiều lập trình viên.

Độinghiên cứu đã tiến hành các cuộc tấn công người giữađường có chủ đích, trình bày các ứng dụng với 3dạng chứng thực giả: một chứng thực tự ký với tênđúng, một chứng thực tự ký với một tên ngẫu nhiênvà một chứng thực từng từ một cơ quan cấp chứngthực hợp pháp nhưng được phát hành cho miền AllYourSSLAreBelongto.us- hầu như không phải là miền đúng. Tất cả 3 chứngthực đã xoay xở để tìm cách tin cậy các nạn nhân đãchấp nhận chúng.

Cácnhà nghiên cứu đã thấy những lỗi đó trong hầu hếttất cả các dạng ứng dụng, từ phần mềm thông điệpmáy trạm tới các ứng dụng nghiệp vụ sống còn truyềncác dữ liệu nhạy cảm của các khách hàng thông qua cácdịch vụ như PayPal và Amazon Flexible Payments Service – FPS(Dịch vụ thanh toán mềm dẻo của Amazon).

Ứngdụng ngân hàng Android của Chase Bank được chứng minh làbị tổn thương, cũng như ứng dụng iOS của Rackspace choviệc quản lý các tài nguyên trong đám mây. Nghiên cứukhác cũng gần đây đưa ra kết luận rằng mã hóa là íthơn so với lý tưởng trong nhiều ứng dụng của Android.

Đểcải thiện tình hình, các nhà nghiên cứu không tin rằngđủ để đổ lỗi một cách đơn giản cho các lập trìnhviên các chương trình - mà thay vào đó, họkêu gọi các tác giả của các thư viện, đặc biệt cungcấp các giao diện báo cáo lỗi đơn giản và phù hợphơn. Hơn nữa, họ nói, hiện có rất ít cách thức nhạycảm để kiểm thử các chương trình sử dụng SSL.

Manyprograms that use encryption are not secure, according to researchersat the University of Texas at Austin and Stanford University. Theresearchers found that a number of e-commerce web applications,well-known instant messaging clients such as Trillian and AIM, and along list of cloud services use ineffective encryption. They say thatthe libraries used for encryption are the main culprit.

SSLis the de facto standard for secure, encrypted internet connections,but that security requires that a program validates the receiver'sidentity, specifically its SSL certificate. This is exactly whe-re theresearchers see a problem: in their study "TheMost Dangerous Code in the World: Validating SSL Certificates inNon-Browser Software", they say that "SSL certificatevalidation is completely broken in many security-criticalapplications and libraries".

Inapplications that aren't written for browsers, SSL is generallyimplemented using SSL libraries such as JSSE, OpenSSL and GnuTLS;data-transport libraries such as cURL may also be used on occasion.But, the researchers say, the interfaces of these libraries are"badly designed" and offer a confusing array of options andsettings that clearly overwhelm a lot of developers.

Theresearch team conducted targeted man-in-the-middle attacks,presenting applications with three kinds of bogus certificates: aself-signed certificate with the correct name, a self-signedcertificate with a random name and a certificate that was f-rom alegitimate authority but issued to the domainAllYourSSLAreBelongto.us– hardly the correct domain. All three certificates managed to findtrusting victims that accepted them.

Theresearchers found these bugs in almost all kinds of applications,f-rom messaging clients to critical business applications thattransmit sensitive customer data via services like PayPal and AmazonFlexible Payments Service (FPS). Chase Bank's Android banking appproved to be vulnerable, as did Rackspace's iOS app for managingresources in the cloud. Another study also recently came to theconclusion that encryptionis less than ideal in many Android apps.

Toimprove the situation, the researchers don't believe that it isenough to simply blame the programs' developers – instead, theycall on library authors in particular to provide simpler and moreconsistent error reporting interfaces. In addition, they say, thereare currently very few sensible ways to test programs that use SSL.

(crve)

Dịch:Lê Trung Nghĩa

letrungnghia.foss@gmail.com