official Kali Linux image

1,369 views
Skip to first unread message

Andrea Barisani

unread,
Jun 15, 2015, 5:07:58 AM6/15/15
to usba...@googlegroups.com

Hello everyone,

FYI Offensive Security has published an official image for the USB armory, available at the following URL:


As a reminder we are keeping track of all available distributions on the wiki at the following URL:

Cheers

omnis

unread,
Jul 10, 2015, 8:30:29 AM7/10/15
to usba...@googlegroups.com
I bought myself a USB Armory solely for the purpose of installing the Kali image and have been getting very frustrated. It keeps refusing connections. The steps I have taken are as follows:
1. Downloaded and verified the image (via SHA1Sum)
2. Used USB Image Tool with a 64GB MicroSD Card (class 10)
3. Downloaded and installed the RNDIS driver for Windows 7 64 bit
4. Shared my existing internet connection with the new device
5. Configured the adapter's IPv4 settings of where IP=192.168.137.2, subnet=255.255.255.0, and gateway/dns=192.168.137.1
6. Attempted SSH connection via Putty with username/pass combos of root/toor/changeme/kali/toortoor, but to no avail.
Are the SSH and VNC credentials root/toor? If not, what are they?
Is there a place with more specific detailed information for the Kali image?
Is there an IRC that is specific to the Kali/Armory?
Please let me know where I can obtain more information. I'm very excited to learn more. Thanks!

omnis

unread,
Jul 10, 2015, 8:38:30 AM7/10/15
to usba...@googlegroups.com
I should also mention  that I've executed a Zemap scan of the 192.168.137.2 and I can see that there are in fact various services running including VNC and SSH, and many others. Is there a web interface? Thanks again.


On Monday, June 15, 2015 at 2:07:58 AM UTC-7, Andrea Barisani wrote:

Andrea Barisani

unread,
Jul 10, 2015, 9:19:42 AM7/10/15
to usba...@googlegroups.com, thisisj...@gmail.com
On Friday, July 10, 2015 at 2:30:29 PM UTC+2, omnis wrote:
I bought myself a USB Armory solely for the purpose of installing the Kali image and have been getting very frustrated. It keeps refusing connections. The steps I have taken are as follows:
1. Downloaded and verified the image (via SHA1Sum)
2. Used USB Image Tool with a 64GB MicroSD Card (class 10)
3. Downloaded and installed the RNDIS driver for Windows 7 64 bit
4. Shared my existing internet connection with the new device
5. Configured the adapter's IPv4 settings of where IP=192.168.137.2, subnet=255.255.255.0, and gateway/dns=192.168.137.1
6. Attempted SSH connection via Putty with username/pass combos of root/toor/changeme/kali/toortoor, but to no avail.
Are the SSH and VNC credentials root/toor? If not, what are they?
Is there a place with more specific detailed information for the Kali image?
Is there an IRC that is specific to the Kali/Armory?
Please let me know where I can obtain more information. I'm very excited to learn more. Thanks!


I am not responsible for the Kali Linux image and I understand that there is some lack of documentation about it, I'll see to get this improved and/or add information on our wiki.

I just downloaded the Kali image to support you.

First of all your step number 5 should only happen after first connection with the USB armory is achieved and only after its IP address has been changed. The Internet Connection Sharing feature of windows require a specific IP address on the RNDIS host interface (192.168.137.1) and a specific subnet on the USB armory address (192.168.137.2) as noted at https://github.com/inversepath/usbarmory/wiki/Host-communication#setup--connection-sharing-windows-78 This requires changing the USB armory interface configuration on the USB armory itself, for this reason this step can only be done later on.

For now let us focus on obtaining connection to the USB armory, without connection sharing. All steps are similar for all available images, the only difference would be that IP addresses and default credentials might change.

Also note that when the Kali Linux image for the USB armory successfully boots, the LED should be blinking (indicating CPU activity), if this does not happen then your image was not flashed correctly, this is similar for other available images. Always remember to image the *uncompressed* image (.img) and not the compressed one (.img.xz).

Then please note that the Kali Linux 1.1.1 image uses the default IP address of 10.42.0.3 (with gateway 10.42.0.1), which is why your steps do not work, as you prematurely tried to use ICS with subnets that the USB armory with Kali does not recognize. (this can be also seen at https://github.com/offensive-security/kali-arm-build-scripts/blob/master/usbarmory.sh)

Therefore you should set your RNDIS interface on windows to static IP address 10.42.0.1, netmask 255.255.255.0 and that would allow you to SSH to the USB armory.

The Kali Linux image starts the OpenSSH daemon on port 22 and a web based console (shellinaboxd) on port 4200.

Finally when you are ready to use ICS please note that your attempt is incorrect as you are setting the RNDIS adapter to 192.168.137.2, which should be otherwise automatically set to 192.168.137.1 when ICS gets enabled. 192.168.137.2 is the IP address on the USB armory side, which also uses 192.168.137.1 as gateway. 

The gateway is specified on the USB armory and *not* on the adapter settings.

Therefore in order to use ICS:

1. change the network configuration (/etc/network/interfaces) *on* the USB armory so that 'usb0' interface gets assigned 192.168.137.2 with gateway 192.168.137.1

2. reboot the USB armory

3. enable ICS sharing, this should automatically prompt and set 192.168.137.1 as the static IP address for your RNDIS interface, please ensure that this is the case.

4. now you should be able to SSH to the USB armory using 192.168.137.2 and the USB armory should be able to use the shared Internet connection

I hope this is clear enough, otherwise let me know and I'll provide further support.

Thanks!
 

an...@semjonov.de

unread,
Aug 29, 2015, 9:41:03 AM8/29/15
to USB armory
On Friday, July 10, 2015 at 3:19:42 PM UTC+2, Andrea Barisani wrote:
On Friday, July 10, 2015 at 2:30:29 PM UTC+2, omnis wrote:
...

Also note that when the Kali Linux image for the USB armory successfully boots, the LED should be blinking (indicating CPU activity), if this does not happen then your image was not flashed correctly, this is similar for other available images. Always remember to image the *uncompressed* image (.img) and not the compressed one (.img.xz).

Hi Andrea,

if may 'hijack' this conversation ..
I received a USB armory in the mail today, and was eager to try it out, so I put a Kali image on my microSD right away.

I had some problems with accessing it at all, but that turned out to be a wrong network configuration (was using the wrong ip when adding the subnet to usb0, I am running an Ubuntu Gnome client)
Now I can successfully ssh into it, can see the exposed web server etc. ..

However .. during all this time I have never even seen the LED blink or flicker for a second.
None of the commands on https://github.com/inversepath/usbarmory/wiki/GPIOs make it light up, there is no heartbeat, etc ...
Also: should it light up when inserting the armory in a USB without a SD card? This might help cross out incompatible/improper images.

Right now, it's just a minor inconvenience, not knowing whether it's actually doing anything or not .. but anyway: would you have any pointers as to what I might try to check if its working?

Cheers,
Anton

 

Andrea Barisani

unread,
Aug 29, 2015, 11:18:10 AM8/29/15
to USB armory, an...@semjonov.de
On Saturday, August 29, 2015 at 3:41:03 PM UTC+2, an...@semjonov.de wrote:
On Friday, July 10, 2015 at 3:19:42 PM UTC+2, Andrea Barisani wrote:
On Friday, July 10, 2015 at 2:30:29 PM UTC+2, omnis wrote:
...

Also note that when the Kali Linux image for the USB armory successfully boots, the LED should be blinking (indicating CPU activity), if this does not happen then your image was not flashed correctly, this is similar for other available images. Always remember to image the *uncompressed* image (.img) and not the compressed one (.img.xz).

Hi Andrea,

if may 'hijack' this conversation ..
I received a USB armory in the mail today, and was eager to try it out, so I put a Kali image on my microSD right away.

I had some problems with accessing it at all, but that turned out to be a wrong network configuration (was using the wrong ip when adding the subnet to usb0, I am running an Ubuntu Gnome client)
Now I can successfully ssh into it, can see the exposed web server etc. ..


Yes the Kali Linux image uses a different IP address, I assumed that you had to change it according to our FAQ (https://github.com/inversepath/usbarmory/wiki/Frequently-Asked-Questions-(FAQ)).
 
However .. during all this time I have never even seen the LED blink or flicker for a second.
None of the commands on https://github.com/inversepath/usbarmory/wiki/GPIOs make it light up, there is no heartbeat, etc ...
Also: should it light up when inserting the armory in a USB without a SD card? This might help cross out incompatible/improper images.

Right now, it's just a minor inconvenience, not knowing whether it's actually doing anything or not .. but anyway: would you have any pointers as to what I might try to check if its working?


Unfortunately the instructions on the wiki apply to our official image, not to the Kali linux image which is not under our responsibility. We can't keep track of the individual behavior of all images, though we do advertise maintainers to keep things as close as possible to ours (like Arch is doing regarding LED and network behavior).

The LED should light up (though not at full brightness so you might not notice it in sunlight) when powered on. The blinking LED depends on the startup behavior of the specific Linux that is booting up.

Hope this helps.

Cheers
 
Cheers,
Anton

 

omnis

unread,
Apr 17, 2016, 11:37:32 PM4/17/16
to USB armory, thisisj...@gmail.com

Hello Andrea,

Thank you for all of your support. I apologize for my tardy response. I have been going to school for linux certification, in part because I simply wanted to further work on this! Anyways, now I am aware of more of the things I should be looking at when setting this up. So, let me give you some more information about what’s happening here. I heeded your advice to avoid internet connection sharing via Windows 10 Pro 64 bit (my current box). I applied IPv4 addressing as follows:

IPv4 Address: 10.0.0.3 (conflict when using 10.0.0.2 – possibly a vmware virtual adapter conflict)

IPv4 Subnet Mask: 255.255.255.0

IPv4 Default Gateway: 10.0.0.1

DNS: (left empty)

There is a reply when it is pinged in a cmd prompt.

Via my windows box previously mentioned, I used Ext2FSD to allow me to mount the sdcard and perform modifications from within windows. Not sure if that messed up my permissions, will have to check on that. I edited the files with Notepad ++. Here are the changes I have made…

I have configured the ssh_config as follows:

 

# This is the ssh client system-wide configuration file.  See

# ssh_config(5) for more information.  This file provides defaults for

# users, and the values can be changed in per-user configuration files

# or on the command line.

 

# Configuration data is parsed as follows:

#  1. command line options

#  2. user-specific file

#  3. system-wide file

# Any configuration value is only changed the first time it is set.

# Thus, host-specific definitions should be at the beginning of the

# configuration file, and defaults at the end.

 

# Site-wide defaults for some commonly used options.  For a comprehensive

# list of available options, their meanings and defaults, please see the

# ssh_config(5) man page.

 

Host *

   ForwardAgent yes

   ForwardX11 yes

   ForwardX11Trusted yes

   RhostsRSAAuthentication yes

   RSAAuthentication yes

   PasswordAuthentication yes

   HostbasedAuthentication yes

#   GSSAPIAuthentication no

#   GSSAPIDelegateCredentials no

#   GSSAPIKeyExchange no

#   GSSAPITrustDNS no

#   BatchMode no

#   CheckHostIP no

   AddressFamily any

#   ConnectTimeout 0

#   StrictHostKeyChecking ask

   IdentityFile ~/.ssh/identity

   IdentityFile ~/.ssh/id_rsa

   IdentityFile ~/.ssh/id_dsa

   Port 22

   Protocol 2,1

#   Cipher 3des

#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc

#   MACs hmac-md5,hmac-sha1,uma...@openssh.com,hmac-ripemd160

#   EscapeChar ~

   Tunnel yes

   TunnelDevice any:any

   PermitLocalCommand yes

   VisualHostKey yes

#   ProxyCommand ssh -q -W %h:%p gateway.example.com

#   RekeyLimit 1G 1h

    SendEnv LANG LC_*

    HashKnownHosts yes

    GSSAPIAuthentication yes

    GSSAPIDelegateCredentials yes

I have configured the sshd_config as follows:

# Package generated configuration file

# See the sshd_config(5) manpage for details

 

# What ports, IPs and protocols we listen for

Port 22

# Use these options to restrict which interfaces/protocols sshd will bind to

ListenAddress ::

ListenAddress 0.0.0.0

Protocol 2

# HostKeys for protocol version 2

HostKey /etc/ssh/ssh_host_rsa_key

HostKey /etc/ssh/ssh_host_dsa_key

HostKey /etc/ssh/ssh_host_ecdsa_key

HostKey /etc/ssh/ssh_host_ed25519_key

#Privilege Separation is turned on for security

UsePrivilegeSeparation no

 

# Lifetime and size of ephemeral version 1 server key

KeyRegenerationInterval 3600

ServerKeyBits 1024

 

# Logging

SyslogFacility AUTH

LogLevel INFO

 

# Authentication:

LoginGraceTime 120

PermitRootLogin yes

StrictModes yes

 

RSAAuthentication yes

PubkeyAuthentication yes

#AuthorizedKeysFile       %h/.ssh/authorized_keys

 

# Don't read the user's ~/.rhosts and ~/.shosts files

IgnoreRhosts yes

# For this to work you will also need host keys in /etc/ssh_known_hosts

RhostsRSAAuthentication no

# similar for protocol version 2

HostbasedAuthentication no

# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication

#IgnoreUserKnownHosts yes

 

# To enable empty passwords, change to yes (NOT RECOMMENDED)

PermitEmptyPasswords no

 

# Change to yes to enable challenge-response passwords (beware issues with

# some PAM modules and threads)

ChallengeResponseAuthentication yes

 

# Change to no to disable tunnelled clear text passwords

PasswordAuthentication yes

 

# Kerberos options

#KerberosAuthentication no

#KerberosGetAFSToken no

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes

 

# GSSAPI options

#GSSAPIAuthentication no

#GSSAPICleanupCredentials yes

 

X11Forwarding yes

X11DisplayOffset 10

PrintMotd no

PrintLastLog yes

TCPKeepAlive yes

UseLogin yes

 

#MaxStartups 10:30:60

Banner /etc/issue.net

 

# Allow client to pass locale environment variables

AcceptEnv LANG LC_*

 

Subsystem sftp /usr/lib/openssh/sftp-server

 

# Set this to 'yes' to enable PAM authentication, account processing,

# and session processing. If this is enabled, PAM authentication will

# be allowed through the ChallengeResponseAuthentication and

# PasswordAuthentication.  Depending on your PAM configuration,

# PAM authentication via ChallengeResponseAuthentication may bypass

# the setting of "PermitRootLogin without-password".

# If you just want the PAM account and session checks to run without

# PAM authentication, then enable this but set PasswordAuthentication

# and ChallengeResponseAuthentication to 'no'.

UsePAM yes

 

I set these parameters in hosts.allow:

# /etc/hosts.allow: list of hosts that are allowed to access the system.

#                   See the manual pages hosts_access(5) and hosts_options(5).

#

# Example:    ALL: LOCAL @some_netgroup

#             ALL: .foobar.edu EXCEPT terminalserver.foobar.edu

#

# If you're going to protect the portmapper use the name "rpcbind" for the

# daemon name. See rpcbind(8) and rpc.mountd(8) for further information.

#

ALL: ALL

For Obscurity I changed my hostname to something other than “kali”.

I created a rule to allow putty through the Windows Firewall.

I created a private key file via puttygen from the private key in the /etc/ssh/ssh_host_rsa_key and saved it. Then imported it into my Putty session and saved it into the “Auth” settings, just in case it wasn’t wanting to use password authentication, though I did allow it. So, it should use the private key upon connection.

However, still, it refused connection. The only other thing I could think of was SELinux, but I’m a noob in that department and it looks like I would only be able to make changes to those settings if I was actually booted into the system. Where have I gone wrong? Again, thank you for your support and I apologize for responding so late.

omnis

unread,
Apr 19, 2016, 2:46:01 PM4/19/16
to USB armory, thisisj...@gmail.com
I have finally SOLVED this!!! Been almost a year of figuring it out, but I have written an extensive tutorial and have attached it as a pdf right here!!! Hope this helps everyone. Cheers!

#   MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160

Getting Kali 2.1.2 to Work on your USB Armory.pdf
Reply all
Reply to author
Forward
0 new messages