https://hub.docker.com/r/phocean/beef/

https://github.com/phocean/dockerfile-beef

It provides an image for the BeEF framework for XSS browser exploitation (http://beefproject.com/).

Enjoy it!

docker pull phocean/msf

It is an automatic build based on the Github repository.

It means that the image is built by Docker, not by me. For this task, they simply have a read access to the Dockerfile on Github.

Thus, you may place in this image the same level of trust than the one you have in Docker (I cannot interfere in the process and mess with the image).

I say it because I am myself reluctant of installing third-party images. While I prefer to rebuild everything from Dockerfiles, I am fine with automatically built images if I am in a hurry and for non sensitive data.

And Lenny was kind enough to integrate it into his Linux distro, REMnux, well known among reversing people. He also came up with very good suggestions and helped me to bring some improvements, so many thanks to him.

Don’t miss reading his blog article on how to use the image in REMnux : “Run Metasploit Framework as a Docker Container Without Installation Pains”.
Stay tuned ;-)

• A volume from the container /root/.msf4 to $HOME/.msf4, so that you can benefit from your customized prompt, scripts and modules anytime and have persistence on them. In other words, just manage them on your host and they will be readily available to the msf container.
• A volume from the container /tmp/data to the host /tmp/msf, so that you can get access to dump files and stuff like that.
• Tmux window manager tool, so that you can easily navigate between msfconsole, bash and other sessions.
• nmap network scanner, just because sometimes it may be useful (along with its ncat).
• nasm, to support your custom encoders.

It is all up-to-date in its github repo. I will keep adjusting it, if I feel something is missing.

I hope I did it the right way, let me know what you think!

Managing updates and dependencies of a Metasploit installation have definitely been too much trouble and repetitive.

Instead of keeping reproducing boring installation steps every x months, I decided to build a Dockerfile for once.

I chose Debian for its good compromise between features, stability and lightness. I am aware of the Kali Dockerfile, that I could have used as a base. But:

•  It is a definitely over-killing image (more than 1 GB) and, at this cost, it does not come with a fully-featured Metasploit (no database connection, for instance).
• I like keeping minimal and controlled stuff. In other words, I like doing things on my own.

So, this Debian-based Metasploit container comes with:

• all dependencies installed,
• automatic updates at startup,
• a connection with the local Postgres database,
• an improved prompt with timestamping and sessions/jobs status.

You can find it on my github.

If you have any trouble or suggestion on how to improve it, please let me know. Enjoy it and go ahead if you want to fork it!

A quick update from a previous post for setting Metasploit on Fedora 21, the latest version.

It is mainly a copy and paste, except for a few typo fixes and some changes on the Ruby part. The good news is that Metasploit was recently ported to Ruby 2.x, so we don’t need anymore the rvm stuff anymore, which makes the process much simpler.

Preparing Postgresql

Install:

 yum -y install postgresql-server postgresql-devel

Initiate a new “cluster” and connect to the sql client through the postgres user:

# as root:
postgresql-setup initdb
systemctl start postgresql.service
su postgres
psql

Inside the psql console, create the new Metasploit user and its database:

create user msf;
alter user msf with encrypted password 'super password';
create database msfdb;
grant all privileges on database msfdb to msf;
\q

Then, we will tell to Postgres how to accept local connections. ident necessitates an system account, trust means no password for any local account and md5 stands for a classic password authentication, which we will prefer.
Back to a root terminal, add this line inside /var/lib/pgsql/data/pg_hba.conf and beware that the order is important:

# IPv4 local connections:
host msfdb msf 127.0.0.1/32 md5
host all all 127.0.0.1/32 ident

Then we can restart the service and check with psql that the credentials are working:

systemctl restart postgresql.service
psql -U msf msfdb -h localhost
\q

Setting Ruby

Metasploit runs well with Ruby 1.9.3, so we will install this version and switch to it using rbenv.
rbenv does a nice job at managing several version of ruby next to each other, installing dependancies (as OpenSSL) and setting PATH:

# as root:
yum install ruby rubygems ruby-devel rubygem-bundler

Getting and running Metasploit

Install:

# as root in e.g. /opt
git clone https://github.com/rapid7/metasploit-framework.git msf
cd msf
yum -y install libpcap-devel sqlite-devel
./msfupdate

The installation of ruby modules will take a while. Then, configure the database by creating config/database.yml:

production:
    adapter: postgresql
    database: msfdb
    username: msf
    password: 
    host: 127.0.0.1
    port: 5432
    pool: 75
    timeout: 5

Launch it and have fun :

# as root
./msfconsole
# check connection to the database
db_status

You may want to add a cron entry in /etc/crontab to get regular updates (though it may break from time to time due to broken dependencies, so you are advised to check it sometimes):

# msfupdate every 2 hours
0 */2 * * * root /opt/msf/msfupdate 2>&1

As I started to use Fedora 20 at work – by the way, a solid distro with all security features enabled, I had the bad surprise to get similar issues to those on OS X.
Again, we will have to face the joy of dependencies! Fedora provides Ruby 2.0 by default, so firing msfconsole would fail with many openssl warnings, ending with:

/usr/share/ruby/openssl/cipher.rb:61:in `': superclass mismatch for class Cipher (TypeError)
from /usr/share/ruby/openssl/cipher.rb:22:in `'
from /usr/share/ruby/openssl/cipher.rb:21:in `'
from /usr/share/ruby/openssl.rb:20:in `require'
from /usr/share/ruby/openssl.rb:20:in `'
from /opt/pentest/exploit/msf/lib/msf/ui/console/driver.rb:144:in `require'
from /opt/pentest/exploit/msf/lib/msf/ui/console/driver.rb:144:in `initialize'
from ./msfconsole:148:in `new'
from ./msfconsole:148:in `'

While the installation steps are globally the same than on Mac, there are some specific issues with rbenv and Postgresql.

Preparing Postgresql

Install:

 yum -y install postgresql-server postgresql-devel

Initiate a new “cluster” and connect to the sql client through the postgres user:

# as root:
postgresql-setup initdb
systemctl restart postgresql.service
su postgres psql

Inside the psql console, create the new Metasploit user and its database:

create user msf;
alter user msf with encrypted password 'super password';
create database msfdb;
grant all privileges on database msfdb to msf;
\q

Then, we will tell to Postgres how to accept local connections. ident necessitates an system account, trust means no password for any local account and md5 stands for a classic password authentication, which we will prefer.
Add this line inside /var/lib/pgsql/data/pg_hba.conf and beware that the order is important:

# IPv4 local connections:
host msfdb msf 127.0.0.1/32 md5
host all all 127.0.0.1/32 ident

Then we can restart the service and check with psql that the credentials are working:

systemctl restart postgresql.service
psql -U msf msfdb -h localhost
\q

Setting Ruby

Metasploit runs well with Ruby 1.9.3, so we will install this version and switch to it using rbenv.
rbenv does a nice job at managing several version of ruby next to each other, installing dependancies (as OpenSSL) and setting PATH:

# as root:
# download and install rbenv
\curl -sSL https://get.rvm.io | bash
rvm install ruby-1.9.3 --autolibs=packages
rvm use ruby-1.9.3
# checking, should obviously return ruby 1.9.3
ruby --version

Getting and running Metasploit

Install:

# as root in e.g. /opt
git clone https://github.com/rapid7/metasploit-framework.git msf
cd msf
yum -y install rubygem-bundler libpcap-devel
bundle install

Configure the database creating config/database.yml:

production:
    adapter: postgresql
    database: msfdb
    username: msf
    password: 
    host: 127.0.0.1
    port: 5432
    pool: 75
    timeout: 5

Launch it and have fun :

ln -s /opt/msf/msf* /usr/local/bin
sudo -i msfconsole
# as root
./msfconsole
# check connection to the database
db_status

Note that the -i option of sudo is mandatory, as it resets the environment for security purposes. That way it will get the environment of the target user, root, which should be just fine if you set rbenv with that user.

UPDATE 02/27/2014: I had some issues starting Metasploit with sudo and I actually failed to find a satisfying solution. I am now just launching it as root and in its work directory.

It is recommended to add a cron entry in /etc/crontab for regular updates:

# msfupdate every 2 hours
0 */2 * * * root /opt/msf/msfupdate 2>&1

Getting Metasploit

First, let’s fetch Metasploit. Adjust the last two lines by replacing .zshrc (I am using Zsh) with .bash_profile if you are using Bash, for instance.

This will download, create symlinks and set the database settings path (we will come back on it later) in your environment:

cd /usr/local/share/
git clone https://github.com/rapid7/metasploit-framework.git
cd metasploit-framework
for MSF in $(ls msf*); do ln -s /usr/local/share/metasploit-framework/$MSF /usr/local/bin/$MSF;done
ln -s /usr/local/share/metasploit-framework/armitage /usr/local/bin/armitage
echo export MSF_DATABASE_CONFIG=/usr/local/share/metasploit-framework/config/database.yml >> ~/.zshrc
source ~/.zshrc

Metasploit is almost ready, but don’t run anything yet. There a still quite a few steps…

Getting Postgres

We use Homebrew:

brew install postgresql --without-ossp-build

Initialization stuff:

initdb /usr/local/var/postgres

To have launchd start postgresql at login:

ln -sfv /usr/local/opt/postgresql/*.plist ~/Library/LaunchAgents

But I prefer to keep my startup clean, so I added two aliases in my .zshrc

alias pg_start='pg_ctl -D /usr/local/var/postgres -l /usr/local/var/postgres/server.log start'
alias pg_stop='pg_ctl stop'

So you now have two commands, pg_start and pg_stop, to use for Metasploit.
Finally, we create the msf user that will connect to the database from within Metasploit:

createuser msf -P -h localhost  
createdb -O msf msf -h localhost 

While we are at the database stuff, let’s configure Metasploit to use it. Create a database.yml file in  /usr/local/share/metasploit-framework/config/ and put these lines:

production:
    adapter: postgresql
    database: msf
    username: msf
    password: <password>
    host: 127.0.0.1
    port: 5432
    pool: 75
    timeout: 5

The database is ready!

Getting Ruby

The last big step is to install Ruby. The one provided by Mac Os is a little too old, and you don’t want to mess with system libraries, so let’s leave it untouched. You could install Ruby with Homebrew, but it happens that the latest version (2.0.0-p0) is not working with Metasploit (OpenSSL libraries conflicts). So we need to use something like the 1.9.3 version of Ruby.

Anyway, a good practice is to have some flexibility on the version you are going to use, so you would be able to switch between 1.9.3, 2.0.0 or whatever and that whenever you need.

Here comes rbenv. For the next steps, I will assume that you have a working homebrew setting.

Let’s go:

brew install rbenv ruby-build

Add this line to your .zshrc or bash_profile:

eval "$(rbenv init -)"

Now you should be able to list all installable versions of Ruby:

rbenv install --list

Let’s pick up 1.9.3:

rbenv install 1.9.3-p392

It takes a while, but after it is completed, you can set it as your default:

rbenv rehash
rbenv global 1.9.3-p392

Note that you could use the local command instead of global to set it for the current terminal only.

Let’s check that everything is correctly set. This is where the Ruby versions are stored:

$ ls ~/.rbenv/versions/
1.9.3-p392 2.0.0-p0

ruby and gem MUST point to the 1.9.3 version:

$ rbenv which ruby
$HOME/.rbenv/versions/1.9.3-p392/bin/ruby
$ rbenv which gem
$HOME/.rbenv/versions/1.9.3-p392/bin/gem

Looks good, let’s go ahead.

We are now able to install up the required gems for Metasploit. They made it easy by packaging these in a Gemfile that can be read by the “bundle” utility:

gem install bundle
cd /usr/local/share/metasploit-framework
rbenv rehash
bundle install

Final steps

Create an vncviewer wrapper to facilitate use from within Metasploit:

echo '#!/usr/bin/env bash'  >> /usr/local/bin/vncviewer   
echo open vnc://\$1 >> /usr/local/bin/vncviewer  
chmod +x /usr/local/bin/vncviewer

Get and compile the pcaprub library (optional):

cd /usr/local/share/metasploit-framework/external
git clone http://github.com/shadowbq/pcaprub.git
cd ./ext/pcaprub
ruby extconf.rb && make && make install

Have fun!

If you haven’t, don’t forget to start Postgres, and you are ready to play:

sudo -E msfconsole

It should deploy the database structure and then start to work without warning. Hurrah! That was not hard, but a bit long, wasn’t it?

In case it still fails for you, it means that something went wrong with the setup. Check the steps again, and then leave a comment as it may be the time for an update or a correction of this article.

Credits

As stated in the introduction, this article is mostly taken from darkoperator.com with minor adjustments (it actually did not work out of the box for me), so the use of rbenv. I hope it will be helpful to other people in the same case as me.

UPDATE 09/07/2013:

• change in pcaprub directory (./pcaprub –> ./ext/pcaprub)

UPDATE 07/23/2013:

• add missing rbenv rehash command (thanks @amukofes)
• add missing commands to retrieve pcaprub (thanks @Ton)
• fix indentation in postgres config file

I had the opportunity to review this security software, and I want to share here the results of my tests.

McAfee bought the SolidCore solution and renamed it into McAfee Application Control (along with other features). For convenience, we will keep referring the solution as SolidCore.

In a few words, this tool falls into the category of white-listing defense systems. It hardens a Windows system by fingerprinting all executables files of the disk drive and enforcing access control based on this hash. Somehow a sort of Tripwire but with access control and attack detection.

The problem is that McAfee claims that the solution will protect unpatched systems. Such a claim is appealing, because in real life it is not always easy to patch systems in production. Beyond technical considerations, there is always business and management constraints. The solution of McAfee is supposed to prevent vulnerabilities to be triggered thanks to the memory protection features. Look on their website, they say it loudly: “you can delay patching and it protects from buffer overflows”.

MacAfee Application Control commercial sheet

Really? When you check more thoroughly, you find that the solution operates only in user-mode, leaving all kernel-mode issues on the side. Already, any security specialist should become suspicious and think about the numerous limitations it implies…

Anyway, such a statement deserves serious testing. Here we go.

Testing Lab

The testing environment is composed of:

• a Windows XP SP1 virtual machine (no patch),
• a Windows XP SP1 virtual machine (no patch) with SolidCore installed and enabled,
• a Windows virtual machine running WinDBG for kernel debugging,
• a Linux virtual machine running Metasploit (Backtrack),
• a few vulnerable programs: aurora.html for heap overflows and two executables vulnerable against buffer overflow,
• OllyDbg on both machines to observe the exploitation process.

The point is simple: test some vulnerabilities against unpatched systems, with and without SolidCore, and compare the results.

The purpose here is only to focus on what SolidCore is doing (though we are not going to attempt to reverse the application). I will not get here into explanations on assembly and memory exploitation, so please refer to the many great tutorials that can be found on the Internet.

As mentioned, I am myself a noob in reversing and shellcoding so please drop a comment if you see something wrong.

Installing SolidCore

Like Tripwire, SolidCore needs to take an image of the system when it is sane.

So, basically, after setting it, there are a few commands to type into a command window to scan the whole disk:

sadmin so
sadmin enable

It will look for executables (.exe, .dll, etc.) and build a database using SHA-1 hashes.

SolidCore commands and status after activation

Now, only applications installed before the scan will be allowed. If you drop a new file or move an existing one to a new patch and try to execute it, it will fail like this:

SolidCore blocks the execution of a new executable file

After that, whenever you need to install a new application, you have to go through the “update mode”. Just enter:

sadmin bu

At this moment, the protection is deactivated and you can execute anything. Then, you need to do a new scan and re-enable the protection as done previously.

Also, not all memory protections are activated by default. This is supposed to enable memory randomization (aka ALSR but McAfee made):

sadmin features enable mp-vasr

Now, see the enabled features:

SolidCore features list and memory protection (mp-vasr, mp-casp)

So far so good, now we can play!

Let’s see what is behind the scene…

The first thing to notice is that SolidCore installs a service launched with the LocalSystem account.

SolidCore service

SolidCore background service process

Let’s have a look within a kernel debugging session with WinDbg.

While booting, the target displays a lot of interesting info concerning the McAfee solution:

Solidcore log buf: F8418B60, F84415C0
K.0004.0008: Nov 30 2012:04:49:09.812: SYSTEM: rtinit.c : 1474: McAfee Solidifier driver version 6.0.1-9049
K.0004.0008: Nov 30 2012:04:49:09.828: SYSTEM: rtinit.c : 1476: DriverEntry @F846E500
K.0004.0028: Nov 30 2012:04:49:10.093: SYSTEM: imgp_rebase.c: 196: Rebased \Device\HarddiskVolume1\WINDOWS\system32\ntdll.dll to \Device\HarddiskVolume1\Solidcore\vasr\ntdll.dll at 0x5cda0000.
K.0004.0028: Nov 30 2012:04:49:10.500: SYSTEM: rtinit.c : 129: Booting up with RTEMode = 1
[...]
K.0432.0436: Nov 30 2012:04:49:15.671: ERROR: cap_kern.c : 1106: Failed to compute checksum for '\Device\HarddiskVolume1\WINDOWS\system32\autochk.exe'. err = 1099
K.0432.0436: Nov 30 2012:04:49:15.796: SYSTEM: imgp_rebase.c: 196: Rebased \Device\HarddiskVolume1\WINDOWS\system32\kernel32.dll to \Device\HarddiskVolume1\Solidcore\vasr\kernel32.dll at 0x65d60000.
K.0432.0436: Nov 30 2012:04:49:15.828: SYSTEM: imgp.c : 3114: Starting decoying of \Device\HarddiskVolume1\Solidcore\vasr\kernel32.dll (\Device\HarddiskVolume1\Solidcore\k32_c__v.dll)
K.0432.0436: Nov 30 2012:04:49:15.890: SYSTEM: imgp.c : 3118: Finished decoying of \Device\HarddiskVolume1\Solidcore\vasr\kernel32.dll (\Device\HarddiskVolume1\Solidcore\k32_c__v.dll) with err = 0
K.0432.0436: Nov 30 2012:04:49:15.953: SYSTEM: imgp_rebase.c: 196: Rebased \Device\HarddiskVolume1\WINDOWS\system32\user32.dll to \Device\HarddiskVolume1\Solidcore\vasr\user32.dll at 0x48c60000.
K.0732.0828: Nov 30 2012:04:49:20.859: SYSTEM: utl.c : 500: Failed to find username, err 0xc000020c, perhaps the service is not running.
K.1312.1316: Nov 30 2012:04:49:21.281: SYSTEM: pkgc_misc.c : 679: Rebased \Device\HarddiskVolume1\Solidcore\pkgc\10980000\Device\HarddiskVolume1\WINDOWS\system32\_si.dll to 10980000
K.1312.1316: Nov 30 2012:04:49:21.390: ERROR: imgp.c : 3190: 0001 Failed to set branch target 0x10c46740 from 0x00000000 at VA 0x10a56760.
K.0732.0828: Nov 30 2012:04:49:23.875: SYSTEM: utl.c : 520: Retrying usermode lookup of username [1].
K.0732.0828: Nov 30 2012:04:49:23.890: SYSTEM: utl.c : 476: Found username as WINXP-MCAFEE\phocean
K.1904.1932: Nov 30 2012:04:49:27.078: SYSTEM: pkgc_misc.c : 679: Rebased \Device\HarddiskVolume1\Solidcore\pkgc\20170000\Device\HarddiskVolume1\WINDOWS\system32\_si.dll to 20170000
K.1904.1932: Nov 30 2012:04:49:27.453: ERROR: imgp.c : 3190: 0002 Failed to set branch targ et 0x20436740 from 0x00000000 at VA 0x20246760.
[...]

We learn the driver entry point and that it is relocating a few strategic DLL: ntdll, kernel32, user32 and _si.dll. Ntdll, kernel32 and user32 are obviously the main user-mode API of Windows and we can expect that SolidCore is also putting a few hooks inside them. _si.dll is part of SolidCore and appear to be unlinked while the system is running.

Let’s look around modules to confirm the position fo the driver:

SolidCore driver (WinDbg kernel debugging)

So, the McAfee driver is named swin. Quickly looking around, we also find that a DLL is injected in all processes: scinject.dll. Also, see on the screenshot, how kernel32 was effectively relocated. So every time the machine will start, the library will be located at a different address (it could be interesting to check the entropy of this randomization, by the way, but this is another topic).

McAfee SolidCore injects the DLL “scinject.dll” in running processes.

Just to make sure, I checked that the dll does not get injected by the registry setting:

McAfee SolidCore does not use AppInit_DLLs

Nothing there, so it must be done through a hook.

First tests: Metasploit

I was told that SolidCore was doing good against Metasploit, so one of the first thing I did was to fire up Backtrack and play with it against the SP1 “solidified” target.

And I have to say that I was quickly disapointed.

Sure, I could not get a Meterpreter session or get a standard payload to work out of the box, whereas it was a piece of cake on the standard SP1.

SolidCore prevents standard Metasploit payloads (including Meterpreter) to run successfully.

But if SolidCore was at least disturbing the exploitation, it did not protect at all against the vulnerability itself. So I got things like this:

Denial of Service during exploitation attempt with Metasploit: SolidCore will not magically “patch” vulnerabilities!

A good old denial of service. Note that on the event log, SolidCore itself doesn’t log the exploitation attempt.

I did several tests and depending on the vulnerability I got:

• service crash
• system instability
• complete DoS (system shutdown)

It was not really a surprise: McAfee will not patch the system! But think twice when you are said the contrary…

More tests, about memory protection: buffer overflows

As I was also told that McAfee was protecting user-mode apps against buffer overflows, I was even more excited.

I prepared various representative tests:

• heap overflow, based on Aurora
• stack overflows (one base on strcpy, the other one on Windows CreateFile)

But first, one thing I wanted to quickly eliminate was the memory randomization feature, named mp-vasr:

SolidCore mp-vasr IS NOT ALSR

mp-vasr is not ALSR! The function gets always loaded at the same memory address, so there is not process memory randomization at all… Another disappointment…

Next step was to try to exploit the stack overflow. The first payload I used displays a message box. It calls LoadLibrary and GetProcAddress to dynamically resolve function addresses.

When we try to exploit the buffer overflow, we get this:

SolidCore causes memory access violation during shellcode injection

We have a memory access violation, because the code is trying the access to the address NULL. Weird, let’s see it with OllyDbg.

First, there is something that looks like a hook in ntdll:

SolidCore checking against PE signature

So this thing is checking the code for a PE signature (5A4D). Then, it will go through scinject.dll (by calling casp_inject_save_addr, wich is the only exported function).

I could not reverse it (which would require much more time and skills than I have now), but at least we know where it is sitting and how it is triggered.

If we continue the execution, we can then see that the buffer overflow is happening very well:

SolidCore does not prevent stack overflow!

Yes, we have the stack is fully overflowed and we can control EIP! So nothing should prevent us from exploiting it, shouldn’t it? ;-)

Here we go:

This first payload is low-tech, with hardcoded addresses of MessageBoxA and ExitProcess:

global _start

_start:

 ;MessageBoxA(windowhandle,msg,title,type)
 mov ebx, 0xEEEEEEEF
 add ebx, 0x11111111 ;\0
 push ebx
 push 0x293a2064 ;d :)
 push 0x656e7770 ;pwne
 mov ecx, esp
 xor edx,edx
 push edx ;OK button
 push ecx ;title
 push ecx ;message
 push edx ;NULL window handle
 mov eax, 0x6a216476 ;MessageBoxA
 call eax
 ;exit
 xor edx,edx ;empty edx out
 push edx ;move address of MessageBoxA onto stack
 mov eax, 0x5cdb98fd ;ExitProcess(exitcode);
 call eax ;exit cleanly so we don't crash parent

Let’s how it looks in OllyDbg:

Buffer overflow exploitation despite McAfee Application Control

I then tested with another more sophisticated shellcode (sorry, I cannot publish this one as I am not the author), which resolves dynamically the addresses of kernel32 and GetProcAddress. It works as well. The only caveat that I observed is that LoadLibraryA is systemically blocked (after going through some scinject.dll routines, it always returns 0 in EAX, wich means failure).

In other words, a simple shellcode will work as long as the necessary library are loaded. Though most real life programs will already come with at least kernel32 and user32, it still gives a lot of opportunities.

And then, with more shellcoding kung-fu, I am sure it is possible to get something even more target independant. The following two articles from Phrack probably give most hints to achieve this:

• Phrack62: Bypassing third-party Windows Buffer Overflow Protection
• Phrack63: NT Shellcodes Prevention demystified

But I need much more knowledge and practice in shellcoding before I can get something to work. I will see it later, and let me know if you could go ahead yourself.

Conclusion

Clearly, McAfee Application Control aka SolidCore is not an efficient protection against buffer overflows. If you want something much better, update your systems to something like Windows 7 64 bits and use Microsoft EMET to force DEP and ALSR on programs that don’t support it by default.

Also, no way to delay patching because you have SolidCore. Full exploitation (shellcode) is just made a little bit more difficult, and that’s it. The systems will still be exposed to many risks like denial of service unless they are patched. Like always, defense in depth and a proper security policy are the foundations to decide on the patching policy, not a tool or a feature.

This is a pity that the marketing teams give the wrong message, because McAfee still surely addresses many use cases. It is surely efficient enough to improve the control on workstations, that, for some reason, are difficult to control. For example, SolidCore will probably be enough to prevent the average Joe to mess the system. Why not being honest and keeping focus on this feature?

On the other hand, if the McAfee guys want to be as ambitious as they claim,  they will have to move SolidCore to the kernel-mode and enhance the memory protections from there.

It happens with bad implementations where the DNAT (destination NAT) and the SNAT (source NAT) use a different IP because of a wrong rule or because the outbound and inbound interfaces are separated.

As a result, the operating system of the client will discard right away such a reply (with a TCP RST), because it does not match an existing TCP session.

The idea is that a pentester auditing such an infrastructure with a classic scanner will miss some entry points. A typical scanner relies on the network stack of the system : it will not receive the reply and will consider the port as filtered.

So Jonathan came with a proof-of-concept to illustrate his purpose.

It is composed of a B-Router and a client. The B-Router will intercept the reply and maintain the session by sending an ACK. This way, it handles an asymetric routing scheme for the client. Just add a filtering rule to block your system’s RST (iptables -A OUTPUT -p tcp –tcp-flags RST RST -j DROP ), and you are good to go.

Simple but brilliant, isn’t it ? The great thing is that the code has now been included in Metasploit, so it is even more straightforward.

Check the slides of Jonathan at DEFCON for more info. You can download the source there (or just update your Metasploit and look for it in auxiliaries).