c0d3 :: j0rg3

A collection of tips, tricks and snips. A proud Blosxom weblog. All code. No cruft.

Tue, 10 Jan 2017

[-] Auxiliary failed: Msf::OptionValidateError The following options failed to validate: RHOSTS.

Mucking about with a fresh copy of Kali brings to attention that it’s packaged with an Armitage that doesn’t correctly work.

I know what you’re thinking… Good. Type the commands into Msfconsole like a real man, y’uh lazy good-fer-naught! And, in practice, that was my immediate solution. But I can’t resist a good tinker when things are misbehaving.

I was anticipating that the problem would be thoroughly solved when I ixquicked it. That was partially correct. Surprised, however, when apt-get update && apt-get upgrade didn’t fix the issue. More surprised at the age of the issue. Most surprised that I could see lots of evidence that users have been plagued by this issue — but no clear work arounds were quickly found.

Guess what we’re doing today?

Okay. The issue is quite minor but just enough to be heartbreaking to the fledgling pentester trying to get a VM off the ground.

In brief, the owner of Armitage’s Github explains:

The MSF Scans feature in Armitage parses output from Metasploit’s portscan/tcp module and uses these results to build a list of targets it should run various Metasploit auxiliary modules against. A recent-ish update to the Metasploit Framework changed the format of the portscan/tcp module output. A patch to fix this issue just needs to account for the new format of the portscan/tcp module.

That is, a colon makes it into the input for the Msfconsole command to define RHOSTS. I.e.: set RHOSTS 172.16.223.150: - 172.16.223.150

An other kind coder tweaked the regex and submitted the patch and pull request, which was successfully incorporated into the project.

Sadly, things have stalled out there. So if this problem is crippling your rig, let’s fix it!

We just want a fresh copy of the project.
root@kali:~/armitage# git clone https://github.com/rsmudge/armitage

Cloning into ‘armitage’…
remote: Counting objects: 7564, done.
remote: Total 7564 (delta 0), reused 0 (delta 0), pack-reused 7564
Receiving objects: 100% (7564/7564), 47.12 MiB | 2.91 MiB/s, done.
Resolving deltas: 100% (5608/5608), done.

Kali is Debian-based and we’re going to need Apache Ant:
root@kali:~/armitage# apt-get install ant

Then, we’ll build our new fella:
root@kali:~/armitage# cd armitage
root@kali:~/armitage# ./package.sh

Buildfile: /root/test/armitage/build.xml

clean:

BUILD SUCCESSFUL
Total time: 0 seconds
Buildfile: /root/test/armitage/build.xml

init:
[mkdir] Created dir: /root/test/armitage/bin

compile:
[javac] Compiling 111 source files to /root/test/armitage/bin
[javac] depend attribute is not supported by the modern compiler
[javac] Note: /root/test/armitage/src/ui/MultiFrame.java uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.

BUILD SUCCESSFUL
Total time: 2 seconds
Buildfile: /root/test/armitage/build.xml

init:

compile:

jar:
[unzip] Expanding: /root/test/armitage/lib/sleep.jar into /root/test/armitage/bin
[unzip] Expanding: /root/test/armitage/lib/jgraphx.jar into /root/test/armitage/bin
[unzip] Expanding: /root/test/armitage/lib/msgpack-0.6.12-devel.jar into /root/test/armitage/bin
[unzip] Expanding: /root/test/armitage/lib/postgresql-9.1-901.jdbc4.jar into /root/test/armitage/bin
[unzip] Expanding: /root/test/armitage/lib/javassist-3.15.0-GA.jar into /root/test/armitage/bin
[copy] Copying 4 files to /root/test/armitage/bin/scripts-cortana
[jar] Building jar: /root/test/armitage/armitage.jar
[jar] Building jar: /root/test/armitage/cortana.jar

BUILD SUCCESSFUL
Total time: 1 second
armitage/
armitage/readme.txt
armitage/teamserver
armitage/cortana.jar
armitage/armitage.jar
armitage/armitage-logo.png
armitage/armitage
armitage/whatsnew.txt
adding: readme.txt (deflated 55%)
adding: armitage.exe (deflated 49%)
adding: cortana.jar (deflated 5%)
adding: armitage.jar (deflated 5%)
adding: whatsnew.txt (deflated 65%)
armitage/
armitage/readme.txt
armitage/teamserver
armitage/cortana.jar
armitage/armitage.jar
armitage/armitage-logo.png
armitage/armitage
armitage/whatsnew.txt
Archive: ../../armitage.zip
inflating: readme.txt
inflating: armitage.exe
inflating: cortana.jar
inflating: armitage.jar
inflating: whatsnew.txt

And here, best I can guess from messages read, is where a lot of people are running into trouble. We have successfully produced our new working copy of armitage. However, it is in our own local directory and will not be run if we just enter the command: armitage

Let’s review how to figure out what we want to do about that.

First, we want to verify what happens when we run the command armitage.
root@kali:~/armitage# which armitage

/usr/bin/armitage

Good! Let’s check and see what that does!
root@kali:~/armitage# head /usr/bin/armitage

#!/bin/sh

cd /usr/share/armitage/
exec ./armitage “$@”

Almost there! It’s running /usr/share/armitage/armitage with whatever variables we’ve passed in. We’ll check that out.
root@kali:~/armitage# head /usr/share/armitage/armitage

#!/bin/sh
java -XX:+AggressiveHeap -XX:+UseParallelGC -jar armitage.jar $@

We have enough information to assemble a solution.

I trust that the people behind Kali and Armitage will get this corrected so I don’t want to suggest a solution that would replace the armitage command and prevent an updated version from running later. So, let’s just make a temporary replacement?

root@kali:~/armitage# echo -e '#!/bin/sh\njava -XX:+AggressiveHeap -XX:+UseParallelGC -jar ~/armitage/armitage.jar $@' > /usr/bin/tmparmitage

Hereafter, we can use the command ‘tmparmitage’ (either CLI or ALT-F2) to run our fresh version until things catch up.

And, of course, to save you the time, weary hacker:

Download here:
    armitage_quick_fix.sh


Tags: , , , , , , ,
Permalink: 20170110.armitage.not.working.in.kali

Tue, 20 Dec 2016

Kicking the Crypto-tires

Some time ago I had begun work on my own Pastebin-type project with a few goals. Basically, I wanted to eat all the cakes — and have them too.

  • Both an online user interface and efficient CLI usage
  • Messages encrypted immediately such that database access does not provide one with the contents of the messages
  • Messages capable of self-destructing
  • Database schema that would allow rebuilding the user/message relationship, provided the same password but would not store those relationships
  • Also, JavaScript encryption to appeal to users who don’t know much about cryptography but would like to try
  • The project, honestly, was going swimmingly when derailed by the goings-on of life.

    One of the interesting components of the project was, of course, choosing crypto implementations. There are know shortcomings to handling it in JS but that’s still the most convenient for some users. Outside of the browser, server-side, you had all the same questions about which solution was best. Which protocol(s) should be available?

    Well, I’ve just learned about a project which I would have loved to have available back then. Project Wycheproof can help you test your crypto solutions against known problems and attacks. Featuring 80 tests probing at 40 known bugs, here’s a snip from the introduction:

    Project Wycheproof has tests for the most popular crypto algorithms, including

  • AES-EAXAES-GCM
  • AES-GCM
  • DH
  • DHIES
  • DSA
  • ECDH
  • ECDSA
  • ECIES
  • RSA
  • The tests detect whether a library is vulnerable to many attacks, including

  • Invalid curve attacks
  • Biased nonces in digital signature schemes
  • Of course, all Bleichenbacher’s attacks
  • And many more — we have over 80 test cases
  • Interesting stuff with exciting potential!


    Tags: , ,
    Permalink: 20161220.kicking.the.crypto.tires

    Sat, 25 Jan 2014

    Network-aware Synergy client

    My primary machines are *nix or BSD variants, though I certainly have some Windows-based rigs also. Today we’re going to share some love with Windows 7 and PowerShell.

    One of my favorite utilities is Synergy. If you’re not already familiar it allows to you seamlessly move from the desktop of one computer to another with the same keyboard and mouse. It even supports the clipboard so you might copy text from a GNU/Linux box and paste it in a Windows’ window. Possibly, they have finished adding drag and drop to the newer versions. I am not sure because I run a relatively old version that is supported by all of the machines that I use regularly.

    What’s the problem, then? The problem was that I was starting my Synergy client by hand. Even more disturbing, I was manually typing the IP address at work and at home, twice or more per weekday. This behavior became automated by my brain and continued for months unnoticed. But this is no kind of life for a geek such as myself, what with all this superfluous clicking and tapping!

    Today, we set things right!

    In my situation, the networks that I use happen to assign IP addresses from different subnets. If you’ve not the convenience of that situation then you might need to add something to the script. Parsing an ipconfig/ifconfig command, you could possibly use something like the Default Gateway or the Connection-specific DNS Suffix. Alternatively, you could check for the presence of some network share, a file on server or anything that would allow you to uniquely identify the surroundings.

    As I imagined it, I wanted the script to accomplish the following things

    • see if Synergy is running (possibly from the last location), if so ask if we need to kill it and restart so we can identify a new server
    • attempt to locate where we are and connect to the correct Synergy server
    • if the location is not identified, ask whether to start the Synergy client

    This is how I accomplished that task:

    # [void] simply supresses the noise made loading 'System.Reflection.Assembly'
    [void] [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")

    # Define Synergy server IP addresses
    $synergyServerWork = "192.168.111.11"
    $synergyServerHome = "192.168.222.22"

    # Define partial IP addresses that will indicate which server to use
    $synergyWorkSubnets = "192.168.111", "192.168.115"
    $synergyHomeSubnets = "192.168.222", "192.168.225"

    # Path to Synergy Client (synergyc)
    $synergyClientProgram = "C:\Program Files\Synergy\synergyc.exe"

    # Path to Syngery launcher, for when we cannot identify the network
    $synergyLauncherProgram = "C:\Program Files\Synergy\launcher.exe"

    # Remove path and file extension to give us the process name
    $processName = $synergyClientProgram.Substring( ($synergyClientProgram.lastindexof("\") + 1), ($synergyClientProgram.length - ($synergyClientProgram.lastindexof("\") + 5) ))

    # Grab current IP address
    $currentIPaddress = ((ipconfig | findstr [0-9].\.)[0]).Split()[-1]

    # Find the subnet of current IP address
    $location = $currentIPaddress.Substring(0,$currentIPaddress.lastindexof("."))


    function BalloonTip ($message)
    {
    # Pop-up message from System Tray
    $objNotifyIcon = New-Object System.Windows.Forms.NotifyIcon
    $objNotifyIcon.Icon = [System.Drawing.Icon]::ExtractAssociatedIcon($synergyClientProgram)
    $objNotifyIcon.BalloonTipText = $message
    $objNotifyIcon.Visible = $True
    $objNotifyIcon.ShowBalloonTip(15000)
    }


    #main

    # If Synergy client is already running, do we need to restart it?
    $running = Get-Process $processName -ErrorAction SilentlyContinue
    if ($running) {
    $answer = [System.Windows.Forms.MessageBox]::Show("Synergy is running.`nClose and start again?", "OHNOES", 4)
    if ($answer -eq "YES") {
    Stop-Process -name $processName
    }
    Else {
    exit
    }
    }

    # Do we recognize the current network?
    if ($synergyWorkSubnets -contains $location) {
    BalloonTip "IP: $($currentIPaddress)`nServer: $($synergyServerWork)`nConnecting to Synergy server at work."
    & $synergyClientProgram $synergyServerWork
    exit
    }
    ElseIf ($synergyHomeSubnets -contains $location) {
    BalloonTip "IP: $($currentIPaddress)`nServer: $($synergyServerHome)`nConnecting to Synergy server at home."
    & $synergyClientProgram $synergyServerHome
    exit
    }
    Else {
    $answer = [System.Windows.Forms.MessageBox]::Show("Network not recognized by IP address: {0}`n`nLaunch Synergy?" -f $unrecognized, "OHNOES", 4)
    if ($answer -eq "YES") {
    & $synergyLauncherProgram
    }
    }

    Then I saved the script in "C:\Program Files\SynergyStart\", created a shortcut and used the Change Icon button to make the same as Synergy’s and made the Target:
    C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -WindowStyle Hidden & 'C:\Program Files\SynergyStart\synergy.ps1'

    Lastly, I copied the shortcut into the directory of things that run when the system starts up:
    %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup

    Now, Synergy connects to the needed server at home and work. If it can’t figure out where it is, it asks if it should run it at all.

    As they say, a millisecond saved is a millisecond earned.

    This post was very nearly published without a Linux equivalent. Nearly.

    Same trick for bash/zsh: #!/bin/zsh

    # Define Synergy server IP addresses
    synergyServerWork="192.168.111.11"
    synergyServerHome="192.168.222.22"

    # Define partial IP addresses that will indicate which server to use
    synergyWorkSubnets=("192.168.111" "192.168.115")
    synergyHomeSubnets=("192.168.222" "192.168.225")

    # Path to Synergy Client (synergyc)
    synergyClientProgram="/usr/bin/synergyc"

    # Path to QuickSyngery, for when we cannot identify the network
    synergyLauncherProgram="/usr/bin/quicksynergy"

    # Remove path and file extension to give us the process name
    processName=`basename $synergyClientProgram`

    # Grab current IP address, assumes '192' is in use. (e.g., 192.168.1.1)
    currentIPaddress=`ip addr show | grep 192 | awk "{print $2}" | sed 's/inet //;s/\/.*//;s/ //g'`

    # Find the subnet of current IP address
    location=`echo $currentIPaddress | cut -d '.' -f 1,2,3`

    for i in "${synergyWorkSubnets[@]}"
    do
    if [ "${i}" = "${location}" ]
    then
    break
    fi
    done

    #main

    # If Synergy client is already running, do we need to restart it?
    running=`ps ax | grep -v grep | grep $processName`
    if [ $running ]
    then
    if `zenity --question --ok-label="Yes" --cancel-label="No" --text="Synergy is running.\nClose and start again?"`
    then
    pkill $processName
    else
    exit
    fi
    fi

    # Do we recognize the current network?
    for i in "${synergyWorkSubnets[@]}"
    do
    if [ "${i}" = "${location}" ]
    then
    notify-send "IP:$currentIPaddress Server:$synergyServerWork [WORK]"
    $synergyClientProgram $synergyServerWork
    exit
    fi
    done

    for i in "${synergyHomeSubnets[@]}"
    do
    if [ "${i}" = "${location}" ]
    then
    notify-send "IP:$currentIPaddress Server:$synergyServerWork [HOME]"
    $synergyClientProgram $synergyServerHome
    exit
    fi
    done

    if `zenity --question --ok-label="Yes" --cancel-label="No" --text="Network not recognized by IP address: $currentIPaddress\nLaunch Synergy?"`
    then
    $synergyLauncherProgram
    fi

    To get it to run automatically, you might choose to call the script from /etc/init.d/rc.local.

    Download here:
      PowerShell:
        synergy.ps1
      GNU/Linux:
        synergy.sh


    Tags: , ,
    Permalink: 20140125.network_aware_synergy_client