Vấn đề về quản lý mật khẩu trong IE và Firefox docx

Vấn đề về quản lý mật
khẩu trong IE và Firefox

1, Giới thiệu

Hai phần của bài viết này sẽ trình bày cho bạn một phân tích về các
kỹ thuật bảo mật, rủi ro, các tấn công và cách phòng chống của hai
hệ thống quản lý mật khẩu trình duyệt được sử dụng rộng rãi, đó là
Internet Explore và Firefox. Đối tượng chính trong bài viết này đề
cập đến hai trình duyệt IE 6 và 7, Firefox 1.5 và 2.0 và cụ thể là
những nội dung sau:
 Kỹ thuật lưu mật khẩu: Ý nghĩa của việc bảo vệ các
username và password trên hệ thống file cục bộ thông qua mã hóa.
 Các kiểu tấn công: Các phương pháp phá hoại hay vượt qua
được sự bảo vệ.
 Những sai lầm về bảo mật: Người dùng sử dụng mật khẩu
không có kiến thức về khả năng rủi ro.
 Khả năng sử dụng: Những đặc tính nhằm nâng cao hay cản
trở khả năng sử dụng của các đặc tính bảo mật.

Bi
ện pháp đối phó v
à kh
ắc phục
: Những hành động cần thiết
để người dùng và các tổ chức giảm những rủi ro không đáng có.
Internet Explorer và Firefox đã cùng nhau chia sẻ khoảng gần 95%
thị phần của tất cả các trình duyệt. AutoComplete và Password
Manager là các tính năng để lưu username, password và URL tương

của IE (từ phiên bản 4) và Firefox (từ phiên bản 0.7)

Mỗi trình duyệt có các tính năng riêng để hỗ trợ người dùng bằng
việc nhớ các username và password khác nhau như một sự thẩm
định cho các trang web. Vì vậy, khi vào một URL
như , nơi có các trường nhập vào, thì cả
Internet Explorer và Firefox đều sẽ nhắc nhở người dùng xem có
muốn lưu username hay password hay không. Khi người dùng vào
lại trang web này thì trình duyệt sẽ tự động điền vào đầy đủ các
trường đó.

Mặc dù những tính năng này giúp đơn giản hóa đáng kể trách
nhiệm của người dùng song chúng cũng đưa ra những vấn đề cần
phải suy xét về bảo mật, điều mà sẽ được nói đến trong những phần
dưới đây.

2, Một trường hợp về bộ quản lý mật khẩu

Sự cần thiết của các bộ quản lý mật khẩu liên quan trực tiếp đến
khó khăn để có thể nhớ một số lượng lớn username và password
cho các trang web cụ thể. Thực tế, cần phải chú ý là bộ quản lý mật
khẩu có thể tăng cường toàn bộ tính bảo mật vì chúng có quyền cho
phép mức entropy lớn hơn trong việc sử dụng các bộ nhận dạng và
mật khẩu. Vì vậy người dùng có thể tạo nhiều username khác nhau
thay vì một username để cho những kẻ tấn công khó khăn hơn trong
việc phỏng đoán.

Xét theo khía cạnh cân bằng mà nói thì người dùng phải tin tưởng
vào ứng dụng để thực hiện vai trò của nó (như việc lưu, xử lý một
cách an toàn và những khả năng tiến bộ để cho phép tồn tại của nó).

Việc quản lý mật khẩu không phải là một phương thuốc chữa bách
bệnh song chúng cũng có tác dụng thúc đẩy về mặt công nghệ, tăng
khả năng rào chắn đối với những tấn công bằng cách cải thiện giao
diện người dùng để tính toán các môi trường thông thường vẫn cần
đến sự thẩm định.

Người dùng cũng như các doanh nghiệp cần phải được bảo đảm
rằng các hệ thống quản lý mật khẩu phải được sử dụng và thực hiện
đúng quy cách, kiến thức về khả năng rủi ro liên quan. Bài viết này
có thể được sử dụng như một kiến thức cơ bản cho việc thiết kế các
bộ quản lý mật khẩu an toàn hơn bằng việc ôn lại những tấn công,
từ đó xây dựng một giải pháp vững chắc đối phó với các tấn công
tương lai.

3, Công việc đầu tiên

Sử dụng cùng một username và password trong nhiều trang web sẽ
làm tăng khả năng thỏa hiệp, chính nhờ đó mà kẻ tấn công chỉ cần
khám phá một username và một password để thỏa hiệp với tất cả tài
nguyên của người dùng. Sử dụng nhiều password, các kỹ thuật ghi
nhớ và mối nguy hiểm khi dùng lại password đều được nghiên cứu
một cách rộng rãi. Thêm vào đó, mở rộng ra Firefox cũng đã được
nghiên cứu để giảm khả năng có thể phỏng đoán password.

4, Các kỹ thuật lưu password

Các vị trí và kỹ thuật lưu username và password được đưa ra dưới
đây. Thông tin này được sử dụng như một nghiên cứu các kiểu tấn
công cơ bản được sử dụng trong phần 5.

4.1, Vị trí lưu

4.1.1, Internet Explorer 6 & 7

Trên Internet Explorer (từ phiên bản 4 đến 6) thông tin định dạng
web AutoComplete được lưu trong Registry ở các vị trí dưới đây:

Các username và password đã được mã hóa:
HKEY_CURRENT_USER\Software\Microsoft\Internet
Explorer\IntelliForms\SPW
Các địa chỉ Web:
HKEY_LOCAL_MACHINE\Software\MicrosoftProtected Storage
System Provider\
Các key mã hóa đối xứng:
HKEY_CURRENT_USER\Software\Microsoft\ Protected Storage
System Provider\Data\\
Trong Internet Explorer 7, thông tin AutoComplete cũng được lưu
trong Registry nhưng trong vị trí khác.

Các username và password đã được mã hóa:
HKEY_CURRENT_USER\Software\Microsoft\Internet
Explorer\IntelliForms\Storage2
Các mục trong registry chỉ được tạo khi người dùng thực hiện lưu
thông tin đăng nhập (username và password) cho một trang web.
SPW là viết tắt của SavedPassWords.

4.1.2, Firefox 1.5 and 2.0

Trong Firefox, các URL (Uniform Resource Locators), các
username và password được lưu trong một filesignons.txt:

Các username và password được mã hóa trong hệ thống Windows
được lưu trong:
%userprofile%\Application Data\Mozilla\Firefox
Profiles\xxxxxxxx.default\signons.txt
Khi %userprofile%, là biến môi trường trong Windows, thể hiện
đường dẫn đến thư mục chủ của người dùng.

Các username và password được mã hóa trong hệ thống Linux đang
chạy Firefox được lưu ở vị trí sau:
~/.mozilla/firefox/ xxxxxxxx.default/signons.txt
Vị trí của xxxxxxxx được chọn ngẫu nhiên khi Firefox được cài đặt.
File signons.txt được tạo ra khi bất kỳ login cho một trang web
được lưu. Các login theo sau với các URL được chèn vào trong file.
Nó hoàn toàn không liên quan đến bộ quản lý password nếu trang
đó truy cập sử dụng HTTP hay HTTPs. Các URL không được mã
hóa bởi vì chúng được sử dụng như một tham chiếu (tra cứu) cho
việc khớp các login. Đặc biệt hơn, khi một bộ quản lý password
trình duyệt cần điền tự động login cho một trang cụ thể, có URL
của trang được tham chiếu vơi file signons.txt (nếu URL đó tồn tại)
thì username và password tương ứng được điền vào login của trang
web.

4.2, Các kỹ thuật truy cập và lưu trữ

4.2.1, Internet Explorer 6 & 7

Kiến trúc lưu: Registry
Định dạng: Nhị phân, và được lưu như một cặp của các giá trị hex
trong một loại dữ liệu REG_BINARY.

Mã hóa: DES- ba cấp.
Truy cập: Bảo vệ API lưu trữ (cho Internet Explorer 4-6); API bảo
vệ dữ liệu (cho Internet Explorer 7)
Các yêu cầu cho truy cập: Người dùng đăng nhập.
Lưu trữ tạm thời: Các key đối xứng được đánh 0 vào bộ nhớ sau
khi sử dụng.

Internet Explorer 4-6 sử dụng bộ cung cấp hệ thống bảo vệ lưu trữ
(PStore) để lưu và truy cập thông tin người dùng gồm có username
và password, các password nhập vào trên định dạng web trong
Internet Explorer. Pstore như định nghĩa bởi MSDN, là một giao
diện lập trình ứng dụng được sử dụng để lưu thông tin một cách an
toàn. Trong một công bố gần đây của Microsoft người ta đã đưa ra:
"… dịch vụ Protected Storage, không sớm thì muộn cũng sẽ được
quan tâm như một phương pháp bảo đảm cho lưu trữ các bí mật.
Ứng dụng Windows đáng kể nhất vẫn sử dụng P-store là Microsoft
Internet Explorer, lưu thông tin Auto-Complete gồm có tên, mật
khẩu được sử dụng để thẩm định dựa trên các form."
Dữ liệu PStore được mã hóa với DES-ba cấp và được lưu trong một
kiến trúc nhị phân. Dữ liệu không mã hóa không thể truy cập trực
tiếp thông qua registry. Mặc dù vậy, việc truy cập và an ninh dữ
liệu cần phải được thắt chặt với các khả năng đăng nhập Windows
của người dùng. Khi người dùng đăng nhập, bất kỳ một chương
trình đang chạy dưới nội dung của người dùng có thể tăng khả năng
truy cập đến dữ liệu PStore không mã hóa bằng việc sử dụng các
triệu gọi API đúng. Mặc dù vậy, các tài khoản người dùng
Windows khác không thể truy cập vào dữ liệu PStore khác.

PStore không phải chỉ được sử dụng riêng trên Internet Explorer mà
nó còn được sử dụng chung cho cả kỹ thuật khác của các sản phẩm

Microsoft như Outlook và MSN Explorer. Các chương trình này
cũng dễ bị ảnh hưởng đến các yếu điểm trong thiết kế bảo mật. Một
số chương trình Spyware đã biết cách phá hoại bảo mật PStore
thông qua API có khả năng lập trình dễ dàng của nó và tăng mức
truy cập không chính đáng.

Internet Explorer 7 sử dụng giao diện lập trình ứng dụng dữ liệu
bảo vệ (DPAPI) nhưng những khả năng trên vẫn có thể tồn tại và
được công bố đến các chương trình mở rộng thông qua các triệu gọi
API.

Mật mã cho AutoComplete trong IE7 được thể hiện dưới đang sử
dụng thuật ngữ chuẩn:
EK - Encryption Key (Khóa mã hóa)
RK - Record Key (Khóa bản ghi)
CRC - Cyclical Redundancy Check (Kiểm tra tình trạng dư thừa
theo chu kỳ)
Hash - Secure Hash Algorithm (SHA) (Thuật toán bảo mật Hash)

Khả năng lưu trữ:
EK: URL
RK: Hash(EncryptionKey)
C: CRC(Record Key)
V: {dữ liệu}EK
Lưu trữ (C, V) được đánh chỉ số bằng RK trong Registry, làm mất
hiệu lực EK

Khả năng phục hồi lại:
EK: URL
RK: Hash(EK)

Tra cứu RK trong Registry, xem có khớp tương ứng dữ liệu mã hóa
và dữ liệu {V}EK hay không
Vì vậy URL được yêu cầu để phục hồi lại các khả năng (dữ liệu)
như nó xếp vào EncryptionKey (EK).

a, Những quan tâm về truy cập của Internet Explorer.

IE AutoComplete làm việc dưới giả thuyết rằng một tài khoản người
dùng Windows cụ thể hoàn toàn có thể truy cập hợp lý với cơ sở dữ
liệu mật khẩu. Vì vậy, nếu một người dùng không được phép có sự
truy cập hợp lý đến máy tính và tài khoản được đăng nhập hoặc nó
không phải là một password được bảo vệ thì kẻ tấn công có thể lạm
dụng các đặc quyền tài khoản và sử dụng password một cách bất
hợp pháp. Sự truy cập hợp lý có thể được thực hiện trực tiếp trên
máy tính đó hoặc sử dụng máy khách truy cập từ xa (VNC, trạm
làm việc từ xa,…).

Như vậy, nếu không có những tôn trọng về việc sử dụng máy (như
việc các phòng được ngăn cách bởi khóa, hay mật khẩu để bảo vệ
việc đăng nhập của các chương trình bảo vệ màn hình) thì bất kỳ ai
cũng có thể sử dụng trực tiếp trên máy tính để truy cập tới bất kỳ
website nào cho phép quản lý password. Nếu quản lý máy tính tốt,
thì một người không đáng tin muốn tăng khả năng truy nhập tới bất
cứ thứ gì (từ email cá nhân của một người tới tài khoản ngân hàng)
sẽ gặp khó khăn.

Thêm vào đó, trong các trường hợp nhiều người có cùng một tài
khoản người dùng hợp lý (một thực tế bảo mật kém), các vấn đề
tăng vọt với người dùng bất hợp lý. Các kỹ thuật điều khiển từ xa
để tăng truy cập được đưa ra trong phần sau và cũng có hiệu lực với

các bổ sung thêm vào.

4.2.2, Firefox 0.7-1.5 và 2.0

Ki
ến trúc l
ưu
: Dạng file văn bản (signons.txt)
Định dạng: ASCII, bằng sử dụng việc mã hóa Base64 (ngoại trừ
URL và các trường)
URL (ví dụ. www.gmail.com)
Trường tên (trong cleartext,ví dụ: username, email, userid,…)
Mã hóa Base64 cho các thông tin ở trên
Trường tên (ví dụ: password, pass, )
Mã hóa Base64 cho các thông tin ở trên
(Có thể có nhiều mục cho mỗi URL)

(Mỗi mục URL kéo dài trong chu kỳ phân chia dòng)
Mã hóa: DES ba cấp (chế độ CBC)
Truy cập: Các dịch vụ an ninh mạng API (NSS)
Các yêu cầu cho truy cập: Người dùng đã đăng nhập và mật khẩu
chủ (nếu thiết lập)
Các file liên quan: Các chứng chỉ (ký các Public Key) được lưu
trong certN.db, còn các cơ sở dữ liệu Private Key được lưu
trong keyN.db và các Module bảo mật được lưu trong secmod.db

Chú ý rằng các vị trí file được định tị từ trước trong phần 4.1.

Firefox sử dụng Network Security Services API để thực hiện mã
hóa. Nó liên quan đến Password ManagerFirefox để tạo ra Public

Key Cryptography Standard (PKCS) #11 (định nghĩa API cho các
modul bảo mật nhóm thứ ba gồm cả phần mềm và phần cứng). Sử
dụng PKCS#5 để mã hóa password. Firefox cũng có một tùy chọn
của việc sử dụng mođul bảo mật luân phiên cho bộ quản lý
password, đó là chuẩn xử lý thông tin quốc gia (FIPS) 140-
1. Master Password được sử dụng cùng chung với một phần trong
file keyN.db thường được sử dụng để cung cấp một Master
Key. Master Key sau đó được sử dụng để giải mã username,
password được lưu trong Password Manager.

Mặc dù không dễ dàng giải quyết nhưng NSS API có một vài chức
năng quan trọng đối với Firefox hay một chương trình liên quan để
tăng khả năng truy nhập vào cơ sở dữ liệu có password. Các thiết
lập password được nắm giữ bởi (PK11_SetPasswordFunc), giải mã
dữ liệu cơ số 64 (NSSBase64_DecodeBuffer), giải mã
(PK11SDR_Decrypt) cho phép một chương trình liên quan đến các
username và password liên quan; đây quả thực là một vấn đề đơn
giản. mã thực tế cần khởi chạy NSS, tuyên bố các biến, quản lý bộ
đệm,… Mặc dù vậy sự bảo mật của toàn bộ hệ thống dựa vào sức
mạnh mật mã của Master Password (được tạo ra bởi người dùng) và
khả năng truy cập vào file key3.db (bao gồm những phần quan
trọng) được lưu trong profile của người dùng.

Modul bảo mật FIPS 140-1 có thể cho phép bằng việc định hướng
theo sự xếp đặt sau:
Firefox 1.5 trên Windows:

Tools | Options | Advanced | Security Devices | NSS Internal
FIPS PKCS #11

Firefox 2.0 trên Windows:

Tools | Options | Advanced | Encryption | Security Devices |
NSS Internal FIPS PKCS #11
5, Các tấn công vào bộ quản lý password

Phần này sẽ quan sát vài tấn công nhằm phá hoại các bộ quản lý
password. Hai tấn công như đã được thảo luận và sau đó chúng tôi
sẽ gộp thành một phần trong một loạt các bào báo.

Một công nghệ chung nhất để tìm tất cả các đường thâm nhập một
hệ thống là sử dụng một sơ đồ hình cây. Mục đích của sơ đồ này
được thể hiện bên dưới hình 1 là sự thỏa hiệp hoàn tất của cơ sở dữ
liệu password.

Hình 1: Tấn công kiểu cây với bộ quản lý password trong Firefox.
Kết quả của việc tăng truy nhập vào cơ sở dữ liệu sẽ cho phép kẻ
tấn công đạt được tất cả các URL, username, password mà đã được
sử dụng để xác nhận trong các trang. Bộ quản lý password thỏa
hiệp cho phép kẻ tấn công truy cập vào bất kỳ thứ gì từ e-mail đến
bảo hiểm, ngân hàng hay thậm chí cả thông tin cộng tác bên trong
mạng nội bộ. Một vấn đề nhỏ (không được liệt kê trong cây trên) sẽ
thỏa hiệp với khả năng đăng nhập cho các trang đặc biệt.

Một hệ thống quản lý password được phát triển cho ứng dụng và
các thành phần người dùng. Để thỏa hiệp với cơ sở dữ liệu
password hay một đăng nhập đặc biệt thì chỉ cần tấn công vào
thành phần yếu nhất của hệ thống. Trong trường hợp này, các liên
kết yếu nhất luôn là người dùng (không mã hóa hoặc bổ xung thêm

phần mềm). Các tấn công đều dựa vào giao diện giữa người dùng
và bộ quản lý password hoặc giữa bộ quản lý password và trình
duyệt.

5.1, Trình duyệt không bị các tấn công JavaScript

Hai tấn công JavaScript sẽ không được thảo luận trong phần này
trước trước khi kết luận: một tấn công chuẩn và một ứng dụng
Ajax.

5.1.1, Tấn công JavaScript chuẩn

Giả định: Kẻ tấn công có tài khoản người dùng hợp lệ

Kết quả tấn công: Kẻ tấn công có khả năng xuyên qua một trang
đã lưu đăng nhập và 1) Tăng truy nhập 2) Sử dụng JavaScript để
phát hiện username và password.

Thiệt hại khác: sử dụng password bị lộ để truy cập vào bộ quản lý
password hoặc các ứng dụng khác và các trang có cùng password.

Sử dụng JavaScript hoàn toàn có thể phát hiện ra các password đã
được lưu trên bất kỳ trang nào thông qua DOM. Khi một ai đó
viếng thăm một trang nào đó mà lưu lại username và password thì
password luôn luôn được để ẩn bằng các dấu *. Đó là những gì mà
người dùng nhìn thấy; nhưng trình duyệt thì lại lưu password
bằng mã ASCII thực và đệ trình nó khi hành động đệ trình được cần
đến. Việc sử dụng các dấu * hoàn toàn tốt trong thiết kế để ngăn
chặn ngoài giao diện.

Để làm việc xung quanh phạm vi ngăn ngừa này, một kẻ tấn công
thông minh có thể sử dụng cả JavaScript được nhúng trong trang
HTML hay chạy một script sau khi tải trang, chúng ta cho rằng kẻ
tấn công đã xác định được username và password.

Hình 2: Mô hình đối tượng tài liệu JavaScript
Mã JavaScript hoàn toàn dễ dàng có thể truy cập online. Nó có thể
được nhúng trong HTML hoặc được chạy trong một bookmarklet.
Một bookmarklet là một chương trình JavaScript nhỏ được lưu như
một URL và chạy cục bộ trong trang web sau khi tải.

Sử dụng logic lập trình, một kẻ tấn công có thể lặp đi lặp lại thông
qua tất cả password-based elements (như trong hình 2) của DOM;
các giá trị tương ứng với các đối tượng password này sẽ được lấy
lại sau đó, việc phá các dấu * là không thể. Bất kỳ ai hay một
chương trình nào logic với máy khách Web (Internet Explorer hoặc
Firefox) có thể “click” trên một link và tìm ra được password.

javascript:(
function(){
var s,F,j,f,i;
s = "";
F = document.forms;
for(j=0; j f = F[j];
for (i=0; i if
(f[i].type.toLowerCase() == "password")
s += f[i].value + "\n";
}
}
if (s) alert("Passwords in forms :\n\n" + s);

else alert("No passwords in forms on this
page.");})();

Hình 3: Mã JavaScript để lấy lại password.
5.1.2, Việc lấy password bằng Ajax

Giả thiết: Kẻ tấn công truy cập đến một web proxy trong suốt hay
được cấu hình cho web máy khách.

Kết quả tấn công: Kẻ tấn công có khả năng chèn, xóa hay thay đổi
nội dung trang, JavaScript cho phép lấy được username và