DNS servers hijacked in the Netherlands

Published: 2013-08-07
Last Updated: 2013-08-08 13:38:36 UTC
by Mark Hofman (Version: 1)
0 comment(s)
Earlier this week reports started to appear that the DNS of several webhosting companies in the Netherlands had been hijacked and those using the services were being redirected to malware sites, notably blackhole. 
According to the notification by the provider (http://noc.digitalus.nl/dashboard/136/Storing-DNS-servers) requests were being forwarded to external name servers. The issue was picked up relatively quickly. According to Digitalus and other reports SIDN, the Foundation for Internet Domain Registration in the Netherlands suffered a breach which affected the domain name registration systems.  The change was made at 0330 and the zone fully recovered by 0800, but that did mean that those who had already erroneously resolved the malicious domains would retain those records for a typical 24 hours. Whilst the provider is still investigating, at the moment there is no additional information available. It is not yet clear how the initial change was made.  the result however is still being felt by a number of their customers.  
Webstekker was another organisation affected by the same issue, however their notificatino states that the issue lies at VD (http://www.webstekker.nl/over-ons/nieuws/2013/augustus/19/berichtgeving-dns-redirect-onjuist - In Dutch). VDS, the third party points the finger at SIDN.  Interestingly SIDN states that it is an "annoying issue" and they are working with the registrars to identify the cause.  (https://www.sidn.nl/nieuws/nieuwsbericht/article/sidn-ondersteunt-onderzoek-naar-incident-bij-een-van-haar-registrars/ - In Dutch). 
FOX-IT wrote up an analysis of the resulting attack here http://blog.fox-it.com/2013/08/05/dns-takeover-redirects-thousands-of-websites-to-malware/
Looking through some other articles it looks like SIDN identified a possible breach back in July (https://www.sidn.nl/en/news/news/article/preventieve-maatregelen-genomen-2/ - In Dutch)  Whilst contained, in my view based on the incident this week, I'm guessing that the whole issue may not have been identified at the time and addressed. DNS.be had a similar defacement issue on their site at about the same time, however their front end systems do not have access to backend systems, according to their notification (http://www.dns.be/en/news/recent_news/deface-hack-on-dnsbe-website2#.UgLiRD7bprh). 
These issues show that attackers are not shy about going after the critical infrastrucutre components on the net. Something we all need to keep in mind. 
Mark H
Keywords: dns hijack
0 comment(s)

Information leakage through cloud file storage services

Published: 2013-08-07
Last Updated: 2013-08-08 02:01:13 UTC
by Manuel Humberto Santander Pelaez (Version: 1)
1 comment(s)

Cloud services are here to stay. This poses a big challenge for information security professionals, because we cannot longer restrict mobility and thus we need to implement controls to ensure that mobility services does not pose a threat to any information security asset of the company.

Bad guys tend to steal critical information from the company and takes it out using e-mails, chat file transfers and could file storage services. The first two are being monitored in most companies, but not all companies have the technical controls available to regulate usage on the third one. There are two big services here: Skydrive and Dropbox. Skydrive does not announce to the network and so the only way to detect it is to monitor outgoing traffic for the file transfer protocol used, which is MS-FSSHTTP (File Synchronization via SOAP over HTTP Protocol). For example, if anyone is saving a file to http://Example/Shared%20Documents/test1.docx, the request sent would be:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
    <RequestVersion Version="2" MinorVersion="0" 
    <RequestCollection CorrelationId="{83E78EC0-5BAE-4BC2-9517-E2747382569B}" 
      <Request Url="http://Example/Shared%20Documents/test1.docx" RequestToken="1">
        <SubRequest Type="Coauth" SubRequestToken="1">
          <SubRequestData CoauthRequestType="RefreshCoauthoring" 
                          SchemaLockID=" 29358EC1-E813-4793-8E70-ED0344E7B73C" 
                          ClientID="{BE07F85A-0CD1-4862-BDFC-F6CC3C8588A4}" Timeout="3600"/>
        <SubRequest Type="SchemaLock" SubRequestToken="2" DependsOn="1" 
          <SubRequestData SchemaLockRequestType="RefreshLock" 
            SchemaLockID=" 29358EC1-E813-4793-8E70-ED0344E7B73C" 
            ClientID="{BE07F85A-0CD1-4862-BDFC-F6CC3C8588A4}" Timeout="3600"/>
        <SubRequest Type="Cell" SubRequestToken="3" DependsOn="2" 
          <SubRequestData Coalesce="true" CoauthVersioning="true" 
                   SchemaLockID="29358EC1-E813-4793-8E70-ED0344E7B73C" BinaryDataSize="17485">
            <i:Include xmlns:i="http://www.w3.org/2004/08/xop/include" 

And the response would be:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
    <ResponseVersion Version="2" MinorVersion="0"
    <ResponseCollection WebUrl="http://Example"
      <Response Url="http://Example/Shared%20Documents/test1.docx"
          RequestToken="1" HealthScore="0">
        <SubResponse SubRequestToken="1" ErrorCode="Success" HResult="0">
          <SubResponseData LockType="SchemaLock" CoauthStatus="Alone"/>
        <SubResponse SubRequestToken="2"
        <SubResponse SubRequestToken="3" ErrorCode="Success" HResult="0">
          <SubResponseData Etag="&quot;{600CE272-068F-4BD7-A1FB-4AC10C54386C},2&quot;"
           CoalesceHResult="0" ContainsHotboxData="False">DAALAJ3PKfM5lAabFgMCAAAOAgYAAwsAhAAmAiAA9jV

The following table resumes all possible subrequest operations and their descriptions.



Cell subrequest

Retrieves or uploads a file’s binary contents or a file’s metadata contents.

Coauth subrequest

Gets a shared lock on a coauthorable file that allows for all clients with the same schema lock identifier to share the lock. The protocol server also keeps tracks of the clients sharing the lock on a file at any instant of time.

SchemaLock subrequest

Gets a shared lock on a coauthorable file that allows all clients with the same schema lock identifier to share the lock.

ExclusiveLock subrequest

Gets an exclusive lock on the file, which ensures only one client edits the file at an instant in time.

WhoAmI subrequest

Retrieves the client's friendly name and other client-specific information for a client with a unique client identifier.

ServerTime subrequest

Retrieves the server time.

Editors Table subrequest

Adds the client to the editors table, which is accessible to all clients editing or reading a document.

GetDocMetaInfo subrequest

Retrieves various properties for the file and the parent folder as a series of string pairs.

GetVersions subrequest

Sends back information about the previous versions of a file.

This protocol can be easily detected and tracked using IPS signatures or, if you have a layer 7 firewall, you can use their functionality to detect this protocol application and stop it. Checkpoint can do it with its software blade for 5052 applications as of today.

Dropbox can be easily detected on the network. It sends every 30 seconds a packet announcing the client for possible LAN Sync operations. Those packets are like the following one:

Dropbox LAN Sync Packet

If you want to detect those packets, you can use wireshark and look for them using the filter udp.port==17500 or performing the following command using nmap:

This command performs portscan to all the IP address where the Dropbox listener was detected. The nmap script shown in the last figure has the following options:

  • --script=broadcast-dropbox-listener: This nmap scripts listen for the Dropbox LAN Sync protocol broadcast packet sent every 30 second on the LAN.
  • --script-args=newtargets: This option tells nmap to add the detected IP as a target to perform a scan.
  • -Pn: Treat all hosts as online without performing host discovery.

How can we provide this kind of services to our users without having their mobility ability affected? Skydrive Pro can be used with Sharepoint Online or local Sharepoint Server 2013. If you don't have servers inside, you can use Dropbox for business, which is now able to integrate with your local active directory.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
e-mail: msantand at isc dot sans dot org

1 comment(s)

Firefox 23 and Mixed Active Content

Published: 2013-08-07
Last Updated: 2013-08-08 01:45:27 UTC
by Johannes Ullrich (Version: 1)
11 comment(s)

One of the security relevant features that arrived in the latest version of Firefox was the blocking of mixed active content. In the past, you may have seen popups warnings in your browser alerting you of "mixed content". This refers to pages that mix and match SSL and non SSL content. While this is not a good idea even for passive content like images, the real problem is active content like script. For example, a page may download javascript via HTTP but include it in an HTTPS page. The javascript could now be manipulated by someone playing man in the middle. The modified javascript can then in turn alter the HTML page that loaded it. After all we are using the HTML to load the javascript, so we will not have any "origin" issues. 

Firefox 23 refined how it deals with "mixed ACTIVE content". If an HTML page that was loaded via HTTPS includes active content, like javascript, via HTTP, then Firefox will block the execution of the active content.

I setup a quick test page to allow you to compare browsers. The first page https://isc.sans.edu/mixed.html just includes two images. One is loaded via https and one via http. The second page, https://isc.sans.edu/mixed2.html does include some javascript as well. If the javascript executes, then you should see the string "The javascript executed" under the respective lock image.

For more details, see Mozilla's page about this feature: 


Johannes B. Ullrich, Ph.D.
SANS Technology Institute

Keywords: firefox javascript
11 comment(s)
New edition of the Ouch! Security Awareness Newsletter is out: http://www.securingthehuman.org/resources/newsletters/ouch/2013


Diary Archives