Sniffing and Securing Cisco Switch traffic


This is the first on the series…..about Securing Cisco Devices.!

Cisco Switches must be configured!!!!
This is the reason you bought a Cisco Switch 😉
By default the ports are all configured as dynamic desirable which will cause a trunk to be automatically created if 2 switches with default configuration are connected.
So lets see what a malicious user can get….by sniffing the network.

After that using  few commands specific for the switchport we will limit  the traffic to protect the switch !

The Final Configuration of the port will be :

SW1#show running-config interface fastEthernet 0/18
Building configuration…

Current configuration : 319 bytes
interface FastEthernet0/18
 switchport mode access
 no cdp enable
 spanning-tree bpdufilter enable
 spanning-tree bpduguard enable

After the above configuration you should not connect another Switch on the interface FastEthernet 0/18. The Configuration is for end devices only.

Links to follow


0day DoS: Mikrotik Server side DoS attack


After exploring the winbox clientserver protocol, i wanted to find some ways to get rid of winbox service and winbox client…
This finding, has to do only with the mikrotik router, who has winbox service running (on port 8291 or in any other port)
On my try to make a test on the server, in order to cause a lot of traffic, i saw the service being unstable, causing various probs to whole router. The minimum prob was the 100% cpu load, but there are various probs depending on hardware and routeros version. The exploit’s logic is very simple, and the winbox protocol analysis is simple too.So it made me identify that vulnerability very easy. The vulnerability found while trying to download a DLL/plugin file from mikrotik router (just like winbox client does) and choose a big file, and request the 1st part of it many times.. That is what causes the DoS. The only file needed here is the .py script, and it is tested on python 2.4 and 2.7 versions.

More details, download and usage, are below.. :

Continue reading

0day: Mikrotik’s Winbox Client Side attack. A remote code execution exploit

Hello ppl,
In this post I wanna present you a vulnerability I found and exploited, concerning Winbox. Winbox is the client that controls mikrotik routers.. It is a popular router OS. For more info 🙂
Winbox has a custom protocol communicating with the mikrotik routers and you can select between secure/unsecure communication. Winbox uses a tcp port 8291 by default. Old routers had that port hardcoded, newer ones have the ability to change port. At the bottom of the post, you’ll find a link to download the script and the files needed. You’ll find info how/why in script comments or here…

About the exploit
The exploit you will see in this post, is a mikrotik winbox service emulator. It is a listener, that waits for a winbox client/victim to connect, sends him a malicious dll/plugin and winbox executes it. Using this feature (that we can inject dlls in winbox) we exploit also the fact that a secure connection can be decided by server-side.. So no matter what client has selected, we can sent unencrypted data in his winbox. So attacker have to social his victim or via a MiTM can gain a shell.

Download the exploit code: mtikInject
* Updated on 30/4/2012 Lines 99 & 148 as said in Post’s comments *


 Vulnerability Description
When you connect to mikrotik router using winbox, it is asking for an index with plugins (DLLs) their size, version and CRCs. If something new is found, or if that client haven’t connected to that mikrotik version yet, winbox requests the new plugin(s) (.dll file(s)) from mikrotik router. When winbox downloads all the DLLs required in order to load the controlling interface of the mikrotik router, loads those DLLs (executes the DllMain() of each one) and then tries to make an authentication to the remote mikrotik router. The vulnerability exploits that winbox is loading the remote dlls before authentication and without any further confirmation of plugins originality.

Continue reading

API Hooking tool injecting code in the PE: tool explanation and application examples..

Hello again.. There was a long time since my last post, cos i was busy with several issues, but most time with this tool.. Checking it’s operation, testing the hooked PE in different OSs, changing the method used, etc..

Finally i came up with this tool, and below i will explain exactly how it works, give you the source code and a binary, and show you some applications of this tool with video and/or shots…

This is an API hooking tool, which uses the PE IAT patch method, and runs the payload, injecting the code in the PE permanently, changing the PE Header apropriately (section sizes, OEP, ..) The final executable produced (hooked, and code-injected) tested on most OSs:

  • Windows 7 x64 – SUCCEED
  • Windows 7 x32 – SUCCEED
  • Windows 2008 x32 – SUCCEED
  • Windows 2000 – FAILED (The VEH APIs not supported by OSs <= Win2k)
  • Windows 2003 x32 – SUCCEED
  • Windows XP x32 – SUCCEED
  • MAC OS running wine – SUCCEED

Here is the tool! CPP Source with injected asm (i could say ASM with injected cpp 😛 ) and the compiled .exe .. if you don’t trust me to run binary 😛 just cl hooking.cpp /w and you got it 🙂 – Get it!

What did I use to do it, was just some VMs to test it in different environments, and:

And ofcourse for the IAT and EAT of the PE Structure, I visited IcZelion’s guides (IAT, EAT) and used those methods in this tool.. Also I use the PEB method to obtain the Kernel Base in runtime on standalone codes, method used by most shellcodes.

Why whould you need an API Hooker ?? There are several reasons.. like :

  • Backdoor files
  • Change the API parameters on runtime
  • Spy API execution on specific process
  • etc

The method used from this tool, is physical modifying the Import Table of the PE, and patching/injection the user’s code so it is executed right BEFORE the API execution begins.. The tool just asks you which API you want to hook, and which is the file with the raw data (asm binary code) that will be inserted before the api execution.. The code that will be inserted must, for sure, be absolutely stand alone, what means that it must keep stack calibrated, must not refer to memory location out of the code (except from locals made in stack or imported functions from PEB) .. You have to know what you’re doing 🙂

BUT.. there is also another option of the tool. You can use the Exception Handling option.. which enables you to use code that may cause exceptions, code that does not manage it’s stack well, and maybe some 3rd party code.. This option, uses VEH (Vectored exception handling), installing the handler before your code execution, and removing the handler after the execution of your code, or after your code causes an exception.. Also the stack is being saved, so you dont have to care about the EBP and ESP values 🙂 The whole consept will be explained.

Here are two very nice and easy to understand API Hooking papers by Brian Mariani from High-Tech Bridge SA, published in exploit-db :

I will try to explain some basic things about how my tool is working. I hope you understand.. You can make your comments ofcourse! 🙂 Here are some Images about the operation.. :


Basic Hooking tool explanation

Basic Hooking tool explanation











Continue reading

PoURaN PE-Cryptor v1.01

PoURaN PE-Cryptor v1.01 cpp/asm source This time contains the executable too…

Yes am back… And this is a very short post.. I just made a new version for the PE-Cryptor because I needed to make the Cryptor work also without adding a new section! So this version has some functions changes, a new parameter for new section or not, and light changes in user messages…

I insert an image just to show the use of the new option..



New feature of pe-cryptor

PoURaN PE-Cryptor v1.01