Metabrik Core And Repository 1.08 Released

A new version of Metabrik Core and Repository is available. Update using Mercurial or follow the installation procedure.

Changes

Core

1.08 Thu Mar 19 06:48:34 CET 2015
 - FEATURE: core::shell: run executable commands found in PATH through system Command
 - UPDATE: shell::command: now use IPC::Run3 to capture shell commands output
 - update: shell::command: system Command now returns $? on success
 - update: Metabrik: display every missing items from brik_require_*_check() before erroring
 - update: new dependance on IPC::Run3

1.07 Sun Mar 8 17:52:37 CET 2015
 - bugfix: shell::history: correctly writes $* variables when calling history Commands
 - new: shell::rc: create an alias to make it easy to switch to root from Shell
 - new: brik::search and perl::module Briks integrated in main distribution
 - remove: no more metabrik-cpanm, enforce use of standard cpanm

Repository

- bugfixes and new Briks

20150316
 AFFECT: http::proxy, iana::countrycode, network::arpdiscover

 - http::proxy Brik renamed to proxy::http
 - iana::countrycode Brik renamed lookup::countrycode
 - network::arpdiscover removed: merged with network::arp

20150311
 AFFECT: client::www

 - post Command returns an HASHREF i/o of WWW::Mechanize object

20150309
 AFFECT: network::portscan

 - synscan Command renamed to tcp_syn

 

Exploiting ElasticSearch RCE For CVE-2015-1427

I told you so: it is a work for Metabrik. While the main target for Metabrik is not to write exploits (you have Metasploit for that), you can still write Briks within the Audit Category. Based on the exploit provided XiphosResearch, we wrote a Command to verify if an ElasticSearch target is vulnerable, and another Command to exploit the issue to execute commands on the target.

Loading the Brik

As always, if a Brik is not loaded yet, you have to do it. Then, the first thing to do is to ask for help, or how to use the Brik, which Attributes can be set and which Commands can be run.

screenshot

Using a check or an exploit Command

To test a target, you can either use the check_cve_2015_1427_rce  Command or use the exploit_cve_2015_1427_rce Command with an innocuous command. We recommand to use the check one, which is actually made to be innocuous.

To use the check or exploit one, you just have to use the run Metabrik Command with the name of a Command, and add Arguments to it. Some Arguments can be set globally for the Brik: here you may use the set Metabrik Command to set uri Attribute.

Note: And don’t forget to use the <Tab> key to perform completion on every Command, and use the <Up> key to recall previous ones.

Example:

screenshot

Our target is vulnerable. Too bad, but it is an exploit lab, it exists for that.

Exploiting the issue to execute commands

But well, if you are here, it is probably because you want to exploit a Remote Command Execution within ElasticSearch. With Metabrik, it is as easy as:

screenshot

We even added some “post intrusion” work, like downloading a file.

A key feature of Metabrik

Yes, one of the key feature of Metabrik is to assemble Briks together to execute a complete scenario. We have shown how to use Briks, especially the one on exploiting a vulnerability within a product and, after this exploitation process, we have shown that we can use a special $RUN variable with another Brik.

Every:

  • run Command sets the global variable $RUN
  • set Command sets the global variable $SET
  • get Command sets the global variable $GET

Thanks to the $RUN variable, you can chain the use of Briks. In fact, Briks within Metabrik may also be written with other Briks. For instance, audit::elasticsearch Brik relies on:

Here, we have chained a few Briks, and one of them allowed to save a remote file to a local file (file::text). You have more global variables, but that’s enough for today. Follow us on twitter @Metabrik.

 

 

Why Writing A TCP SYN Scanner In Perl Can Be Efficient

Everyone wants to write (or already did) its own TCP SYN scanner. Why? Because it is a fun exercise which will teach you a lot of things, like what raw sockets are and, more importantly, how to build packets.

Perl for the task

Some may argue that using Perl would be inefficient for such a task. Plain false. You can use Perl/XS to write part(s) of a program that require performance. That’s what we did with Net::Write::Fast: a module able to send packets over the network at speed of wires.

Design goals behind Net::Write::Fast

A few design goals were followed when writing this module:

  • TCP SYN scanner working over IPv4 and IPv6
  • Portable on at least Linux, FreeBSD and MacOS X
  • Perform a scan in a predictable way: we know when it will finish
  • Send packets over a transport layer socket

The transport layer socket

Usually, people tend to write packets using raw sockets directly from the network layer, requiring them to also craft the IP layer. And that’s a total waste of code and time. You can send your TCP or UDP packets without having to craft the IP header; no need to use the include IP header socket option.

To make it short, opening a raw socket within Net::Write::Fast was as simple as:

int fd;
fd = socket(v6 ? AF_INET6 : AF_INET, SOCK_RAW, IPPROTO_TCP);

The TCP header

So you did open a raw socket at the transport layer, now you just need to write the TCP layer. You don’t have to care about IP layer at all, and the differences of endianess from OS to OS for some of its fields (header length, for instance). Well, you still have to write the pseudo header so you can compute TCP checksum, but that’s another story.

Glueing C code to Perl

Full Perl/XS code can be found here. It is exactly like standard C code. But for the C function to be callable from Perl, we need to add a binding. It is a little bit tricky when you want to do it right. The prototype of the function is:

int
l4_send_tcp_syn_multi(src, dst, ports, pps, n, v6, warnings = NO_INIT)
      char *src
      SV   *dst
      SV   *ports
      int   pps
      int   n
      int   v6
      int   warnings

A forked sender process and a listener

Now everything is in place to send packets at the speed of wires. We still have to think about listening for answers and parsing them. Here, no need for Perl/XS for the listening task: you have Net::Frame::Dump module which is a pure Perl one.

Now, we need proof

Here is a screenshot from a TCP SYN scan of the TOP 1000 most common ports on the local network (256 hosts). We configure the scanner to send 2 times a probe, at a rate of 100 000 packets per second. If you do your math, you will see it should take 5 seconds and consume around 8 MB of bandwidth per second. One packet takes 20 bytes for IP header followed by 60 bytes for the TCP header plus its full options.

Of course, you can send at a greater speed, or change the number of tries to tweak your scanning process. Screenshot:

screenshot

So, it took a little bit more than the 5 seconds estimation, but you have 2 or 3 seconds needed by the program to load and compile, and to wait at the end of sending process to gather remaining replies.

But what about IP source address spoofing?

Some may argue that we cannot spoof source IP address using transport layer sending. And that’s just wrong. You can do it by just adding an alias to your network interface, and using that as the source address for sending packets. It will be used right away by your transport layer raw socket.

Tweaking your TCP/IP stack

Under GNU/Linux, don’t forget to increase your send buffers. Or you will have the following error:

WARNING: Net::Write::Fast: sendto: ENOBUFS, sleeping for 1 second

# Increase send buffer to 100 MB
sysctl -w net.core.wmem_max=109051904
sysctl -w net.core.wmem_default=109051904

Conclusion

Writing a TCP SYN scanner in Perl is reliable, fast, and predictable. And of course, there is now a Brik for that within Metabrik, it is named network::portscan. Happy scanning, and don’t forget to follow us on Twitter: @metabrik.