.~r~----------------------------------------------------------~r~. ; ** WHAT THE PHRACK!?!?!?! - route reloaded ; `----------------------------------------------------------------' This is a littl HOW-TO steal phrack articles in the wild... (By the FAKE MASTER) 1) Sorry nefele, this is just a collateral damage for making our HOW-TO (nothing personal) 2) We have nothing to do with netsniper (just coincidence) 3) We have nothing to do with Joxean Koret 4) We are not PHC ***#phrack @ efnet*** 14:29 -!- nefele [nefele@NIGHT.PL] has joined #phrack 14:29 <+nt> good night! 14:29 do phrack email servers work at all? 14:29 <+nt> which 14:30 I was trying to submit an article and got bounces every time 14:30 to phrackstaff 14:30 <+nt> which email 14:30 phrackstaff@phrack.org 14:31 phrack.efnet.ru -- one and only true phrack 14:32 -!- nocte [~nocte@pwned.p0rnstar.info] has joined #phrack 14:33 so this one is fake? ;) 14:33 now it is 14:36 -!- ttransien [crossbox@penguin.linux.am] has joined #phrack 14:36 awps j00 h0m0z 14:37 -!- slon [~mhm@3ffe:80ee:2e23::2] has quit [Ping timeout: 255 seconds] 14:44 what up 14:46 chillin 14:47 ugh ninjachat 14:52 ku3 zachem ti podpezdivaesh pod etu temu ) 15:14 netcraft @#! 15:14 hiya 15:20 hifa wehbe 15:22 <@route> nefele submit@phrack.ru 15:22 <@route> other mta is wrong 15:22 just submit to my mail 15:22 thats it 15:24 hi route 15:28 <@route> y0 15:29 <@route> nefele we finished the timeline for presenting papers last sunday... but .. maybe we can do an exception ***privmsg*** 15:48 [nefele(nefele@NIGHT.PL)] I was trying to send you mail from several accounts on Sunday ;) 15:49 [nefele(nefele@NIGHT.PL)] I always got bounces with 'e-mail address had a fatal error' 15:49 [msg(nefele)] yeah we have lot of problems with the mta 15:49 [msg(nefele)] you can submit to route@phrack.ru or submit@phrack.ru 15:49 [nefele(nefele@NIGHT.PL)] hah, well the paper is at http://nef****** 15:49 [msg(nefele)] we still have few articles 15:49 [nefele(nefele@NIGHT.PL)] maybe that would be easier? 15:49 [msg(nefele)] ok thx 15:51 [msg(nefele)] i think the article will be approved 15:51 [msg(nefele)] can u give me ur contact mail or smthing to put credits ? 15:54 [nefele(nefele@NIGHT.PL)] oh right, you could just say 'blueberry flan' as the author with no e-mail 15:54 [nefele(nefele@NIGHT.PL)] that okay? 15:55 [msg(nefele)] rigth 15:56 [nefele(nefele@NIGHT.PL)] well, have fun with your phrack stuff ;) 15:56 [nefele(nefele@NIGHT.PL)] see you 15:56 [msg(nefele)] l8r ***by mail*** After receiving the article approval; -mail to nefele: phrack High Council to nefele Jul 14 Hi, your phrack article has been accepted. Please review the attached version and submit any updates within the next 36h. thanks submit@phrack.efnet.ru - PHRACK MAGAZINE - ------------------------------------------------------------------- -response to phrack: From: "phrack High Council" To: Sent: Thursday, July 14, 2005 5:14 PM Subject: [!dSR-staff] ANTISPAM Re: phrack article accepted On 7/14/05, staff_sr@phrack.org wrote: > Hi, > > your phrack article has been accepted. Please review the attached > version and submit any updates within the next 36h. > > thanks > > staff_rs@phrack.org > - PHRACK MAGAZINE - ***attached p63_dns_worm_covert_channel.txt*** ==Phrack Inc.== Volume 0x0b, Issue 0x3d, Phile #0x00 of 0x00 |=---------=[ DNS Covert Channels and Bouncing Techniques ]=-------------=| |=-----------------------------------------------------------------------=| |=--------------------=[ pHC - phrack.efnet.ru ]=------------------------=| This article describes a new type of covert channel in the DNS protocol and its application as a communication scheme for an Internet worm. It is divided into two parts: Part 1 is a description of the NCACHE channel, with a summary of standard DNS behavior, introduction of the communication method, benefits and limitations. Part 2 discusses how this scheme could be used for co-ordination between worm instances, potential for being detected and other enhancements. Table of contents 1. NCACHE Channel Description 1.1. Introduction 1.2. DNS Behavior 1.3. Communication Details 1.3.1. Advantages 1.3.2. Choosing a Good Domain and Subdomains 1.4. Potential Issues 1.4.1. Efficiency 1.4.2. Synchronization 1.4.3. Reliability 2. Application for Worm Communication 2.1. More on Choosing Good Domains 2.2. What Kind of Data is Useful? 2.3. Detection 2.4. Closing Notes 3. References PART 1. NCACHE Channel Description ---[ 1.1 Introduction In the last 15 years several covert channels in DNS have been found [1], and utilities such as nstx [3] and DNShell [4] have been developed for communication between hosts by using UDP packets with DNS queries. By creating regular resource records (type TXT, A or any other) with information disguised as legitimate RR content, it is possible to communicate while maintaining the illusion that our packets represent innocent DNS queries. However, most of the methods proposed require that the parties which want to engage in the communication have authority over a DNS zone and run a DNS server. For many purposes this is not acceptable, because it allows to trace the communication back to the owner of the domain, and it provides the communicating parties with no benefits if DNS traffic is monitored or if a NIDS is deployed. Also, most covert channels in established protocols rely on overloading the meaning of a certain portion of the protocol (Sequence number field in TCP, TXT resource record in DNS), and they still require direct data flow between communicating hosts. For an administrator or reverse engineer the mere fact that a suspiciously behaving host is exchanging traffic with another machine is a strong hint that they are both infected with some kind of malware. One notable exception to this is an interesting idea touched upon by Dan Kaminsky at Black Ops 2004 -- "DNS Cache Modulation" [1]. In short, it relies on two hosts querying a given DNS server for the same domain and distinguishing based on whether the server replied using information from its local cache. Unfortunately, the way it was originally described made it unnecessarily complex and limiting. In this article I build upon this idea and describe a new covert channel using DNS negative caching (NCACHE). The NCACHE channel uses the DNS infrastructure to pass messages and does not require the hosts to communicate directly. It allows a worm to co-ordinate all hosts on one network (for our purposes a network is a group of hosts using the same DNS server or multiple DNS servers with a shared cache) solely by issuing valid DNS queries to the ISP's servers. ---[ 1.2 DNS Behavior Whenever a client machine wants to connect to an Internet host (such as www.google.com) it queries its local DNS forwarding server for the address of this host. When the forwarding DNS retrieves this information from an authoritative server, it caches this information for the number of seconds specified by the zone administrator in the TTL (time-to-live) field. All queries within the next TTL seconds will be satisfied from the cache; as part of the response the local forwarder will also include the number of seconds until the record expires from the cache. This behavior, designed to improve performance, is also applied to queries for non-existent domains. If a person mistypes a URL, the NXDOMAIN answer received by the authoritative server will also be cached by the forwarder so other people who make the same mistake will be immediately notified of it. Negative caching was introduced as optional by RFC 1034, but made its way to the official standard via RFC 2308 which specifically states that any resolver which maintains a cache, must also cache negative answers. The TTL for a non-existent domain is controlled by its parent zone. For almost all TLDs that parameter is either 3600 or 10800 seconds (one or three hours), i.e. if we query for nxdomain-1.com or nxdomain-1.nxtld, our local DNS will cache the result of our query for 10800 seconds. We can easily check for the presence of a particular domain in the cache by issuing a non-recursive query to the forwarder. If the answer we get is a referral (it contains the NS records for one of the parents of the queried zone), we know that the information we seek isn't cached: no-one has queried for this particular domain in the last TTL seconds. When querying for a non-existent domain this process is even easier: if the domain is in the cache, the answer status is NXDOMAIN. Otherwise, the answer will be a NOERROR, accompanied by several NS records for the parent zone. ---[ 1.3 Communication Details The gist of this scheme is as follows: two hosts on the same network query for the same domain which is known to them not to exist. If the second host queries for the domain while it is still in the cache, it will notice this fact and will infer that it has someone to talk to on its network. If the second host uses a non-recursive query, it will not change the state of the cache and thus make it possible for other hosts to receive this 'message' in a similar manner. By querying a previously agreed-upon set of subdomains of this non-existent domain the hosts will be able to covertly exchange messages, treating each cached subdomain as a '1' bit, and non-cached domain as '0'. While this isn't a particularly efficient communication method (we can only send/receive 1 bit per query), it has some surprising applications which we will shortly discuss. ---[ 1.3.1 Advantages There are three main advantages of this method: 1. Neither host needs to know the address of the other, nor do the hosts need to agree on a particular server to use for the communication - they will both use the default DNS server(s), which in most cases is the one maintained by their ISP. 2. Communicating hosts never directly exchange any traffic, all work is done by issuing DNS queries. What follows is that a host can make it known to an entire network that it is willing to talk, while never sending anything but a query to the DNS server. 3. In contrast to other covert channels in DNS, we do not need to maintain a domain or run a DNS server; we make use of the existing infrastructure maintained by our ISP. ---[ 1.3.2. Choosing a Good Domain and Subdomains The set of subdomains for which a query is issued should be automatically derived by each host, so the number of bits that can be set isn't limited. Some possible choices are: 00.nxdomain1, 01.nxdomain1, 02.nxdomain1 ... aaa.nxdomain2, aab.nxdomain2, aac.nxdomain2 ... www-1.nxdomain3, www-2.nxdomain3, www-3.nxdomain3 ... There are several fine points to selecting the right (sub)domains. We must make a trade-off between avoiding attention to our queries and assuring that a particular domain is invalid (by "invalid" we mean that doesn't exist and that it is a child of a TLD or the root domain). While choosing "bogus.foo" might seem tempting, a particularly astute sysadmin who happens to monitor DNS traffic could expose our channel. On the other hand, if we query for subdomains of "go-ogle.com" we might find that this domain exists and other users on the network frequent this website. While not necessarily devastating for our scheme, this would introduce three problems: 1. Legitimate traffic could interfere with our communication making it seem like there is a message set, when there really is none. 2. The DNS administrator for the queried zone could notice an increase in the number of queries for its members from our network and expose our channel. 3. The DNS administrator for the queried zone could set the MINIMUM field in the SOA record to 0, thus disabling caching for the zone and disabling our channel. A reasonable idea might be to try subdomains similar to "www-03.ib.mcom", which exploits the naming scheme of IBM public webservers and also assures that no such host will exist on the Internet. Of course a sudden spike of queries for .mcom domains wouldn't go unnoticed for long... Side note: for a particularly paranoid individual with an aversion to NXDOMAIN responses we can modify our scheme to do one of the following: 1. Query for one or more obscure, but legal domains which are unlikely to get traffic from our network (hosts with most two-letter TLDs, with the exception of some famous domains in .cx). 2. Query for some .in-addr.arpa domains. 3. Query for subdomains of a known wildcard-enabled zone, such as "linux01.slashdot.org" Communication using those alternative methods would be similar, but could exhibit a bit different properties and introduce new challenges. For the sake of brevity I will stick to the NCACHE channel in this article. ---[ 1.4 Potential Issues Before we describe the usefulness of this channel, I will make one last attempt to discourage the reader by listing the limitations of our scheme. ---[ 1.4.1 Efficiency Each query allows us to send/read only one bit. With approx. 50 bytes per query and 100 bytes per DNS answer, we will need to push 2.4MB data through the network to send and receive each kilobyte of useful information. If we want to post our IP address in the cache we will need to generate 32 packets with DNS queries. ---[ 1.4.2 Synchronization It is relatively easy to post our message in the cache and for other hosts to receive it. However, for two-way communication we would need to have a 'semaphor' domain which another host would set when it has a message. We could then proceed to query the predefined subdomains of the semaphor domain. The catch is that we won't know immediately that the semaphor domain is set, so we will have to nonrecursively query for it at regular intervals to see if there is a message waiting for us, which will increase the traffic we generate and might give us out. ---[ 1.4.3 Reliability One problem is that the channel is vulnerable to several race conditions. If Host A wants to broadcast its message for an extended period of time it will have to resend all its queries in exactly TTL-second intervals to populate the cache. If Host B happens to issue a query before Host A renews the message, it won't see the information in the cache, or worse, assume it can broadcast information using the same set of domains, therefore creating a mangled uninterpretable message. It's possible to safeguard against that by using two 'control' domains with a slight time shift, but one generally has to be wary of such details. Another potential problem would occur if the DNS server couldn't meet the requirement to cache the record for the entire TTL period. This could happen if it was flooded with queries, or just poorly implemented. DNS administrators and server programmers try not to let that happen, and it usually doesn't, so we'll assume that the server we use is sane and conforms to the standard. Also, this method of communication probably won't withstand reverse engineering of any of our clients on a network. Once the details of our protocol are known, an individual can mangle our message by setting all our bits to '1' by querying all subdomains in our set. If we so desired, we could probably create a "mirrored set" of subdomains with opposite information to enable a reliability check, i. e.: a.nxdom = 1; b.nxdom = 0; c.nxdom = 1; d.nxdom = 1; m-a.nxdom = 0; m-b.nxdom = 1; m-c.nxdom = 0; m-d.nxdom = 0; We could then proceed to XOR both messages and assume the message is correct if all bits are set to '1'. This would introduce unnecessary complexity, increase the amount of traffic we generate and would be utterly useless if an administrator decided to purge the DNS cache. In other words, for some with the right mindset to implement this entire communications scheme, it will probably make perfect sense to include this 'feature' as well. ---[ 2. Application for Worm Communication The ability to make our message visible to all hosts on a network without having to establish direct connections with them provides us with a way to communicate in a more subtle fashion than what is being observed in the wild. Currently, distributed malware writers who want to execute commands on controlled hosts typically communicate via IRC networks to which every infected host connects and awaits orders. However, as such malware grows more sophisticated [5], we will probably see attempts to create less ostentatious control mechanisms, i.e. ones that generate less traffic and are more covert. Let's see how we can use the NCACHE channel for such a purpose. Suppose a worm infects one host on a given network. After hiding its presence in the OS and maybe patching the vulnerability it exploits, it will nonrecursively query its local DNS for the set non-existent domain to check if it has any peers on this network. If so, it will query the predefined set of subdomains to retrieve a message left by its colleague. If not, the worm will assume that it's the only worm of its kind on the network, recursively query for the control domain, and then set a message using its subdomains, becoming a "master worm" which will co-ordinate the actions of other worms on the network. ---[ 2.1 More on Choosing Good Domains One more caveat regarding choosing an appropriate domain name: it should be set according to our guidelines from Part 1, but we would definitely want to avoid hardcoding the same control domain into all copies of the worm. If all our worms used the same domain name, sooner or later an administrator or reverse engineer would discover it, which would immediately blow our cover globally, and allow for the creation of simple NIDS rules to detect our presence. Therefore all worms on a network should utilize a part of network-specific data in the construction of the control domain. This could be the network address, DNS server IP (although we need to be careful because almost all ISPs have several DNS servers with a shared cache), the ISP name or any variation thereof. This will make it possible for any worm on the network to get this data, but can't be automatically detected by a NIDS. A rather straightforward example: if we're on the 172.16.0.0/16 network we can set the control domain by expressing the first two octets as hex numbers and get "ac10.org" as the control domain. This particular naming scheme would have a side effect of dividing all hosts using one DNS server into groups depending on their subnet, which might not be desirable in some cases. It is of course possible to obfuscate the control domain name even more, while making it seem more believable; this is left as an exercise to the reader. ---[ 2.2 What Kind of Data is Useful? Assuming that we have an inconspicuous control domain and a believable subdomain naming scheme, what kind of data would we like to transfer? Again, we have to make a trade-off between the size of the message and the risk of being detected. Although theoretically we could post entire patches or diffs to our code, this would be a sure way to attract attention. A better idea might be for the master worm to post its IP address, or maybe just the last [32 - subnet mask] bits of it. Other worms could then connect to the specified port (the port could be dynamic and also posted in the DNS cache). This would be an interesting way for the master worm to obtain the list of infected hosts on its network without broadcasting messages directly to each host. For the more paranoid, it might suffice to set flags which would be understood by other worms. The presence of a given subdomain in the cache could mean "do not infect any other hosts on my network", "remain hidden" or "do your deed, minions!". This last concept leads us to a final point in this section, which is the ability of the worm writer to manually trigger a certain action of a worm. Assuming he knows the control domain used by his worm on a certain network, he can issue a query for a subdomain, which would prompt the worms to perform a certain action. It is also conceivable that similar interaction could occur between separate networks with worms on one looking up another ISP's DNS addresses and communicating across network boundaries. ---[ 2.3 Detection At the moment there are no NIDS capable of detecting this method of communication on a network. If the domain and subdomains are picked sensibly, each packet on its own will seem completely benign. What could attract attention is a sudden increase in the volume of DNS traffic, and especially NXDOMAIN replies (although using a wildcard domain or some .in-addr.arpa queries would result in NOERROR replies). Since all the replies we get are eventually removed from the cache, the only way to try and reconstruct a message would be to keep a log of all DNS requests and look for patterns. This could be based on the number of queries for a particular domain and the intervals between queries (the host setting a message will have to resend its queries every TTL seconds), but would still return a lot of false positives. The way we described it, our scheme would also be vulnerable to detection due to one characteristic: we query for a domain, and even after receiving an NXDOMAIN response we query for its subdomains. This is obviously troubling, and no sane program should behave like that. It's possible to work around that, by querying the subdomains of a different domain than the control domain. We lose the benefit of being sure that the parent of the used subdomain doesn't exist, but if we picked the name wisely, it should not be a problem. ---[ 2.4 Closing Notes As mentioned in Part 1, we do not need to rely on the NCACHE behavior to implement such a scheme: it might be interesting to experiment with wildcard domains or .in-addr.arpa lookups. Also, we're not confined to the DNS infrastructure: almost any system which caches queries (think Web proxies) can be used for a similar purpose. And while a widespread worm using co-ordination mechanisms is yet to be written, you might just want to start logging the requests to your company's DNS server... ---[ 3. References [1] http://www.cs.ucl.ac.uk/staff/M.Rogers/kaminsky.html [2] http://www.dns.net/dnsrd/rfc/index.html [3] http://nstx.dereference.de/nstx/ [4] http://www.klake.org/~jt/dnshell [5] http://www.schneier.com/blog/archives/2005/06/attack_trends_2.html [6] http://blanu.net/curious_yellow.html [7] ftp://ftp.rfc-editor.org/in-notes/rfc1034.txt [8] ftp://ftp.rfc-editor.org/in-notes/rfc1035.txt [9] ftp://ftp.rfc-editor.org/in-notes/rfc2308.txt [10] http://www.digitalsec.net/ |=[ EOF ]=---------------------------------------------------------------=| ***Some days later.... in full-disclosure list we found the following message;*** http://lists.grok.org.uk/pipermail/full-disclosure/2005-July/035321.html [Full-disclosure] thctest netsniper netsniper at mail.ru Wed Jul 20 07:37:25 BST 2005 * Previous message: [Full-disclosure] PatchAdvisor Vulnerability Alert - Cisco CallManager Remote Denial of Service Vulnerability * Next message: [Full-disclosure] thctest * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] I had some fun with The Hacker's Choice website and thought some of you may want to learn from their lack of proper security. THC.org hosts project files, source code, and many other things. It also includes pictures of members and CCC friends, some that seem to request anonymity from public. Anyways, here are segfault's passwd and hosts files. I'll leave it up to you to determine if they are legit. I have no idea... passwd: root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/dev/null bin:x:2:2:bin:/bin:/dev/null sys:x:3:3:sys:/dev:/dev/null ....... ....... ....... dvorak:x:1045:1045:,,,:/home/dvorak:/bin/bash disque:x:1046:1046:,,,:/home/disque:/bin/bash whyking:x:1047:1047:,,,:/home/thc/whyking:/bin/bash vh:x:1049:1049:,,,:/home/thc/vh:/bin/bash nil:x:1050:1050:,,,:/home/thc/nil:/bin/bash hosts: 127.0.0.1 localhost 213.131.229.154 segfault 10.1.1.1 wu.sec wu 62.67.59.35 www.thc.org I also ripped some nice stuff from the site, rarred it up, and posted it on alt.binaries.warez.quebec-hackers if you take a look. Nothing special, but just for fun :-) This hack was pretty lame, seriously...read the nfo netsniper ***Then phrack papers leaked;*** http://lists.grok.org.uk/pipermail/full-disclosure/2005-July/035324.html http://lists.grok.org.uk/pipermail/full-disclosure/2005-July/035325.html -> LOL ***THC Official Response*** http://lists.grok.org.uk/pipermail/full-disclosure/2005-July/035348.html [Full-disclosure] RE: thctest (official response :-) vh vh at thc.org Thu Jul 21 10:33:34 BST 2005 * Previous message: [Full-disclosure] [USN-150-1] KDE library vulnerability * Next message: [Full-disclosure] RE: thctest (official response :-) * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Hi folks, here is some official response to the hack, or rather "hack" ... kudos to netsniper (or better: PHC) who really fooled us with this trick of a partial real and partial fake hack - it took us a day to figure things out :-) To clear things up: (1) The file thc-pwn3d.rar in alt.binaries.warez.quebec-hackers really contains password protected data from our web site, from our http://www.thc.org/root/tmp CMS directory to be specific. The bug was in our .htaccess file, which contained the following entry: require valid-user As netsniper found by testing, POST requests were therefore not protected with a password ... We use this directory to share stuff with friends from teso, phenoelite etc. hence its no secret stuff. Lots of photographs from events can be found on our web page without password protection. Note: not all people wearing a THC shirt there are from THC. This year we gave our t-shirt also to all our friends, fans and groupies :-) (2) The passwd and hosts file - clever trick. The PHC guys had legitimate accounts on the old segfault box about 1 1/2 years ago. From that time are these old files, directly copied because they were allowed to. proof: take the /etc/hosts entry for www.thc.org: 62.67.59.35 www.thc.org this is old, old, old. try it yourself, thc.org is now: Name: www.thc.org Address: 82.165.25.125 Also the passwd file is way old, however this is something someone without access to the box can not verify :-) (3) The phrack articles allegedly stolen from www.phrack.org (hosted on the same box as www.thc.org): Some months ago PHC disgused themselve on irc in the #phrack channel as editors and tricked two authors to send them their articles. Clever. Both texts are NOT articles in the phrack magazine to be published. As the hardcopy edition (to be given out for free on What-The-Hack) is already printed, no way to make something up here. In conclusion: one config mistake by us which was hard to find - congrats here - combined with information obtained otherwise (I like the social engineering trick for the phrack submissions) to fool everyone including us that www.thc.org was hacked. Neat. Last: Netsniper was hacking directly from his Ubuntu Linux 1.0.4 machine. And I thought real hackers only use Gentoo, Debian or SuSE, and prefer hacking with bouncers in between *g* Cheers, van Hauser / THC ------- ... yeah ... lame ... but funny