DNS Black List / RBL Checking in Python

November 22nd, 2014

Following on from performing basic DNS Lookups in Python, it’s relatively trivial to begin testing DNS Block Lists/Real Time Black Lists for blocked mail server IP addresses. To assist in preventing spam, a number of public and private RBLs are available. These track the IP addresses of mail servers that are known to produce spam, thus allowing recipient mail servers to deny delivery from known spammers.

RBLs operate over DNS. In order to test a RBL, a DNS query is made. As an example, zen.spamhaus.org is a popular RBL. If I wanted to test IP address 148.251.196.147 against the zen.spamhaus.org blocklist, I would reverse the octets in the IP address and then append ‘.zen.spamhaus.org’, i.e. 147.196.251.148.zen.spamhaus.org. I then perform an ‘A’ record lookup on said host:

root@w:~/tmp# host -t a 147.196.251.148.zen.spamhaus.org
Host 147.196.251.148.zen.spamhaus.org not found: 3(NXDOMAIN)

Excellent. IP 148.251.196.147 was not found in zen.spamhaus.org. NXDOMAIN is returned.

Now, to take a known spammer’s IP: 144.76.252.9:
Read the rest of this entry »

Performing DNS Queries in Python

November 21st, 2014

dnspython provides a detailed interface into DNS. In its simplest form, it’s possible to perform queries in only a couple of lines of code. Here’s a commented example:

import dns.resolver #import the module
myResolver = dns.resolver.Resolver() #create a new instance named 'myResolver'
myAnswers = myResolver.query("google.com", "A") #Lookup the 'A' record(s) for google.com
for rdata in myAnswers: #for each response
    print rdata #print the data

The results in my case are:

173.194.125.3
173.194.125.7
173.194.125.4
173.194.125.8
173.194.125.9
173.194.125.5
173.194.125.2
173.194.125.0
173.194.125.6
173.194.125.1
173.194.125.14

Read the rest of this entry »

DNS Zone Transfer (AXFR) Vulnerability

August 16th, 2013

A vulnerability exists when DNS servers are [mis]configured to allow for public zone transfers. A zone transfer is literally that – the transfer of an entire zone file, intended primarily for replication and availability between multiple DNS servers. A DNS zone transfer is attempted as follows:

dig axfr <domain> @<DNS server>

Read the rest of this entry »

Two paid wifi attacks to bypass hotspot payment

July 4th, 2013

Most hotels around the world offer paid wireless internet services. There are various different ways that these operate on a technical level, however in general terms;

  1. Your device connects to the paid network
  2. The network router puts your ‘MAC address’ into the unpaid pool
  3. Any traffic from your device is blocked aside from DNS traffic which is hijacked by the router and resolves any query to the router’s IP, and web traffic which is also hijacked by the router and redirected to a page presenting a signup and payment page
  4. The router will only allow traffic to the internal payment system and perhaps allowed IPs such as the hotel web site servers.
  5. Once payment is made, the payment system notifies the router and your MAC address is added into the paid list
  6. Enjoy surfing the net
Basic WiFi Hotspot Network

Basic WiFi Hotspot Network

A basic wifi hotspot will contain a wireless access point allowing wireless devices to connect, and a router that performs, you guessed it, routing, hotspot authentication and so on acting as the ‘gatekeeper’. This router will then be connected to the internet. More complex systems may include more access points to span multiple floors or locations, more routers, separate authentication servers and so on, although the basic principle is the same, and the network layout is largely irrelevant to our attack scenario in any case.

To the non technical readers, there are a few terms we are interested in –

MAC Addresses & IP Addresses: A MAC address is a hardware address assigned to your network device – the ethernet (network) card has one, the wireless card has one, the wireless device in a mobile phone has one. It’s not the same as an IP address. A MAC address is (or should be) unique to your device but most importantly, unique to the current network segment. In this case, the network segment that we are on extends through the wireless network and up to the top connection on the internet router. The secondary connection between the router and the internet provider is a second segment. Routers break up segments and MAC addresses do not pass through the router. To simplify, in this case, every device connected to the wireless network will have a different MAC. IP addresses are ‘routed’ i.e. passed across the internet and translated, MAC addresses are not. This point is important to know in understanding one of the attacks. Of course as with every rule there are exceptions and for more advanced reading, ‘proxy ARP’ is one such exception however this scenario has specifically been kept basic to illustrate a successful attack.

DHCP: When you connected to the wireless network, your device sent out a ‘DHCP request’. Basically – “I’m new to this network, please let me have the details”. The DHCP server then responds providing a private IP address, router, DNS server and so on. As all of your traffic is passed through the network router, the network router can mangle it and modify it in any way that it wishes.

DNS: DNS is the service that turns addresses such as ‘www.adampalmer.me/iodigitalsec’ into an IP address such as 54.236.191.54 which are what the IP networks on the internet run on. Other protocols also exist that we don’t need to be concerned with here. DNS actually does a lot more than just turning names into IP addresses but that’s all that’s relevant here. As an unpaid user, when you fire up your browser and visit www.adampalmer.me/iodigitalsec your browser will contact the DNS server (router in this case) and ask for the IP address. The router will respond with it’s own address, perhaps 192.168.0.1 rather than the real address. This means that your browser will then attempt to connect to the web server on 192.168.0.1 – the paid hotspot signup page. Attempting to enter 54.236.191.54 in to your browser directly will bypass the DNS query, but the router will nevertheless hijack the request and redirect it to the payment page – if it didn’t that would be a simple method for bypassing the payment system.

Read the rest of this entry »

Fully Automatic Wireless Hacking Station

April 26th, 2013

This article describes a working all-in-one standalone mobile wireless attack station that can perform MITM type attacks on clients automatically and without any internet access or other external connectivity or influence.

In laypersons terms; this portable battery powered device can automatically entice wireless devices to connect to it, be that iPhones/iPads, Androids and other phones or laptops and PCs. Most devices will connect to it automatically without the user even realizing. The device will provide a fake network running fake email and web servers and using some network trickery, will capture the hostname, username and password of any attempted connection and log it, along with the GPS co-ordinates of where the details were captured. This device could be used to hijack corporate and personal email logins, facebook logins, and so on.

HTTPS ActiveSync


Messing around with airbase-ng, part of the aircrack-ng suite over the last few months and researching wireless client vulnerabilities has led to an interesting proof of concept project. There are several weaknesses within the current wireless technologies in widespread use. First however, an explanation of the project. The project description was to launch a wireless man in the middle (MITM) attack, without having another end to connect the victim to. We need to create a MITM attack without having any internet access. Such an attack could theoretically be used on the tube, in locked down buildings, on the move, and so on, and without the use of a mobile data card. Built on top of a modified raspberry pwn release, although any Linux distribution would have been suitable, I have set my wireless device with a power output of 30dBm and started the following automated process:

Firstly, an airbase instance on my rtl8187 card as follows;

/usr/local/sbin/airbase-ng -c 3 wlan0 –essids “/root/pen/code/scripts/essids” -P -C 60 -I 60 -vv|grep –line-buffered  “directed probe request”|tee /run/probes

This starts an access point on channel 3, beaconing the SSIDs contained within /root/pen/code/scripts/essids as well as any probe requests that the access point may receive from clients looking to connect to an access point. Now, in a little more detail, regular ‘non-hidden’ access points will broadcast ‘beacons’ which are pieces of data that specify the SSID (wireless network name) as well as the supported encryption types and so on. These beacons are usually sent every 100msec. Wireless clients will send probe packets, containing the SSIDs of all wireless networks that they have stored, and asking if any of them are here.

Raspberry Pi

Raspberry Pi

The -P switch to airbase-ng will have airbase respond to all probes saying “yes, that’s me” at which point assuming the encryption or lack thereof matches the stored profile, the client will attempt to associate. Mid way through building this test however, Apple released IOS 6, and one of the changes seems that the iPhone will now only send out broadcast probes rather than directed probes, rendering the -P feature useless against them. The broadcast probe is where the device sends out a “is anyone there?” probe, and waits to see which access points reply. Most iPhones however have connected at some point to a wireless hotspot, and so the SSIDs I chose for the essids file are “Boingo Hotspot”, “BTOpenzone” and “BTWiFi” in the UK. I believe that “attwifi” is a popular one in the US.

Read the rest of this entry »

Implementing DNS backup

July 1st, 2010

Maintaining a backup DNS server is an example of prudent planning, even if you don’t run a major website. With backup DNS, you can ensure the timely delivery of your e-mail if your server should ever go down, or if you use an external e-mail service such as Google Apps. It will also give your visitors an entirely different error message when your site is down– a connection failure message as opposed to your site not being found.

Backup DNS servers are quite easy to set up. You can use one of the many backup services on the Internet, or you can arrange your own backup servers, configuring the zone files appropriately. But one of the most important adjustments that needs to be made is often overlooked: adjustment of your named.conf file, which controls your nameserver, which in turn is the heart of your server.
Read the rest of this entry »

Disable recursion (public DNS) with Bind

April 27th, 2010

I’ve just set up two new nameservers, and after only a few weeks, I’ve noticed that random IP addresses are hitting my nameservers requesting DNS records for 3rd party domains. What’s worse is that my nameservers are responding with the results.

To disable this in bind, add the following to the ‘options’ stanza within named.conf:

allow-recursion {“none”;};
recursion no;

DNS based Load Balancing

January 22nd, 2009

There are two main options for DNS based load balancing. The first and most simple is the round robin option. We can use this for ‘A (alias) records’ and ‘MX (Mail-eXchanger) records’.

We can specify a priority for MX records. If we specify the same priority for multiple MX records, the querying client will toss a coin and ‘randomly’ decide which to use. The same applies to A records. This should provide with a reasonable split between your various records however provides no mechanism for server loads or using any kind of intelligence to route queries.

Another option is to return a record based on intelligence. Assume we are trying to balance load between web servers. The two popular methods we can use are to return a record based on knowledge of the load of the web servers, or alternatively return a record based on originating IP (location) of the requesting client.

This is all well and good however there are a number of considerations, specifically that DNS was not intended to be operated in this way.

  1. You can set your records expire time to as low as you like, it will still be cached in circumstances by the browser and/or the resolver. This method will not account for ‘downed’ or ‘overloaded’ servers, they will still receive traffic.
  2. Due to caching, should your browser or resolver hold on to the record, it will blindly access the same IP next time the host name is requested, without requerying the DNS server and ignorant of the changed network conditions.

A BIND9 zonefile and commentary

December 15th, 2008

I’m often asked for a copy of various zone files for Bind, that other users may use as a template. Here’s the zonefile for www.adampalmer.me/iodigitalsec:

$TTL 604
@       IN      SOA      iodigitalsec.com. root.iodigitalsec.com. (
2008101023        ; Serial
172800         ; Refresh
900         ; Retry
1209600         ; Expire
3600 )       ; Negative Cache TTL
;
IN      NS      ns3.apnichosting.com.
IN      NS      ns2.apnichosting.com.
IN      MX      10      mail3.sasdataservices.com.
IN      MX      100     mail2.sasdataservices.com.
IN      MX      1000    backup-0.l3.iodigitalsec.com.
IN      A       217.10.156.197
*                       CNAME   iodigitalsec.com.

I’ll now cover each type of record briefly, and explain the ellusive decimal point.

The SOA or “start of authority” record indicates the domain name “iodigitalsec.com” and the email address of the domain administrator “root@iodigitalsec.com”, replacing the at symbol with a decimal point (this decimal point does not have the same meaning as those later on). There is only one SOA record allowed per domain. Contained within the SOA record is also a serial number, refresh, retry, expiry and TTL. The serial number is the ‘version’ of the zone. This is generally incremented each time the zone is updated. The refresh is used by the slave or secondary DNS server as an instruction on how often to update in seconds. The ‘retry’ is the length in seconds that the slave DNS server should wait before retrying to contact an unreachable primary DNS server. The expiry specifies how long until the slave DNS server stops responding to requests for this domain name, should the primary DNS server remain unreachable. If the primary DNS server becomes available again, the timer is reset. Lastly, the Negative TTL or ‘time to live’ value indicates how long the server will cache a NAME ERROR (NXDOMAIN) record. The longest permitted is 3h (10800 seconds).

On to the more simple records…
Read the rest of this entry »