Vấn đề an ninh Token

3.2 Phân tích các vấn đề an ninh trong Openstack và đưa ra giải pháp,

3.2.3 Vấn đề an ninh Token

Token được cấp phát cho người dùng khi họ đã được xác thực bởi Keystone và người dùng sẽ dùng Token để làm việc với các project. Việc phân tích các vấn đề an ninh của Token có thể tránh được các tấn công đạt được Token từ những Token trước đó. Giờ đây Token đã được bảo vệ rất tốt khi truyền từ server xuống client thông qua SSL. Do đó chúng ta cần phân tích đó chính là cơ chế tạo ra Token ngoài việc bảo đảm Token khi vận chuyển. Việc phân tích cơ chế tạo ra Token cũng sẽ phản ánh được độ khó, độ ngẫu nhiên của Token.

Để đánh giá phân tích Token chúng ta sử dụng 2 công cụ đánh giá là OWASP WebScarab [23]. WebScarab sẽ ghi lại các sessionID thông qua lời gọi HTTP sau đó chuyển đổi sang các số và đưa lên biểu đồ. Tuy nhiên Webscarab chỉ ghi lại SessionID từ HTTP header cho các ứng dụng Website thông thường trong khi Keystone sẽ trả về Token qua trường X-Subject-Token, do đó luận văn sẽ sử dụng một Proxy trung gian nhằm chuyển đổi Token thu được từ hệ thống xác thực keystone thông qua X-Subject-Token và đưa vào trường sessionID để WebScarad thu được và đánh giá. Một công cụ khác đó chính là Burp Sequencer từ PortSwigger [24].

Để đánh giá sự tạo Token chúng ta tiến hành phân tích kiểm thử như sau:

 Thiết đặt thời gian hết hạn của token xuống nhỏ nhất để có thể lấy được các Token khác nhau trong một thời gian ngắn

 Lấy được 100-10000 Token

 Phân tích các Token lấy được với OWASP WebScarab để kiểm tra có hay không các vấn đề trong các Token được tạo ra

 Phân tích tạo Token với Burp Sequenser để kiểm tra mức độ ngẫu nhiên giữa các Token được tạo dựa vào phân tích cấu tạo Token

51

Với OWASP WebScarab chỉ lấy thông tin từ Set-Cookie header và Response

body trong khi Token của Openstack được chứa trong trường X-Subject-Token, do

đó chúng ta cần sử dụng một phần mềm trung gian để lấy nội dung trường X- subject-Token để đưa vào trường Set-Cookie header cho OWASP WebScarab để sử dụng. Phần mềm này là Reverse proxy [25]

Hình 32 Chạy Reverse Proxy

Tiến hành chạy OWASP WebScarab và sử dụng chức năng SessionID Analysis

Hình 33 Phần mềm OWASP WebScarab

Dựa vào các hàm API của Openstack được cung cấp sẵn trong Keytone API[36], cho phép chúng ta sử dụng các hàm gọi HTTP thông qua POST và GET để lấy được các thông tin như Token… dựa vào các Header có tương ứng.

Điền thông tin của người dùng đế xác thực với hệ thống Keystone trong Openstack theo các tham số sau:

POST http://127.0.0.1:9562/v3/auth/tokens HTTP/1.0 Content-Type: application/json

Content-length: 403

52 Password: Welcome@123

Thông qua đoạn mã hàm gọi HTTP bởi API cho phép giao tiếp với Keystone để lấy Token [phục lục 1]. Chúng ta có thể xác thực với Keystone với tài khoản user và lấy được Token qua trường X-Subject-TokenĐoạn mã trên sử dụng URL của keystone với lời gọi HTTP 1.0 và cung cấp các thông tin đăng nhập. Ở đây chúng ta sẽ phân tích Token cho user có quyền Admin với thông tin đăng nhập là Admin và password: Welcome@123

Webcarab lấy được các Token dựa vào trường X-Storage-Token và sau đưa lên biểu đồ.

Hình 34 Một Token sau khi đã mã hóa MD5

Hình 34 là thể hiện một trong những Token mà phần mềm lấy được sau khi đã xác thực thành công với Keystone thông qua API. Do phần mềm không định sẵn trước header “Token” nên chúng đã đã dùng proxy trung gian nhằm chuyển đổi header “ Token” thành header “ JSESSIONID” một header thường dùng trong xác thự website.

53

Hình 35 Bảng giá trị và so sánh Tokens

Trong hình số 35 là tập hợp tất cả các Token mà phần mềm đã lấy được trong một khoảng thời gian. Cùng với đó là giá trị sau khi đươc chuyển đổi sang số của Token, sự so sánh sai khác giữa các giá trị Token. Chúng ta có thể thấy các giá trị Token khác nhau rất là nhiều. Giá trị sai khác rất lớn cho thấy được các Token được tạo ra là tốt, không có trường hợp các Token tạo ra trùng nhau hoặc sai khác ít trong cùng một khoảng thời gian gần nhau.

54

Tiếp theo chúng ta đưa các giá trị Token được mã hóa MD5 và chuyển đổi sang giá trị số lên đồ thị để có cái nhìn trực quan hơn. Đồ thị cho thấy các giá trị Token qua các mốc thời gian. Với đồ thị này nếu các nút đỏ biểu thị cho các Token mà càng gần nhau, nhóm thành các cụm thì các Token đó được tạo ra với giá trị gần giống nhau trong khoảng thời gian ngắn. Điều đó có nghĩa là những Token này rất dễ có thể đoán trước và dự đoán các Token tiếp theo nhờ vào các Token trước đó. Với hình 36 chúng ta thấy có rất ít các tụ điểm Token gần nhau. Chúng phân tán khá tốt trong khoảng thời gian ngắn cho thấy các Token này rất khó được dự đoán trước nhờ biết các Token trước đó.

Tiếp theo chúng ta sử dụng Burp Sequencer để kiểm tra chất lượng cũng như độ ngẫu nhiên của Token.

Hình 37 Phần mềm Burp Sequencer

Cũng giống như phần mềm trước đó, Burp Sequencer sẽ sử dụng URL của Keystone và sử dụng các hàm API để xác thực và nhận lấy các Token sau khi đã xác thực thành công.

Chúng ta tiến hành thu thập các Tokens qua việc cung cấp user/password. Các Tokens lấy được càng nhiều thì phân tích càng cho kết quả chính xác. Chúng ta kiểm thử bằng việc lấy 1000 tokens. Sau đó phân tích ta có kết quả như hình 38

55

Hình 38 Kết quả sau khi phân tích

Kết quả cho thấy chất lượng và độ ngẫu nhiên của các Tokens ghi nhận được là rất tốt. Token sử dụng có độ dài 950 ký tự. Với hình 39 sau khi đã tính toán các ký tự sai khác nhau trong các Token. Chúng ta có biểu đồ như hình, trên hình chúng ta có thể thấy được Token sử dụng 6 bit cho các giá trị cuối từ 610 đến 950 để thay đổi giá trị, 3 bit để thay đổi giá trị đầu. Chỉ một vài giá trị là giữ nguyên trong các Token được tạo ra. Với các thay đổi đó trong một thời gian ngắn, việc tạo ra các Token này khá là tốt, các giá trị Token sẽ sai khác nhau rất nhiều và khó có thể đoán trước, tính ngẫu nhiên của Token cũng cao.

Hình 39 Biểu đồ bit token

Sau khi phân tích các Tokens dựa vào việc sử dụng các công cụ, chúng ta đi vào phân tích tệp cấu hình dành cho việc khởi tạo các Tokens này. Tệp cấu hình chứa thông tin tạo Tokens là uuid.py tại:

56

Hình 40 UUID trong Keystone

Dựa vào mã nguồn có thể thấy Tokens được tạo ra dựa vào cơ chế tạo mã ngẫu nhiên UUID phiên bản 4. Theo RFC 4122 thì UUID phiên bản 4tạo ra các giá trị ngẫu nhiên dựa vào truly-random và Psedo-random[10].Theo RFC 4122 thì không giống các phiên bản khác, UUID 4 không chỉ bao gồm các giá trị ngâu nhiên và còn bao gồm cả giá trị thời gian, lock sequence gồm 6 bits. Kèm theo đó việc tạo Token sẽ tổng hợp gồm của UUID và cơ chế radom của Ubuntu [26].

Dựa vào các tài kiểm tra và phân tích trên đây chúng ta có thể thấy rằng việc tạo các Tokens là không thể được dự đoán trước, tính ngẫu nhiên của Token là khá cao và không có bất kỳ mối lo ngại an ninh, lỗ hổng nào được tìm thấy.