Lưu ý: Phần lớn lý thuyết được viết bằng Tiếng Anh, do vậy hãy đảm bảo mình có vốn tiếng Anh vững chắc hoặc xài từ điển nhé
Đầu tiên chúng ta sẽ đi qua 1 báo cáo về tình hình Web Application Attack trên toàn thế giới
- Các trang web viết bằng PHP có nguy cơ mắc lỗ hổng XSS cao hơn GẤP BA LẦN các web viết bằng ASP.NET
- Các trang Web sử dụng WordPress bị tấn công nhiều hơn 24.1% trong tất cả các website sử dụng CMS (Content Management System-Hệ thống quản lí nội dung)
- Các website bán lẻ chiếm 48.1% trong các mục tiêu của hacker
- Vào năm 2014 số cuộc tấn công đã tăng 44% so với năm 2013
- Server của Amazon (AWS-Amazon Web Server) chứa 20% các lỗ hổng đã được biết tới (CVE)
- Vào năm 2014 các cuộc tấn công lợi dụng lỗ hổng RFI tăng 24% so với năm 2013
Chúng ta sẽ xem 1 Web Applications hoạt động như thế nào
Tìm hiểu về các kiến trúc ở Clients, Business Layer, Web Server, Database Layer
Các stack về lỗ hổng bảo mật
Một số lỗ hổng bảo mật của Web Applications.
Trong đó những lỗ hổng sau đây là khá quan trọng và các bạn phải nắm chắc (TOP 10 OWASP)
- Injection. (SQL Injection, Command Injection,LDAP injection,CRLF injection, File Injection)
- Broken Authentication and Session Management
- Sensitive Data Exposure
- XML External Entity
- Broken Access Control
- Security Misconfiguration
- Cross-Site Scripting
- Insecure deserialization
- Using Components With Known Vulnerabilities
- Insufficient Logging and Monitoring
1. Injection
1.1 SQL Injection
Đầu tiên chúng ta sẽ tới với lỗ hổng SQL Injection
- Một lỗi có tỉ lệ bị hacker tận dụng rất cao, cho phép hacker chạy
các câu lệnh SQL từ trình duyệt và truy xuất nội dung của các bảng, cột chứa thông tin
quan trọng. (Như truy xuất Admin Password)
- Phân loại SQL Injection
1. SQL Injection :
– Cái này nói đến những cái lỗi thuộc về câu lệnh truy vấn SQL trực tiếp vào database và ta CÓ THỂ NHÌN
THẤY ĐƯỢC.
2. Blind SQL Injection :
– Ám chỉ những lỗi truy vấn đi sâu vào trong mệnh đề logic với database, tất nhiên là LOGIC THÌ KHÔNG
THỂ THẤY ĐƯỢC.
– Vì là LOGIC nên chỉ có 2 kiểu dữ liệu trả về TRUE hoặc FALSE. Nếu TRUE thì kết quả sẽ hiện ra còn FALSE
thì sẽ không hiện ra
3. Blind SQL/XPath Injection
– Cái loại này còn cáo hơn cả Blind..Nó cũng như Blind không hề có thông báo gì hết và chỉ có 2 giá trị trả
về TRUE hoặc FALSE nhưng áp dụng với các XMLDatabase ví dụ như DbXML, OraXML, XMLBase, ColdXML…
Các loak này sử dụng cấu trúc XPath để truy cập dữ liệu trong file XML
hiểu>
Một trang Web bị lỗi SQL Injection
Một Website bị SQL Injection đã bị khai thác show ra toàn bộ các cột trong Table Thanhvien. Trong đó chứa username và password của admin
1.2 Command Injection
- Một lỗ hổng tiếp theo cũng nằm trong thể loại Injection. Đó là Command Injection
- Ba hình thức phổ biến là Shell Injection, HTML Embedding và File Injection
- VD trong hình này, hacker đã sử dụng 1 trick nhỏ là 192.168.1.2 ; cat /etc/passwd có nghĩa là sau khi ping địa chỉ IP 192.168.1.2 thì source code web đã bị lỗi, cho phép thực thi tiếp câu lệnh cat /etc/passwd từ đó show ra nội dung file /etc/passwd (Một file khá nhạy cảm trong hệ thống)
1.3 File Injection
- Lỗ hổng File Injection
1.4 Lỗ hổng LDAP Injection
2. Lỗ hổng XSS (Cross-Site Scripting)
- Kỹ thuật XSS được thực hiện dựa trên việc chèn các đoạn script nguy hiểm vào trong source code ứng dụng web. Nhằm thực thi các đoạn mã độc Javascript
Website hình trên đã bị lỗ hổng XSS. Đoạn mã Javascript alert('Co lo hong XSS') Đã được thực thi, dẫn tới việc hiện popup báo Co Lo Hong XSS
- Phân loại lỗ hổng XSS: Có 3 loại Reflected XSS, Stored XSS và DOM-based XSS
- Reflected XSS: Ở kịch bản này, hacker sẽ gửi cho nạn nhân một URL có chứa đoạn mã nguy hiểm. Nạn nhân chỉ cần gửi request đến URL này thì hacker sẽ có được kết quả mong muốn. Cụ thể:
- Khác với Reflected tấn công trực tiếp vào một số nạn nhân mà hacker nhắm đến, Stored XSS hướng đến nhiều nạn nhân hơn. Lỗi này xảy ra khi ứng dụng web không kiểm tra kỹ các dữ liệu đầu vào trước khi lưu vào cơ sở dữ liệu (ở đây tôi dùng khái niệm này để chỉ database, file hay những khu vực khác nhằm lưu trữ dữ liệu của ứng dụng web). Ví dụ như các form góp ý, các comment … trên các trang web.
Reflected XSS và Stored XSS có 2 sự khác biệt lớn trong quá trình tấn công.
• Thứ nhất, để khai thác Reflected XSS, hacker phải lừa được nạn nhân truy cập vào URL của mình. Còn Stored XSS không cần phải thực hiện việc này, sau khi chèn được mã nguy hiểm vào CSDL của ứng dụng, hacker chỉ việc ngồi chờ nạn nhân tự động truy cập vào. Với nạn nhân, việc này là hoàn toàn bình thường vì họ không hề hay biết dữ liệu mình truy cập đã bị nhiễm độc.
• Thứ 2, mục tiêu của hacker sẽ dễ dàng đạt được hơn nếu tại thời điểm tấn công nạn nhân vẫn trong phiên làm việc(session) của ứng dụng web. Với Reflected XSS, hacker có thể thuyết phục hay lừa nạn nhân đăng nhập rồi truy cập đến URL mà hắn ta cung cấp để thực thi mã độc. Nhưng Stored XSS thì khác, vì mã độc đã được lưu trong CSDL Web nên bất cứ khi nào người dùng truy cập các chức năng liên quan thì mã độc sẽ được thực thi, và nhiều khả năng là những chức năng này yêu cầu phải xác thực(đăng nhập) trước nên hiển nhiên trong thời gian này người dùng vẫn đang trong phiên làm việc.
Từ những điều này có thể thấy Stored XSS nguy hiểm hơn Reflected XSS rất nhiều, đối tượng bị ảnh hưởng có thế là tất cả nhưng người sử dụng ứng dụng web đó. Và nếu nạn nhân có vai trò quản trị thì còn có nguy cơ bị chiếm quyền điều khiển web.
- DOM Based XSS
- Một kịch bản của CEH, tấn công XSS qua Email
- Thêm 1 số ví dụ về tấn công XSS
Dùng XSS cướp Cookie người dùng
Dùng XSS để gửi những yêu cầu không cần xác thực
XSS trong các bài blog
XSS trong các khung comment
3. Lỗ hổng CSRF
Tấn công CSRF: CSRF ( Cross Site Request Forgery) là kĩ thuật tấn công bằng cách sử dụng quyền chứng thực của người sử dụng đối với 1 website khác. Các ứng dụng web hoạt động theo cơ chế nhận các câu lệnh HTTP từ người sử dụng, sau đó thực thi các câu lệnh này.
Hacker sử dụng phương pháp CSRF để lừa trình duyệt của người dùng gửi đi các câu lệnh http đến các ứng dụng web. Trong trường hợp phiên làm việc của người dùng chưa hết hiệu lực thì các câu lệnh trên sẽ dc thực hiện với quyền chứng thực của người sử dụng.
Kịch bản tấn công CSRF
- Các bạn có thể tham khảo 2 ví dụ sau của toidicodedao
4. Sensitive Data Exposure
- Do vô tình hoặc cố ý. Admin đã để lộ ra một số thông tin "nhạy cảm" của website ra ngoài
Admin dump cơ sở dữ liệu rồi tống vào 1 folder với tên dễ đoán db=database. Lại còn chmod 755 dẫn tới việc hacker lao vào chôm toàn bộ CSDL về máy mà không ai biết
Vô số Google Dork để giúp chúng ta dò ra các file password bị đưa ra public
VD với dork inurl:wp-config -intext:wp-config "'DB_PASSWORD'" tôi có thể dò ra rất nhiều trang WordPress bị lộ config. Show rõ password database
5. Security Misconfiguration
- Gồm 3 vấn đề
- Server không cập nhật bản vá
- Sử dụng Software, các phương thức xác thực lỗi thời
- Kích hoạt nhều dịch vụ không cần thiết
- Ví dụ: Ta có một trang web như thế này
URL: http://192.168.1.6/mutillidae/index.php?page=installation.php
- Server bị lỗi ở phần Directory Browsing. Do vậy khi tôi thay đổi thành
URL: http://192.168.1.6/mutillidae/index.php?page=/etc/passwd
Nó sẽ show ra nội dung file /etc/passwd như đã trình bày ở trên nó là 1 file khá nhạy cảm trong server
6. Tấn công từ chối dịch vụ: (DOS)
- Một cuộc tấn công từ chối dịch vụ (tấn công DoS - viết tắt của Denial of Service) là một nỗ lực làm cho những người dùng không thể sử dụng tài nguyên của một máy tính. Mặc dù phương tiện để tiến hành, động cơ, mục tiêu của tấn công từ chối dịch vụ có thể khác nhau, nhưng nói chung nó gồm có sự phối hợp, sự cố gắng ác ý của một người hay nhiều người để một trang, hay hệ thống mạng không thể sử dụng, làm gián đoạn, hoặc làm cho hệ thống đó chậm đi một cách đáng kể với người dùng bình thường, bằng cách làm quá tải tài nguyên của hệ thống. Thủ phạm tấn công từ chối dịch vụ thường nhắm vào các trang mạng hay server tiêu biểu như ngân hàng, cổng thanh toán thẻ tín dụng và thậm chí DNS root servers.
- Một phương thức tấn công phổ biến kéo theo sự bão hoà máy mục tiêu với các yêu cầu liên lạc bên ngoài, đến mức nó không thể đáp ứng giao thông hợp pháp, hoặc đáp ứng quá chậm. Trong điều kiện chung, các cuộc tấn công DoS được bổ sung bởi ép máy mục tiêu khởi động lại hoặc tiêu thụ hết tài nguyên của nó đến mức nó không cung cấp dịch vụ, hoặc làm tắc nghẽn liên lạc giữa người sử dụng và nạn nhân.
- Tấn công từ chối dịch vụ là sự vi phạm chính sách sử dụng internet của IAB (Internet Architecture Board) và những người tấn công hiển nhiên vi phạm luật dân sự.
1. Winnuke :
2. Ping of Death :
3. Teardrop :
4. SYN Attack :
6. Smurf Attack :
7. UDP Flooding :
8. Tấn công DNS :
- Riêng về DDOS: Các bạn có thể tham khảo CEHv9 Module 09 nhé, có dịp ad sẽ trình bày trên blog này sau
7. Cookie Posioning
- Cookie là một khái niệm hết sức cơ bản mà ta được học khi mới lập trình web. Tuy nhiên, nếu
sử dụng không đúng cách, nó sẽ thành “mồi ngon” cho vô số hacker.
- Server và client giao tiếp với nhau thông qua giao thức HTTP. Đặc điểm của giao thức này là
stateless. Server không thể biết được 2 request có tới từ cùng 1 client hay không. Vì đặt điểm
này, cookie ra đời. Về bản chất, cookie là một file text nhỏ được server gửi về client, sau đó
browser lưu vào máy người dùng. Khi client gửi request tới server, nó sẽ gửi kèm cookie.
Server dựa vào cookie này để nhận ra người dùng.
- Cookie thường có name, value, domain và expiration:
- Name, đi kèm với value: Tên cookie và giá trị của cookie đó
- Domain: Domain mà cookie được gửi lên. Như ở hình dưới, cookies chỉ được gửi khi client truy cập website
- Expiration: Thời gian cookie tồn tại ở máy client. Quá thời gian này, cookie sẽ bị xoá.
- Cookie có thể bị lấy theo các con đường sau:
- Sniff cookie qua mạng: Sử dụng 1 số tool đơn giản để sniff như Fiddler, Wireshark, ta có thểchôm cookie của người dùng ở cùng mạng. Sau đó, sử dụng EditThisCookie để dump cookie này vào trình duyệt để mạo danh người dùng.
- Chôm cookie (Cookie thief) bằng XSS: Với lỗ hỗng XSS, hacker có thể chạy mã độc (JavaScript)ở phía người dùng. JS có thể đọc giá trị từ cookie với hàm document.cookie. Hacker có thể gửi cookie này tới server của mình. Cookie này sẽ được dùng để mạo danh người dùng.
- Thực hiện tấn công kiểu CSRF (Cross-site request forgery). Hacker có thể post một link ảnh như sau:
Trình duyệt sẽ tự động load link trong ảnh, dĩ nhiên là có kèm theo cookie. Đường link trongảnh sẽ đọc cookie từ request, xác nhận người dùng, rút sạch tiền mà người dùng không hề hay biết. Cách tấn công này có rất nhiều biến thể
8. Insecure Direct Object References
- Lỗ hổng này xảy ra khi chương trình cho phép người dùng truy cập tài nguyên (dữ liệu, file, thư mục, database) một cách bất hợp pháp, thông qua dữ liệu do người dùng cung cấp
- VD: Ở trong 1 trang web bán hàng. RL của một đơn hàng sẽ có dạng như
sau: http://shop.com/user/order/1230. Server sẽ đọc ID 1230 từ URL, sau đó tìm đơn hàng có ID 1230 trong database và đổ dữ liệu vào HTML. Thay 1230 bằng các giá trị từ 1 tới 2000. Hệ thống cứ thế mà đọc và hiển thị cho mình toàn bộ các đơn hàng có ID từ 1 tới 2000 (kể cả đơn hàng của các khách hàng khác).
- Có một vài vụ việc hi hữu, hacker scan được git repository nằm trên server. Truy cập git, hắn lấy được username, password của database và các thông tin quan trọng khác. Bạn đừng nghĩ là mình… hư cấu. Cách đây vài hôm, git của vietnamwork vẫn nằm public chễm chệ tại vietnamwork.com/.git/, không bảo mật gì! May mà gặp hacker “có tâm” đi ngang qua nên chưa có gì đáng tiếc xảy ra.
9. Using Components With Known Vulnerabilities
- Lỗi này có nghĩa là sử dụng những phần mềm, mã nguồn, hệ điều hành có những lỗ hổng bảo mật đã được public. Dẫn tới Exploit vào hệ thống
10. Improper Error Handling
- Lỗi này Có nghĩa là, thay vì chỉ show ra thông báo lỗi, thì lại show ra những thông tin nhạy cảm như source code, database, .....
11. Broken Authentication and Session Management
- Hệ thống xác thực và quản lí phiên người dùng bị hỏng, hoặc gặp vấn đề
12. Một số lỗ hổng khác trong giáo trình CEH
Tài liệu tham khảo
- Giáo trình CEHv9 EC-Council
- Bảo mật nhập môn - Phạm Huy Hoàng - Toidicodedao
- Một số các Website bảo mật trên Internet
