from.hell

“The ldd utility is more vulnerable than you think. It’s frequently used by programmers and system administrators to determine the dynamic library dependencies of executables. Sounds pretty innocent, right? Wrong! It turns out that running ldd on an executable can result in executing arbitrary code. This article details how such executable can be constructed and comes up with a social engineering scenario that may lead to system compromise. I researched this subject thoroughly and found that it’s almost completely undocumented.”

source:
http://www.catonmat.net/blog/ldd-arbitrary-code-execution/
http://tech.slashdot.org/story/09/10/26/1314209/Arbitrary-Code-Execution-With-ldd

source : http://securitytube.net/How-to-own-a-Windows-Domain-video.aspx

Z (Z [at] wechall [dot] net) submitted this cool video to us. According to his submission:- I had to cut this video to a short one, so please use the pause button if something is too quick The mission is to create a new Windows domain administrator – in case we do not have any user in the domain or any local user at the workstation. Prerequisites:

1. Physical access to one of the domain member workstations for ~20 minutes.
2. Every local administrator user on the workstations have the same password. Strong or weak, it does not matter. NO social engineering, NO password stealer, NO password cracker, NO malicious code, NO exploiting zero-day or already patched vulnerabilities.

Tools used for the attack:

1. ophcrack (to get the local admin LM&NTLM hashes)
2. Offline NT Password & Registry Editor, Bootdisk / CD from Petter Nordahl-Hagen (to login as local admin)
3. pass-the-hash toolkit from Hernan Ochoa – Core Security (to authenticate with the hashes, so we do not have to crack them)
4. psexec from Mark Russinovich (to run remote commands)

Demo architecture: We have at least 3 computers: the workstation (WKS) for which we have physical access, the domain controller, and a workstation (ADMIN-WKS) with a logged in domain administrator (DomainAdmin).

Steps:

1. Boot the workstation with ophcrack. Stop the cracking process, and save the hashes. View the hashes, and write the local administrator hashes down with pencil&paper (or copy it on a USB stick, etc.).
2. Boot in with the Offline NT Password & Registry Editor. Reset the local administrator password to blank, and reboot. 3. Login with administrator to the workstation with blank password.
4. Use iam.exe or iam-alt.exe to change the LM&NTLM hashes in the memory.
5. Copy the pass-the-hash toolkit to the admin-wks via an administrator share.
6. Run the whosthere.exe or whosthere-alt.exe to get the DomainAdmin LM&NTLM hashes.
7. Create a local user called DomainAdmin, and login into that profile.
8. Use iam.exe or iam-alt.exe with the DomainAdmin hashes to change the LM & NTLM hashes in the memory.
9. Right now we have the same privileges as the DomainAdmin, so we can create a domain admin for ourself. Or anything else we want in the domain (reset anyone elses password, read someone elses e-mail, etc.).

Known limitations:

1. Some Windows versions / service packs are not compatible with the pass-the-hash toolkit, feel free to modify the source or debug the libraries to get the correct memory addresses.
2. Some AV engines detect pass-the-hash toolkit as malicious code, use AV evasion techniques against them.

What is cool?

1. It does not matter how complex the local admin and domain admin passwords are.
2. It works even if the domain admins are forced to use smart cards for interactive login.
3. We have not used any of the attacks mentioned above, so it works on fully patched networks with security paranoid admins.

Tools
Ophcrack live CD
Offline NT Password & Registry Editor, Bootdisk / CD from Petter Nordahl-Hagen
pass-the-hash toolkit from Hernan Ochoa – Core Security
psexec from Mark Russinovich

source: http://www.cromwell-intl.com/security/security-stack-hardening.html

#Disable ICMP broadcast echo activity.
sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1
#Disable ICMP routing redirects.
sysctl -w net.ipv4.conf.all.accept_redirects=0
sysctl -w net.ipv6.conf.all.accept_redirects=0
sysctl -w net.ipv4.conf.all.send_redirects=0
sysctl -w net.ipv6.conf.all.send_redirects=0
#Disable IP source routing.
sysctl -w net.ipv4.conf.all.accept_source_route=0
sysctl -w net.ipv4.conf.all.forwarding=0
sysctl -w net.ipv4.conf.all.mc_forwarding=0
#Enforce sanity checking, also called ingress filtering or egress filtering
sysctl -w net.ipv4.conf.all.rp_filter=1
#Log and drop "Martian" packets.
sysctl -w net.ipv4.conf.all.log_martians=1
#Increase resiliance under heavy TCP load (which makes the system more resistant to SYN Flood attacks).
sysctl -w net.ipv4.tcp_max_syn_backlog=1280
sysctl -w net.ipv4.tcp_syncookies=1


1.- Overlong UTF-8:
As REQUIRED by UNICODE 3.1, and noted in the Unicode Technical Report #36, UTF-8 is forbidden to interpretate a character’s non-shortest form.

2.- Ill formed sequences:
As REQUIRED by UNICODE 3.0, and noted in the Unicode Technical Report #36, if a leading byte is followed by an invalid successor byte, then it should NOT consume it.

3.- Integer overflow:
Unsigned short has a size of 16 bits (2 bytes), that is UNCAPABLE of storing unicode characters of 21 bits, and represented on UTF with 4 bytes (1111 0xxx 10xx xxxx 10xx xxxx 10xx xxxx). PHP attempts to sum a 21 bits value to a 16 bits-size variable, and then makes no checks on the value.

The firefox one

Firefox is supposed to consider the non-shortest form exception (point #1 in the PHP vulnerabilities), and section 3.1 of the Unicode Technical Report #36 but apparently there’s a flaw on it. This is specially problematic for the reasons that an overlong unicode sequence not taken into consideration may allow several types of filter bypasses.

http://sirdarckcat.blogspot.com/2009/10/couple-of-unicode-issues-on-php-and.html