Monday, April 22, 2013

Configuring pfSense (part deux)


It’s been a few days and I’m sure that billions of you have been waiting for the next thrilling installment of earning S+ CEUs theater, er I mean configuring pfSense in a virtual machine on Xubuntu.  When we last left off, the VM wasn’t really configured to do much of anything.  Fortunately, my pfSense VM decided to deny access to the web configurator so I get to start over and share all the fun clicks and whatnot with the Internet.  As a reason for the lack of access, I attribute that the VMs, disk image is located in a bad section of the host machines hard drive.  Who would have thought that a laptop proudly sporting a “Designed for Microsoft® Windows® XP” sticker would have a failing hard drive?  
Moving along at near breakneck pace, I reset pfSense to factory defaults via the menu that I accessed via SSH.  This led to the dilemma that I was unable to configure the now headless VM.  A few commands on the host machines terminal would kill the appliance.  First, ps -A | grep VBox showed the processes that were running the VM.  From there, I could either kill each process by the associated PID or be lazy and just use pkill VBox to kill them all.  Laziness won out and another ps -A | grep VBox showed that the processes were gone.  Having killed the headless server, I restarted it via the GUI (laziness again versus learning the correct command line verbiage to do it from there).  
The now restarted server was back to square one asking me about configuring VLANs and which interfaces were to serve as WAN and LAN.  For my setup, em1 was WAN and em0 was LAN and I’m not configuring any VLANs at this point.  The WAN connection retrieved its address via DHCP from my other laptop that was sharing its Internet connection.  The LAN connection auto-configured to a 192.168.1.0 subnet taking address 192.168.1.1 and enabled its own DHCP server and gave the host machine an IP address from its pool.  
I wanted to change the default addressing scheme on the LAN interface so I selected option 2- Set interface(s) IP address.  It then prompts for which interface (WAN or LAN), what IPv4 address, subnet mask in classless inter-domain routing notation, if the DHCP server was to be enabled on this interface, the starting and ending address of the DHCP pool, and if the webConfigurator was to use HTTP or HTTPS.  In this case, I wanted to keep a class C network and for security, one should use HTTPS vs the unsecured HTTP.  After entering the desired info, pfSense reconfigured the interface as I requested.  The host machine hadn’t released its IP address because its lease wasn’t anywhere close to its expiration so a quick unplug and replug of the ethernet cable yielded a new IP address on the correct network.  
Upon entering the IP address into the web browser on the host machine, it noted that the site’s security certificate isn’t trusted by the machine.  Having duly noted this, I chose to accept the risk that I could be the victim of an attacker that could be nestled inside my newly minted network.  Having braved ahead, I was greeted by the login screen.  Using the default username and password, admin/pfsense, I logged on and began to go through the initial config wizard (intial config part 2 if you will).  Options in this second initial config include hostname, domain, DNS servers, timeserver info, WAN specific configuration, LAN config, and admin password change (probably a good idea to do that if you are actually going to be exposing this thing to the Internet even if you are configuring it to only allow logins from the LAN connection).  After it applies the desired config, it prompts you to reload the page which lands you on the dashboard.  This is where the real fun and configuration begins.  On the main menu under system/packages, there is a plethora of services that are available, from Asterisk to Zabbix to be somewhat specific.  Looking through the list of services, a proxy server may be a good place to start.  
One option for a such a service is squid coupled with squidGuard.  The first time I installed and configured these services, I had a problem with squid not loading properly.  Googling for a solution revealed that it is somewhat recommended to install squidGuard first as it may attempt to overwrite squid with some older files.  Having completed the installation of both these packages, configuration can begin under services/ proxy server and services/ proxy filter.  
Looking under the general tab of proxy server shows such options as what interface to bind to, what port to use and whether local LAN users will be allowed on the interface.  Also on this page is the option to enable logging and how frequently to rotate the logs.  In this case, I enabled logging and set the logs to rotate weekly.  
Skipping remote cache tab (as I’m not using this feature), I next configure the local cache.  The default settings in cache general settings are fine for my application here so I leave those as is.  The hard disk cache settings however need some adjustment.  100MB of disk space for cache is hardly anything especially if I have more than one user.  I increase this to 2000MB and adjust the default maximum object size from 4KB to 4000KB (roughly 4MB).  The default memory settings are also a bit on the small side so I increase them as well.  Memory cache size goes from 8MB to 200MB and maximum object size in RAM goes from 32KB to 512KB.  
The ACLs tab can be left as is if desired or specific subnets, IPs or hosts may be blocked or whitelisted if so desired.  Specific ports outside of the default list (21, 70, 80, 210, 280, 443, 488, 563, 591, 631, 777, 901, 1025-65535) may also be allowed. The defaults here suit my application just fine.  On the traffic management tab, I configure the throttle options for binary and CD images as these aren’t high priority (and if they are, I can simply disable throttling).  

Next time on the exciting adventures of pfSense setup, configuring squidGuard! (Probably)

Monday, April 15, 2013

Configuring pfSense on virtualBox with Xubuntu as the host (Part 1:The Boredom Ensues)

This is just a short little sorta how-to on configuring pfSense on a virtualBox virtual machine utilizing Xubuntu as the host with two network cards.  I utilized the cheapest oldest laptop that was available, a Sony PCG-4A1L.  This system has a humble 1Ghz processor, 512Mb of RAM and a 40Gb hard drive.  Sadly, this system’s processor doesn’t have PAE support so I had to utilize an older version of OS, specifically 12.04LTS.  After installing Xubuntu, I set about installing the new hardware. I used this USB network adapter from dealextreme (as I only use the most extreme components).  Fortunately, the adapter’s price didn’t break the bank ($4.80).  Unfortunately, it isn’t autosensing for cabling so actually remembering to use a crossover was an issue at first.


Now that the host system was generally configured, I installed virtualBox and downloaded the pfSense virtual machine image (http://www.pfsense.org/index.php?option=com_content&task=view&id=58&Itemid=4/).  This was a fairly straightforward process with only configuring how much RAM was allotted to pfSense and configuring the network adapters for bridged mode.  The more complicated process was getting pfSense and the host machine to utilize the network adapters in the manner I desired.  One adapter would only be used by the VM to access the WAN and the other would have two addresses on the same subnet for the LAN, a statically assigned address for the VM and a DHCP address for the host machine so that its packets would be routed through the VM.  After an intense session of Googling (hey Google, I’m genericizing your trademark) which failed to yield the desired information, I ended up doing things the hard way via trial and error.  All that was actually necessary was to edit the ethernet adapter for the WAN connection in the host so that it was not managed by the host.  In this case, that was unchecking the “connect automatically” checkbox.  I tested the functionality by using a shared connection from my main laptop that was connected to the wi-fi router.  
Before continuing, I entered option 14 from the pfSense menu to enable SSH logins.  As this setup is destined to be headless, it is useful to be able to SSH into the VM which, by default, shows the same thing as the monitor would anyway.  Of course, enabling SSH is opening the system to attack just like enabling any service or opening any ports.  
Once the physical and logical connectivity were complete, it was time to get pfSense running on headless on startup.  A quick Googling yielded a near answer at http://askubuntu.com/questions/57220/start-vboxheadless-vm-at-startup with a script that was only slightly out of date.  A quick review of the error message and a review of the current VBox commands yielded the answer.  The line
sudo -H -b -u $VMUSER /usr/bin/VBoxVRDP -s "$VMNAME"
was out of date and /usr/bin/VBoxVRDP should be /usr/bin/VBoxHeadless. Having corrected that and added the script to be executed on startup and shutdown.  The system was in need of actually being configured to do something.  
Just like Security+ is pretty much useless, this virtual machine wasn’t able to route, serve DHCP addresses, or perform firewall and proxy duties.  Setup of pfSense is done largely through a web browser with a limited set of options from a menu prompt (although one menu option is to access a full openBSD command prompt).  While this has been so much not sarcastic fun, further configuration will have to wait for the next thrilling installment.  

Shoutout to Wiz(!) and S+ auditors.  

Monday, March 18, 2013

Structured Query Language Injection (SQLi), Part 2: Particulars of the attack.


As noted in part 1, hackers extend the already structured SQL statement by injecting more legal syntax into the user input field of the interface. The simple example demonstrated the concept of SQLi but did little more than prove that the chosen interface was subject to exploitation. Also, we did not specifically uncover what the table and field names were, we just know that they existed and we could reach them. Now, using the same example, we take a closer look to see what more we can discover about the exposed application.

Most attackers are after something specific or they're just hunting for anything of value. Sometimes this means firing in the dark to see if they can hit anything. Part 1 was the shot in the dark with a hit, now we explore the target further by enhancing the complexity of our injections. Consider the following:

x' AND date_of_birth IS NULL;--

We use 'x' as a filler for data within the field, simply because at this point we're not too interested in trying to get a legitimate value or values in return, we're just trying to map the database. This is also why why we suggest a NULL value for 'date_of_birth', it doesn't really matter. The double hyphens at the end are syntax for SQL comments, this is sometimes added to eliminate effort in matching quotesat the end since they become commented out. This would make the full executed statement something like this:

SELECT unknown FROM unknown WHERE unknown = 'x' AND date_of_birth IS NULL;--';

First, it's important to note that we are arbitrarily targeting a column called 'date_of_birth'. We have no idea if there is a column called 'date_of_birth', but due to the form indicating that a last name is required we do know that there is a column with a person's last name. We can conjecture that the database may have other information about users, so at this point we make some guesses as to what they might be called. In this example we chose 'date_of_birth'. If there is a column titled 'date_of_birth' the database will respond with a 'no data found', 'date_of_birth not found for user', or similar error. Any other type of error would probably indicate that our SQL syntax was malformed, which could be due to the usage of a column that does not exists in the database.

If we were to inject a few statements in the this manner, changing 'date_of_birth' with whatever other column names we'd like to try (probably starting with more common columns like email, password, userid, name, etc.), and if we watch our return messages carefully we may end up capturing one or more legitimate column names within the database being attacked. With this information we begin to form the database schema, or the names of the database and subsequent columns or fields, which will serve as a road-map for attack using further and more intense injections.



Wednesday, March 13, 2013

Structured Query Language Injection (SQLi): A look at one of the oldest and most efficient attack vectors for hackers

Only the foolish believe that this form of attack is obsolete. The truth is that SQL Injection was rated as one of the top ten attack methods used on applications in 2007 and again as recent as 2010. Applications in production are subject to as many as 71 SQLi attacks per hour, with high value applications being attacked 800-1300 times per hour. So what's at risk? How does SQLi work? And how do I defend my application against SQLi? Let's find out.

Some of the most powerful applications use a database to store their data. On the back-end data is accessed via SQL statements that are either fixed or are customized based on user input. The goal of attackers is to make the application run an SQL query that was not intended by the application programmers, with the result being attackers gaining access to information they should not be authorized to have, or they can manipulate data or even control an entire database.

The user interface to input the data should be considered the gateway by which the injection occurs. SQL statements are often structured similar to this:

SELECT thiscolumn FROM thistable WHERE data = '$value';

If the database table we are accessing is called 'member_information', and the column in the table we are trying to capture data from is 'birth_date', and the column we are verifying user input against is 'last_name', then since the “$value” is the variable container representing input from the user if the user submits the value “Smith” into the user interface the application handler would execute the following SQL statement:

SELECT birth_date FROM member_information WHERE data = 'Smith';

Although simplified, this is a very common approach to verifying data in a database. This particular statement would probably return the targeted members recorded birth date. Unfortunately, this approach can be subject to manipulation by using SQLi to return other-than expected results to the application user. Continuing with our last example, what if the user input the following instead of “Smith”:

anything' OR 'x'='x

Note the placement of the apostrophes. Since $value parameter of the pre-defined SQL statement already includes apostrophes to enclose the variable, the intentional placement of further apostrophes gives opportunity to the SQL injector to extend the query to include more parameters – which is the core of SQLi. This extended statement now looks like this:

SELECT birth_date FROM member_information WHERE data = 'anything' OR 'x'='x';

This is a perfectly valid SQL statement, but instead of returning one value based on one record it would now return the birth_date from every instance where the targeted data was true (because x will always equal x). This means that the return would be the birth_date for every record in the table.

This is perhaps the most basic way to understand how SQL injection works. It's easy to see how this strategy can be easily harnessed and configured to extract sensitive information or even identify information regarding the schema of a particular database. On outset that may not look like too much of a reward for a successful cyber attack, but considering the data maintained by financial organizations and in military or government databases the gains could be far worth every bit of effort.

Is there a way to protect against SQLi? Yes there is, but that's an article for another day.