I had this thought last night as I was falling to sleep, and I realise it has probably already been talked about but I will explain how easy it is to do and how hard it is for existing detections to detect.
So my idea is basic data exfiltration via DNS lookups. Say you are sitting on an internal machine, you logged on as a local user through some exploit via boot disk or what not. You probably don't have internet access and you can't install a tunnelling tool, you don't want to set off the local HIDS of the machine by plugging in an unknown USB stick, so what do you do?
Well if you already have a DNS server running on a server you control, pre-setup for something like
DNS tunnelling, or just legitimately resolving your own domains. Now your existing DNS server you need to turn on verbose logging for one of your subdomains, this is pretty easy to do on BIND or even in Windows's DNS server. Then simply encode from the local machine anyway you want, or if you can't encode it don't and just do an nslookup data.sub.mydomain.com, bear in mind the whole lookup can't be longer than 255 characters and the subdomain can be 63 characters tops, if you need to use some special characters then you will need to either encode in base32 or use some system in your head.
Mitigation: Do your client machines really need to resolve every site, surely they are going through a proxy or application aware firewall that can do the DNS lookups for them. The issue of course with this is most networks now use DNS to resolve internal services, and usually the DNS servers that service these requests are allowed to go to the internet in some way, and the proxies or firewalls refer back to these internal DNS servers as they would also point to resources the proxies need like authentication. The only suggestion then is to more finely split your DNS server infrastructure up. Specific internal DNS servers that are allowed to do lookups to both the internal DNS servers and the wider internet, but the only device internally that is allowed to these is the proxy server. Of course depending on the way your proxy server works it may not wait for the client to be authenticated before it does a lookup so the lookups could simply be proxied through the compromised machines web browser that is connected to the proxy.
Labels: exfiltration, proxies
Not really a 100% IT security post. But Fiona had an issue with getting a particular sites print functionality to work on her Ubuntu laptop. It seemed to "print" by opening a PDF, that was secured in some fashion. Having a look at the error led no where, something like "could not open plugin". Having a look at source etc didn't give any help, there was no help page that Fiona could find on the site.
I resorted to trying to open the files with Windows, bam it tried to install a plugin called Openfile, I found there was a Linux version of OpenFile
here.
Excellent, a Linux version I downloaded it and ran the installer shell script, it error'ed out as I had Adobe9.3 installed, the latest. Looking in the script it had a check for the version of Adobe installed, it only checks for 7 or 8, else fail. Googling led me to a recipe sites support page with posts from back in 2008 with someone complaining that Adobe 9 wasn't supported, the recipe site had started to ditch FileOpen as the support request hadn't been fixed to support Adobe9. The main reason I am posting this is to help others in this predicament.
It was important I get the site to work, so I assured Fiona that windows was not the answer.
I ran the following (as I had installed it manually from a deb from adobe just in case it was an old version issue)
sudo sh /opt/Adobe/Reader9/bin/UNINSTALL
Then managed to download an older version from here
http://ardownload.adobe.com/pub/adobe/reader/unix/8.x/8.1.1/enu/AdobeReader_enu-8.1.1-1.i386.deb and installed it, then ran the OpenFile shell installer and all was good, site worked all was happy with the world.
Just posting this for anyone else who has the issue.
So in case you haven't heard an international budget airline here in Australia has had a major computer issue, see
here.
By the sounds of it their outsourced service provider doesn't have redundant kit, as they couldn't simply fail-over. But it gets worse currently going to https://book.virginblue.com.au/FlightInfo.aspx or https://book.virginblue.com.au leaks a lot of information, and leaks a nice juicy standard ASP.Net error page, of the type that the recently discussed Asp.Net oracle padding attack can take great use of, see
here.
Ouch and double ouch. Oh and we hear this is not the first outage they have had in as many months...
Labels: asp.net, virgin, web, web-security
