4 ms·

While this is a very interesting read (learned a thing or two), the author's conclusion is a bit suspect. Using my custom http-traceroute, I've proven that the

by mfkp 12y ago

While this is a very interesting read (learned a thing or two), the author's conclusion is a bit suspect. Using my custom http-traceroute, I've proven that the man-in-the-middle machine attacking GitHub is located on or near the Great Firewall of China. Although suspicious, it seems one would need to know a lot more about China Unicom and their infrastructure to say this conclusively.

deleted 12y ago
[deleted]
mikekchar 12y ago
I apologize because I have not had time to really looking into this closely, but I think you are correct that the author's conclusions need to be reviewed. He repeatedly says that it is a man in the middle attack, but the link he points to says it is a man on the side attack. This is a very different beast: a man on the side attack does not rewrite packets, but rather uses it's position on the backbone to send replacement packets that will arrive before the real ones do. Also, the referenced link states that these packets are being sent on only 1% of responses. So if this is the case a traceroute is probably not going to find the issue. The offending node does not have to respond at all -- especially if it sends the bogus packets by a different route. Again, I have not looked at this in detail yet and probably won't have time for a few days. I would welcome a discussion on this point.
- makomk 12y ago
  Because it's a man on the side attack, it sends its attack packets when it sees the original request. He's taking advantage of this by lowering the TTL so that the request never actually reaches the destination server and only the system doing the attack is able to respond.
- tedunangst 12y ago
  The man in the middle attack was injecting javascript to recruit unwitting man on the side attackers against github. github was not being MITM'd, but its "attackers" were. edit: above may be imprecise. I went back and read the original more closely. they note that if they artificially drop an injected packet, it doesn't get resent (and hence the conclusion that it's man on the side), but they don't mention whether they get the original packets or not. If something is blocking the original baidu packets, it would have to be in the middle, not just on the side.
  - mikekchar 12y ago
    Yes, I was wondering whether the original packets arrive or not as well. I'd love to see the traces. In my quick read of the this article I couldn't understand the method that they used to make their determination. Was it the bad packets or the good packets that had the TTL rewritten? The fact that there is a system rewriting packets does not necessarily imply it is an attack. I once wrote a SIP client and the local ISP actually rewrote my headers -- I had a bug in the header and just sending it through the network rewrote it so that it was fixed. This was in Canada. As a result, I have absolutely no doubt that packets are being rewritten all over the place, not just in China. Detecting this is not proof in itself that this is the origin of the attack.
    - mikekchar 12y ago
      Responding to my own post (bad form). But hasn't he just found a network cache? Many firewalls block certain kinds of ICMP traffic for security reasons. So not being able to traceroute to some place is not suspicious in and of itself. So he sets the TTL so that it should not hit Baidu, but I notice in the picture of the last trace that he actually gets a "200 OK". I would not have thought that a man in the middle device would respond because then it would have to also know the content with which to respond. Since this is not the target Baidu machine, this has to be a cache. It is possible that the cache is also injecting the attack, but I don't actually see anything that suggests this from the data in the article.
samcrawford 12y ago
My first thought was that at the very least he should be comparing it to a tcp-traceroute (i.e. traceroute -T ...) rather than an ICMP one. Other routers before them may make different routing decisions based upon the type of IP traffic, so assuming both take the same path is unsafe.
snowwolf 12y ago
I think the thing everyone is forgetting is that if it isn't state sponsored/approved then why hasn't it been turned off (as far as I am aware the attack is still ongoing). If it was a hack, surely China Unicom should have fixed it by now?
- moe 12y ago
  Has someone contacted China Unicom about this? Perhaps they don't even know something is going on?
- SyneRyder 12y ago
  Hasn't it stopped as of March 31? Github system status now shows green, whereas they previously said "We will keep our status at yellow until the threat has subsided": https://status.github.com/messages https://status.github.com/messages

by mfkp 12y ago

deleted 12y ago

[deleted]

mikekchar 12y ago

I apologize because I have not had time to really looking into this closely, but I think you are correct that the author's conclusions need to be reviewed. He repeatedly says that it is a man in the middle attack, but the link he points to says it is a man on the side attack. This is a very different beast: a man on the side attack does not rewrite packets, but rather uses it's position on the backbone to send replacement packets that will arrive before the real ones do. Also, the referenced link states that these packets are being sent on only 1% of responses. So if this is the case a traceroute is probably not going to find the issue. The offending node does not have to respond at all -- especially if it sends the bogus packets by a different route. Again, I have not looked at this in detail yet and probably won't have time for a few days. I would welcome a discussion on this point.

makomk 12y ago
Because it's a man on the side attack, it sends its attack packets when it sees the original request. He's taking advantage of this by lowering the TTL so that the request never actually reaches the destination server and only the system doing the attack is able to respond.
tedunangst 12y ago
The man in the middle attack was injecting javascript to recruit unwitting man on the side attackers against github. github was not being MITM'd, but its "attackers" were. edit: above may be imprecise. I went back and read the original more closely. they note that if they artificially drop an injected packet, it doesn't get resent (and hence the conclusion that it's man on the side), but they don't mention whether they get the original packets or not. If something is blocking the original baidu packets, it would have to be in the middle, not just on the side.
- mikekchar 12y ago
  Yes, I was wondering whether the original packets arrive or not as well. I'd love to see the traces. In my quick read of the this article I couldn't understand the method that they used to make their determination. Was it the bad packets or the good packets that had the TTL rewritten? The fact that there is a system rewriting packets does not necessarily imply it is an attack. I once wrote a SIP client and the local ISP actually rewrote my headers -- I had a bug in the header and just sending it through the network rewrote it so that it was fixed. This was in Canada. As a result, I have absolutely no doubt that packets are being rewritten all over the place, not just in China. Detecting this is not proof in itself that this is the origin of the attack.
  - mikekchar 12y ago
    Responding to my own post (bad form). But hasn't he just found a network cache? Many firewalls block certain kinds of ICMP traffic for security reasons. So not being able to traceroute to some place is not suspicious in and of itself. So he sets the TTL so that it should not hit Baidu, but I notice in the picture of the last trace that he actually gets a "200 OK". I would not have thought that a man in the middle device would respond because then it would have to also know the content with which to respond. Since this is not the target Baidu machine, this has to be a cache. It is possible that the cache is also injecting the attack, but I don't actually see anything that suggests this from the data in the article.

samcrawford 12y ago

My first thought was that at the very least he should be comparing it to a tcp-traceroute (i.e. traceroute -T ...) rather than an ICMP one. Other routers before them may make different routing decisions based upon the type of IP traffic, so assuming both take the same path is unsafe.

snowwolf 12y ago

I think the thing everyone is forgetting is that if it isn't state sponsored/approved then why hasn't it been turned off (as far as I am aware the attack is still ongoing). If it was a hack, surely China Unicom should have fixed it by now?

moe 12y ago
Has someone contacted China Unicom about this? Perhaps they don't even know something is going on?
SyneRyder 12y ago
Hasn't it stopped as of March 31? Github system status now shows green, whereas they previously said "We will keep our status at yellow until the threat has subsided": https://status.github.com/messages https://status.github.com/messages