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.