| [Question] [Thảo luận] Local exploitations |
22/07/2008 00:43:10 (+0700) | #1 | 142620 |
![[Avatar]](/hvaonline/images/avatar/089f41810321eefc3f4eef5d4a388e42.png "[Avatar]")
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
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. |
|
| What bringing us together is stronger than what pulling us apart. |
|
 |
|
| [Question] Re: [Thảo luận] Local exploitations |
22/07/2008 01:53:19 (+0700) | #2 | 142625 |
boom_jt
Member
![[Minus]](/hvaonline/templates/viet/images/minus.gif "[Minus]") |
0 |
![[Plus]](/hvaonline/templates/viet/images/plus.gif "[Plus]")
|
|
Joined: 02/08/2007 23:51:10
Messages: 125
Offline
|
|
hi,
boom đưa 1 trường hợp đơn giản đầu tiên có thể nghĩ đến cho cả 2 trường hợp a) và b): do "khách hàng" sử dụng webservice có quyền trong tài khoản của mình (-> trường hợp b). Thông thường với 1 số server thì khách hàng còn có thể được cấp 1 shell account -> trường hợp a. Dựa trên những quyền truy nhập cơ bản này mà "khách hàng" - cũng có thể là kẻ có chủ định tấn công - dựa trên các lỗ hổng có thể khai thác được để "local exploit".
Kẻ tấn công có chủ định có thể tự bỏ tiền ra sử dụng dịch vụ của server hòng nhắm tới 1 mục đích nào đó cùng nằm trên server chẳng hạn. Cũng có thể dịch vụ của server là hoàn toàn miễn phí (boom thấy server thể loại này nhiều khi config lại tốt hơn thể loại trả tiền  )
Đây là 1 trường hợp hoàn toàn có thể, không nên nói "ôi dào, người ta bỏ tiền ra thuê thì còn nói chuyện làm gì" ^^ Ta cứ trả lời từng ý một, thảo luận sẽ còn dài (boom hi vọng thế  )
Boom nghĩ cũng nói thêm chút về các trường hợp ứng dụng cụ thể của hack local, các cách bypass ... có lẽ sẽ học hỏi được rất nhiều từ "nghề" của mọi người đấy ;
p/s: @bác conmale: chờ ý kiến bác ở thread thảo luận về session hijacking mà chưa thấy nè |
|
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
22/07/2008 02:53:18 (+0700) | #3 | 142631 |
![[Avatar]](/hvaonline/images/avatar/b6d767d2f8ed5d21a44b0e5886680cb9.png "[Avatar]")
|
Z0rr0
Q+WRtaW5pc3RyYXRvc+g
|
Joined: 14/08/2002 12:52:01
Messages: 1323
Location: Underground
Offline
|
|
1) Local exploitation có thể xảy ra khi:
a) Có sơ hở ở tầng application hoặc business, để attacker gửi shell script vào khu vực của application hoạt động
b) Có sơ hở ở web/app server trong việc phân quyền thực thi và truy xuất của web script đến những khu vực không mong muốn như thiết kế
c) Có sơ hở ở tầng hệ điều hành trong việc phân quyền truy xuất giữa các web space/host và bảo vệ dữ liệu (encryption)
c) Có sơ hở ở tầng mạng trong việc cung cấp dịch vụ, giám sát và phân quyền truy xuất giữa các tài nguyên trong hạ tầng mạng
2) Với các shell như unix shell, điều đầu tiên nghĩ đến là quyền hạn của mình đến đâu và tìm cách nâng quyền. Ví dụ như những lỗi trong linux kernel gần đây cho phép một normal user trở thành root. Shell dạng này thường yêu câu thực hiện tương tác (interactive) trực tiếp với tài nguyên của OS, ví dụ file system, memory...
Với các dạng web script, việc khai thác tùy thuộc vào quyền hạn của user đang chạy ứng dụng web và cấu hình của web server, OS. Web application chạy với user càng được phân nhiều đặc quyền thì script sẽ càng nguy hiểm.
3) Việc nâng quyền từ người dùng bình thường lên mức cao nhất thường tận dụng các lỗi implementation như buffer overflow (stack hoặc heap), race condition...
4) Lý do có được interactive shell:
+ Được quản trị trao quyền truy xuất shell, ssh, telnet...
+ "Vô tình lượm được bí kíp", từ các default shell, mò mật khẩu của shell quản trị, test shell xong rồi quên đóng...
Lý do có được web script shell: chủ trang web dễ dàng upload lên web host của mình, attacker lợi dụng lỗi của web application mà upload. |
|
| Hibernating |
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
22/07/2008 04:24:55 (+0700) | #4 | 142650 |
![[Avatar]](/hvaonline/images/avatar/4dd20f1e87dfb889bc97230e2c87c6a5.png "[Avatar]")
|
xnohat
Moderator
|
Joined: 30/01/2005 13:59:19
Messages: 1210
Location: /dev/null
Offline
|
|
Chẳng nhẽ nhất thiết phải có shell mới local exploit được ạ 
Ta chỉ bàn về local exploit chứ có bàn về Leo thang đặc quyền đâu nhỉ |
|
iJust clear, "What I need to do and how to do it"/i
br
brBox tán gẫu dời về: http://www.facebook.com/hvaonline |
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
22/07/2008 04:41:07 (+0700) | #5 | 142652 |
|
Z0rr0
Q+WRtaW5pc3RyYXRvc+g
|
Joined: 14/08/2002 12:52:01
Messages: 1323
Location: Underground
Offline
|
|
xnohat wrote:
Chẳng nhẽ nhất thiết phải có shell mới local exploit được ạ
Ta chỉ bàn về local exploit chứ có bàn về Leo thang đặc quyền đâu nhỉ
- Đâ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? |
|
| Hibernating |
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
22/07/2008 04:43:53 (+0700) | #6 | 142653 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
xnohat wrote:
Chẳng nhẽ nhất thiết phải có shell mới local exploit được ạ
Ta chỉ bàn về local exploit chứ có bàn về Leo thang đặc quyền đâu nhỉ
Đọc kỹ lại bài đầu tiên. |
|
| What bringing us together is stronger than what pulling us apart. |
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
22/07/2008 13:55:12 (+0700) | #7 | 142747 |
DLKC
Elite Member
|
|
0 |
|
|
Joined: 24/03/2003 14:14:41
Messages: 161
Location: buồng chuối
Offline
|
|
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 
Thân |
|
| Biển học vô bờ. |
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
30/07/2008 13:05:02 (+0700) | #8 | 144164 |
LinuXpert
Member
|
|
0 |
|
|
Joined: 27/06/2008 18:59:57
Messages: 65
Offline
|
|
Có lẽ nên thảo luận về vấn đề dưới đây trước:
Nếu một user đồng thời cũng là một hacker được quyền truy cập shell hoặc tự upload các web shell lên để dùng thì phải làm thế nào để ngăn user/hacker đó không hack được các tài khoản khác trên cùng server?
Có lẽ không nên bàn về các lỗi của kernel mà được dùng để nâng quyền truy cập lên root. |
|
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
31/07/2008 01:08:18 (+0700) | #9 | 144253 |
![[Avatar]](/hvaonline/images/avatar/6b9c98a0d9c1c97294bf0772ae4dd207.jpg "[Avatar]")
|
nhocbmt
Member
|
|
0 |
|
|
Joined: 26/06/2006 17:55:21
Messages: 75
Location: Ban Mê City
Offline
|
|
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 " |
|
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
31/07/2008 04:44:42 (+0700) | #10 | 144308 |
![[Avatar]](/hvaonline/images/avatar/7f11b15655b2342b01a2db7edb7961cd.jpeg "[Avatar]")
|
gamma95
Researcher
|
Joined: 20/05/2003 07:15:41
Messages: 1377
Location: aaa">
Offline
|
|
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 |
|
Cánh chym không mỏi
lol |
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
31/07/2008 05:01:04 (+0700) | #11 | 144313 |
jforum3000
Member
|
|
0 |
|
|
Joined: 26/08/2007 02:53:39
Messages: 1172
Offline
|
|
| 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á. |
|
|
|
|
| [Question] [Thảo luận] Local exploitations |
31/07/2008 06:52:37 (+0700) | #12 | 144347 |
![[Avatar]](/hvaonline/images/avatar/0f582db1571dbc18ef01cfd0ce961178.png "[Avatar]")
|
Tal
Member
|
|
0 |
|
|
Joined: 15/09/2007 16:50:17
Messages: 67
Offline
|
|
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?
|
|
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
31/07/2008 07:00:15 (+0700) | #13 | 144349 |
|
Tal
Member
|
|
0 |
|
|
Joined: 15/09/2007 16:50:17
Messages: 67
Offline
|
|
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. |
|
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
31/07/2008 08:00:23 (+0700) | #14 | 144361 |
|
Tal
Member
|
|
0 |
|
|
Joined: 15/09/2007 16:50:17
Messages: 67
Offline
|
|
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ó . Ở đâ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 .
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.  |
|
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
01/08/2008 01:36:01 (+0700) | #15 | 144473 |
pearltran
Member
|
|
0 |
|
|
Joined: 15/08/2007 13:10:08
Messages: 33
Offline
|
|
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
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
|
|
|
|
|
| [Question] [Thảo luận] Local exploitations |
05/08/2008 04:30:32 (+0700) | #16 | 145095 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
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. |
|
| What bringing us together is stronger than what pulling us apart. |
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
05/08/2008 05:50:45 (+0700) | #17 | 145111 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
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
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
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. |
|
| What bringing us together is stronger than what pulling us apart. |
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
05/08/2008 07:41:40 (+0700) | #18 | 145125 |
catle
Member
|
|
0 |
|
|
Joined: 25/08/2007 21:06:39
Messages: 26
Offline
|
|
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 đó.
|
|
|
|
|
| [Question] [Thảo luận] Local exploitations |
05/08/2008 23:26:55 (+0700) | #19 | 145195 |
cvhainb
Member
|
|
0 |
|
|
Joined: 04/01/2007 14:32:38
Messages: 251
Offline
|
|
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. |
|
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
06/08/2008 01:34:51 (+0700) | #20 | 145225 |
boom_jt
Member
|
|
0 |
|
|
Joined: 02/08/2007 23:51:10
Messages: 125
Offline
|
|
xanh: chưa chắc do nhà cung cấp đâu bạn, mình đã từng gặp trường hợp có admin để cả thông tin bàn giao host trên server của mình và có directory listing -> ko còn gì để nói !
@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 ^^ ) |
|
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
07/08/2008 01:57:31 (+0700) | #21 | 145437 |
BigballVN
Elite Member
|
|
0 |
|
|
Joined: 12/06/2005 07:25:21
Messages: 610
Offline
|
|
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). |
|
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
07/08/2008 05:58:58 (+0700) | #22 | 145480 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
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. |
|
| What bringing us together is stronger than what pulling us apart. |
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
07/08/2008 10:47:32 (+0700) | #23 | 145529 |
cvhainb
Member
|
|
0 |
|
|
Joined: 04/01/2007 14:32:38
Messages: 251
Offline
|
|
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 . |
|
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
11/08/2008 18:44:08 (+0700) | #24 | 146117 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
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?
|
|
| What bringing us together is stronger than what pulling us apart. |
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
13/08/2008 05:05:11 (+0700) | #25 | 146470 |
cvhainb
Member
|
|
0 |
|
|
Joined: 04/01/2007 14:32:38
Messages: 251
Offline
|
|
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?
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 . |
|
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
13/08/2008 05:07:16 (+0700) | #26 | 146471 |
cvhainb
Member
|
|
0 |
|
|
Joined: 04/01/2007 14:32:38
Messages: 251
Offline
|
|
| Hi vọng xong cuộc thảo luận này anh commale góp lại những ý đúng để các coder cùi như em còn biết đường tránh. Cám ơn anh trước . |
|
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
13/08/2008 05:23:59 (+0700) | #27 | 146474 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
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?
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 .
Ý 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? |
|
| What bringing us together is stronger than what pulling us apart. |
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
13/08/2008 22:57:51 (+0700) | #28 | 146613 |
![[Avatar]](/hvaonline/images/avatar/a7c6d9a58a47a1e771142c96f76a128c.jpg "[Avatar]")
|
canh_nguyen
Elite Member
|
|
0 |
|
|
Joined: 23/08/2004 18:55:09
Messages: 775
Location: Broken dream
Offline
|
|
Với việc upload ngoài check extension, mime cháu thường thêm dòng
Code:
vào .htaccess trong thư mục chứa file upload. |
|
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
14/08/2008 01:51:53 (+0700) | #29 | 146661 |
boom_jt
Member
|
|
0 |
|
|
Joined: 02/08/2007 23:51:10
Messages: 125
Offline
|
|
| Vậy điều gì xảy ra nếu filename được truyền lên có dạng ../filename.php trong khi ta vẫn cho phép upload php và chỉ quan tâm đảm bảo an toàn cho thư mục uploads ? ^^ |
|
|
|
|
| [Question] Re: [Thảo luận] Local exploitations |
14/08/2008 05:14:14 (+0700) | #30 | 146693 |
watchd0g
Member
|
|
0 |
|
|
Joined: 30/11/2006 18:05:23
Messages: 42
Offline
|
|
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.
|
|
|
| Users currently in here |
|
1 Anonymous
|
|
Powered by JForum - Extended by HVAOnline
hvaonline.net | hvaforum.net | hvazone.net | hvanews.net | vnhacker.org
1999 - 2013 ©
v2012|0504|218|
|
|
![[Rule]](/hvaonline/templates/viet/images/icon_mini_rule.gif "[Rule]"){kind=icon}
![[Home]](/hvaonline/templates/viet/images/icon_mini_groups.gif "[Home]"){kind=icon}
![[Portal]](/hvaonline/templates/viet/images/icon_mini_portal.gif "[Portal]"){kind=icon}
![[Members]](/hvaonline/templates/viet/images/icon_mini_members.gif "[Members]"){kind=icon}
![[Statistics]](/hvaonline/templates/viet/images/icon_mini_stats.gif "[Statistics]"){kind=icon}
![[Search]](/hvaonline/templates/viet/images/icon_mini_search.gif "[Search]"){kind=icon}
![[Reading Room]](/hvaonline/templates/viet/images/icon_mini_book.gif "[Reading Room]"){kind=icon}
![[Register]](/hvaonline/templates/viet/images/icon_mini_register.gif "[Register]"){kind=icon}
Register![[Login]](/hvaonline/templates/viet/images/icon_mini_login.gif "[Login]"){kind=icon}
Login [
Thảo luận bảo mật
![[Profile]](/hvaonline/templates/viet/images/en_US/icon_profile.gif "[Profile]"){kind=icon}
![[PM]](/hvaonline/templates/viet/images/en_US/icon_pm.gif "[PM]"){kind=icon}
![[Up]](/hvaonline/templates/viet/images/en_US/icon_up.gif "[Up]"){kind=icon}
![[Print Copy]](/hvaonline/templates/viet/images/en_US/icon_print.gif "[Print Copy]"){kind=icon}
![[WWW]](/hvaonline/templates/viet/images/icon_www.gif "[www]"){kind=icon}
![[Yahoo!]](/hvaonline/templates/viet/images/icon_yim.gif "[YIM]"){kind=icon}
![[Email]](/hvaonline/templates/viet/images/icon_email.gif "[E-mai]"){kind=icon}
![[MSN]](/hvaonline/templates/viet/images/icon_msnm.gif "[MSN]"){kind=icon}
![[ICQ]](/hvaonline/templates/viet/images/icon_icq_add.gif "[ICQ]"){kind=icon}
![[digg]](/hvaonline/templates/viet/images/digg.gif "[digg]")
![[delicious]](/hvaonline/templates/viet/images/delicious.gif "[delicious]")
![[google]](/hvaonline/templates/viet/images/google.gif "[google]")
![[yahoo]](/hvaonline/templates/viet/images/yahoo.gif "[yahoo]")
![[technorati]](/hvaonline/templates/viet/images/technorati.gif "[technorati]")
![[reddit]](/hvaonline/templates/viet/images/reddit.gif "[reddit]")
![[stumbleupon]](/hvaonline/templates/viet/images/stumbleupon.gif "[stumbleupon]")