Scientists have developed free software that can prevent the techniques used by the Hacienda spy program to avoid a server being taken over.
Today, a group of journalists has reported the existence of the "Hacienda" spy program. According to this report, five western intelligence agencies are using the Hacienda software to identify vulnerable servers across the world in order to control them and use them for their own purposes. Scientists at the Technische Universität München (TUM) have developed free software that can help prevent this kind of identification and thus the subsequent capture of systems.
Port scanners are programs that search the Internet for systems that exhibit potential vulnerabilities. According to the report published today by journalists at Heise Online, Hacienda is one such port scanning program. The report says that this program is being put into service by the "Five Eyes," a federation of the secret services of the USA, Canada, the UK, Australia and New Zealand. "The goal is to identify as many servers as possible in other countries that can be remotely controlled," explains Dr. Christian Grothoff, Emmy Noether research group leader at the TUM Chair for Network Architectures and Services.
Source available at: https://gnunet.org/knock
(Score: 1) by NeoNormal on Tuesday August 19 2014, @08:02PM
I thought port scanning someone else's network is illegal? Or is that only for us plebes?
(Score: -1, Troll) by Anonymous Coward on Tuesday August 19 2014, @08:12PM
‧̴̵̶̷̸̡̢̧̨̛̖̗̘̙̜̝̞̟̠̣̤̥̦̩̪̫̬̭̮̯̰̱̲̳̹̺̻̼͇͈͉͍͎̀́̂̄̃̅̆̇̈̉̊̋̌̍̎̏̐̑̒̓̔̽̾̿̀́͂̓̈́͆͊͋͌̕̚ͅ͏͓͔͕͖͙͚͐͑͒͗͛ͣͤͥͦͧͨͩͪͫͬͭͮͯ͘͜͟͢͝͞͠͡
‧̴̵̶̷̸̡̢̧̨̛̖̗̘̙̜̝̞̟̠̣̤̥̦̩̪̫̬̭̮̯̰̱̲̳̹̺̻̼͇͈͉͍͎̀́̂̄̃̅̆̇̈̉̊̋̌̍̎̏̐̑̒̓̔̽̾̿̀́͂̓̈́͆͊͋͌̕̚ͅ͏͓͔͕͖͙͚͐͑͒͗͛ͣͤͥͦͧͨͩͪͫͬͭͮͯ͘͜͟͢͝͞͠͡
‧̴̵̶̷̸̡̢̧̨̛̖̗̘̙̜̝̞̟̠̣̤̥̦̩̪̫̬̭̮̯̰̱̲̳̹̺̻̼͇͈͉͍͎̀́̂̄̃̅̆̇̈̉̊̋̌̍̎̏̐̑̒̓̔̽̾̿̀́͂̓̈́͆͊͋͌̕̚ͅ͏͓͔͕͖͙͚͐͑͒͗͛ͣͤͥͦͧͨͩͪͫͬͭͮͯ͘͜͟͢͝͞͠͡‧̴̵̶̷̸̡̢̧̨̛̖̗̘̙̜̝̞̟̠̣̤̥̦̩̪̫̬̭̮̯̰̱̲̳̹̺̻̼͇͈͉͍͎̀́̂̄̃̅̆̇̈̉̊̋̌̍̎̏̐̑̒̓̔̽̾̿̀́͂̓̈́͆͊͋͌̕̚ͅ͏͓͔͕͖͙͚͐͑͒͗͛ͣͤͥͦͧͨͩͪͫͬͭͮͯ͘͜͟͢͝͞͠͡
‧̴̵̶̷̸̡̢̧̨̛̖̗̘̙̜̝̞̟̠̣̤̥̦̩̪̫̬̭̮̯̰̱̲̳̹̺̻̼͇͈͉͍͎̀́̂̄̃̅̆̇̈̉̊̋̌̍̎̏̐̑̒̓̔̽̾̿̀́͂̓̈́͆͊͋͌̕̚ͅ͏͓͔͕͖͙͚͐͑͒͗͛ͣͤͥͦͧͨͩͪͫͬͭͮͯ͘͜͟͢͝͞͠͡‧̴̵̶̷̸̡̢̧̨̛̖̗̘̙̜̝̞̟̠̣̤̥̦̩̪̫̬̭̮̯̰̱̲̳̹̺̻̼͇͈͉͍͎̀́̂̄̃̅̆̇̈̉̊̋̌̍̎̏̐̑̒̓̔̽̾̿̀́͂̓̈́͆͊͋͌̕̚ͅ͏͓͔͕͖͙͚͐͑͒͗͛ͣͤͥͦͧͨͩͪͫͬͭͮͯ͘͜͟͢͝͞͠͡‧̴̵̶̷̸̡̢̧̨̛̖̗̘̙̜̝̞̟̠̣̤̥̦̩̪̫̬̭̮̯̰̱̲̳̹̺̻̼͇͈͉͍͎̀́̂̄̃̅̆̇̈̉̊̋̌̍̎̏̐̑̒̓̔̽̾̿̀́͂̓̈́͆͊͋͌̕̚ͅ͏͓͔͕͖͙͚͐͑͒͗͛ͣͤͥͦͧͨͩͪͫͬͭͮͯ͘͜͟͢͝͞͠͡
‧̴̵̶̷̸̡̢̧̨̛̖̗̘̙̜̝̞̟̠̣̤̥̦̩̪̫̬̭̮̯̰̱̲̳̹̺̻̼͇͈͉͍͎̀́̂̄̃̅̆̇̈̉̊̋̌̍̎̏̐̑̒̓̔̽̾̿̀́͂̓̈́͆͊͋͌̕̚ͅ͏͓͔͕͖͙͚͐͑͒͗͛ͣͤͥͦͧͨͩͪͫͬͭͮͯ͘͜͟͢͝͞͠͡
‧̴̵̶̷̸̡̢̧̨̛̖̗̘̙̜̝̞̟̠̣̤̥̦̩̪̫̬̭̮̯̰̱̲̳̹̺̻̼͇͈͉͍͎̀́̂̄̃̅̆̇̈̉̊̋̌̍̎̏̐̑̒̓̔̽̾̿̀́͂̓̈́͆͊͋͌̕̚ͅ͏͓͔͕͖͙͚͐͑͒͗͛ͣͤͥͦͧͨͩͪͫͬͭͮͯ͘͜͟͢͝͞͠͡
‧̴̵̶̷̸̡̢̧̨̛̖̗̘̙̜̝̞̟̠̣̤̥̦̩̪̫̬̭̮̯̰̱̲̳̹̺̻̼͇͈͉͍͎̀́̂̄̃̅̆̇̈̉̊̋̌̍̎̏̐̑̒̓̔̽̾̿̀́͂̓̈́͆͊͋͌̕̚ͅ͏͓͔͕͖͙͚͐͑͒͗͛ͣͤͥͦͧͨͩͪͫͬͭͮͯ͘͜͟͢͝͞͠͡
‧̴̵̶̷̸̡̢̧̨̛̖̗̘̙̜̝̞̟̠̣̤̥̦̩̪̫̬̭̮̯̰̱̲̳̹̺̻̼͇͈͉͍͎̀́̂̄̃̅̆̇̈̉̊̋̌̍̎̏̐̑̒̓̔̽̾̿̀́͂̓̈́͆͊͋͌̕̚ͅ͏͓͔͕͖͙͚͐͑͒͗͛ͣͤͥͦͧͨͩͪͫͬͭͮͯ͘͜͟͢͝͞͠͡‧̴̵̶̷̸̡̢̧̨̛̖̗̘̙̜̝̞̟̠̣̤̥̦̩̪̫̬̭̮̯̰̱̲̳̹̺̻̼͇͈͉͍͎̀́̂̄̃̅̆̇̈̉̊̋̌̍̎̏̐̑̒̓̔̽̾̿̀́͂̓̈́͆͊͋͌̕̚ͅ͏͓͔͕͖͙͚͐͑͒͗͛ͣͤͥͦͧͨͩͪͫͬͭͮͯ͘͜͟͢͝͞͠͡
‧̴̵̶̷̸̡̢̧̨̛̖̗̘̙̜̝̞̟̠̣̤̥̦̩̪̫̬̭̮̯̰̱̲̳̹̺̻̼͇͈͉͍͎̀́̂̄̃̅̆̇̈̉̊̋̌̍̎̏̐̑̒̓̔̽̾̿̀́͂̓̈́͆͊͋͌̕̚ͅ͏͓͔͕͖͙͚͐͑͒͗͛ͣͤͥͦͧͨͩͪͫͬͭͮͯ͘͜͟͢͝͞͠͡‧̴̵̶̷̸̡̢̧̨̛̖̗̘̙̜̝̞̟̠̣̤̥̦̩̪̫̬̭̮̯̰̱̲̳̹̺̻̼͇͈͉͍͎̀́̂̄̃̅̆̇̈̉̊̋̌̍̎̏̐̑̒̓̔̽̾̿̀́͂̓̈́͆͊͋͌̕̚ͅ͏͓͔͕͖͙͚͐͑͒͗͛ͣͤͥͦͧͨͩͪͫͬͭͮͯ͘͜͟͢͝͞͠͡
(Score: 2) by frojack on Tuesday August 19 2014, @08:27PM
Don't believe it is illegal.
It might become illegal depending on what you do after you find an open port, but just sending a packet to an IP:port pair isn't illegal.
(Not that that would matter to the spooks).
No, you are mistaken. I've always had this sig.
(Score: 3, Interesting) by frojack on Tuesday August 19 2014, @08:25PM
Port Knocking has been around for a long time, and this is a new twist on the old method.
It relies on packing the sequence field in a standard SYN packet with some additional data, so the knock is essentially the initial connection.
Your first SYN is supposed to have a sequence number of zero, but past bugs allowed it to be essentially random garbage, which gets set upon establishing the connection. Nothing relied on this first SYN sequence number being correct. So these guys take advantage of that.
After evaluating the payload in the sequence number, your ports are opened and work as expected.
But how long will it take for this trick to be discovered by people who are in a position to actually watch for SYN packets?
No, you are mistaken. I've always had this sig.
(Score: 1) by X1 on Tuesday August 19 2014, @09:32PM
I like to play this little game of understanding issues more from my existing base of knowledge and comments, rather than RTFA. And that seems in spirit with this site and its ancestor. In that regard, can you further clarify? My existing understanding parses the summary "superpower spooks actually use nmap and satan/saint and the like, that sysadmins have been familiar with for over a decade. New tool somehow thwarts that threat, in ways that past standard security thinking on port knocking failed to see for years.". That seems to be a statement so incredible, and with no illumination provided by the summary, composed mainly of the upstream article. Which as aforementioned, I don't want to bother reading.
Frojack, you seem to have highlighted an interesting key- a channel of data communication that due to evolution and convention was available to be exploited (not in the nefarious, but rather the utilitarian sense of the word). But I still can't imagine how that extra communication channel would really help you against a state power using standard internet protocol port scanning combined with a willingness to commit 'unauthorized access to computer systems', and the power to likely do the same with most backbone internet routers/infrastructure.
Rereading your comment subject "port knocking without the knock", I wonder if that could be rephrased as "second implementation of port knocking" (as if there haven't already been a multitude of security-through-obscurity one-off variants on port knocking. I.e. if you want to get rube-goldstein(?) about it, you could run a fake slashcode instance, with chatbot generated comments, and then only after logging in and making a comment talking about BUGS BUNNY would your remote server allow you to administrate via ssh. I.e. is this new thing truly a new way to secure a server, or is it just one of a multitude of security through obscurity tactics such as the aforementioned BUGS BUNNY technique?
Perhaps if I understood better, my bottom line would be along the lines of your bottom line. I.e., ok, new tool works for a day, until people understand it is being used, and submit patches to nmap/satan/saint/etc. Or those that could have been monitoring the network for such unauthorized access (the ISPs, the spooks that infiltrated the ISPs, etc) now pay attention to that data too, and nothing fundamentally has changed. If it's more groundbreaking than that, as I truly hope the emdrive is in another field, please help me to better understand the theory of operation here without having to RTFA.
(Score: 2) by kaszz on Tuesday August 19 2014, @10:36PM
I think Google has an interesting approach in their internal network. Sign all packets and discard anything that isn't signed. This eliminates physically rough computers and protects sensitive servers (except for stupid lights-out-management-console without security). This could also deal with pw0ned ISPs.
So let clients send a signed timestamped? code to the network service. And only if it's matched will *that* stream be allowed to even begin. Following packets has to have the correct signing.
The problem is to phone-home from a place that doesn't have this software.. Ie almost all places.
(Score: 2) by frojack on Tuesday August 19 2014, @11:27PM
Where did you read that? You really can't sign every packet, that would require additional packets.
My understanding is that they are just encrypting all traffic, using a changing stream cipher.
No, you are mistaken. I've always had this sig.
(Score: 2) by kaszz on Wednesday August 20 2014, @12:25AM
You could decrease MTU and add a key or just redesign the protocol all the way. Otoh, the method you described is likely to accomplish the same end result.
(Score: 2) by Yog-Yogguth on Wednesday September 17 2014, @06:23AM
Just to clear up any confusion and point the way: the word ‘packets’ has a specific meaning referring to IP packets which are required for packet-switching which allows the network to work the way it does i.e. the internet doesn't work the way you suppose, it uses TCP (RFC 793 [ietf.org] —you'll find SYN and ACK there) and IP (RFC 791 [ietf.org] —you'll find packets there), feel free to read and understand it all (and more, there's a lot more) but as far as packets are concerned have a look at page 11 of RFC 791 and the schematic of what a packet header contains, there's no meaningful space for what you suggest (attempts at “real” security requires big keys) and it would be a terrible idea even if there was (many small packets are better than a few big packets to ensure routing/packet-switching works efficiently or even works at all, moving away from this is the same as moving away from the core largely decentralized nature of the technology towards greater centralization, go far enough and you're back to leasing your own direct lines, one to each destination you want, as one did in “the stone age” before packet-switching). The content of higher level protocols (which might be encrypted, signed, or whatever) are carried as dumb data (payload) inside multiple sequential IP packets.
Everything you talk about is (as it should be) at higher levels than these things and everything the article (or at least the summary) talks about is at these low levels. There's nothing stopping anyone from implementing anything they wish at higher levels, all the way up to metanets like the existing Tor, Freenet, and I2P.
Also and not in particular to you but because the article claims are not only extravagant but obviously stupid hype I'll just point out that HACIENDA is far more [heise.de] than “just” port-scanning (protecting against SYN attacks won't do much), the port-scanning is only the second step and after that it goes much further and at some point hands over to other systems and particularly LANDMARK, slides 24 and 26 are the most informative if anyone just want a quick glance. Pay attention to the word automated, realize this is global, unlimited, continuous, efficient, and cheap, and that it ends up taking everything it can get and subverting and infiltrating anything it can (and the pathway after that is the normal one even if it isn't pointed out in these slides: it all goes into NSA-net from which it is taken out according to data type and digested by whatever of the other systems are appropriate (other slides elsewhere show this process for specific examples of data types).
It's better to think of HACIENDA as a stepping stone consisting of automated triage and delegation to other 5-eyes functionality rather than “only” port-scanning or “only” 0-days etc.
Bite harder Ouroboros, bite! tails.boum.org/ linux USB CD secure desktop IRC *crypt tor (not endorsements (XKeyScore))
(Score: 2) by frojack on Tuesday August 19 2014, @11:21PM
In a typical port knock scenario, you send a packet to host:portA maybe followed by several other pairs host:portX host:portM ...
When your port knock setup sees these connection attempts on closed ports, it denies them as usual, but it remembers the sequence of their arrival, and the time in which they arrived. If they arrive in the proper sequence, and in the proper time your iptables will open/listen on some other port, say SSH(22) for X minutes/seconds.
So SSH only becomes available AFTER you a given sequence of other ports in a period of time.
This isn't that hard to outsmart, because you can't arbitrarily try to reject the sequence if some other connection attempt arrives between say host:portA and host:portX, because there are enough random connection attempts happening all the time that resetting the sequence for a random connect would amount to a self-denial of service.
Port Knocking has be fooled strictly by random knocks, but also by anyone in a position to watch packets being sent.
See: a couple explanations of why port knocking is not all that great Here [blogspot.com] and
Here [securitygeneration.com]
I din't mean to imply there is an "extra communication" channel. This new method is using part of a standard SYN packet, the first packet used when trying to connect, a part that has historically been ignored.
Cute animated SYN handshake demo here: http://www.inetdaemon.com/tutorials/internet/tcp/3-way_handshake.shtml [inetdaemon.com]
Coverage of the Sequence portion of a SYN packet here:
http://packetlife.net/blog/2010/jun/7/understanding-tcp-sequence-acknowledgment-numbers/ [packetlife.net]
Scroll down to "Sequence and Acknowledgment Numbers"
When a host initiates a TCP session, its initial sequence number in the first SYN packet is effectively random; it may be any value between 0 and 4,294,967,295, inclusive. It originally was designed to be zero in the standard, but because of historical bugs, nobody checked the first SYN, and all stacks allow it to be anything.
These guys are planning to make use of that, so that the first SYN packet can also carry some (not so secret) information
to pass to the Kernel.
You could combine this with standard port knocking, so not only do you have to get the host:sequence series of packets, but they all have to contain your special sequence numbers in a specific order.
But these guys never mention that, they are just using it to pass some additional bit of information that will tell the target to open up (listen on) the SSH port. That seems simplistic to me. Log some traffic, get some keys.
That said, they are offering some additional features that have never been used, such as being able to tell the target stack exactly how much of the subsequent data stream to "protect".
I haven't waded through all the code yet myself.
No, you are mistaken. I've always had this sig.
(Score: 1) by X1 on Wednesday August 20 2014, @07:35AM
Thanks for the thorough explanation, it is good context even if I understood all the basic theory of port knocking already.
Here is where you further enlighten me, though as I suspect, I still remain unimpressed by this new technique. I.e. this is clearly just adding complexity to the 'knock'. My BUGS BUNNY technique is just that taken to the comically illustrative extreme. Likewise, they are using the "historically ignored" bits as a new 'covert' 'extra communication channel'. Which could be portrayed to the non-security-expert (read: NPR listener) as some uber-terrorist-helping covert communication ability. However to people who understand the basics of Internet Protocol and how networks work, seems a lot less interesting. I.e. any ISP or network that wanted to prevent this kind of activity could easily just rewrite those bits as 0s. End of 'new terrorist communication threat'. I could still be wrong and maybe there is something landscape-changing here, but I don't grok it yet. I find it far more plausible that this is something the NSA has been using for themselves, flying underneath the ISP radar, or if need be, twisting ISP arms to have the channel ignored. Now however they can spin it to people who don't understand that it really isn't any new capability, as some sort of terrorist hacker threat to make people afraid of how Snowden educated all those terrorists. When in fact, it isn't fundamentally of any more use to terrorists than simple best-practices use of GPG/SSH/IPSEC/ETC.
Likewise, as to kaszz's description of Google inhouse network practices, it sounds like fundamentally no greater gain than properly managed IPSEC/SSH/router-packet-filtering-of-unexpected-traffic/etc.
Clearly I'm trying to derive the conclusion that there is "nothing to see here folks, move along and ignore the scary talk meant to incite fear in those who don't understand the issues". Which is sadly my conclusion of many 'security' articles on popular tech sites since the post-snowden propaganda wars have been raging...
(Score: 2) by frojack on Wednesday August 20 2014, @05:19PM
I pretty much agree with your assessment, and I'm not sure that kernel patch they offered is going to make it into any standard kernel, (and they only address linux, not MS/BSD/etc). It makes a bug in stack handling into a feature that people depend on, all without benefit of a RFC.
No, you are mistaken. I've always had this sig.
(Score: 0) by Anonymous Coward on Wednesday August 20 2014, @02:30PM
Watching SYN packets can only work if the secret message is always the same. But what if it depends on other parts of the package? The obvious solution would be to make a cryptographic hash with the secret and the IP of the sender, thus making it impossible to use the same ID from another source address; unfortunately that would not work with NAT (unless the NAT router knows the secret and sets the field).
(Score: 2) by frojack on Wednesday August 20 2014, @05:15PM
Adding something into that Sequence portion of the first SYN packet is all the descriptions really talked about.
but since both ends of the connection are likely to be NATted, I don't think its possible to hide an IP in there because the receiving end can't actually know the source's actual IP (just the external IP of the last NAT in what could be a chain of NATs) as you point out.
They specifically said it does work with NAT, but it breaks SIP and dual channel FTP. Meh! Nobody uses those!. (not!)
On the other hand this isn't meant for things like web servers or ftp servers of SIP, but rather for the admin gateways that we all have to leave open to manage remote servers. (SSH, and friends).
No, you are mistaken. I've always had this sig.
(Score: 0) by Anonymous Coward on Wednesday August 20 2014, @10:22AM
It will cause an extra hurdle to every attacker and will potentially stop
1) script kiddies
2) automated criminals, like the govt
Script kiddies could be stopped also with fail2ban or similar unless they are in control of a botnet and can poke you from a large number of IPs. And of course should the unblinking eye fix its gaze on you, this will probably not shield you for a very long time.