A conversation with RIPE NCC regarding Quasi Networks LTD (AS29073)

Recently I contacted RIPE NCC regarding Quasi Networks (AS29073) and their blatant disregard to abuse complaints. I have contacted Quasi Networks via the email addresses documented in the RIPE WHOIS database:

abuse@quasinetworks.com
operations@quasinetworks.com
gov.request@quasinetworks.com

However to little surprise, I received no response or confirmation of my emails. The attacks from IP addresses managed by Quasi Networks continue at this very moment.

I also tried contacting the building they were located in, per the RIPE database WHOIS record:

Suite 1, Second Floor
Sound & Vision House, Francis Rachel Street
Victoria, Mahe, SEYCHELLES

However no one at Sound & Vision Pty Ltd. answered the phone or returned my email.

So it appears Quasi Networks has not received my messages due to invalid emails addresses provided or has chosen to ignore to them, both a violation of RIPE NCC policies.

RIPE NCC

I contacted the RIPE NCC Regulatory Review Team about this issue and spoke with Laurens Hoogendoorn, RIPE NCC IP resource analyst and discussed the following questions:

Me: Why does RIPE NCC require the burden of proof to fall to the victim of network abuse when the RIPE Database contains invalid or false information for an organization?

Laurens: At the moment that they become a member they sign an agreement  in which they confirm that they will keep the contact details up-to-date. We consider contact details valid until proven otherwise and this is why we ask to provide evidence that contact details are invalid.

Me: Why does RIPE NCC not assist in the facilitation of communication between users and organizations in the RIPE Database when no response is received from the organization?

Laurens: As a membership association we implement and enforce policies that are made by the RIPE Community. We do have the mandate from the RIPE community to take action if contact details are proven to be invalid. We don’t have the mandate from the community to liaise between a party that reports abuse and the resource holder that is unresponsive.

Me:  Does RIPE NCC recommend contacting law enforcement in the  organization’s jurisdiction to assist in such matters mentioned above?

Laurens: We always recommend to contact the relevant authorities
if you are the victim of a crime.

Laurens also recommended contacting the holder of the parent IP block, Novogara LTD via email (only available method) at support@novogara.com. This is did not see to follow the documented protocol, so I asked additional follow up questions:

Me: You stated, “Finally, I do want to emphasise that I did double check our records before I sent my first email and we don’t have any reason to believe at this moment that the contact details are invalid.” What steps did you (RIPE NCC) take to complete this check? Did you contact the organization (Quasi Networks LTD) in any way to verify? Does RIPE NCC maintain a “backchannel” to organizations? You recommended that I “could also try to contact the holder of the parent IP block; maybe they are able to assist further.” I was not aware of this as the standard communication protocol per RIPE NCC policies regarding unresponsive abuse complaints to organizations. Is this something you recommended to try informally?

Laurens: 80.82.65.0/24 is a PA assignment and was created by our member Novogara LTD without the involvement of the RIPE NCC. For PA assignments you can indeed contact the holder of the parent block (as it is their address space). Quasi Networks LTD also holds AS29073 and the RIPE NCC did validate the registration details at the moment that they received the ASN.

So how does RIPE NCC policies differ from other Regional Internet Registries? In the case of invalid WHOIS details, there are indeed some differences.  The American Registry for Internet Numbers  (ARIN) will take action to contact organizations when they receive a report of invalid WHOIS data. Per Jonathan Roberts, ARIN Registration Services, ARIN will attempt to find updated contact information for invalid abuse records.

In my case, the attacks from Quasi Networks will continue unabated with no regulatory power from RIPE NCC to stop them. I have contacted support@novogara.com for assistance but have not received a response.

 

Intel® AMT related port attacks on the rise and hits close to home

It comes at no surprise attacks on ports related to Intel® AMT have risen after the recent disclosure of an escalation of privilege vulnerability in Intel® Active Management Technology (AMT) that can allow an unprivileged attacker to gain control of the manageability interface of the affected servers. This exploit has been dubbed “Silent Bob is Silent” and is shocking in its simplicity to perform.  Intel has published a full mitigation guide to disable the attack vector until a permanent solution is in place.

Per Intel® documentation, the affected ports to monitor are 16992, 16993, 16994, 16995, 623, and 664. So, let’s review the recently dropped packets on those ports and where they’re coming from since the vulnerability was disclosed:

Intel AMT ports attacked

 

The good news is that it appears a majority of the dropped packets where from scanning services, such as the Shadowserver Foundation and Project Sonar. However the remaining attackers probably didn’t have good intentions in their attempt to get in

The bad news is after running the INTEL-SA-00075 Discovery Tool, I found one of my servers was affected.

Intel AMT vulnerability detected!
Intel AMT vulnerability detected!

I contacted the manufacturer of the motherboard, Super Micro Computer, Inc., and spoke with Application Engineer Kin Yan.  He stated, “Our team is working on this BIOS update to fix this issue. The target release date of this BIOS is by the end of this month.” In the meantime he strongly recommended to disable Intel® AMT in the BIOS settings until the vulnerability was patched.

Latest firmware update for Amcrest cameras results in constant connection to cloud servers even for non-cloud customers

I recently updated the firmware of my Amcrest IP2M-841 and  IP3M-943 cameras to the latest version. Afterward I began noticing a constant connection to three separate, unknown servers.

Amcrest likes to watch you.

I found this odd as I had not seen these connections prior to the firmware update.  Performing a simple DNS lookup for each yielded the following:

ec2-52-90-88-253.compute-1.amazonaws.com
ec2-107-23-233-106.compute-1.amazonaws.com
ec2-52-91-65-92.compute-1.amazonaws.com

This clearly shows that all three servers are hosted on Amazon AWS.  Unfortunately this tells  us nothing about who is using Amazon’s infrastructure to talk to my cameras. So to investigate further, I went directly to ec2-52-90-88-253.compute-1.amazonaws.com in the browser, noting to use HTTPS since port 443 was being used.

Dan Burkett also likes to watch!

This triggered a warning that the SSL certificate was not trusted and could not connect.  The error message provided by Chrome was “ERR_BAD_SSL_CLIENT_AUTH_CERT” with no further details.  I was not able to find out the certificate was self-signed by someone named “Dan Burkett” until I used Pale Moon.  So who is Dan Burkett and why are my cameras using a self-signed SSL cert to speak to him?

According to CrunchBase, Dan Burkett is co-founder and CTO at Camcloud, based in Ontario, Canada, where he primarily focuses on platform architecture, mobile development and streaming media.

So is Dan watching me undress?  Probably not, but let’s see how much bandwidth (traffic) my IP2M-841 camera is using to talk to Dan’s servers.  This is accomplished with an SNMP sensor in PRTG once the SNMP option is enabled and the strings set in the camera configuration page.

Camera bandwidth (traffic) usage

Over the last two days the traffic has been constant, averaging about 14 kbit/s during the time period.  Is this enough usage to be watching a secret live video feed of me? Not likely as that equates to a transfer rate of 1.75 kilobytes per second.  At this level even a low resolution JPEG snapshot being taken at a reasonable interval would be near impossible.

So what is actually being disseminated to these mysterious cloud servers? The only way to find out would be to complete a packet capture with Wireshark and monitor the traffic in real time.

 

Wireshark capture

Unfortunately the traffic to the mysterious cloud servers is encrypted, so without the server’s private key we will never known what is being transmitted.

However, we are able to find out the DNS names of the servers based on the queries sent from the camera.  Finally the names were revealed when the DNS lookup answers came in:

Queries
ftps.hostedcloudvideo.com: type A, class IN
Answers
ftps.hostedcloudvideo.com: type A, class IN, addr 54.159.91.18
ftps.hostedcloudvideo.com: type A, class IN, addr 54.224.213.162
ftps.hostedcloudvideo.com: type A, class IN, addr 54.80.240.204
ftps.hostedcloudvideo.com: type A, class IN, addr 54.80.249.22
ftps.hostedcloudvideo.com: type A, class IN, addr 54.158.231.89
ftps.hostedcloudvideo.com: type A, class IN, addr 23.20.159.229
ftps.hostedcloudvideo.com: type A, class IN, addr 54.159.95.70
ftps.hostedcloudvideo.com: type A, class IN, addr 54.166.187.129
ftps.hostedcloudvideo.com: type A, class IN, addr 54.162.101.239
ftps.hostedcloudvideo.com: type A, class IN, addr 54.198.155.118
ftps.hostedcloudvideo.com: type A, class IN, addr 54.158.208.74
ftps.hostedcloudvideo.com: type A, class IN, addr 54.146.1.185
ftps.hostedcloudvideo.com: type A, class IN, addr 54.167.219.193
ftps.hostedcloudvideo.com: type A, class IN, addr 54.162.218.154
ftps.hostedcloudvideo.com: type A, class IN, addr 54.146.46.97
ftps.hostedcloudvideo.com: type A, class IN, addr 54.221.201.14
ftps.hostedcloudvideo.com: type A, class IN, addr 23.20.254.144

Queries
config.amcrestcloud.com: type A, class IN
Name: config.amcrestcloud.com
Answers
config.amcrestcloud.com: type A, class IN, addr 54.158.250.32

Queries
command-4.amcrestcloud.com: type A, class IN
Answers
command-4.amcrestcloud.com: type A, class IN, addr 52.90.88.253

Queries
media-amc-0.hostedcloudvideo.com: type A, class IN
Answers
media-amc-0.hostedcloudvideo.com: type A, class IN, addr 54.162.224.230

Queries
dh.amcrestsecurity.com: type A, class IN
Answers
dh.amcrestsecurity.com: type A, class IN, addr 54.84.228.44

This shows the constant connection to 52.90.88.253 is the “command server” command-4.amcrestcloud.com.  Amcrest Support was not able to provide any reasons why is this connection necessary.

 

Bonus Notes

The last DNS query shows another connection the camera made to another server, dh.amcrestsecurity.com. This connection was not encrypted.

 

Wireshark Capture 2

It appears the camera reads the file http://dh.amcrestsecurity.com/readbinfile.html as some sort of firmware check.

 

6/1/2017 — Update

After much discussion with Amcrest Support regarding this issue, the following update was received:

Hello Troy,

I’m from Amcrest Cloud support. Sorry for all the back and forth. We’ve finally come to understand the situation. Thanks for all the feedback via email and your blog post (great analysis btw). A couple of points:

1 – All the traffic from camera -> cloud is expected and standard for this kind of device and matches what would be in our server logs, including pings to the cloud servers, certificate exchange/setup, etc.

2 – The problem you’ve identified is that the outbound communication is supposed to stop after 2 hours if a user has not attached their camera to a cloud account. We have finally reproduced this problem internally and you’re right, there is an issue in the firmware.

We are working with the firmware team to ensure this traffic is halted after 2 hours, as intended. I’m currently testing a release that fixes this, so it shouldn’t be long before the new firmware is released.

Once again, thanks for taking the time to dig into our product at this level of detail.

Regards,
Alen

8/22/2017 — Update

Amcrest has fixed this issue for certain cameras / firmware versions. Read more in my update here.

Another look into no-reverse-dns-configured.com’s troubled past

I previously reported on no-reverse-dns-configured.com and the current and previous owners.  But what about the February 2016 botnet attacks? Who was the owner when the domain name was invoked in those attacks?

According to DomainTools, the owner of no-reverse-dns-configured.com in February 2016 was Slawek Modrzejewski.  Slawek was original owner of the domain name since it was first registered in 11/15/2015.

On 4/9/2016, the registration for no-reverse-dns-configured.com was dropped by GoDaddy.  Five days later, the registration was picked up by SouthNames Inc. (NamePal.com) with an anonymous owner protected by United Privacy Corp, which is based in Belize.

In addition to the number WHOIS record updates for no-reverse-dns-configured.com, there has been an equally historic hosting history.  As of this writing, no-reverse-dns-configured.com has been pointed to 14 different IP addresses, shown in the illustration below from DomainTools.

Epic hosting history!

During the botnet attacks, the hosting IP address was changed to 23.250.123.223 which is managed by ColoCrossing.  After the attacks the server IP address was changed to 12.12.12.12 – which is a bit odd as that IP is managed by Alascom, Inc. in Anchorage, Alaska.  Further information provided by DomainTools shows 78 domain names have A records going to 12.12.12.12.

This leads to none of those domain names actually resolving anywhere, which may appear to be some sort of “spammer nullroute”.  The full list of the 78 domain names pointing to 12.12.12.12 is available here. I notified AT&T/Alascom about these fake A records pointing to their infastructure and will follow up if I hear back from their NOC/IPAM team.