Rivian Constantly sending Buffer Overflow traffic to AWS

[PurseChicken]

Hello,

I was looking at my local network today, and I noticed that a device on my network is constantly being denied due to an IPS rule. Specifically in the Buffer Overflow Category with the name "SSL OpenSSL CRL Verification X.400 Address Handling Type Confusion Vulnerability (CVE-2023-0286)" Here is a link to the details of this detection in my WatchGuard appliance: https://securityportal.watchguard.com/threats/detail?ruleId=1231758

After some digging, I found that this appears to be my R1S with a MAC address that is associated with Vendor "u-blox ag" (OUI 20:BA:36). All of the traffic appears to be going to destination IP addresses that are associated with AWS. Additionally, it appears DNS lookups occur for "v1authz.prod.rivianservices.com" in the same cycle of the events.

Granted, my home setup also doubles as my lab, so I am sure I am unique in seeing this as most home users may not notice. That being said, I am posting here to see if anyone else has happened to see this on their network or if they have any insight. Definitely a discussion topic. I will likely also contact Rivian about this as well.

Thanks!

Sponsored

 

[Glembi2]

You may have found the cause of the increase in drain since the last update! A number of folks have noticed an increase in truck activity when it should be sleeping. Constantly pinging AWS would do it

 

[tate16t]

Can you check your logs to determine when this started? Does it coincide with the update release?

 

[COdogman]

Your S has become sentient and is taking its first steps. It’s Skynet all over again….

 

[NY_Rob]

I wonder if our vehicles will continue sending all that data if we make it "forget" our home networks or will it just find another route and send it via LTE?

That's precisely why I'm very interested in what will happen connectivity wise if we don't pay the $149 fee for the Connect + package when our "trial" period ends? Is Rivian going to keep our modems going with an AT&T account on their dime or will it just have no connectivity without someone paying AT&T for service?

Less like Skynet, more like Colossus: The Forbin Project

 

[gultin]

I wonder if our vehicles will continue sending all that data if we make it "forget" our home networks or will it just find another route and send it via LTE?

That's precisely why I'm very interested in what will happen connectivity wise if we don't pay the $149 fee for the Connect + package when our "trial" period ends? Is Rivian going to keep our modems going with an AT&T account on their dime or will it just have no connectivity without someone paying AT&T for service?

Less like Skynet, more like Colossus: The Forbin Project

I had actually tried turning off WiFi for a few days to see if it helps with vampire drain, (that's been significantly higher since the last update and I'm seeing 5-6% loss every 24 hours), but it made no difference.

 

[NY_Rob]

I had actually tried turning off WiFi for a few days to see if it helps with vampire drain, (that's been significantly higher since the last update and I'm seeing 5-6% loss every 24 hours), but it made no difference.

Thanks... so it simply switched to LTE to send data, nice..

As I mentioned above, it will be interesting to see what Rivian is going to do with those of us who are not going to subscribe to Connect +. It would be ironic indeed if canceling Driver + (and making your Rivian forget your home network) mitigated vampire drain
Rivian would really be painting themselves in to a corner at that point!

 

[FooF]

Maybe try allowing the traffic and see if your drain decreases?

 

[Lopsed]

I wonder if our vehicles will continue sending all that data if we make it "forget" our home networks or will it just find another route and send it via LTE?

That's precisely why I'm very interested in what will happen connectivity wise if we don't pay the $149 fee for the Connect + package when our "trial" period ends? Is Rivian going to keep our modems going with an AT&T account on their dime or will it just have no connectivity without someone paying AT&T for service?

Less like Skynet, more like Colossus: The Forbin Project

I don't know what will happen...but I want to unsubscribe from this subscription in the future too.

 

[Zoidz]

Your S has become sentient and is taking its first steps. It’s Skynet all over again….

How we imagined AI vs. today's reality:

 

[BCondrey]

I think you can safely permit this, or turn off the detection of the CVE. This is to protect against malformed addresses causing buffer overflows. Chances are your Rivian is not going to hack the AWS. I would be more concerned about the uploads failing all the time. u-blox is the marker for the MAC, correct.

 

[Osyras]

Hello,

I was looking at my local network today, and I noticed that a device on my network is constantly being denied due to an IPS rule. Specifically in the Buffer Overflow Category with the name "SSL OpenSSL CRL Verification X.400 Address Handling Type Confusion Vulnerability (CVE-2023-0286)" Here is a link to the details of this detection in my WatchGuard appliance: https://securityportal.watchguard.com/threats/detail?ruleId=1231758

After some digging, I found that this appears to be my R1S with a MAC address that is associated with Vendor "u-blox ag" (OUI 20:BA:36). All of the traffic appears to be going to destination IP addresses that are associated with AWS. Additionally, it appears DNS lookups occur for "v1authz.prod.rivianservices.com" in the same cycle of the events.

Granted, my home setup also doubles as my lab, so I am sure I am unique in seeing this as most home users may not notice. That being said, I am posting here to see if anyone else has happened to see this on their network or if they have any insight. Definitely a discussion topic. I will likely also contact Rivian about this as well.

Thanks!

Out of curiosity, what tools are you using to capture the traffic? I have a lot of network experience and am very familiar with tools like wireshark, but none of it is in the monitoring side.

Tx

Danny

 

[PurseChicken]

Can you check your logs to determine when this started? Does it coincide with the update release?

Unfortunately, the logs on these were so great that they were just overwriting the log file. So basically, I can't go back far enough to determine if this was a last update issue of if it has been present for some time before that.

I think you can safely permit this, or turn off the detection of the CVE. This is to protect against malformed addresses causing buffer overflows. Chances are your Rivian is not going to hack the AWS. I would be more concerned about the uploads failing all the time. u-blox is the marker for the MAC, correct.

The risk here is less that my Rivian is going to "hack the AWS", however I am more concearned about malicious looking traffic egressing my network and being inspected as such on the AWS side. Not only is this bad hygiene, but it has the potential for ending up on block lists \ ban lists.

Out of curiosity, what tools are you using to capture the traffic? I have a lot of network experience and am very familiar with tools like wireshark, but none of it is in the monitoring side.

Tx

Danny

Its not too complex on my side. I just have IPS enabled on my ingress and egress traffic with my firewall. It is what logs the events and signatures for analyzing later or in real time.

 

[godfodder0901]

Unfortunately, the logs on these were so great that they were just overwriting the log file. So basically, I can't go back far enough to determine if this was a last update issue of if it has been present for some time before that.



The risk here is less that my Rivian is going to "hack the AWS", however I am more concearned about malicious looking traffic egressing my network and being inspected as such on the AWS side. Not only is this bad hygiene, but it has the potential for ending up on block lists \ ban lists.



Its not too complex on my side. I just have IPS enabled on my ingress and egress traffic with my firewall. It is what logs the events and signatures for analyzing later or in real time.

I wouldn't be too concerned. I've never seen an IDS/IPS that didn't throw false positives from time to time. FWIW I'm not getting any malicious packets flagged through Snot/Suricata.

Sponsored