Interesting Ali Express web server behavior...

Mon Dec 11 02:53:51 UTC 2023

>
> But why would AliExpress be redirecting to DDN space? Is this legitimate?
> Ali hoping to get away with squatting, or something else?

I've seen a large number of cases that a company was  using someone else's
non-RFC1918 space for some reason, and that was accidentally exposed via
application communication when some process / procedure they were using to
fix that up didn't work. This feels like that to me.

On Sun, Dec 10, 2023 at 12:57 AM Owen DeLong via NANOG <nanog at nanog.org>
wrote:

> So I’m having trouble connecting to the Ali Express web server this
> evening and decided to investigate a little.
>
> What I found surprised me…
>
> owen at odmbpro3-3 ~ % openssl s_client -connect www.aliexpress.com:443
>
> CONNECTED(00000005)
>
> depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert
> Global Root CA
>
> verify return:1
>
> depth=1 C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
>
> verify return:1
>
> depth=0 C = CN, ST = \E6\B5\99\E6\B1\9F\E7\9C\81, L =
> \E6\9D\AD\E5\B7\9E\E5\B8\82, O = Alibaba Cloud Computing Ltd., CN =
> ae01.alicdn.com
>
> verify return:1
> … certificate stuff, blah blah from Akamai, routine…
>
> SSL-Session:
>
>     Protocol  : TLSv1.3
>
>     Cipher    : AEAD-CHACHA20-POLY1305-SHA256
>
>     Session-ID:
>
>     Session-ID-ctx:
>
>     Master-Key:
>
>     Start Time: 1702187128
>
>     Timeout   : 7200 (sec)
>
>     Verify return code: 0 (ok)
>
> ---
>
> read R BLOCK
>
> read R BLOCK
>
> GET / HTTP/1.1
>
> Host: www.aliexpress.com
>
>
> HTTP/1.1 302 Moved Temporarily
>
> Content-Type: text/html
>
> Content-Length: 258
>
> Location: http://33.3.37.57/
>
> Access-Control-Allow-Origin: https://hz.aliexpress.com
>
> Server: Tengine/Aserver
>
> EagleEye-TraceId: 2103253917021871367418570ec8e3
>
> Strict-Transport-Security: max-age=31536000
>
> Timing-Allow-Origin: *
>
> Date: Sun, 10 Dec 2023 05:45:36 GMT
>
> Connection: keep-alive
>
> Set-Cookie: ali_apache_id=33.3.37.57.1702187136742.612980.2; path=/;
> domain=.aliexpress.com; expires=Wed, 30-Nov-2084 01:01:01 GMT
>
> Server-Timing: cdn-cache; desc=MISS
>
> Server-Timing: edge; dur=65
>
> Server-Timing: origin; dur=3
>
> Server-Timing: ak_p;
> desc="1702187128314_400069768_2521981097_6837_5323_25_43_-";dur=1
>
>
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
>
> <html>
>
> <head><title>302 Found</title></head>
>
> <body bgcolor="white">
>
> <h1>302 Found</h1>
>
> <p>The requested resource resides temporarily under a different URI.</p>
>
> <hr/>Powered by Tengine</body>
>
> </html>
> … OK, so far so good, though the hard coded IP redirect is a bit odd.
> Especially when you consider this:
>
> NetRange:       33.0.0.0 - 33.255.255.255
>
> CIDR:           33.0.0.0/8
>
> NetName:        DISN-IP-LEGACY
>
> NetHandle:      NET-33-0-0-0-1
>
> Parent:          ()
>
> NetType:        Direct Allocation
>
> OriginAS:
>
> Organization:   DoD Network Information Center (DNIC)
>
> RegDate:        1991-01-01
>
> Updated:        2013-09-11
>
> Ref:            https://rdap.arin.net/registry/ip/33.0.0.0
>
>
>
> OrgName:        DoD Network Information Center
>
> OrgId:          DNIC
>
> Address:        3990 E. Broad Street
>
> City:           Columbus
>
> StateProv:      OH
>
> PostalCode:     43218
>
> Country:        US
>
> RegDate:
>
> Updated:        2011-08-17
>
> Ref:            https://rdap.arin.net/registry/entity/DNIC
>
>
>
> OrgTechHandle: REGIS10-ARIN
>
> OrgTechName:   Registration
>
> OrgTechPhone:  +1-844-347-2457
>
> OrgTechEmail:  disa.columbus.ns.mbx.arin-registrations at mail.mil
>
> OrgTechRef:    https://rdap.arin.net/registry/entity/REGIS10-ARIN
>
>
> OrgAbuseHandle: REGIS10-ARIN
>
> OrgAbuseName:   Registration
>
> OrgAbusePhone:  +1-844-347-2457
>
> OrgAbuseEmail:  disa.columbus.ns.mbx.arin-registrations at mail.mil
>
> OrgAbuseRef:    https://rdap.arin.net/registry/entity/REGIS10-ARIN
>
>
> OrgTechHandle: MIL-HSTMST-ARIN
>
> OrgTechName:   Network DoD
>
> OrgTechPhone:  +1-844-347-2457
>
> OrgTechEmail:  disa.columbus.ns.mbx.hostmaster-dod-nic at mail.mil
>
> OrgTechRef:    https://rdap.arin.net/registry/entity/MIL-HSTMST-ARIN
>
> Which seems in line with the announcement of that address I’m seeing:
>
> owen at delong-fmt2-mx-01> show route 33.3.37.57
>
>
> inet.0: 947480 destinations, 2018685 routes (947480 active, 0 holddown, 0
> hidden)
>
> + = Active Route, - = Last Active, * = Both
>
>
> 33.0.0.0/8         *[BGP/170] 1w6d 05:39:58, localpref 2000
>
>                       AS path: 6939 3356 749 I, validation-state:
> unverified
>
>                     >  to 64.71.131.26 via ge-2/0/0.0
>
>                     [BGP/170] 1w6d 05:35:29, localpref 100, from
> 192.124.40.252
>
>                       AS path: 36236 2914 3356 749 I, validation-state:
> unverified
>
>                     >  via gr-2/3/0.70
>
> (AS749 is also DISA/DDI)
>
> But why would AliExpress be redirecting to DDN space? Is this legitimate?
> Ali hoping to get away with squatting, or something else?
>
> Owen
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20231210/7c7f8dbc/attachment.html>