3

Assuming a network which has absolutely no support for SSL/TLS, as rationalised by this blog post, is it possible guarantee the security of privileged operator connections?

There are already mechanisms which allow us to oper using salted password hashes, which should be unfeasible to attack.1 As I understand, traffic is routed between devices I have no control over, and those devices could trivially hijack an already established connection. Should I be concerned that any router between my IRC client at home and my server hosted in a different country could steal my authenticated, yet insecure connection, and use it to wreak havoc?

Furthermore, I'm aware that IP addresses are often allocated dynamically to home internet connections such as mine, and so my IP address might change on occasions. When such a DHCP renewal event occurs, is it possible that some other user of my ISP might be able to steal an authenticated, yet plain-text (insecure) connection?

Footnote: I've chosen to leave that there to keep previous answers relevant, but I've realised it's not really worth mentioning. If you'd like to include attacks against salted oper authentication, that would probably be a valuable discussion, but otherwise anything seemingly relevant to current IRCds that don't support SSL/TLS (such as ircu) should be fine.

Anders
  • 64,406
  • 24
  • 178
  • 215
autistic
  • 734
  • 6
  • 17
  • The information you have provided (while plentiful) is still not-quite-sufficient. Is there a known shared secret password between the IRC server & these privileged operators? – Samuel Allan Feb 08 '18 at 03:38
  • @SamuelAllan I'm interested in current existing implementations, though preferably not obscure ones. Hence the reason I struck the hash-related content out of the question. – autistic Feb 08 '18 at 04:55

3 Answers3

3

No it is not pointless. The easiest example: You want nobody to know what's your nickname, in which channels you are and what you're writing in queries (private messages).

To address the concrete question

Should I be concerned that any router between my IRC client at home and my server hosted in a different country could steal my authenticated, yet insecure connection, and use it to wreak havoc?

In theory you should be concerned, as every router can do so. In practice it depends on who might want to do so and what he can do. I would think the people who both may want it and can do it are inside your LAN.

Your network admin might take over your connection and this won't be too complicated. You do not need to think about messing with TCP-Packets of your stream. He may just have a TCP-Proxy running, which can be as simple as two netcat instances and a firewall rule.

allo
  • 3,173
  • 11
  • 24
  • This does not answer OP's threat model. – forest Feb 02 '18 at 13:15
  • I simplified it, because you do not need more complicated threat models, when the most basic things are at risk. So you can answer the question already at that point with "it is not pointless". And yeah I know quite a few networks tell you they do support TLS because they think they do not need it. – allo Feb 02 '18 at 13:18
  • But we're not here to answer a question with our own threat model. It may be that OP only cares about integrity, not confidentiality (for example, he uses OTR for all private messages, and only talks in already publicly-logged channels). – forest Feb 02 '18 at 13:21
  • I see your point. I added a paragraph what I think about active attacks. I guess the local network admin is the most plausible scenario. – allo Feb 02 '18 at 13:38
  • *"I would think the people who both may want it and can do it are inside your LAN."* Though it's quite trivial to find well documented examples of people outside of your LAN perpetrating similar attacks, thanks to the likes of Snowden, you do present another point which I've not discussed: The LAN-based (or rather, wifi-based) attacks which... allow connection hijacking... of potentially OPER'd accounts. Thanks for that food for thought! I'll be sure to exploit it, if the IRC community turns a blind eye to the information I'm trying to put in front of their face ;) – autistic Feb 02 '18 at 18:16
  • I like the way you've explained your answer with what is essentially the simplest proof of concept, significantly reduced in complexity from I had in mind... At the moment, this is looking like an accepted answer, but I hope you can understand my intentions are to bring to light information to secure the world of IRC as best possible, so I'll wait for tomorrow to arrive, put a bounty up (which should earn everyone who answers some rep) and... then make my choice... :) – autistic Feb 02 '18 at 18:22
  • Yes of course every router outside can do the same as people in your LAN. But for the threat model its plausible that people in your environment are more interested in what you're doing than some random person controlling a router in the internet, as long as you aren't annoying secret agencies. After all, the middle nodes in the path from your LAN to the IRC-server are normally kind of random. – allo Feb 03 '18 at 18:51
  • 1
    Feel free to wait with accepting, I think some more discussion is interesting for such topics. I started with the general "Always use TLS" advice as well before @forest told me to expand more on the detailed threat model. – allo Feb 03 '18 at 18:53
  • Just thought of something you could add, which is common enough... In a home router I used to own, packets destined to ports not mapped to a DHCP address (whether that be due to a DHCP lease renewal or what-not?) would be routed to a DMZ, which means, theoretically, a malicious ISP employee could just throw a single computer on the DMZ and... they might not succeed in every hijacking... but they really only need to succeed once every now and then to be motivated, right? In terms of IRC, this could result in hijacked user accounts, channel takeovers, oper compromisation... server links? – autistic Feb 06 '18 at 14:10
  • This is especially an issue considering they can trigger the renewals. If at first you don't succeed, try, try again! ... and I see a lot of netsplits on undernet... I've not tested this, but it seems plausible from what I have observed; my server hosted by kimsufi links via DHCP... so... hmmm – autistic Feb 06 '18 at 14:10
  • I do not get your scenario. What the usual home router calls DMZ is normally as catch-all port forwarding to one PC which can be configured. When there is no forwarding the packets are usually dropped or rejected, not routed back to the ISP in some way. Or what do you mean? – allo Feb 06 '18 at 14:34
  • @allo I rent dedicated server with a well-known business in the industry, here... When my dedicated server boots, it uses DHCP to obtain an IP address. It's the same IP address every time, but it uses DHCP because... that's just the way it's configured. I suppose it reduces the volume of questions floating upstream to the dedicated service provider, along the lines of "What are network configurations?"... My provider isn't the only one; I've used others in the past which have used DHCP to dynamically assign public IP addresses from a pool, not suitable for a server, but for a bnc, OTOH... – autistic Feb 08 '18 at 09:50
  • What happens when the lease runs out? The upstream provider gets to route traffic as they choose, which they could anyway... but in the case of the latter, where the new IP may be assigned to some other customer, then wouldn't the other customer get packets from that TCP stream? We can assume a connection will timeout due to the PING TIMEOUT mechanism that IRC uses, which is the window of attack... after that timeout period ends, the attacker knows they can trigger their own DHCP renewal to try again, right? So even if they fail the first time, there's an element of "try, try again", right? – autistic Feb 08 '18 at 09:52
  • I'd love to take this to chat, as there are some things that I think would need to be considered in order to boost the probability of success, some... events that can be observed from the outside world... which would be useful to base predictions of the future from... and those predictions seem like they would boost the probability of success of a targeted attack, to me. If no other answer attempts to verify and addresses this, then I'm happy to work with you to try to reproduce these circumstances. As it is, this answer gets my tick anyway, but an answer that expands the attack surface? Gold. – autistic Feb 08 '18 at 10:01
  • Indeed, when a IP is allocated to a new customer and the connection isn't terminated before (the reallocation was too), the new customer may get a few packets before the stream gets a timeout or reset if the attacker does not supress connection resets. But most people do not need to be scared of this, as the connection will be probably be reset before your lease expires, if your server had a disconnected and did not give back the lease (and terminate all connections before) correctly. But still a valid case where TLS helps to avoid attacks. – allo Feb 20 '18 at 08:40
1

The short answer is NO, it is not pointless. You should use TLS.

What would stop a bad person from seeing your salted hash go by, and reusing it? Either just reusing or as a MitM attack.

'Mechanisms to oper using salted password hashes', just cries out as 'roll your own crypto'. (I could be wrong but,) Remember the first rule of Crypto is: You are doing it wrong.

Protecting against replay or MitM attacks, without using standard secure channel mechanisms is more than likely to be:

  1. Overly complex
  2. Flaky
  3. Insecure

<Sarcasm>

Maybe you could do it with some public-private crypto (or shared secret (which you shared over a secure channel right?!?...)), signing each message, oh and don't forget to add a non repeating nonce.

</Sarcasm>

Oh but that would be 1. Overly complex 2. Flaky and still 3. Insecure!

TLS is standard, well understood, battle tested, and easy to implement. That is pretty much the only way to reliably secure against replay and or MitM attacks here.

Now maybe you don't trust TLS CAs (because state actors), well my response to that is: Don't IRC about things, that will annoy state actors, over plaintext!!!

Edit: to address the comments:

  1. If setup correctly (Certs signed by a trusted CA) TLS should work fine. Just because some users will not use it correctly does not mean you should make it insecure for all users, especially privileged ones. (The blog post seems to describe an incorrectly configured system, so its point is moot)

  2. There are feasible attacks to (correctly) salted passwords* used in this way (Replay and MitM). So any router (or someone listening as you use an open wifi connection) along the way could mess with you.

  3. IP address changes (or NATed IP addresses) will only affect you if your server is using IP address white listing. Which is insufficent to protect you in the scenario you have described.

So in conclusion: use correctly configured TLS, to secure your all your communications , including authentication information. Otherwise you could get burnt by a bad person. Also educate your users to not just blindly click OK all the time.

Look at letsencrypt.org as a way to get legit CA signed certs for free. (note you will need to setup a renewal mechanism as they need to be refreshed every 90 days)

*(Salting only really protects you when you loose data at rest, not data in flight like this)

Community
  • 1
DarcyThomas
  • 1,298
  • 1
  • 10
  • 15
  • Well, I would not personally roll an auth system that reuses salts (at least, not weakly), just as I wouldn't roll a crypto that repeats nonce but... self-crit trigger... you have a valid point! It doesn't exactly answer the questions at hand, but it does give some advice to the IRC dev community, which often seems to turn a blind eye to idioms accepted throughout programming in all other realms: *Don't needlessly reinvent the wheel*, *(especially) don't (ever) authenticate plaintext* and *use the most appropriate tool for the job*... – autistic Feb 03 '18 at 10:32
  • Can you work on addressing the questions at hand, as opposed to the solutions? Because right now the problem is that the development community I'm talking about seem *blind* to the issues (and thus unwilling to fix them), and *need to be made aware*... or I need to be told that I'm wrong... – autistic Feb 03 '18 at 10:36
  • @Sebivor My solution is to use TLS! Anything else is Overly complex, Flakly, and Insecure. – DarcyThomas Feb 03 '18 at 10:40
  • I think you should take some time to read the question carefully, and identify what it is I'm asking... Extract the questions, literally, copy and paste the statements which end in a question mark into notepad, and ask yourself... "Am I answering this?". – autistic Feb 03 '18 at 10:42
  • Don't just answer the title. There are three paragraphs. Each paragraph has a question. If you quote them, answer yes/no, give citations/examples/supporting reason where possible, then you have most likely answered my questions, and you get my tick. – autistic Feb 03 '18 at 10:45
  • In the blog post the second set of bullet points, bullet point 2 implies that the TLS cert has not been setup correctly (It is self signed, only good for testing). The cert should be signed by a trusted CA. That way users are not being trained to click Ok all the time because 99% of the time that is what they do after checking the thumb-print is correct. – DarcyThomas Feb 03 '18 at 11:01
  • @Sebivor Ok, I have added some more detail hopefully that answers things to your satisfaction :D – DarcyThomas Feb 03 '18 at 11:17
0

Using the standard IRC protocol, no, you can't guarantee security over a plaintext channel. With a modified OPER command set using some kind of signed commands, you would be able to prevent others from forging commands.

As to taking over your connection due to an IP change, this would be incredibly unlikely. Your IP would need to be passed on to an attacker almost immediately (so the connection doesn't time out). The attacker would need to be in a position to respond to the first packet that comes in, and it would need to be an ACK packet (to get the right sequence numbers). Anything else would cause a connection reset.

David
  • 15,814
  • 3
  • 48
  • 73
  • You seem to have missed some key details. For a start, I already mentioned that we have salted forms of authentication that are unfeasible to break. There's no need for a signed OPER, and even if there were, you seem to have neglected the entire middle paragraph of my question where I raise that the routers between the server and the oper in question may tamper with, misroute or otherwise hijack connections. Would you mind addressing THAT part of the question? – autistic Feb 02 '18 at 06:38
  • Additionally, when we talk about *attacks*, you need to keep in mind that *attackers are opportunistic*. For example, there are DNS hijack attacks that have only a slim window, perhaps making it "unlikely" as you would describe that someone would perform a successful hijacking, yet a patient attacker will be well prepared for the opportunity, right? Would you mind addressing that in your answer, too? Because as it currently stands, I think you're in denial/brushing some things aside. – autistic Feb 02 '18 at 06:40
  • Do you think there might be situations where an attacker might be able to... reasonably guess... how many bytes they think their target has received? ... and what if they send a number that's too high? Would that still cause a reset? My understanding is that such a "gap" would be evident to the attacker in the lack of timely ACK response, allowing the attacker to... try to "guess" to fill in the gap... after some time. Is my understanding of retransmission rules correct? – autistic Feb 02 '18 at 07:00
  • I do recall being taught that TCP allows packets to be delivered out of order, and reordered by the kernel as a result. How might this affect the *likelyhood* (I think you meant "feasibility" or "difficulty", by the way) of exploitation? – autistic Feb 02 '18 at 07:04
  • 3
    @Sebivor: it sounds like the answer totally misses the point for you... in which case you can down vote it and obviously not accept it as your chosen answer. You may have gone on a bit more of a rant than appropriate here. – Jeff Ferland Feb 02 '18 at 18:49
  • @JeffFerland I suspect you're right. I'm prone to going on rants... but I'd rather assume I can help to transform a misunderstanding, and hence an answer into something more relevant and... accurate; I'd rather give the opportunity... even though I know the meaning of a numeric rank is relative and in this case, a downvote is unlikely to make a difference to OP (or answer author, rather) overall, some people do get upset when they're downvoted without being given a reason. – autistic Feb 02 '18 at 21:48