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 x́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ể đốn trước và dự đố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ự đố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 tố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ể đố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ự đố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.
3.2.4 Cơ lập dữ liệu
Theo chương 2, chúng ta sử dụng mã hóa MD5 để mã hóa đường dẫn logical của Object, sau đó dựa vào phương pháp dịch bit để có được thơng tin về partion sẽ được lưu Object đó thơng qua vịng Ring.
Với mã hóa hồn hảo thì với mọi đường dẫn sẽ được mã hóa cho ra một giá trị tuyệt đới không trùng lặp với các giá trị khác. Tuy nhiên với mã hóa MD5 sử dụng 16 bytes và độ dài giá trị mà tùy ý. Do đó khơng có gì đảm bảo rằng có hai đường dẫn khác nhau và có một giá trị hash sau khi mã hóa.
57
1. Tài khoản A tải lên FileA trong containerA 2. Tài khoản B tải lên FileB trong containeB
3. Tài khoản B tải xuống fileB nhưng nhận được fileA
Việc trên xảy ra khi chức năng mã hóa MD5 đã cho ra 1 giá trị trong khi mã hóa 2 đường dẫn khác nhau.
1. Khi server được yêu cầu lưu trữ fileA trước tiên nó kiểm tra thơng tin đăng nhập userA. Sau khi xác nhận rằng UserA có quyền tải file lên ContainerA. Nó cho phép tải lên
2. Sau đó, chức năng mã hóa sẽ mã hóa đường dẫn /accountA/containerA/FileA.
3. Dựa vào phép dịch bit số thứ tự của partion sẽ được tính.Khi đó đường dẫn vậy lý của ObjectA là Object/Bit arithmetic/def/hash code.
4. AccountB tài lên cũng tương tự như AccountB. Do giá trị mã hóa giớng nhau lên số partion cũng giống nhau, dẫn đến đường dẫn vật lý giống nhau. Và theo như quy định, Object có timedate cũ hơn sẽ bị xóa.
5. Cuối cùng khi AccountA tải x́ng fileA nó sẽ nhận được FileB thay vì fileA như ban đầu.
Các nhà phát triển đã nhận ra được các mối đe dọa này nếu người tấn công tìm ra được các đường dẫn mà mã MD5 mã hóa ra cùng giá trị thì sẽ tiến hanh tải file lên và do đó dữ liệu cũ của khách hàng khác sẽ bị xóa. Thực tế cho thấy khả năng mã hóa MD5 cho ra cùng giá trị với các đầu vào khác nhau là 0.1% [11] tuy nhiên với các cơng ty lớn như Gmail thì một ngày có rất nhiều email được gửi đó. Do đó khả năng của 0.1% là rất lớn.
Thêm nữa là chức năng hash của Openstack dễ dàng được tìm thấy trong tệp cấu hình ở đường dẫn sau:
58
Hình 41 Cấu hình mã hóa MD5
Dựa vào hình 40 chúng ta thấy Keystone đã sử dụng đường dẫn cho các Container, Object… và giá trị Hash_Path_Suffix để tránh lỡi hổng MD5 có thể bị khai khác.
Chúng ta thử nghiệm việc thay đổi cách mã hóa MD5 này thì hệ thớng khơng thể truy cập được vào các Container.
Hình 42 Trước khi thay đổi chức năng Md5
Sau khi thay đổi chức năng MD5 thì Openstack đã không thể kiểm tra được thư mục được tạo trước đó.
Hình 43 Sau khi thay đổi chức năng MD5
Để ngăn chặn việc này chúng ta thêm một giá trị khác vào đường dẫn logical của Object trước khi đem đi mã hóa gọi là Hash_Path_Prefix. Cho dù một người tấn
59
cơng có thể dò ra được các đường dẫn có giá trị mã hóa giớng nhau, tuy nhiên Openstack lại thêm của Hash_Path_Prefix nên giá trị mã hóa lúc đó sẽ khác nhau. Bởi vì người tấn cơng khơng thể biết được Hash_Path_Prefix
Hình 44 Giá trị Hash_Path_Prefix trong tệp cấu hình
Việc tiếp theo đó chính là Hash_Path_Prefix cần được bí mật. Tuy nhiên thơng sớ này hiện đang được cấu hình trong tệp đính kèm và có thể đọc dưới dạng ký tự nên có khả năng bị tấn cơng.
Trong việc phân tích vấn đề này chúng ta đưa ra các khuyến nghị sau:
Người quản trị hệ thớng phải đảm bảo rằng tệp cấu hình /etc/swift/swift.config phải được bảo vệ trước việc thay đổi nội dung. Kèm theo đó một bản sao lưu cũng được lưu ý tới. T Nếu giá trị Hash_Path_Prefix mà bị thay đổi thì các dữ liệu được tải lên Openstack Object trước đó sẽ khơng thể truy cập, lúc đó nếu chúng ta có bản sao lưu của Hash_Path_prefix thì mới có thể khơi phục được dữ liệu.
3.3 Kết luận
Trong chương này chúng ta đã triển khai thành công Openstack cũng như các dịch vụ của nó. Kèm theo đó chúng ta đã kiểm thử một số vấn đề an ninh cấp thiết trong Openstack:
Vấn đề về tấn công Injection:
Injection đang được Openstack xử lý khá tốt, không thấy bất kỳ mối đe dọa nào. Tuy nhiên các nhà phát triển cần nhận thức về việc sử dụng truy vấn sơ khai RawQuery
Vấn đề mật khẩu:
Openstack quản lý mật khẩu chưa tớt và có rất nhiều vấn đề cần được cải thiện như mã hóa mật khẩu hệ thống, yêu cầu độ mạnh mật khẩu cho user. Kèm
60
theo đó luận văn cũng đã đưa ra các khuyến nghị nhằm khắc phục tình trạng này như sử dụng Regex và Hacklib.
Vấn đề Token:
Qua phân tích các Tokens thu được và mã nguồn ta có thể thấy được Token có tính ngẫu nhiên cao, rất khó để đốn được Token. Điều cần cải thiện đó là cập nhập thêm các bản UUID mới và có thuật tốn ngẫu nhiên tớt hơn.
Vấn đề lưu trữ dữ liệu.
Openstack đã khắc phục khá tốt lỗi của MD5 bằng cách thêm trường Hash_Path_Suffix tuy nhiên lại không quản lý tốt tệp này.
Luận văn khuyến nghị các nhà quản trị nên sử dụng các modul mã hóa kèm theo đó tạo bản sao lưu trong trường hợp cần phục hồi.
61
KẾT LUẬN
Trong luận văn này tơi đã phân tích một số các vấn đề an ninh trong Openstack, đưa ra các vấn đề an ninh cần được chú ý, đảm bảo khi sử dụng các dịch vụ đám mây. Trong quá trình thực hiện, tôi đã tìm hiểu các tài liệu được cung cấp bởi các tổ chức lớn như CSA, ENISA, NIST và lập ra danh sách các vấn đề an ninh được sử dụng khi đánh giá các giải pháp đám mây Openstack.
Tiếp theo, luận văn đã thực hiện các phân tích về quản lý truy cập và định danh trong Openstack, bao gồm: Quá trình định danh, xác thực, điều khiển truy cập và ủy quyền cũng như dữ liệu trong Openstack. Kèm theo đó là các kết quả tìm ra các vấn đề an nình hiện hữu như: Tấn cơng Injection, độ mạnh yếu và bảo vệ mật khẩu, vấn đề an ninh token, cô lập dữ liệu giữa các người dùng.
Openstack hiện đang phát triển rất nhanh mỡi 6 tháng một bản update mới. Do đó cơng việc trong tương lai sẽ đánh giá các bản update mới này, với các project mới cũng được đưa ra như Heat, Ceilometer, Trove[28]. Thêm nữa các vấn đề an ninh được đưa ra trong chương 1 và 2 sẽ được tiến hành kiểm thử thêm ngoài các vấn đề cấp thiết đã được phân tích trong chương 3.
62
TÀI LIỆU THAM KHẢO
[1] Cloud Security Alliance. About Cloud Security Alliance. https://cloudsecurityalliance.org/about/
[2] The European Union Agency for Network and Information Security https://www.enisa.europa.eu/about-enisa
[3] The National Institute of Standards and Technology https://www.nist.gov/about-nist
[4] G. Brunette and R. Mogull. Security Guidance for Critical Areas of Focus in Cloud Computing, Version 2.1. Technical report, Cloud Security Alliance, December 2009.
http://www.cloudsecurityalliance.org/guidance/csaguide.v2.1.pdf
[5] D. Catteddu and G. Hogben. Cloud Computing Security Risk Assessment. Technical report, European Network and Information Security Agency, November 2009.
http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-risk- assessment/at_download/fullReport
[6] E. Brown. Cloud Computing at NIST: Two New Draft Documents and a Wiki http://www.nist.gov/itl/csd/cloud-020111.cfm
[7] NIST. NIST Cloud Computing Collaboration Site
http://collaborate.nist.gov/twiki-cloud-computing/bin/view/CloudComputing/
[8] W. Jansen and T. Grance. Guidelines on security and privacy in public cloud computing. Technical report, National Institute of Standards and Technology, January 2011. Draft Special Publication 800-144.
http://csrc.nist.gov/publications/drafts/800-144/Draft-SP-800-144_cloud-computing.pdf. [9] Tombstone (data store)
https://en.wikipedia.org/wiki/Tombstone_(data_store)
[10 P. Leach, M. Mealling, and R. Salz. RFC 4122: A Universally Unique IDentifier (UUID) URN http://www.ietf.org/rfc/rfc4122.txt
[17] Security of Django
https://docs.djangoproject.com/es/1.9/topics/security/ [18] SQLmap for injection testing
http://sqlmap.org
[19] Hashlib - secure hashes
http://docs.python.org/library/hashlib.html [20] Electronic Authentication Guideline
63
[21] Password validator
http://docs.openstack.org/developer/horizon/topics/settings.html#password-validator [22] Python-crack
https://pypi.python.org/pypi/python-crack/0.5 [23] OWASP. WebScarab Project
https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project [24] PortSwigger Web Security. Burp Sequencer.
https://portswigger.net/burp/sequencer.html [25] Reverse proxy
https://github.com/wunderlist/moxy
[26] Ubuntu Manpage: random, urandom - kernel random number source devices.
http://manpages.ubuntu.com/manpages/xenial/en/man4/random.4.html [27] OpenStack Swift and the hash_path_suffix