Các tấn công phòng thủ dựa trên việc tập trung theo dõi một ngƣời dùng hợp pháp đang đăng nhập, và quản lý các hành động của kẻ tấn công. Tại mỗi điểm cuối của chuỗi đăng nhập, kẻ tấn công cũng gửi trong ký tự nhập và nhanh hơn, hoặc gửi trong tất cả các ký số cuối cùng có thể để hoàn thành mã xác thực. Trong đáp ứng cho các tấn công, aceserver sẽ trễ từ 1 đến 15 giây trƣớc khi đáp ứng yêu cầu, và nếu nó nhiều yêu cầu cùng một lúc, nó sẽ huỷ tất cả. Tuy nhiên, độ trễ này hoạt động giống nhƣ một tấm chắn may mắn để giả mạo gói tin hợp pháp.
Có một khó khăn thực tế trong việc quyết định cổng nào mà sdshell sẽ gắn vào. Nếu tính an toàn cuối cùng dựa vào độ khó của việc tìm kiếm cổng, thì sau đó hệ thống có thể đƣợc cho là bảo mật thực sự qua tính khó hiểu. Đây thực sự là chính xác nếu kẻ tấn công là cục bộ và muốn mạo nhận một ngƣời ngƣời khác.
Nếu ngƣời dùng là cục bộ, họ chỉ cần chạy lệnh ‗netstat -a‘ để tìm ra sdshell nào đang nghe. Nếu là ngƣời dùng từ xa, thì cần một máy thăm dò mở rộng để tìm ra dãy cổng để tấn công.
2.6.4. Phòng thủ phía ngƣời dùng
Xem xét hai nhóm tấn công: bên ngoài và bên trong. Các tấn công bên ngoài dễ dàng bị tất bại hơn là các cuộc tấn công bên trong.
Để tự bảo vệ chống lại tấn công từ phía ngoài, ngăn chặn tất cả các gói UDP đến, chấp nhận những gì cần thiết nhƣ DNS. Dù thế nào thì đây cũng là một chính sách hiệu quả và rất nhiều nơi đã thực hiện mà không cần phải hành động gì, ngoại trừ xác thực những gì hoạt động theo thiết kế.
Phòng thủ chống lại các tấn công bên trong thì không dễ dàng. Ngƣời dùng mất khả năng sử dụng SecurID nếu học chặn các gói UDP. Những ngƣời sử dụng SecurID cho xác thực bên trong để yêu cầu Security Dynamic để cung cấp giao thức phù hợp đã đƣa ra để xem xét.
Việc cài đặt các hub chống lại sự nhòm ngó, hoặc triển khai IPsecurity có thể cung cấp các phòng thủ chính đáng.
Tuy nhiên, không một cách nào đƣợc thực hiện nhanh chóng hay rẻ tiền. Lƣu ý là việc mã hóa phiên không cung cấp sự phòng thủ, do đó đây là một tấn công trên các thiết bị đƣợc cấp quyền cho một ngƣời dùng phiên, không phải là một tấn cống liên quan đến việc trộm cắp passcode.
Ngoài ra, nó đang đƣợc xem là có giá trị bằng việc sử dụng một công cụ xác thực khác cho Ace/Server của ngƣời dùng cho đến khi họ tin tƣởng rằng vấn đề này đã đƣợc xác định. Những ngƣời trong nội bộ muốn giả mạo là một ngƣời khác trên máy cục bộ bằng việc truy cập đến các số hiệu cổng, timestamp và các thông tin khác.
2.6.5. Cố định giao thức
Giao thức là có trạng thái. Một giao thức có trạng thái sẽ cho phép vấn đề này đƣợc xác định bằng một biến đổi nhỏ đến phần mềm của máy chủ, đấy là đặt timestamp đƣợc gửi ra ngoài không cùng kích thƣớc. Đó là việc đặt các thông tin đủ ra khỏi tầm với của kẻ tấn công để tấn công không có thực. Nó cũng cho phép phát hiện dễ dàng khi một ngƣời dùng đang cố gắng đăng nhập nhiều lần vào cùng một máy.
Thêm vào đó, một giao thức có trạng thái sẽ yêu cầu các truy cập đầy đủ để giả mạo các số TCP tuần tự mà hoạt động tốt hơn trong trƣờng hợp một giao thức dựa trên UDP.
Khóa đƣợc sử dụng trong bƣớc cuối cùng là khóa bí mật đƣợc thoả thuận trƣớc đó. Nó sẽ cố định vấn đề bằng cách làm cho việc gửi một gói tin giả mạo trở nên khó khăn sao cho gói tin này sẽ đƣợc chấp nhận giống nhƣ một gói tin đáng tin bằng sdshell nhƣng yêu cầu cập nhật cho tất cả các phần mềm đã triển khai. Việc thay đổi thủ tục quản lý khóa tất nhiên sẽ mang lại đầy những rủi ro. Rủi ro đó có khả năng ít hơn là tiếp tục bằng các vấn đề chỉ ra ở đây và có thể đƣợc giảm nhẹ bằng thiết kế mã hóa chính xác.
Có thể phân tách chính xác các khóa xác thực và mã hóa. Khả năng đánh dấu thông điệp xác thực cuối cùng đƣợc xem xét. Tuy nhiên, việc sử dụng một khóa riêng biệt cần để chia sẻ với mỗi máy đặt trách nhiệm lên máy chủ để quản lý các khoá, tại đó một khóa DES sẽ làm việc giống nhƣ hai khóa hoặc nhiều hơn. Các khoá thỉnh thoảng có thể đƣợc thay đổi tự động để phát hiện chống lại một kẻ tấn công đã chiếm đƣợc quyền truy cập gốc đến máy đang tiếp tục có khả năng tấn công vào bằng những kiến thức thu đƣợc về các khóa mã hóa. [5]
2.7. CÁC TẤN CÔNG DỰA TRÊN ĐIỂM YẾU CỦA THẺ RSA SECURID 2.7.1. Tấn công dựa vào mã Token của thẻ Token có độ dài cố định 2.7.1. Tấn công dựa vào mã Token của thẻ Token có độ dài cố định
Mã Token là một xâu có độ dài cố định là 4, 5 hoặc 6 chữ số. Bằng việc quan sát ai đó sử dụng thẻ SecurID để đăng nhập vào hệ thống, kẻ tấn công sẽ biết đƣợc độ dài xâu của mã token cho server cụ thể. Chuẩn là gồm có 6 chữ số từ 000000 đến 999999, không có số ở hệ 16 và các chữ cái alpha. Ngƣời dùng có khoảng tổng cộng một triệu số, nhƣng chỉ có 10 giá trị cho chữ số cuối cùng. Hơn nữa, khi biết đƣợc vị trí của chữ số cuối cùng nên quá trình tấn công trở nên đơn giản.
Trong quá trình tấn công, kẻ tấn công sẽ theo dõi trao đổi giữa ngƣời dùng và chƣơng trình sdshell, đặc biệt lúc ngƣời dùng đăng nhập vào hệ thống. Ngay lúc ngƣời dùng Alice đăng nhập, kẻ tấn công Mallory cũng tạo ra 10 kết nối khác với máy sdshell. Mỗi kết nối này sẽ cố gắng để đăng nhập với các thông tin giống nhƣ Alice đã nhập vào.
Ví dụ nhƣ Alice đang nhập số 132862, thì đến khi Alice nhập đến số 6, Mallory đã nhập xong tất cả 10 khả năng có thể của chữ số cuối cùng. Nhƣ vậy đối với máy sdshell sẽ thấy Alice login mƣời một lần. Bởi vì Alice là con ngƣời và một số thực tế rằng 1) Có khả năng cô ấy không thể cài đặt chƣơng trình máy khách ở chế độ LINE BUFFERED, 2) bàn phím số thƣờng đáp ứng chậm hơn khi ngƣời dùng gõ vào và 3) bởi vì hầu hết các thẻ là token vật lý (ví dụ con ngƣời không thể copy và dán trực tiếp). Do đó Mallory có cơ hội để chiến thắng cuộc đua đăng nhập với thông tin đăng nhập trùng với thông tin đăng nhập của Alice. Có một số phƣơng pháp để Alice có thể bảo vệ thông tin đăng nhập của mình trong trƣờng hợp này:
Đặt chƣơng trình máy khách cô ấy đang sử dụng ở chế độ Line Buffer. Hầu hết các máy unix hỗ trợ điều này, nhƣng đối với các máy windows và Macintosh không hỗ trợ.
Gõ các phản hồi từ thẻ token vào một cửa sổ khác trên máy tính rồi sao chép và dán phản hồi vào phiên đăng nhập thực. Không đƣợc lơ là, chậm trễ khi nhập các phản hồi từ thẻ token, vì nhƣ thế kẻ tấn công sẽ có nhiều thời gian để chiến thắng trong cuộc đua đăng nhập.
Phiên bản mới nhất của ACE/Server từ SDTI có một số cơ chế để ngăn chặn kiểu tấn công này. Tuy nhiên, các cơ chế này không thực sự chống lại đƣợc các kiểu tấn công này và lại tự tạo ra tấn công từ chối dịch vụ (Denial of Service) đƣợc mô tả sau đây.
2.7.2. Tấn công từ chối dịch vụ
Sinh ra khi ngăn chặn tấn công dựa vào phản hồi của thẻ token, độ dài cố định.
Trong ví dụ trên, khi Alice đăng nhập vào hệ thống, Mallory cũng tạo ra 10 kết nối đăng nhập tƣơng tự. Máy sdshell sẽ gửi sẽ gửi một truy vấn tới máy chủ ACE để chứng thực ngƣời dùng. Nếu máy chủ ACE nhận đƣợc nhiều hơn một truy vấn này cho cùng một ngƣời dùng trong vòng 2 giây (ở chế độ mặc định) thì máy chủ này sẽ không cho phép ngƣời dùng đăng nhập vào hệ thống. Nhƣ vậy Mallory đã làm cho Alice không thể đăng nhập vào hệ thống mặc dù Alice đã nhập đúng thông tin đăng nhập.
Tiếp tục chứng thực ngƣời dùng khi thực hiện tấn công dựa trên phản hồi có độ dài cố định mặc dù máy chủ không cho phép đăng nhập nhiều lần trong một khoảng thời gian.
Bởi vì các truy vấn gửi từ máy sdshell đến máy chủ ACE để chứng thực ngƣời dùng nằm trong khoảng thời gian khi ngƣời dùng nhập xong mã token và bấm ENTER, nên cải tiến này của SDTI không ngăn chặn đƣợc tấn công khi khoảng thời gian này đủ lớn.
Trong trƣờng hợp này, Mallory chỉ đƣợc phép tạo ra một kết nối đăng nhập duy nhất và có một phần mƣời cơ hội để chọn đúng chữ số cuối của Alice. Mallory vừa phải đoán và vừa phải trì hoãn quá trình đăng nhập của Alice hơn 2 giây, ví dụ nhƣ Mallory có thể gọi điện cho Alice khi thấy Alice đang nhập chữ số cuối, v..v.
Mallory chờ đợi một thời điểm thích hợp (ví dụ nhƣ chờ đợi khi Alice nhập xong chữ số thứ 2 gần cuối) thì kích hoạt tấn công từ chối dịch vụ đối (Denial of Service) với máy của Alice nhƣ là ping flood, udp storm, đặt lại netmask thông qua tấn công icmp, rip, v…v.
Một dạng biến đổi rất phổ biến của cách tấn công trên mà luôn thành công là reset kết nối của Alice. Mallory thực hiện bằng cách theo dõi các gói tin trao đổi giữa Alice và máy sdshell. Khi Alice nhập xong kí tự thứ hai gần cuối, Mallory gửi lại một gói tin giống nhƣ gói tin từ máy sdshell gửi đến máy của Alice có địa chỉ nguồn là từ máy sdshell.
Nhƣ vậy, kết nối của Alice đối với máy sdshell sẽ đƣợc đóng khi nhận đƣợc gói tin RST mà Mallory giả danh gửi. Khi đó Mallory có nhiều thời gian để thực hiện tấn công dựa trên phản hồi có độ dài cố định.
2.7.3. Tấn công replay khi máy chủ và máy slave tách biệt
Có lỗ hổng bảo mật trong trƣờng hợp máy chủ ACE và máy slave tách biệt. Khi Alice đăng nhập vào máy sdshell, máy sdshell sẽ gửi một truy vấn đến máy chủ ACE để xác thực Alice.
Máy chủ ACE sẽ kiểm tra và gửi lại kết quả xác thực ngƣời dùng. Máy ACE slave sẽ đƣợc sử dụng khi máy chủ ACE có vấn đề.
Khi vấn đề xảy ra một trong hai máy này sẽ khóa file của máy còn lại, không cho phép thay đổi các tài khoản đã có hoặc thêm mới các tài khoản ngƣời dùng trong hệ thống. Đồng thời máy còn lại hoạt động tốt sẽ chịu trách nhiệm trả lời các truy vấn của máy sdshell.
Giữa máy chủ ACE và máy slave có một kết nối gọi là hearbeat để thực hiện đồng bộ hóa giữa hai máy này.
Tình huống:
1/.Tập hợp các máy sdshell đang liên lạc với máy chủ ACE để xác thực mã token
2/.Một tập hợp các máy sdshell khác cũng đang liên lạc với máy chủ ACE để xác thực mã token.
3/.Máy chủ ACE
5/.Máy slave của máy chủ ACE
Giả sử kết nối giữa nhóm B và máy chủ ACE bị mất. Khi đó máy slave sẽ đƣợc sử dụng để xác thực mã token cho các máy sdshell ở nhóm B.
Trong khi đó, máy chủ ACE vẫn thực hiện việc xác thực mã token cho các máy sdshell ở nhóm A. Mallory sẽ nghe lén kết nối của một máy trong nhóm A, thực hiện các tấn công nhƣ Denial of service và thực hiện đăng nhập vào hệ thống bằng chính tài khoản và mã token của máy đó trên nhóm B. Khi đó Mallory sẽ đƣợc xác thực bởi máy slave.
Có thể khắc phục lỗ hổng bảo mật này bằng cách nhƣ sau:
Khi kết nối heartbeat giữa máy chủ ACE và máy slave bị mất, cả hai máy này sẽ chuyển sang chế độ next-token với một máy mặc định là next-token cộng 1.
Với mã token thứ nhất mà Mallory nghe lén đƣợc sẽ đƣợc xác thực, nhƣng sau đó hệ thống sẽ yêu cầu Mallory nhập tiếp token thứ hai khác với token thứ nhất nghe lén đƣợc. Trong trƣờng hợp này Mallory sẽ khó có thể đăng nhập vào hệ thống đƣợc.
Security Dynamic đã nhận ra đƣợc nhƣợc điểm này và khắc phục, tuy nhiên lỗ hổng này vẫn không đƣợc giải quyết triệt để.
2.7.4. Hiểm họa trong giao tiếp giữa máy chủ ACE và máy khách
Khi một ngƣời dùng kết nối vào máy khách và nhập tên ngƣời dùng, mã token, có một vài giao tiếp sẽ xảy ra nhƣ sau.
Khi ngƣời dùng khởi tạo kết nối với mày khách, máy sdshell sẽ gửi một gối tin UDP đến máy chủ ACE, máy chủ ACE sẽ xác nhận gói tin này với một gói tin thời gian.
Khi ngƣời dùng nhập tên tài khoản và mã token sau đó ấn ENTER, máy sdshell sẽ gửi một gói tin chứa tên tài khoản và 64 bit WP đầu tiên. Máy chủ ACE nhận đƣợc gói tin sẽ giải mã gói tin để xác thực ngƣời dùng. Nếu hợp lệ, máy chủ ACE sẽ gửi một gói tin xác nhận đƣợc mã hóa bởi chính 64 bit WP nhận đƣợc.
Trong giao tiếp này có một lỗ hổng bảo mật khi sử dụng giao thức UDP vì giao thức này truyền dữ liệu không đáng tin cậy và không lƣu trạng thái nên có thể dễ dàng thay đổi và đƣợc truyền đi trên mạng.
Gói tin thời gian sẽ đƣợc mã hóa DES bằng khóa DES mà máy khách gửi tới. Máy khách giải mã gói tin, lấy thông tin thời gian trong gói tin này cùng với mã token và địa chỉ IP của máy khách để tạo ra một xâu băm 256 bit bằng thuật toán nhƣ sau:
256bit_result = f2(time,hashcode, IP);
Xâu băm này sẽ bao gồm bốn 64bit chunk, đƣợc gọi là khóa WP.
Sau khi tính toán đƣợc khóa WP này, máy khách gửi thông tin tên tài khoản cùng với 64 bit đầu của khóa WP đến máy chủ.
Máy chủ sau khi nhận đƣợc gói tin, bóc tách mã token và địa chỉ IP của máy gửi để tính hàm f2 và tìm đƣợc một xâu 256 bit, sau đó lấy 64 bit đầu của xâu này so sánh với 64 bit WP nhận đƣợc của máy khách, nếu hai thông tin này khớp nhau máy chủ xác thực ngƣời dùng là hợp lệ. Sau đó máy chủ sẽ gửi lại gói tin OK sử dụng 64 bit thứ hai làm khóa để mã hóa DES gói tin.
Bởi vì các tham số của hàm f2 là hoàn toàn có thể đoán đƣợc nên Mallory có thể tính đƣợc xâu 256 bit và gửi một gói tin chứa tên tài khoản ngƣời dùng và
64 bit đầu WP cho máy chủ. Máy chủ tính toán thông tin và xác nhận yêu cầu là đúng, gửi lại gói tin OK để xác thực Mallory. Trong trƣờng hợp nếu Mallory biết nội dung của gói tin OK, Mallory có thể tính toán khóa WP trƣớc khi đăng nhập và có thể thực hiện tấn công Denial of service.[5]
Chương 3. CÀI ĐẶT HỆ THỐNG ĐẢM BẢO AN TOÀN TRUYỀN TIN CHO VINAPHONE
3.1. LỜI MỞ ĐẦU
Thời báo Kinh tế Sài Gòn Online ngày 25/11/2009 có đăng bài ―Doanh
nghiệp còn thờ ơ với an toàn thông tin‖ với nội dung đƣợc trích lại nhƣ sau:
[Ông Trần Văn Hòa, Trưởng phòng phòng chống tội phạm công nghệ cao, Cục cảnh sát điều tra tội phạm kinh tế thuộc Bộ Công an, cho biết hiện các doanh nghiệp còn thờ ơ với công tác an toàn an ninh thông tin.
Tại hội thảo Ngày an toàn thông tin Việt Nam 2009 vừa được tổ chức tại Hà Nội, ông Hòa cho biết hiện đa số các doanh nghiệp đều có website để cung cấp thông tin và dịch vụ trên mạng nhưng lại chưa xây dựng những giải pháp bảo vệ an ninh thông tin.