dns

/Tag:dns

DNS Black List / RBL Checking in Python

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: […]

By | November 22nd, 2014|Python|2 Comments

Performing DNS Queries in Python

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 […]

By | November 21st, 2014|Development, Python|3 Comments

DNS Zone Transfer (AXFR) Vulnerability

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> […]

By | August 16th, 2013|Security Consultant|2 Comments

Two paid wifi attacks to bypass hotspot payment

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; Your device connects to the paid network The network router puts your ‘MAC address’ into the unpaid pool 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 The router will only allow traffic to the internal payment system and perhaps allowed IPs such as the hotel web site servers. Once payment is made, the payment system notifies the router and your MAC address is added into the paid list Enjoy surfing the net 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. […]

By | July 4th, 2013|Security Consultant, Wireless|0 Comments

Fully Automatic Wireless Hacking Station

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. 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. 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. […]

By | April 26th, 2013|Linux, Perl, Projects, Raspberry Pi, Security Consultant, Wireless|18 Comments

Implementing DNS backup

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. […]

By | July 1st, 2010|Security Consultant|0 Comments

A BIND9 zonefile and commentary

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… […]

By | December 15th, 2008|Internetworking & Routing, Technology|2 Comments