I made a graphical overview of how AppExchange packages are structured, for use during a security assessment:
Ryan Linn from SpiderLabs has released an excellent Nmap script which takes screenshots of web services. However, the original blog post is no longer accurate and some tweaks are needed to get the script working. I’ve included updated instructions below:
1) The Nmap script requires wkhtmltoimage to take screenshots. First, install a dependency of wkhtmltoimage:
$ sudo apt-get install xfonts-75dpi
2) Navigate to the wkhtmltoimage website (http://wkhtmltopdf.org/downloads.html) and download the appropriate package for your system. In this case, I’m installing on an Ubuntu 14.04 machine:
$ wget http://downloads.sourceforge.net/project/wkhtmltopdf/0.12.2.1/wkhtmltox-0.12.2.1_linux-trusty-i386.deb
$ sudo dpkg -i wkhtmltox-0.12.2.1_linux-trusty-i386.deb
3) Download the Nmap script and move it to the appropriate location:
$ git clone git://github.com/SpiderLabs/Nmap-Tools.git
$ cd Nmap-Tools/NSE/
$ sudo cp http-screenshot.nse /usr/share/nmap/scripts/
$ sudo nmap --script-updatedb
4) We need to change a line within the Nmap script, or it will throw the error, “failed (verify wkhtmltoimage-i386 is in your path)”:
$ sudoedit /usr/share/nmap/scripts/http-screenshot.nse
5) Change line 51 within http-screenshot.nse:
local cmd = "wkhtmltoimage-i386 -n " .. prefix .. "://" .. host.ip .. ":" .. port.number .. " " .. filename .. " 2> /dev/null >/dev/null"
local cmd = "wkhtmltoimage -n " .. prefix .. "://" .. host.ip .. ":" .. port.number .. " " .. filename .. " 2> /dev/null >/dev/null"
The script should now function properly.
- Sign up for a VPN service in the country which your application belongs to
- Login to the VPN within Android, “Settings -> Connections -> VPN”
- Browse to “Settings -> Application Manager -> Google Play Store”, and select the following:
- Force Stop
- Clear Data
- Clear Cache
- Re-open Google Play Store
- Download the application
When using Burp Suite, you may notice that some websites transported over HTTPS will throw the error, “burpsuite handshake alert: unrecognized_name”.
This problem stems from an update in Java 7, where Server Name Indication (SNI) support was enabled by default. According to Wikipedia:
Server Name Indication (SNI) is an extension to the TLS protocol that indicates what hostname the client is attempting to connect to at the start of the handshaking process. This allows a server to present multiple certificates on the same IP address and port number and hence allows multiple secure (HTTPS) websites (or any other Service over TLS) to be served off the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 virtual hosting for HTTPS.
Certain misconfigured websites will send an “Unrecognized Name” warning in the SSL handshake, causing Java to mishandle the connection. To get around this using Burp Suite, use the following command, with Burp Suite version 1.5.21 as an example:
$ java -Djsse.enableSNIExtension=false -jar burpsuite_pro_v1.5.21.jar
A problem I’ve run into several times occurs when trying to run virt-manager on Gnome. When connecting to a new server, the connection will fail the the error:
Unable to connect to libvirt.
You need to install openssh-askpass or similar to connect to this host.
To get past this, open a terminal and run the following command:
$ sudo virt-manager --no-fork
Then pay attention to the terminal window, as any password prompts will appear there.
Oracle refers to Solaris updates by their release date, which can get pretty confusing. I’ve made the table below for reference:
|Version||Release Date (mm/yy)|
|Solaris 10 update 1||01/06|
|Solaris 10 update 2||06/06|
|Solaris 10 update 3||11/06|
|Solaris 10 update 4||08/07|
|Solaris 10 update 5||05/08|
|Solaris 10 update 6||10/08|
|Solaris 10 update 7||05/09|
|Solaris 10 update 8||10/09|
|Solaris 10 update 9||09/10|
|Solaris 10 update 10||08/11|
|Solaris 10 update 11||01/13|
VMWare Workstation 8 is currently unable to update on certain Linux distributions. The updater runs, is unable to stop “Virtual Network Device”, and ultimately fails saying “Unable to start services”. I solved this problem by doing the following:
attaining the 8.0.2 patch at this helpful website: http://weltall.heliohost.org/wordpress/2012/01/26/vmware-workstation-8-0-2-player-4-0-2-fix-for-linux-kernel-3-2-and-3-3/ (they also have a patch for 7.1.5)
Since I have VMware Workstation 8.0.3 build-703057, I had to change the following line in the file patch-modules_3.2.0.sh:
and you’re done!
I hope these instructions make your life easier and your anonymity stronger!
-Register a handle on Freenode with NickServ. Unfortunately, this must be setup before accessing freenode over Tor. If you’re very paranoid, you can always complete your NickServ registration from a public library or something similar. If you don’t know how to use NickServ, see this link: http://freenode.net/faq.shtml#userregistration
-Next, install Tor.
:~$ sudo apt-get install tor
(or compile from source on their website at: https://www.torproject.org/download/download.html.en)
-Edit your Tor configuration at /etc/tor/torrc and add the following line:
## Map Freenode's Tor address to 10.40.40.40 mapaddress 10.40.40.40 p4fsi4ockecnea7l.onion
The address 10.40.40.40 can be adjusted to any valid IP address you want.
-Restart Tor to apply changes
:~$ /etc/init.d/tor restart
-Install irssi and all the necessary cryptographic packages
:~$ sudo apt-get install irssi irssi-scripts libcrypt-openssl-bignum-perl libcrypt-dh-perl libmath-bigint-gmp-perl libmath-bigint-perl libcrypt-blowfish-perl
-Move the irssi scripts into your home directory’s .irssi folder and ensure the SASL plugin beings at irssi startup
:~$ cp /usr/share/irssi/scripts/*.pl ~/.irssi/scripts :~$ cd ~/.irssi/scripts :~$ mkdir autorun :~$ cp cap_sasl.pl autorun
-Run irssi through torify
:~$ torify irssi
-Load the SASL plugin and configure it for your chosen NickServ registration
/script load cap_sasl.pl /sasl set freenode DH-BLOWFISH /connect -network freenode 10.40.40.40
At this point, you should be connected to Freenode IRC over Tor!
Snort, like any IDS, is bound to detect false positives, particularly right after its been installed. This is especially true for very ambiguous alerts. Take the following for instance:
SHELLCODE x86 inc ebx NOOP
This alert is generated by an executable being downloaded over the network. Of course, an executable program can be an equally legitimate or malicious thing. An alert generated every time a .exe is pulled from the internet is unfavorable, but disabling the rule altogether might result in an administrator missing a security risk. Wouldn’t it be great it we could ignore certain networks from Snort altogether? That way, we can add the IP ranges of legitimate organizations where we expect such downloads to come from, (Microsoft, etc) and only be alerted when the download source comes from an untrusted location.
Let’s begin by opening snort.conf, Snort’s configuration file. Search for the line which says:
Begin by uncommenting it. Next, add in the location of the file which will define our whitelisted domains. What you call it isn’t important. The line in my Snort configuration therefore looks like the following:
config bpf_file: /etc/snort/ignore.bpf
Save your snort.conf and exit the editor. Next, create the file you just specified. In it, it is simple to whitelist individual hosts or networks in CIDR notation. Here’s some examples below. The ! before a line indicates the network is to be ignored. You can get granular with options like src, dst, port and more. Notice that an ‘and’ must be appended onto the end of each line if there are more after it!
# Business partner IP Ranges
!(net 18.104.22.168/17) and
!(net 22.214.171.124/17) and
!(host 126.96.36.199) and
!(src net 10.10.1.1/24 && dst net 10.10.10.210 && dst port 80)
Today we’re going to go through the steps necessary to get Snort up and running on a 64-bit CentOS 6 box, dumping its alerts to MySQL.
Begin by installing CentOS 6. Installing no more than you need to is a good security practice, and also helps performance. With that in mind, try to keep the number of packages you include down to a minimum. This can be done simply by choosing the ‘Minimal’ install from the choices CentOS gives you. However, this will leave you without a desktop environment, meaning command-line only. If you feel more comfortable in a graphical environment, make sure you include the appropriate packages during installation.
After this is completed, the system will reboot and you’ll be presented with a login. Enter your credentials and we can begin working on Snort’s dependencies. Personally, I had to run the following commands to begin networking upon logging in:
(replace eth0 with your adapter)
ifconfig eth0 up dhclient eth0
Part I: Package installation
Let’s get our main packages installed. This will grab them from the CentOS6 Base repository, along with their respective dependencies.
yum install gcc gcc-c++ make libpcap libpcap-devel pcre-devel bison flex zlib zlib-devel mysql-server mysql-devel
Next we need libdnet, which isn’t available through the default CentOS repos. Let’s download it and compile from source.
Download the sourcecode from: http://libdnet.sourceforge.net/
tar zxvf libdnet-1.12.tgz ./configure, make, and make install
, and we’re done!
Finally, we need DAQ, which you can get from the snort website. Download and compile it the same way as libdnet.
– This should complete without any errors. In this version of CentOS, the MySQL libraries are placed in an unusual location, so we need to specify where they’re at. After it’s done configuring,
make make install
Next let’s move these snort files into the proper directory and make a user associated with Snort. The following commands will make a directory to hold the snort config and rulesets, and another directory to hold Snort logs.
Part II: Setting up users/directories
Adduser snort passwd snort -l mkdir -p /etc/snort/rules /var/log/snort chown -R root.snort /var/log/snort chmod -R 770 /var/log/snort
After these commands, copy everything from the folder etc in the directory you compiled from into /etc/snort. The file snort.conf will be in this directory.
Part III: MySQL Setup
Great! Now let’s handle the MySQL side of things. Nothing will be configured at this point so we need to set up MySQL a bit.
First, start MySQL with the command:
Then, add a password for the root mysql account.
Mysqladmin -u root password NEWPASSWORD
Log into MySQL with: (It will now ask you for your password)
mysql -u root -p
This will bring you into the MySQL console. Next let’s do our Snort-related changes.
mysql> create database snort; mysql> grant all privileges on snort.* to 'snort'@'localhost' identified by 'snort_password'; mysql> exit;
Back at the standard command-line, let’s import our Snort database structure…
mysql -D snort -u snort -p < /snort/download/location/schemas/create_mysql
Part IV: Snort Configuration
MySQL should be all done at this point. Next we need to change our snort config file at /etc/snort/snort.conf. Change the following values:
- “ipvar HOME_NET any” to “ipvar HOME_NET 192.168.1.0/24”, reflecting your organization’s subnet and mask.
- “ipvar EXTERNAL_NET any” to “ipvar EXTERNAL_NET !$HOME_NET” to say that the external network is anything other than our internal subnet
- Optional: Explicitly define your rules location by modifying the line “var RULE_PATH”
- Uncomment the appropriate line and modify it to say the following:output database: log, mysql, user=snort password=snort_password dbname=snort host=localhost
Part V: Installing Rules
Snort needs rules to identify potentially malicious traffic. These are patterns which, if Snort detects them on the network, will create an Alert. Rules can be found from a variety of sources on the internet, or you can write your own. A good starting point is the official Snort rulesets, available on their website at http://snort.org. You need to make an account in order to download them.
Installing rules is very easy. Simply download them from your preferred location, then copy everything with a .rules extension into your /etc/snort/rules directory. You then need to configure /etc/snort/snort.conf to include these rules. Scroll to the bottom of the config file to find this section.