<![CDATA[Latest posts for the topic "[Thảo luận] Local exploitations"]]> /hvaonline/posts/list/8.html JForum - http://www.jforum.net [Thảo luận] Local exploitations xảy ra trên máy cục bộ (shared host hoặc dedicated server). Thứ nhì, thế nào là "xảy ra trên máy cục bộ"? a) Nếu kẻ tấn công có một cái unix shell (bash, csh...) như conmale@someserver$ và cái shell này có thể dùng để làm gì đó dung hại ngay trên server đang bị tấn công. b) Nếu kẻ tấn công có một cái php, asp, python, perl... script nào đó (còn gọi là shell nhưng shell này khác shell trên ở chỗ nó hoàn toàn hoạt động trên giao thức http và có tầng php, asp, python, perl... đứng giữa thay vì bash shell, c shell tương tác trực tiếp với hệ điều hành). Con "shell" này phải được upload và thực thi ngay trên server bị tấn công. Thứ ba, giới hạn có thể tấn công của từng dạng shell ở trên thế nào? 1) Nếu kẻ tấn công có một cái unix shell (như a) ở trên) thì tùy vào hệ điều hành bị bug cỡ nào và tùy mức độ thiết kế và quản lý server như thế nào. Nếu shell này chỉ cung cấp và dừng lại ở chủ quyền của một người dùng bình thường thì độ "tàn phá" sẽ hạn chế. Nếu hệ điều hành có lỗi hoặc độ thiết kế server lỏng lẻo thì có thể bị escalate thành root thì coi như là "game over". 2) Nếu kẻ tấn công có một cái shell (như b) ở trên) thì tùy và tính bảo mật của apache và mức độ tinh xảo của con shell ấy. Thứ tư, thử phân tích xem: I) Do đâu kẻ tấn công có một con shell như a) II) Do đâu kẻ tấn công có một con shell như b) Sau đó mới bàn tiếp, làm sao để không cho I) và II) xảy ra. Mời các bạn thảo luận.]]> /hvaonline/posts/list/23670.html#142620 /hvaonline/posts/list/23670.html#142620 GMT Re: [Thảo luận] Local exploitations /hvaonline/posts/list/23670.html#142625 /hvaonline/posts/list/23670.html#142625 GMT Re: [Thảo luận] Local exploitations /hvaonline/posts/list/23670.html#142631 /hvaonline/posts/list/23670.html#142631 GMT Re: [Thảo luận] Local exploitations /hvaonline/posts/list/23670.html#142650 /hvaonline/posts/list/23670.html#142650 GMT Re: [Thảo luận] Local exploitations

xnohat wrote:
Chẳng nhẽ nhất thiết phải có shell mới local exploit được ạ B-) Ta chỉ bàn về local exploit chứ có bàn về Leo thang đặc quyền đâu nhỉ :D 
- Đâu có ai nói phải có shell mới thực hiện được local exploitation đâu bồ, chỉ nói rằng bồ được quyền access (truy cập) vô hệ thống, ở mức độ nhất định - Nếu mọi cấu hình ở mức ứng dụng và hệ thống được coi là an toàn, thì bồ sẽ làm gì để thực hiện hiện local exploitation?]]> /hvaonline/posts/list/23670.html#142652 /hvaonline/posts/list/23670.html#142652 GMT Re: [Thảo luận] Local exploitations

xnohat wrote:
Chẳng nhẽ nhất thiết phải có shell mới local exploit được ạ B-) Ta chỉ bàn về local exploit chứ có bàn về Leo thang đặc quyền đâu nhỉ :D 
Đọc kỹ lại bài đầu tiên.]]> /hvaonline/posts/list/23670.html#142653 /hvaonline/posts/list/23670.html#142653 GMT Re: [Thảo luận] Local exploitations b) Nếu kẻ tấn công có một cái php, asp, python, perl... script nào đó (còn gọi là shell nhưng shell này khác shell trên ở chỗ nó hoàn toàn hoạt động trên giao thức http và có tầng php, asp, python, perl... đứng giữa thay vì bash shell, c shell tương tác trực tiếp với hệ điều hành). Con "shell" này phải được upload và thực thi ngay trên server bị tấn công.  
II) Do đâu kẻ tấn công có một con shell như b)  
Em nghĩ thường gặp nhất là kẻ tấn công chia sẻ mã nguồn (Music box, forums, CMS ...). Cứ cúi đầu up lên web server rồi sử dụng thì 99% dính chấu. =(( Ngăn ngừa: tìm hiểu kỹ trước khi sử dụng :x Thân]]> /hvaonline/posts/list/23670.html#142747 /hvaonline/posts/list/23670.html#142747 GMT Re: [Thảo luận] Local exploitations /hvaonline/posts/list/23670.html#144164 /hvaonline/posts/list/23670.html#144164 GMT Re: [Thảo luận] Local exploitations Môi trường bị "hack" này thường là: - Hệ điều hành: Linux - Web service: Apache (1.3.x 2.x) - PHP (4.x, 5.x) - Ứng dụng: các forums PHP-based, các web applications viết bằng PHP. - Shared hosting và dedicated servers.   Windows - IIS - ASP vẫn bị và nguy hiểm như thường mèn bro :d " Local attack "]]> /hvaonline/posts/list/23670.html#144253 /hvaonline/posts/list/23670.html#144253 GMT Re: [Thảo luận] Local exploitations

nhocbmt wrote:
Môi trường bị "hack" này thường là: - Hệ điều hành: Linux - Web service: Apache (1.3.x 2.x) - PHP (4.x, 5.x) - Ứng dụng: các forums PHP-based, các web applications viết bằng PHP. - Shared hosting và dedicated servers.  
Windows - IIS - ASP vẫn bị và nguy hiểm như thường mèn bro :d " Local attack " 
Cứ bàn thấu đáo trên LAMP trước, win+iis blah blah gì đó bàn sau để đỡ lẫn lộn]]> /hvaonline/posts/list/23670.html#144308 /hvaonline/posts/list/23670.html#144308 GMT Re: [Thảo luận] Local exploitations /hvaonline/posts/list/23670.html#144313 /hvaonline/posts/list/23670.html#144313 GMT [Thảo luận] Local exploitations

conmale wrote:
Môi trường bị "hack" này thường là: - Hệ điều hành: Linux - Web service: Apache (1.3.x 2.x) - PHP (4.x, 5.x) - Ứng dụng: các forums PHP-based, các web applications viết bằng PHP. - Shared hosting và dedicated servers. Thứ nhất, local exploitation do đâu mà có? Chìa khóa quan trọng nhất đó là: việc thực thi hành động exploit nào đó xảy ra trên máy cục bộ (shared host hoặc dedicated server). Thứ nhì, thế nào là "xảy ra trên máy cục bộ"? a) Nếu kẻ tấn công có một cái unix shell (bash, csh...) như conmale@someserver$ và cái shell này có thể dùng để làm gì đó dung hại ngay trên server đang bị tấn công. b) Nếu kẻ tấn công có một cái php, asp, python, perl... script nào đó (còn gọi là shell nhưng shell này khác shell trên ở chỗ nó hoàn toàn hoạt động trên giao thức http và có tầng php, asp, python, perl... đứng giữa thay vì bash shell, c shell tương tác trực tiếp với hệ điều hành). Con "shell" này phải được upload và thực thi ngay trên server bị tấn công.  
Theo em nghĩ "xảy ra trên máy cục bộ" có nghĩa là attacker có thể trực tiếp ra lệnh và sử dụng tài nguyên của máy tính bị hack như là đang ngồi trên máy tính đó. Do dó "local exploitation" xảy ra khi attacker có được công cụ ra lệnh trực tiếp cho hệ thống và lợi dụng công cụ đó để thay đổi phương thức làm việc của hệ thống. Công cụ này có thể là bash shell (trong trường hợp attacker có tài khoản), hoặc là shell script php, asp...

conmale wrote:
Thứ ba, giới hạn có thể tấn công của từng dạng shell ở trên thế nào? 1) Nếu kẻ tấn công có một cái unix shell (như a) ở trên) thì tùy vào hệ điều hành bị bug cỡ nào và tùy mức độ thiết kế và quản lý server như thế nào. Nếu shell này chỉ cung cấp và dừng lại ở chủ quyền của một người dùng bình thường thì độ "tàn phá" sẽ hạn chế. Nếu hệ điều hành có lỗi hoặc độ thiết kế server lỏng lẻo thì có thể bị escalate thành root thì coi như là "game over". 2) Nếu kẻ tấn công có một cái shell (như b) ở trên) thì tùy và tính bảo mật của apache và mức độ tinh xảo của con shell ấy.  
shell trong trường hợp 1 rõ ràng là có ưu thế hơn ở trường hợp 2. Lý do là nó ra lệnh trực tiếp cho hệ điều hành, có đầy đủ chức năng hệ thống cung cấp, và chỉ bị giới hạn bởi quyền hạn. Nếu có shell này với quyền root thì tốt quá rồi, còn nếu không thì attacker có thể lợi dụng shell để "leo thang đặc quyền". Tóm lại có shell này là có 1 lợi thế lớn. Con shell trong trường hợp 2 thì kém hơn vì nó bị bó buộc trong bản thân ngôn ngữ viết ra nó và cấu hình của webserver. Con shell này bị bó buộc và có thể coi là nó gián tiếp hơn trường hợp 1.

conmale wrote:
Thứ tư, thử phân tích xem: I) Do đâu kẻ tấn công có một con shell như a) II) Do đâu kẻ tấn công có một con shell như b) Sau đó mới bàn tiếp, làm sao để không cho I) và II) xảy ra. Mời các bạn thảo luận. 
Con shell 1 là do attacker bằng cách nào đó có được tài khoản (username + password) trên máy tính đó. Các cách có thể có: sniff đường truyền, lừa người dùng có bằng cách cài keylogger, lỗi phần mềm, social engineering... Con shell 2 thì em không biết nhiều lắm. Vấn đề em muốn hỏi: 1. Có bao nhiêu cách leo thang đặc quyền khi đã có con shell 1. Em mới biết 1 cách là tận dụng lỗi buffer overflow. 2. Con shell thứ 2 ta có thể có quyền hạn đối với máy tính bị hack đến đâu? ]]> /hvaonline/posts/list/23670.html#144347 /hvaonline/posts/list/23670.html#144347 GMT Re: [Thảo luận] Local exploitations

jforum3000 wrote:
Cho mình hỏi là ở các phần mềm forum nguồn mở thường có 1 file config.php để lưu thông tin cấu hình, file này thường hay được khuyên là hãy đổi sang một tên khác để tránh bị hack local attack, nhưng liệu giải pháp này có thật sự an toàn ko? Vì còn có 1 file khác lưu thông tin của file config.php đã được đổi tên, thường là common.php, nếu hacker local attack vào file common.php này thì sao, họ sẽ biết được tên của file cofig.php đã được đổi, như vậy việc đổi tên này cũng công cốc? Giải pháp tốt nhất là đổi tất cả các file .php? Như vậy thì thật là mệt quá. 
Đã là nguồn mở thì ai cũng có khả năng sử dụng, và soi xem nó có cái gì, lỗi nó nằm ở đâu. Do đó đổi tên hay không không phải vấn đề. Vấn đề ở đây là phương pháp phân quyền, phương pháp bảo vệ tài khoản của superuser, và phương pháp cấu hình webserver cụ thể thế nào để hạn chế attacker thay đổi nội dung file. Nếu attacker không có quyền xem, ghi file đó thì anh ta cũng đâu có làm được gì đâu. :) ]]> /hvaonline/posts/list/23670.html#144349 /hvaonline/posts/list/23670.html#144349 GMT Re: [Thảo luận] Local exploitations

jforum3000 wrote:
Đã là nguồn mở thì ai cũng có khả năng sử dụng, và soi xem nó có cái gì, lỗi nó nằm ở đâu. Do đó đổi tên hay không không phải vấn đề. Vấn đề ở đây là phương pháp phân quyền, phương pháp bảo vệ tài khoản của superuser, và phương pháp cấu hình webserver cụ thể thế nào để hạn chế attacker thay đổi nội dung file. Nếu attacker không có quyền xem, ghi file đó thì anh ta cũng đâu có làm được gì đâu. :)  
Vì mình có đọc được 1 đoạn cảnh báo bảo mật này ở một diễn đàn support phpBB như sau, liệu những tình huống này có thể xảy ra không?
Bình thường một kẻ cố truy cập trực tiếp tập tin config.php của bạn sẽ cho ra một trang trắng trên trình duyệt. Nhưng nếu giả sử trình biên dịch PHP trên máy chủ của bạn gặp sự cố (hoặc khi nâng cấp server, dịch vụ hosting thường tắt hết các trình biên dịch PHP), các tập tin PHP không còn được biên dịch để trả kết quả về trình duyệt người xem nữa, nó sẽ xuất ra "hết thảy những gì mình có" lên trình duyệt. Khi đó kẻ truy cập đó có thể xem tất tần tật tập tin config.php của bạn bằng trình duyệt. Dù không có chuyện gì xảy ra, một khi biết được tên tập tin config.php của bạn và vị trí của nó, kẻ tấn công bạn vẫn có thể sử dụng lệnh include() từ một nơi nào khác, "include" tập tin config.php trên máy chủ bạn rồi xuất ra các biến: $dbhost, $dbname, $dbuser và $dbpasswd trong tập tin kết quả của chúng. 
Mọi thứ đều có điều kiện của nó :D. Ở đây là khi máy chủ web không được cấu hình đúng như nó cần phải cấu hình nữa. Theo mình nghĩ lỗi khả năng xảy ra lỗi này không cao :). Hơn nữa từ đoạn trích trên mình còn thấy là tác giả của nó có vẻ gì đó mờ ám, phóng đại sự việc lên rồi, không tin được :D. Tốt nhất là bám sát chủ đề của anh conmale kẻo bị cảnh cáo đấy . Mình thấy bạn hơi bó hẹp phạm vi thảo luận. :P ]]> /hvaonline/posts/list/23670.html#144361 /hvaonline/posts/list/23670.html#144361 GMT Re: [Thảo luận] Local exploitations

conmale wrote:
I) Do đâu kẻ tấn công có một con shell như a)  
Theo em ở đây phân ra 2 trường về kẻ tấn công :Một là kẻ tấn công là một user trong hệ thống như vậy hắn sẽ có được 1 shell nào đó do root quy định khi tạo account.Hai là không phải user trong hệ thống,do kiến thức hạn hẹp nên em cũng không biết được trong trường hợp này hắn sẽ làm gì để có được 1 con shell,em nghĩ chắc hắn sẽ làm cách nào đấy để chôm được 1 tài khoản đăng nhập vào hệ thống---->Sẽ có được shell :D Khi đã có trong tay một shell và hắn vẫn đang đăng nhập như một user bình thường,thì đâu tiên em nghĩ hắn sẽ rất hăng hái để nâng quyền của mình lên là root hoặc tìm cách thực thi các lệnh mà với các đặc quyền của hắn không thực thi được.Hắn có thực hiện được ý định của mình không sẽ phụ thuộc vào hệ thống được thiết lập như nào với kiến thức hiện tại của mình thì theo em nó xoay quanh các trườn hợp như sau :Giả sử kẻ tấn công đang muốn thay đổi nội dung một file nào đó mà không phải là của hắn 1>Nếu hệ thống ấn định umask lỏng lẻo ,1 file do một user tạo ra mà user khác lại có quyền thay đổi nội dung file đó------>Game over 2>Trong trường hợp phương án 1 không thực hiện được,hắn sẽ nghĩ đến việc chmod file đó bằng sudo,nếu hắn có tên trong sudoer file và được ấn định là có quyền chạy chmod------>Game over 3>2 phương án trên đều không thực hiện đươc,thì em nghĩ hắn sẽ tìm trên hệ thống các script thỏa mãn các điều kiện:Script đó chạy dưới quyền của root và user có quyền ghi và thực thi script đó,nếu tìm được-------->Game over 4>Nếu hệ thống thuộc dạng "xe tăng húc không đổ ,đạn bắn không thủng": thì em nghĩ hắn sẽ xài đến cách là lợi dụng các lỗi của các binary.Nếu hệ thống đang dùng các chương trình với phiên bản cũ và chưa được vá lỗi thì theo em đây cũng là 1 cánh cửa cho kẻ tấn công thực hiện mục đích của mình. Không biết em có lạc đề không anh conmale :D ]]> /hvaonline/posts/list/23670.html#144473 /hvaonline/posts/list/23670.html#144473 GMT [Thảo luận] Local exploitations

Tal wrote:
.... Vấn đề em muốn hỏi: 1. Có bao nhiêu cách leo thang đặc quyền khi đã có con shell 1. Em mới biết 1 cách là tận dụng lỗi buffer overflow.  
BoF là một trong nhiều cách để leo thang đặc quyền và có lẽ nó là cách khó nhất, phức tạp nhất nếu như mình muốn tự tìm một soft nào đang chạy ở chủ quyền cao hơn chủ quyền của mình đang có và nó đang bị nguy cơ BoF (nếu dựa vào các bug track và shellcode có sẵn để BoF thì không kể). Ngoài BoF ra, có nhiều cách để leo thang dựa vào "mis-configuration" ví dụ như sudo set sai, executable script ở chế độ 777 và owned by root, script được cronjob thực thi và owned by root nhưng cho phép write.... Nói chung, một khi đã có một cái bash shell thì cơ hội bị escalate lên root khá cao.

Tal wrote:
2. Con shell thứ 2 ta có thể có quyền hạn đối với máy tính bị hack đến đâu?  
Con "shell" ở dạng php-based, asp-based, perl-based... dù có làm gì đi chăng nữa, nó chỉ có quyền thực thi y hệt như quyền đã gán cho account nào chạy web service (ví dụ nobody được dùng cho apache process, SYSTEM được dùng cho IIS...). Account nào dùng để gán cho web service thì các "shell" kia sẽ có quyền hạn tương tự. Nếu apache được chạy ở chế độ root và không được "drop privilege" sau khi đã tạo LISTENED port 80 (cần root để tạo hi-privilege port) thì con shell php nào đó được thực thi y hệt như root và nếu nó được thực thi như root thì... game over. Tất nhiên sẽ có một số lệ thuộc ở "tính năng" của con shell ấy khiến cho game over nhanh hay chậm và tất nhiên "cái game" này đi tới đâu tùy thuộc vào kiến thức và kinh nghiệm của người dùng "con shell" lúc ấy.]]> /hvaonline/posts/list/23670.html#145095 /hvaonline/posts/list/23670.html#145095 GMT Re: [Thảo luận] Local exploitations

pearltran wrote:

conmale wrote:
I) Do đâu kẻ tấn công có một con shell như a)  
Theo em ở đây phân ra 2 trường về kẻ tấn công :Một là kẻ tấn công là một user trong hệ thống như vậy hắn sẽ có được 1 shell nào đó do root quy định khi tạo account.Hai là không phải user trong hệ thống,do kiến thức hạn hẹp nên em cũng không biết được trong trường hợp này hắn sẽ làm gì để có được 1 con shell,em nghĩ chắc hắn sẽ làm cách nào đấy để chôm được 1 tài khoản đăng nhập vào hệ thống---->Sẽ có được shell :D  
Thông thường, shell có được là do đoán tên đăng nhập và password. Có rất nhiều công cụ viết sẵn để brute force SSH login và đây cũng là một cách "chiếm shell".

pearltran wrote:
Khi đã có trong tay một shell và hắn vẫn đang đăng nhập như một user bình thường,thì đâu tiên em nghĩ hắn sẽ rất hăng hái để nâng quyền của mình lên là root hoặc tìm cách thực thi các lệnh mà với các đặc quyền của hắn không thực thi được.Hắn có thực hiện được ý định của mình không sẽ phụ thuộc vào hệ thống được thiết lập như nào với kiến thức hiện tại của mình thì theo em nó xoay quanh các trườn hợp như sau :Giả sử kẻ tấn công đang muốn thay đổi nội dung một file nào đó mà không phải là của hắn 1>Nếu hệ thống ấn định umask lỏng lẻo ,1 file do một user tạo ra mà user khác lại có quyền thay đổi nội dung file đó------>Game over  
Không biết rõ hệ thống mình đang thâm nhập thì không cách gì có thể thâm nhập.

pearltran wrote:
2>Trong trường hợp phương án 1 không thực hiện được,hắn sẽ nghĩ đến việc chmod file đó bằng sudo,nếu hắn có tên trong sudoer file và được ấn định là có quyền chạy chmod------>Game over 3>2 phương án trên đều không thực hiện đươc,thì em nghĩ hắn sẽ tìm trên hệ thống các script thỏa mãn các điều kiện:Script đó chạy dưới quyền của root và user có quyền ghi và thực thi script đó,nếu tìm được-------->Game over 4>Nếu hệ thống thuộc dạng "xe tăng húc không đổ ,đạn bắn không thủng": thì em nghĩ hắn sẽ xài đến cách là lợi dụng các lỗi của các binary.Nếu hệ thống đang dùng các chương trình với phiên bản cũ và chưa được vá lỗi thì theo em đây cũng là 1 cánh cửa cho kẻ tấn công thực hiện mục đích của mình. Không biết em có lạc đề không anh conmale :D  
Những điểm trên có thể bàn rộng ra muôn trùng. Tùy hoàn cảnh, tùy ứng dụng, tùy cấu hình, tùy khả năng người thiết lập server và services. Thân mến.]]> /hvaonline/posts/list/23670.html#145111 /hvaonline/posts/list/23670.html#145111 GMT Re: [Thảo luận] Local exploitations commale wrote
II) Do đâu kẻ tấn công có một con shell như b)  
Vấn đề này thấy mọi người vẫn chưa bàn đến nên mình có 1 số ý kiến như sau: Thông tin google được Để đoạt được script shell thì theo mình kẻ tấn công cũng phải tìm username / password của account được gán cho script shell. Hoặc kẻ tấn công có thể tìm cách thực hiện những malicious code mà không cần thông qua shell ( ví dụ phpBB Remote PHP Code Execution http://www.securiteam.com/exploits/5QP0X00G0C.html Cái này chỉ là ý kiến riêng của mình Trong lúc tấn công, kẻ phá hoại có thể sử dụng cả 2 dạng shell để điều chỉnh tiến trình làm việc của hệ thống. Vd1: kẻ phá hoại bằng 1 trong 2 cách trên đã đoạt được tài khoản để điều khiển script shell và hắn dùng nó để tìm cách chiếm đoạt cả unix shell (bash, csh, ...). Cách cụ thể thì mình chưa tìm thấy ? ( Nhờ anh em đóng góp thêm ) Vd2: kẻ phá hoại đã đoạt được unix shell và hắn đang tìm cách đoạt luôn cả script shell. Theo mình trường hợp này khó xảy ra vì nếu đã đoạt được unix shell thì hắn cũng không cần phải tìm script shell làm gì, nhưng khó không có nghĩa là không thể. Kẻ tấn công đã có unix shell với quyền normal user, thay vì hắn tìm cách để leo thang đặc quyền ( priviledge escalation = BoF ) thì hắn dùng unix shell để tấn công và tìm account của script shell với chủ quyền cao hơn ( có nhiều quyền tác động vào hệ thống hơn ). Mình chỉ đưa ra những hướng tấn công còn cách tấn công cụ thể thì mình không rành lắm, ai có ví dụ cụ thể thì đăng thêm ? Vấn đề đặt ra: 1 . Đã sở hữu script shell, thì có những cách nào để tấn công và đoạt lấy cả unix shell ? Và tất nhiên là cách chống lại việc đó ? 2 . Có unix shell với tài khoản của normal user làm thế nào để khai thác tìm ra và điều khiển script shell ? Và làm thể nào để phòng tránh trường hợp đó. ]]> /hvaonline/posts/list/23670.html#145125 /hvaonline/posts/list/23670.html#145125 GMT [Thảo luận] Local exploitations

conmale wrote:
Tôi tạo chủ đề này ra vì nhận được khá nhiều người câu hỏi xoay quanh chủ đề "local exploitations" (còn gọi nôm na là "hack local") để anh chị em thảo luận cho rốt ráo bởi vì rất nhiều người vẫn còn lờ mờ với khái niệm "local hack" này và cách chống đỡ. Môi trường bị "hack" này thường là: - Hệ điều hành: Linux - Web service: Apache (1.3.x 2.x) - PHP (4.x, 5.x) - Ứng dụng: các forums PHP-based, các web applications viết bằng PHP. - Shared hosting và dedicated servers. Thứ nhất, local exploitation do đâu mà có? Chìa khóa quan trọng nhất đó là: việc thực thi hành động exploit nào đó xảy ra trên máy cục bộ (shared host hoặc dedicated server). Thứ nhì, thế nào là "xảy ra trên máy cục bộ"? a) Nếu kẻ tấn công có một cái unix shell (bash, csh...) như conmale@someserver$ và cái shell này có thể dùng để làm gì đó dung hại ngay trên server đang bị tấn công. b) Nếu kẻ tấn công có một cái php, asp, python, perl... script nào đó (còn gọi là shell nhưng shell này khác shell trên ở chỗ nó hoàn toàn hoạt động trên giao thức http và có tầng php, asp, python, perl... đứng giữa thay vì bash shell, c shell tương tác trực tiếp với hệ điều hành). Con "shell" này phải được upload và thực thi ngay trên server bị tấn công. Thứ ba, giới hạn có thể tấn công của từng dạng shell ở trên thế nào? 1) Nếu kẻ tấn công có một cái unix shell (như a) ở trên) thì tùy vào hệ điều hành bị bug cỡ nào và tùy mức độ thiết kế và quản lý server như thế nào. Nếu shell này chỉ cung cấp và dừng lại ở chủ quyền của một người dùng bình thường thì độ "tàn phá" sẽ hạn chế. Nếu hệ điều hành có lỗi hoặc độ thiết kế server lỏng lẻo thì có thể bị escalate thành root thì coi như là "game over". 2) Nếu kẻ tấn công có một cái shell (như b) ở trên) thì tùy và tính bảo mật của apache và mức độ tinh xảo của con shell ấy. Thứ tư, thử phân tích xem: I) Do đâu kẻ tấn công có một con shell như a) II) Do đâu kẻ tấn công có một con shell như b) Sau đó mới bàn tiếp, làm sao để không cho I) và II) xảy ra. Mời các bạn thảo luận. 
Theo em: Đỏ: về shell thì trên mạng nó share rất là nhiều. Còn việc có bị upload lên hay ko là do cách lập trình của coder. Xanh: Do ISP. Vì thế phải chọn một ISP nào tốt tốt. :) ]]> /hvaonline/posts/list/23670.html#145195 /hvaonline/posts/list/23670.html#145195 GMT Re: [Thảo luận] Local exploitations

conmale wrote:
... Nói chung, một khi đã có một cái bash shell thì cơ hội bị escalate lên root khá cao. 
Khi nào rảnh anh có thể làm 1 bài tổng hợp về vấn đề này được ko ạ? Theo suy nghĩ và hiểu biết hiện tại của em thì nó không đến nỗi "khá cao", phụ thuộc vào nhiều yếu tố mà (trong đó tất nhiên có yếu tố cá nhân người thâm nhập nữa ^^ )]]> /hvaonline/posts/list/23670.html#145225 /hvaonline/posts/list/23670.html#145225 GMT Re: [Thảo luận] Local exploitations

cvhainb wrote:
Xanh: Do ISP. Vì thế phải chọn một ISP nào tốt tốt. :)  
Có lẽ bạn nhầm ISP (Internet Service Provider) với HP (Host Provider).]]> /hvaonline/posts/list/23670.html#145437 /hvaonline/posts/list/23670.html#145437 GMT Re: [Thảo luận] Local exploitations

boom_jt wrote:
@anh conmale:

conmale wrote:
... Nói chung, một khi đã có một cái bash shell thì cơ hội bị escalate lên root khá cao. 
Khi nào rảnh anh có thể làm 1 bài tổng hợp về vấn đề này được ko ạ? Theo suy nghĩ và hiểu biết hiện tại của em thì nó không đến nỗi "khá cao", phụ thuộc vào nhiều yếu tố mà (trong đó tất nhiên có yếu tố cá nhân người thâm nhập nữa ^^ ) 
Privilege escalation trên *nix thì muôn hình vạn trạng nhưng chỉ có một số nguyên tắc nhất định (mà anh đã liệt kê vài cái trong bài nào trước đây). Phần lớn privilege escalation dựa vào BoF để "chôm" chủ quyền cao hơn ở một địa chỉ nào đó trên memory. Phần còn lại là dựa vào mis-configuration trên system. Nếu tấn công một box nào đó mà mình chưa nắm rõ cấu trúc filesystem của nó và những restriction được ấn định thì việc tìm BoF cực khó. Thông thường kẻ tấn công dựa vào phiên bản của soft bị lỗi BoF và tìm xem trên mục tiêu có cái nào như thế hay không rồi tấn công trực tiếp vào nó. Ngoài ra, việc mò mẫm trên một mục tiêu hoàn toàn lạ đối với mình đòi hỏi rất nhiều thời gian và kiên trì. Chẳng những thế, mỗi điều thăm dò được, em phải ghi xuống để tránh phí thời gian và để có thể thu hẹp lại biên độ thăm dò. Đối với dạng tấn công vào mis-configuration, tiện ích như find là thứ không thể thiếu được. Mục tiêu thường là các executable scripts và xung quanh khu vực crontab. Trên mạng có những công cụ hoặc script dùng để "audit" tính bảo mật của một box *nix, nghiên cứu chúng là cách rất hay để hiểu những điểm yếu thường thấy trên một server chung chung. Thân mến.]]> /hvaonline/posts/list/23670.html#145480 /hvaonline/posts/list/23670.html#145480 GMT Re: [Thảo luận] Local exploitations

BigballVN wrote:

cvhainb wrote:
Xanh: Do ISP. Vì thế phải chọn một ISP nào tốt tốt. :)  
Có lẽ bạn nhầm ISP (Internet Service Provider) với HP (Host Provider). 
Đúng là bé cái nhầm:^) .]]> /hvaonline/posts/list/23670.html#145529 /hvaonline/posts/list/23670.html#145529 GMT Re: [Thảo luận] Local exploitations /hvaonline/posts/list/23670.html#146117 /hvaonline/posts/list/23670.html#146117 GMT Re: [Thảo luận] Local exploitations

conmale wrote:
Tiếp tục dạng "shell" thứ nhì (php) nhá? Giả sử trên cấu hình của apache ấn định một root directory là /home/abc/public_html và cho phép các file .php thuộc directory và sub-directory này được chạy. Giả sử một sub-directory có tên là "uploads" (chẳng hạn) cho phép người dùng attach files (upload file lên). Xuyên qua cơ chế upload này, kẻ tấn công có thể upload php files, jpg file có nhúng php... vậy: - Làm sao vẫn cho phép file upload nhưng bảo đảm bảo mật? - Có bao nhiêu cách kiểm soát và hạn chế? - Kiểm soát và hạn chế chúng ở những mức độ nào? :P  
Chào anh, trong cơ chế upload mình chỉ cho upload những file: jpg,gif,zip,pdf,...Ngoài các file này ra thì ko cho upload những ngôn ngữ lập trình khác. Còn kiểm soát và hạn chế ở những mức độ nào thì...chờ người tiếp theo trả lời giúp vậy :P.]]> /hvaonline/posts/list/23670.html#146470 /hvaonline/posts/list/23670.html#146470 GMT Re: [Thảo luận] Local exploitations /hvaonline/posts/list/23670.html#146471 /hvaonline/posts/list/23670.html#146471 GMT Re: [Thảo luận] Local exploitations

cvhainb wrote:

conmale wrote:
Tiếp tục dạng "shell" thứ nhì (php) nhá? Giả sử trên cấu hình của apache ấn định một root directory là /home/abc/public_html và cho phép các file .php thuộc directory và sub-directory này được chạy. Giả sử một sub-directory có tên là "uploads" (chẳng hạn) cho phép người dùng attach files (upload file lên). Xuyên qua cơ chế upload này, kẻ tấn công có thể upload php files, jpg file có nhúng php... vậy: - Làm sao vẫn cho phép file upload nhưng bảo đảm bảo mật? - Có bao nhiêu cách kiểm soát và hạn chế? - Kiểm soát và hạn chế chúng ở những mức độ nào? :P  
Chào anh, trong cơ chế upload mình chỉ cho upload những file: jpg,gif,zip,pdf,...Ngoài các file này ra thì ko cho upload những ngôn ngữ lập trình khác. Còn kiểm soát và hạn chế ở những mức độ nào thì...chờ người tiếp theo trả lời giúp vậy :P. 
Ý em là không cho upload những định dạng khác? :) Vậy hành động "cho" hoặc "không cho" ở đây dựa vào những yếu tố nào? (kiểm tra đuôi của file? kiểm tra header của file? kiểm tra trọn bộ nội dung file?) Giả sử vẫn cho họ upload .php file nhưng làm thế nào để đạt được: cho nhưng vẫn bảo mật? Hãy thử phân tích xem: một file php được parse và hoạt động trên một apache web server cần những điều kiện nào? Nếu rút bỏ hết các điều kiện ấy, liệu file php còn được parse và hoạt động hay không?]]> /hvaonline/posts/list/23670.html#146474 /hvaonline/posts/list/23670.html#146474 GMT Re: [Thảo luận] Local exploitations Code:
AddType text/plain     php
vào .htaccess trong thư mục chứa file upload.]]> /hvaonline/posts/list/23670.html#146613 /hvaonline/posts/list/23670.html#146613 GMT Re: [Thảo luận] Local exploitations /hvaonline/posts/list/23670.html#146661 /hvaonline/posts/list/23670.html#146661 GMT Re: [Thảo luận] Local exploitations /hvaonline/posts/list/23670.html#146693 /hvaonline/posts/list/23670.html#146693 GMT Re: [Thảo luận] Local exploitations

watchd0g wrote:
Các bước "kiểm tra đuôi của file? kiểm tra header của file? kiểm tra trọn bộ nội dung file?" đều có cách giả dạng 1 phiên upload để đưa lên server file mong muốn. Theo em nên kết hợp với việc hạn chế user truy cập trực tiếp vào file vừa upload, điều này có thể dễ dàng thực hiện: - Dời những file upload sang 1 thư mục không phải là web root (theo ví dụ của anh comale thì web root là public_html) or - Hạn chế user truy cập vào upload folder trên web root directory. or - Đổi tên file upload bằng 1 chuỗi ngẫu nhiên.  
Đây chính là cách mà 1 số code 4rum áp dụng, và ko phải là "or", mà họ dùng "and" :D]]> /hvaonline/posts/list/23670.html#146708 /hvaonline/posts/list/23670.html#146708 GMT Re: [Thảo luận] Local exploitations

conmale wrote:

cvhainb wrote:

conmale wrote:
Tiếp tục dạng "shell" thứ nhì (php) nhá? Giả sử trên cấu hình của apache ấn định một root directory là /home/abc/public_html và cho phép các file .php thuộc directory và sub-directory này được chạy. Giả sử một sub-directory có tên là "uploads" (chẳng hạn) cho phép người dùng attach files (upload file lên). Xuyên qua cơ chế upload này, kẻ tấn công có thể upload php files, jpg file có nhúng php... vậy: - Làm sao vẫn cho phép file upload nhưng bảo đảm bảo mật? - Có bao nhiêu cách kiểm soát và hạn chế? - Kiểm soát và hạn chế chúng ở những mức độ nào? :P  
Chào anh, trong cơ chế upload mình chỉ cho upload những file: jpg,gif,zip,pdf,...Ngoài các file này ra thì ko cho upload những ngôn ngữ lập trình khác. Còn kiểm soát và hạn chế ở những mức độ nào thì...chờ người tiếp theo trả lời giúp vậy :P. 
Ý em là không cho upload những định dạng khác? :) Vậy hành động "cho" hoặc "không cho" ở đây dựa vào những yếu tố nào? (kiểm tra đuôi của file? kiểm tra header của file? kiểm tra trọn bộ nội dung file?) Giả sử vẫn cho họ upload .php file nhưng làm thế nào để đạt được: cho nhưng vẫn bảo mật? Hãy thử phân tích xem: một file php được parse và hoạt động trên một apache web server cần những điều kiện nào? Nếu rút bỏ hết các điều kiện ấy, liệu file php còn được parse và hoạt động hay không? 
Em có ý này: Code:
RewriteRule   ^.php$ .txt
Vẫn cho upload .php file lên nhưng khi chạy thì show hàng ra lun :D]]> /hvaonline/posts/list/23670.html#147450 /hvaonline/posts/list/23670.html#147450 GMT Re: [Thảo luận] Local exploitations

conmale wrote:
Vậy hành động "cho" hoặc "không cho" ở đây dựa vào những yếu tố nào? (kiểm tra đuôi của file? kiểm tra header của file? kiểm tra trọn bộ nội dung file?) Giả sử vẫn cho họ upload .php file nhưng làm thế nào để đạt được: cho nhưng vẫn bảo mật? Hãy thử phân tích xem: một file php được parse và hoạt động trên một apache web server cần những điều kiện nào? Nếu rút bỏ hết các điều kiện ấy, liệu file php còn được parse và hoạt động hay không? 
Chào anh, nếu cho upload một file .php thì có thể em sẽ mã hóa file bằng chuỗi ngẫu nhiên hoặc tên file như cũ nhưng đổi extension của file thành .txt.]]> /hvaonline/posts/list/23670.html#147779 /hvaonline/posts/list/23670.html#147779 GMT Re: [Thảo luận] Local exploitations

cvhainb wrote:
Chào anh, nếu cho upload một file .php thì có thể em sẽ mã hóa file bằng chuỗi ngẫu nhiên 
Mã hóa nội dung file hay mã hóa tên file?]]> /hvaonline/posts/list/23670.html#147916 /hvaonline/posts/list/23670.html#147916 GMT Re: [Thảo luận] Local exploitations

nguoididingoaipho wrote:
Mã hóa nội dung file hay mã hóa tên file? 
Em thì chỉ biết mã hóa tên file thôi. :D ]]> /hvaonline/posts/list/23670.html#148058 /hvaonline/posts/list/23670.html#148058 GMT Re: [Thảo luận] Local exploitations

cvhainb wrote:
Em thì chỉ biết mã hóa tên file thôi. 
Cái này cũng khá là phí công, vì phải dùng script để liên kết đến. Mà như vậy thì bằng chi ta để thư mục Upload vào nơi ko public, và khi đó cũng ko cần phải mã hóa tên file làm gì, vì nó đâu có truy cập trực tiếp dc]]> /hvaonline/posts/list/23670.html#148103 /hvaonline/posts/list/23670.html#148103 GMT Re: [Thảo luận] Local exploitations

nguoididingoaipho wrote:

cvhainb wrote:
Em thì chỉ biết mã hóa tên file thôi. 
Cái này cũng khá là phí công 
cái này thì 3 line là xong :D .]]> /hvaonline/posts/list/23670.html#148398 /hvaonline/posts/list/23670.html#148398 GMT Re: [Thảo luận] Local exploitations

canh_nguyen wrote:
Với việc upload ngoài check extension, mime cháu thường thêm dòng Code:
AddType text/plain     php
vào .htaccess trong thư mục chứa file upload. 
em thấy cách này là khả thi nhất dù up được file php lên nhưng ko run được thì cũng không làm được gì]]> /hvaonline/posts/list/23670.html#148641 /hvaonline/posts/list/23670.html#148641 GMT