Warning To All Internet Users In Thailand

[meatboy]

not sure if this is connected to the problem i have been getting,my internet supplier is TOT the past couple of weeks while logged in every so often 6times on fri. 7am.-11am.my power has been turned OFF,then when i log back in my server in the left hand corner at the top has been changed to NEW TAB i then close it straight away.

[RedCardinal]

13 hours ago, KhunBENQ said:

C:\Users\admin>tracert google.com

Tracing route to google.com [203.113.51.90]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  ADSL [192.168.1.1]
  2     *        *        *     Request timed out.
  3     3 ms     2 ms     2 ms  192.168.7.5
  4    11 ms     9 ms     9 ms  203.113.44.237
  5     8 ms     8 ms     8 ms  203.113.44.201
  6     8 ms     8 ms     8 ms  203.113.51.90

Yeah, that's not right. If you visit www.google.com in browser are you seeing any warnings?  

[steven100]

AIS internet is fine. Google is fine.  There is nothing wrong from what I see,

just some issues with 3BB ... they are doing some tests. ....

[KhunBENQ]

I just checked the route again and it looks back to normal.

30 ms and an IP that belongs to Google.

 

So be optimistic and assume it was indeed just a technical problem.

(until proofed wrong)

 

Tracing route to google.com [216.58.221.46] over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  ADSL [192.168.1.1]
  2     *        *        *     Request timed out.
  3     3 ms     2 ms     2 ms  192.168.7.5
  4     9 ms    10 ms     8 ms  203.113.44.237
  5    14 ms     8 ms     9 ms  203.113.44.201
  6     9 ms     9 ms     8 ms  203.113.37.182
  7     8 ms     8 ms     8 ms  in-addr.net [203.190.250.221]
  8    25 ms    26 ms    25 ms  in-addr.net [203.190.251.230]
  9    32 ms    31 ms    32 ms  in-addr.net [203.190.250.57]
 10    32 ms    32 ms    32 ms  108.170.249.242
 11    35 ms    34 ms    34 ms  108.170.233.173
 12    31 ms    30 ms    31 ms  kul01s10-in-f14.1e100.net [216.58.221.46]

[RedCardinal]

If you check any of the IPs that the above trace routes point to they all redirect to Google:

 

43.245.144.114

110.164.10.89

203.113.51.90

 

I'm not a network engineer, but this does not look normal at all.  It looks like they are diverting DNS to their own servers and then 301 redirecting those requests to Google.  This is really a poor man's Man-In-The-Middle as they are commandeering your requests via DNS.  That said, it still may well give them access to your entire request including the URI.  They cannot see the actual content returned given that Google serves everything over TLS/SSL, but they do know what you are looking at/for.  If DNS resolved properly to Google's servers these ISPs would only be able to see that you requested a Google domain, but not the URI (or page) of the request itself.

 

A VPN to a nearby country should avoid this entirely, but I'd take care with what you search for or look at if you are on one of these ISPs.  I use True and AIS and neither seem affected by this currently.

[manarak]

31 minutes ago, KhunBENQ said:

So be optimistic and assume it was indeed just a technical problem.

(until proofed wrong)

ummm... that kind of thinking can be catastrophic as far as security is concerned.

the thinking for security is rather to consider everything compromised until proven safe.

[muratremix]

UDP traceroute could look normal.

TCP Traceroute to port 80 and 443 more important.

[manarak]

2 minutes ago, RedCardinal said:

 

They cannot see the actual content returned given that Google serves everything over TLS/SSL, but they do know what you are looking at/for.

this is actually only true if the request is really redirected to the intended target server. anyone having control over the routing could redirect the traffic anywhere he wants (for example to servers hosting a fake version of the websites you wanted to visit), spoof google's IP addresses and serve fake certificates which he will then himself confirm being valid.

I don't think it is the case here, but this scenario is possible and I wouldn't dismiss the possibility that it is being used against certain individuals.

[billd766]

15 hours ago, cmsally said:

I have just started to get problems, I think mostly google but other websites seem affected. I am with AIS fibre. Problems started approx 8pm. Before that all was normal.

 

 I had a few problems with Youtube and Gmail yesterday but it seems OK now today.

 

I use a 3BB VDSL link out here in Nakhon Nowhere.

[RedCardinal]

12 hours ago, muratremix said:

They can use hidden servers. Traceroute uses UDP.

There are tcp traceroute programs, that shows different routing to destination if port is 80 or 443.

3BB's man in the middle attack server is very professional. It gives ping in last hope exactly same (not bogus) ping.

like

us.server.com ....

1.

2.

3.

4. .... 200 ms!

Although server is in Thailand, they can manipulate everything.

Just to be clear - if you request a resource over TLS then Man-In-The-Middle is exceptionally hard to do.  It requires the "Man" to have trusted certs, and while this is possible, companies like Google, Facebook etc. will be watching carefully.  Google regularly removes untrusted keys from their browser for instance.  But it's very normal for requests to pass through multiple routers to get to their destination, and does not indicate that the intermediary steps are being listened to.

[RedCardinal]

For anyone on the affected ISPs - where do trace routes to facebook.com and twitter.com go?

 

Both Twitter and Facebook would be far more important from a security POV to the Thai authorities than Google, and if you see the same DNS poisoning for these then you can be fairly sure that Big Brother is indeed involved.

[RedCardinal]

10 minutes ago, manarak said:

spoof google's IP addresses and serve fake certificates which he will then himself confirm being valid.

You cant simply validate your own certs...

[Don Mega]

Everything working peachy here on True !

[manarak]

2 hours ago, RedCardinal said:

You cant simply validate your own certs...

it's possible using fake websites, fake IPs, fake servers, fake certs.

it's like generating an alternate reality.

Edited May 7, 2017 by manarak

[ukrules]

Just now :

 

C:\Users\user>tracert google.com

Tracing route to google.com [110.164.16.113]
over a maximum of 30 hops:

  1     4 ms     1 ms     3 ms  192.168.1.1
  2    22 ms    22 ms    37 ms  10.121.76.245
  3    20 ms    21 ms    21 ms  10.121.76.246
  4    25 ms    26 ms    23 ms  mx-ll-110.164.0-235.static.3bb.co.th [110.164.0.235]
  5    23 ms    23 ms    23 ms  192.168.254.49
  6     *        *        *     Request timed out.
  7    23 ms    22 ms    22 ms  mx-ll-110.164.16-113.static.3bb.co.th [110.164.16.113]

Trace complete.

 

[cmsally]

  C:\Documents and Settings\owner>tracert google.com                                                                                                             

Tracing route to google.com [43.245.144.153]                                    over a maximum of 30 hops:                                                                                                                                       

1     5 ms     6 ms     1 ms  192.168.1.1                                      

2    89 ms     3 ms     2 ms  10.207.240.6                                     

3    12 ms    12 ms    17 ms  10.207.240.5                                     

4    12 ms    12 ms    12 ms  10.154.1.37                                      

5    13 ms    12 ms    14 ms  49.228.1.33                                      

6    13 ms    17 ms    13 ms  ae46-406.NIXJ-TLS1-PE01.ais-idc.com [49.228.1.134]                                                                               

7    14 ms    14 ms    21 ms  49-231-33-112.sbn-idc.com [49.231.33.112]        

8    15 ms    15 ms    15 ms  dial-425.ras-18.bkk.c.cscoms.com [203.170.173.109]                                                                               

9    17 ms    14 ms    14 ms  dial-417.ras-19.bkk.c.cscoms.com [203.170.173.165]                                                                              

10     *        *        *     Request timed out.                              

11    15 ms    19 ms    15 ms  mx-ll-110.164.14-200.static.3bb.co.th [110.164.14.200]                                                                          

12    48 ms    41 ms    41 ms  mx-ll-110.164.1-111.static.3bb.co.th [110.164.1.111]                                                                            

13     *        *        *     Request timed out.                         

14    40 ms    40 ms    45 ms 43.245.144.153                                                                                                                

  Trace complete.      

 

            This is for AIS , however it seems to go through 3BB. Is there an explanation for this?                                                  

[alocacoc]

from 3bb:

 

>tracert google.com

Tracing route to google.com [216.58.221.46]
over a maximum of 30 hops:

  1     1 ms     1 ms    <1 ms  192.168.1.1
  2    29 ms    20 ms    20 ms  10.121.20.121
  3    19 ms    21 ms    21 ms  10.121.20.14
  4    22 ms    21 ms    21 ms  mx-ll-110.164.0-108.static.3bb.co.th [110.164.0.
108]
  5    22 ms    22 ms    22 ms  mx-ll-110.164.0-140.static.3bb.co.th [110.164.0.
140]
  6    22 ms    22 ms    21 ms  mx-ll-110.164.1-19.static.3bb.co.th [110.164.1.1
9]
  7    22 ms    22 ms    22 ms  mx-ll-110.164.1-117.static.3bb.co.th [110.164.1.
117]
  8    41 ms    41 ms    41 ms  10.33.35.125
  9    41 ms    40 ms    40 ms  72.14.205.192
 10    41 ms    41 ms    42 ms  108.170.249.226
 11    41 ms    42 ms    42 ms  108.170.233.173
 12    41 ms    41 ms    41 ms  kul01s10-in-f14.1e100.net [216.58.221.46]

Trace complete.

 

[ukrules]

It's changed very recently for me too :

 

C:\Users\user>tracert google.com

Tracing route to google.com [216.58.196.206]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  192.168.1.1
  2    25 ms    23 ms    89 ms  10.121.76.245
  3    21 ms    22 ms    20 ms  10.121.76.254
  4    24 ms    23 ms    22 ms  mx-ll-110.164.0-108.static.3bb.co.th [110.164.0.108]
  5    23 ms    22 ms    25 ms  mx-ll-110.164.0-140.static.3bb.co.th [110.164.0.140]
  6    22 ms    22 ms    23 ms  mx-ll-110.164.1-19.static.3bb.co.th [110.164.1.19]
  7    25 ms    26 ms    25 ms  mx-ll-110.164.1-11.static.3bb.co.th [110.164.1.11]
  8    43 ms    43 ms    42 ms  10.33.35.121
  9    42 ms    48 ms    60 ms  74.125.48.212
 10    43 ms    43 ms    43 ms  108.170.249.227
 11    72 ms    42 ms    42 ms  209.85.250.173
 12    42 ms    41 ms    41 ms  kul06s14-in-f14.1e100.net [216.58.196.206]

Trace complete.

 

 

Now using a google registered IP address which based on the timings is either hosted in Thailand or very nearby.

 

[ukrules]

There was something on the Thai news about this last night, the woman who lives in my house said someone deleted something which caused some problems.

[cmsally]

I just tried tracing some other sites and so far nothing else is going through 3BB or cscoms

and also for google there was Triple T

 

So basically my tracing for Google (bear in mind I'm using AIS) goes through AIS, then CSCOMS, 3BB and finally Triple T

Is that normal?

[RedCardinal]

2 hours ago, cmsally said:

Tracing route to google.com [43.245.144.153]

The important thing to look for is the IP that your DNS gives to Google.com.

 

In this case this isn't Google's IP at all, and belongs to TTT.   So this isn't right at all.  I wouldn't worry about the hops between you and the final IP, as so long as the final IP is Google then no one can (easily) track what you're doing apart from knowing you've made a request to Google's domain.  In your case you probably want to change the DNS servers you're using.

 

Talk of spoofing IPs, servers and certs etc. fails to grasp how TLS and other security protocols work.

Edited May 7, 2017 by RedCardinal

[RedCardinal]

2 hours ago, ukrules said:

Tracing route to google.com [110.164.16.113]

This isn't Google either - try changing your DNS servers.

[RedCardinal]

If you want to know if your DNS is sending you to a Google IP use this tool to check the IP tracert shows after the domain:

 

Tracing route to google.com [216.58.196.206]

 

https://www.ultratools.com/tools/ipWhoisLookup

 

If the response is a Thai ISP then they are directing all traffic for Google's domain to their own servers and then redirecting.  Doesn't strike me as something that could happen by accident...

 

[janclaes47]

1 minute ago, RedCardinal said:

If you want to know if your DNS is sending you to a Google IP use this tool to check the IP tracert shows after the domain:

 

Tracing route to google.com [216.58.196.206]

 

https://www.ultratools.com/tools/ipWhoisLookup

 

If the response is a Thai ISP then they are directing all traffic for Google's domain to their own servers and then redirecting.  Doesn't strike me as something that could happen by accident...

 

Do you know of any isp anywhere in the world where your trace route only contains 2 IP addresses, that is yours and the destination?

[manarak]

33 minutes ago, RedCardinal said:

The important thing to look for is the IP that your DNS gives to Google.com.

 

In this case this isn't Google's IP at all, and belongs to TTT.   So this isn't right at all.  I wouldn't worry about the hops between you and the final IP, as so long as the final IP is Google then no one can (easily) track what you're doing apart from knowing you've made a request to Google's domain.  In your case you probably want to change the DNS servers you're using.

 

Talk of spoofing IPs, servers and certs etc. fails to grasp how TLS and other security protocols work.

https://www.blognone.com/node/82129

 

is it a coincidence that the page is written in Thai ?

 

but here you can see what I meant...

 

see also:

https://kuix.de/blog/index.php?entry=entry110616-171707

 

and there are numerous other examples of how TLS/SSL confidentiality was breached by a man in the middle attack carried out by people controlling the routing infrastructure.

don't come and tell me it's impossible. it has already been done and for years.

Edited May 7, 2017 by manarak

[RedCardinal]

13 hours ago, manarak said:

see also:

https://kuix.de/blog/index.php?entry=entry110616-171707

 

and there are numerous other examples of how TLS/SSL confidentiality was breached by a man in the middle attack carried out by people controlling the routing infrastructure.

don't come and tell me it's impossible. it has already been done and for years.

I'm not here to fight with you, but the example you gave is from 2011 and applies to old security protocols. If you choose to investigate how modern security protocols work, especially those used by leading Internet companies, you'll quickly see that attacks such as the one you link to are far more difficult to pull off nowadays.   What is happening here is not a MitM attack - nobody is listening in on your encrypted communications.  What's happening here is these ISPs are directing your DNS requests for Google.com to servers they control and then redirecting these requests onto Google.  After the redirect a secure encrypted connection to real Google servers is made.  All those ISPs can actually intercept is the request URI, which wouldn't usually be available to them under TLS (only the domain can be easily known).  That's still not OK, but they cant see your passwords or the content you view.

 

Tracert simply shows the route to a defined IP, but doesn't show the eventual redirect that is happening.

[RedCardinal]

13 hours ago, janclaes47 said:

Do you know of any isp anywhere in the world where your trace route only contains 2 IP addresses, that is yours and the destination?

Physically impossible.  

[NickJ]

L 

[manarak]

10 hours ago, RedCardinal said:

I'm not here to fight with you, but the example you gave is from 2011 and applies to old security protocols. If you choose to investigate how modern security protocols work, especially those used by leading Internet companies, you'll quickly see that attacks such as the one you link to are far more difficult to pull off nowadays.   What is happening here is not a MitM attack - nobody is listening in on your encrypted communications.  What's happening here is these ISPs are directing your DNS requests for Google.com to servers they control and then redirecting these requests onto Google.  After the redirect a secure encrypted connection to real Google servers is made.  All those ISPs can actually intercept is the request URI, which wouldn't usually be available to them under TLS (only the domain can be easily known).  That's still not OK, but they cant see your passwords or the content you view.

 

Tracert simply shows the route to a defined IP, but doesn't show the eventual redirect that is happening.

Obviously there is something I don't understand about https then, I'd be glad if you could explain it to me.

 

Could you please explain how the https protocol protects a client whose traffic on all ports is redirected (fake DNS) to prepared fake website(s) that will spoof the domainname and serve fake certificates with fake certificate authority to the client?

 

Edited May 8, 2017 by manarak

[ukrules]

1 hour ago, manarak said:

Obviously there is something I don't understand about https then, I'd be glad if you could explain it to me.

 

Could you please explain how the https protocol protects a client whose traffic on all ports is redirected (fake DNS) to prepared fake website(s) that will spoof the domainname and serve fake certificates with fake certificate authority to the client?

 

That's not what happened here, of course it's possible to do but not likely to be done in a widespread public manner as you can't hide it.

 

If that did happen then people who look at certificates would notice the CA change, the only way to do it would be to have a friendly CA issue a certificate, this would compromise the CA. This has happened before and the consequences are severe.

 

When something like this is noticed it would be reported, my bet is that this would be noticed almost immediately, probably by google themselves, a browser update would happen and the CA would be removed from the included list of valid Certificate Authorities and that would be the end of the matter with the CA going out of business and all trust revoked worldwide.