Messages posted by: khuongduybui

Nhock_Coi wrote:

Em đã làm như anh hướng dẫn...Nhưng khi Up lên host xong rồi em tiến hành gõ vô trình duyệt để chạy với đường dẫn như thế này mydomain/upload/view.pl ( my domain là hos của em ) thì nó tự động tải 1 file view.pl về chứ nó không hiện ra trang gì cả anh ạ

Cái này là vì một (vài) trong nhũng lý do sau
1: host của bạn không hỗ trợ Perl CGI
2: chmod không đúng hoặc .htaccess không cho execute file .pl trong chỗ bạn đang để file, đặc biệt là các thư mục "upload".
3: đường dẫn đến Perl CGI của host không giống mặc định, nên file view.pl không được parsed mà bị coi như resource
Bạn đổi tên nó thành .php thì càng ngớ ngẩn hơn, tất nhiên nó không chạy được rồi.
Nói chung bạn nên học cơ bản về lập trình web trước khi hack web đi.

chiro8x wrote:

guard_dawn1403 wrote:
Dùng lệnh
Code:
net localgroup administrator tên_username /add
để đưa user name vào nhóm admin rùi remote
Còn chuyện firewall chặn các kết nối tới cổng của REMOTE DESKTOP thì sao . Việc này rất thường gặp.

Mình không hiểu sao bạn lại hỏi điều này, hỏi đố chăng? (nên không ai trả lời bạn).
1. Vì bạn hỏi cách "hack" để remote desktop, nên mình cho rằng bạn đang can thiệp trực tiếp vào máy chủ (ngồi ngay tại đó, xài bàn phím, con chuột của nó). Nếu không thì bạn đang làm gì, telnet hay gì, ít nhất phải nói rõ chứ?
2. Theo mình biết thì để chạy được câu lệnh set quyền 1 user nào đó thành admin, bạn phải đang đăng nhập dưới tài khoản của 1 admin, nếu vậy thì còn "nâng quyền" cái gì nữa? Có chăng là tạo backdoor?
3. Nếu bạn thật sự, bằng cách nào đó, "nâng quyền" thành công và có 1 tài khoản admin đường đường chính chính, thì bạn cứ đăng nhập vào, gọi chương trình Firewall lên (bạn không nói rõ thì ai biết nó là chương trình nào mà chỉ?) rồi mày mò cách mở port, nếu chương trình Firewall đòi mật mã để chỉnh sửa thì bạn xui rồi, google tên,và version của nó coi có cách nào không hoặc lập chủ đề khác hỏi thăm mọi người, nhưng nói chung chuyện đó thì chả liên quan gì đến việc "nâng quyền" admin nữa.

Vậy nhé, chúc may mắn.

Cái Timing Attack này nghe qua cũng thú vị nhưng nó chẳng qua là một kiểu bruteforce, chỉ cần mã hóa cẩn thận chút và thay đổi mã thường xuyên thì nó mò cả đời cũng không ra. Có nguy hiểm chăng là người ta có thể lợi dụng nó để DOS hệ thống của bạn.
Mà điều này thì đã thuộc vào chống SQL injections rồi nên mình thấy chỉ cần escape string là được, không cần mấy cái regexp rắc rối này, trừ khi bạn định để cho users trực tiếp nhập SQL queries vào ( :O )

x_cuibap_x wrote:

Chuyện là thế này:
có 1 pro nào đó chú ý e. anh ấy pm yahoo và hỏi thăm vài câu (giống điều tra). xong anh ấy gửi cho 1 file rar bảo là xem tin nhắn mà ko cần log in (???), xong e cũng nhận vì cứ nghĩ là không run thì cũng chã sao. khi nhận xong rồi e cũng open file rar thử (trong đó có file exe, và xml hay gì đó, open rar thì đâu có sao nhỉ?). Một lúc sau anh ấy pm hỏi bạn xem gì trong HVA thế nhỉ? mình cũng giật mình. tuy nhiên hiện tại thì đã tắt HVA ==> chắc anh ấy không hoàn toàn theo dõi được e? nhưng thế cũng nguy hiểm quá. các anh cho hỏi anh ấy đã dùng "skills" nào vậy ạ?
e cám ơn ạ!

Nói khơi khơi như bạn thì khó đoán được anh ta dùng "skill" gì lắm, có khi là skill "chém gió" hù bạn không chừng smilie

)
Nhưng mình có lời khuyên thế này, thái độ liều lĩnh của bạn khá nguy hiểm đó. Đầu tiên bạn nghĩ nhận mà không mở thì đâu có sao, rồi nhận xong bạn lại nghĩ mở file .rar thì đâu có sao... Vậy một trường hợp nào đó bạn nghĩ "không có sao" nhưng thật ra có mà bạn chưa biết đến thôi thì làm thế nào?
Để thoả mãn sự tò mò "xem có sao không" như trên, theo mình tốt nhất là bạn chat / duyệt web trên một máy tính riêng, cũ thôi cũng được, chỉ dùng để "thử", có hư cũng không sao. Đúng là chỉ nhận file mà không mở thường thì không có vấn đề gì, nhưng nhận xong rồi thì bạn nên cô lập máy tính đó đi, ngắt tất cả các mạng và các đĩa USB đang cắm, rồi hãy "mở thử" xem có gì không. Trong trường hợp bạn chỉ có 1 máy, dùng các biện pháp cô lập như sandboxie hay máy ảo cũng được, nhưng vẫn không an toàn bằng dùng 1 máy tính thật không kết nối mạng với ai, không chứa dữ liệu riêng tư gì, hư thì mình nó hư thôi.
Tuy nhiên cũng có 1 điểm lưu ý, là khi bạn nhận file qua Yahoo thì bạn đã mở một connection p2p, cái file bạn nhận có thể sẽ không có vấn đề gì, dù có cũng chưa được kích hoạt nếu bạn còn chưa mở nó ra, nhưng cái connection này thì có thể bị lợi dụng. Ngoài việc như có người đã nói là người ta thấy External-IP của bạn, có khi người ta còn có thể thông qua cái port đang open này mà thực hiện những tấn công khác. Cái này thì hên xui tuỳ mức độ bảo vệ của mạng nhà bạn như nào, nhưng nói chung không phải là không có rủi ro.
Nói chung nếu bạn cứ mang cái tâm lý "chắc đâu có sao" đó mà không thường xuyên cập nhật tin tức về các lỗ hổng bảo mật mới thì đi đêm có ngày gặp ma thôi.

Không phải nói cách của bạn không hiệu quả, mà thật ra là vầy. Bạn xem lại ngay bài đầu tiên của chủ đề người ta đã nói.
Không chỉ dùng <? include('config.php') ?>, một số trang web còn dùng hàm include tự động cho các pages khác, ví dụ như $page hay 1 biến nào đó. Thí dụ như URL là "/index.php?module=blog" thì sẽ include(blog.php), nếu URL là "/index.php?module=gallery" thì sẽ include(gallery.php)...
Như vậy nếu trang web code không kỹ, chỉ để là <? include($_GET['module'].'.php') ?> thì người ta sẽ lợi dụng điểm này, dùng URL là "/index.php?module=a_secret_file" để lấy được nội dung của cái "a_secret_file.php", ví dụ vậy. Cụ thể thì bạn xem lại bài viết ở trên mình không nhắc nữa.

Còn theo mình, nguyên tắc chung của security là blacklist hơn ở chỗ tiện dụng, whitelist hơn ở chỗ an toàn. Nếu là mình code trang kia, mình sẽ làm vầy.
Code:

<?php
$whitelisted_modules = {'blog', 'gallery', 'config', 'contact', 'about'};
if(in_array($_GET['module'],$whitelisted_modules))
{
include($_GET['module'].'.php');
}
else
{
//lưu vào log detected intrusion attempt, gồm timestamp, $_GET['module'], Client IP, Cookie content, ...
//hiện thông báo lỗi
//wwwect về trang chủ hoặc khoá IP hiện tại của client tuỳ admin strict tới cỡ nào
}
?>

leanhthuong wrote:

Hay quá! em có 1 chuỗi như đây bác dịch giúp em được không?E chẳng biết dịch từ đâu
@%^%@144@#^#@422822023523722722223023223323523822722622627323922422622122627622123627122822422922627122223323627727122527827827922323527822123722023323422126.

nhìn kiểu này thì chắc là mấy kiểu mã hoá "homebrewed" (tự đặt) rồi, mấy cái @%^%@ và @#^#@ chắc là delimiter thôi.
Nhìn số 144 đứng riêng lẻ thì ta có thể phỏng đoán một vài khả năng về ý nghĩa của nó, nhưng khi copy đống số từ 4228... đến 2126 ra 1 file txt thì ta thấy size của nó đúng là 144 bytes. Vậy rất có khả năng số 144 này là package-size, vậy nó chả giúp ích gì được cho việc giải mã, đành phải mò mẫm từ con số 0.
Lại xem xét đống số kia, nếu may mắn thì là mã ASCII còn nếu không thì có thể là một dạng mật mã tự quy định nào đó. Nhưng khả năng nó là mã ASCII hơi khó vì ta đã biết mã ASCII cho các ký tự thường dùng vượt quá 99, nên nếu muốn dùng 1 chuỗi như vậy thường phải quy định cứ 3 digits vào 1 group, mà group đầu tiên là 422 đã vượt quá 255, hơn nữa tổng độ dài cũng không chia hết cho 3 --> đây là trường hợp thứ 2, một dạng mã hóa tự quy định nào đó.
Để giải quyết cái này, độ dài 144 bytes cũng có một số ý nghĩa nhất định vì nó chia hết cho 24, 36 và 72, một số thuật toán mã hóa sau này cũng lấy mấy độ dài không phải là lũy thừa của 2 như thế này để làm cho nó phức tạp thêm, nhưng chỉ dựa vào 1 chuỗi này rất khó phán đoán. Hơn nữa, các dạng mã hoá loại này thường cho ta 1 fixed-length output, mà đã fixed-length thì thường không phải thêm package-size vào trước làm gì nữa, cho nên có thể là phán đoán theo hướng này không chính xác, lần này gặp mã có độ dài 144bytes là trùng hợp thôi. Nhưng cũng có thể là người ta lo xa, sợ sau này đổi giải thuật nên cứ để phòng hờ vậy, hoặc cố tình tung hỏa mù, nói chung rất khó đoán.
Tốt hơn hết là tìm thêm vài chục cái ví dụ như vậy nữa, kết hợp với dự đoán nội dung của package, là 1 string message, hay 1 hash tag, hay cái gì gì rồi mới tìm ra được pattern. Chớ còn chỉ dựa vào 1 sample này mà bro nào phá được thuật giải của người ta thì mình ngả mũ bái phục.

duongtnhat wrote:

Theo em biết thì dùng:
Code:
<?php
$include = "config.php";
include($include);
?>
Thay vì:
Code:
<?php
include("config.php");
?>
Cũng không bị lỗi trên (em đọc trong tài liệu nhưng cũng chưa thử bao giờ lên không biết kết quả ra sao)

Nếu bạn đã ghi thẳng là Code:

<? include('absolute_file_name.php'); ?>

thì sẽ chẳng có vấn đề gì đâu. Người ta chỉ khai thác được khi bạn truyền vào trong hàm include 1 tên biến, ví dụ $include, mà tên biến này có thể bị override từ trong URL query.
Còn cách giải quyết như bạn nói, khai báo $include ngay trước khi dùng, thì cũng tránh được URL query exploit, nhưng không khác gì so với bỏ string vào thẳng trong hàm include().