SSL
certificates and "the most dangerous code in the world"
26
October 2012, 10:21
Bài
được đưa lên Internet ngày: 26/10/2012
Lời
người dịch: Người sử dụng sẽ tin cậy hơn vào
các ứng dụng được mã hóa. Tuy nhiên, các nhà nghiên
cứu tại Đại học Texas ở
Austin và Đại học Stanford đã phát hiện ra rằng rất
nhiề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á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ụ đá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óa
là thủ phạm chính...
Các
nhà nghiên cứu đã thấy những lỗi đó trong hầu hết
tất cả các dạng ứng dụng, từ phần mềm thông điệp
máy trạm tới các ứng dụng nghiệp vụ sống còn truyền
các dữ liệu nhạy cảm của các khách hàng thông qua các
dị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ệt
cung cấp các giao diện báo cáo lỗi đơn giản và phù hợp
hơn”.
Nhiều
chương trình sử dụng mã hóa là không an ninh, theo các
nhà nghiên cứu tại Đại học Texas ở Austin và Đại học
Stanford. 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á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ụ đá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óa là thủ phạm chính.
SSL,
là chuẩn de facto cho an ninh, các kết nối Internet được
mã hóa, nhưng an ninh đó đòi hỏi rằng một chương trình
kiể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ày
là 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ểm
nhất trên thế giới: việc kiểm tra tính hợp lệ các
chứng thực SSL trong các phần mềm không phải là trình
duyệt”, họ nói rằng “sự hợp lệ của chứng thực
SSL hoàn toàn bị gãy trong nhiều ứng dụng và thư viện
an ninh - sống còn”.
Trong
cá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ác
thư viện SSL như JSSE, OpenSSL và GnuTLS; các thư viện
truyề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ủa
nhữ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ết
lập mà rõ ràng lấn át nhiều lập trình viên.
Đội
nghiê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 3
dạ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ên
và một chứng thực từng từ một cơ quan cấp chứng
thự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ứng
thực đã xoay xở để tìm cách tin cậy các nạn nhân đã
chấp nhận chúng.
Các
nhà nghiên cứu đã thấy những lỗi đó trong hầu hết
tất cả các dạng ứng dụng, từ phần mềm thông điệp
máy trạm tới các ứng dụng nghiệp vụ sống còn truyền
các dữ liệu nhạy cảm của các khách hàng thông qua các
dịch vụ như PayPal và Amazon Flexible Payments Service – FPS
(Dịch vụ thanh toán mềm dẻo của Amazon).
Ứng
dụ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 cho
việc quản lý các tài nguyên trong đám mây. Nghiên cứu
khác cũng gần đây đưa ra kết luận rằng mã hóa là ít
hơ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ình
viê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 cung
cấp các giao diện báo cáo lỗi đơn giản và phù hợp
hơn. Hơn nữa, họ nói, hiện có rất ít cách thức nhạy
cảm để kiểm thử các chương trình sử dụng SSL.
Many
programs that use encryption are not secure, according to researchers
at the University of Texas at Austin and Stanford University. The
researchers found that a number of e-commerce web applications,
well-known instant messaging clients such as Trillian and AIM, and a
long list of cloud services use ineffective encryption. They say that
the libraries used for encryption are the main culprit.
SSL
is the de facto standard for secure, encrypted internet connections,
but that security requires that a program validates the receiver's
identity, specifically its SSL certificate. This is exactly where the
researchers see a problem: in their study "The
Most Dangerous Code in the World: Validating SSL Certificates in
Non-Browser Software", they say that "SSL certificate
validation is completely broken in many security-critical
applications and libraries".
In
applications that aren't written for browsers, SSL is generally
implemented 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 and
settings that clearly overwhelm a lot of developers.
The
research team conducted targeted man-in-the-middle attacks,
presenting applications with three kinds of bogus certificates: a
self-signed certificate with the correct name, a self-signed
certificate with a random name and a certificate that was from a
legitimate authority but issued to the domain
AllYourSSLAreBelongto.us
– hardly the correct domain. All three certificates managed to find
trusting victims that accepted them.
The
researchers found these bugs in almost all kinds of applications,
from messaging clients to critical business applications that
transmit sensitive customer data via services like PayPal and Amazon
Flexible Payments Service (FPS). Chase Bank's Android banking app
proved to be vulnerable, as did Rackspace's iOS app for managing
resources in the cloud. Another study also recently came to the
conclusion that encryption
is less than ideal in many Android apps.
To
improve the situation, the researchers don't believe that it is
enough to simply blame the programs' developers – instead, they
call on library authors in particular to provide simpler and more
consistent error reporting interfaces. In addition, they say, there
are currently very few sensible ways to test programs that use SSL.
(crve)
Dịch:
Lê Trung Nghĩa
Không có nhận xét nào:
Đăng nhận xét
Lưu ý: Chỉ thành viên của blog này mới được đăng nhận xét.