แบบนี้ถือว่าเป็นช่องโหว่? ตัว bus ถูกเชื่อมต่อกับอุปกรณ์ที่ไม่ได้รับอนุญาตแล้ว flood จนระบบตัดตัวเอง

ถ้าทำแบบนั้นได้ผมตัดสาย CAN bus ก็ได้เหมือนกัน?

โดยต่ออุปกรณ์สำหรับโจมตีเข้ากับรถยนต์ คืออะไรครับท่านนักวิจัย?

ถ้าปล่อยให้เค้าถึงตัวถังรถได้ ซึ่งต้องเปิดกระโปรง/เข้าถึงห้องโดยสารเพื่อเชื่อมต่อบัสได้ ถ้าผมจะประสงค์ร้าย ผมไม่ต้องรู้หรอกครับว่ารถนี้จะไฮเทคหรือไม่ จะใช้รูปแบบคำสั่งไหนในการเข้าควบคุมรถ จะ ICAN, WEDO, YOUCANT

ใช้วิธีการอย่างคลาสิคอย่างประเภท ตัดสายเบรค เจาะรูสายน้ำมันเบรค หรือตูมตามหน่อยอย่าง ติดระเบิดที่ตัวถังรถ จะแบบตั้งเวลาหรือรีโมทก็ได้ ซึ่งกระบวนการเหล่านี้มีการพิสูจน์แล้วกว่าหลายสิบปีว่าได้ผลจริง มันจะไม่ง่ายและหวังผลแต่ชีิวิตและทรัพย์สินได้มากกว่ารึ

ผมว่าประเด็นสำคัญอยู่ที่ การต่ออุปกรณ์ ที่ตั้งใจต่อเข้า CAN เพื่อทำให้เกิดปัญหา มันจะหลอกว่า Frame data ที่ส่งเข้าไป Flood ระบบมันมาจากอุปกรณ์อื่นได้เนี่ย อารมณ์เดียวกับ MAC Spoof ปลอมตัวเป็น ABS ยิง Flood มันเข้าไป

มิตรสหายท่านหนึ่ง

Seriously?
Those groups are making noise like this is a critical issue that must be addressed.

Everyone who works with CAN bus knows that physical access to the bus means the network can be compromised. Duh!

That's true for every type of communications protocol where you can either inject messages or intercept and rebroadcast. And once doesn't need the OBD-II connector to do this. For that matter the OBD-II CAN connection often doesn't even touch the real CAN buses used on a vehicle. Assume a vehicle uses the Freescale 9S12 with 5 CAN bus channels. One channel specifically to generate the OBD-II port, one for the instrument panel, one for engine to transmission, one to body electronics and I still have one left over.

So if you want to damage messages you have to hack into physical wiring for a specific bus and not just a connector. Any car company dumb enough to put a system critical bus on the OBD-II connector will find themselves with a recall I'm sure.

Next to do this is relatively easy. Years ago I worked with a semiconductor company to develop what I called the CBMM or CAN Bus Message Marker. It's express purpose (using an FPGA) was to park on the CAN bus and look for specific CAN IDs and then create an Error Flag of 6 dominant bits. It also had an occurrence counter so we could do this more than one time so we could create bus warning, bus passive right up to bus off events. The tool was use to verify that individual custom modules would properly hand a bus off situation. We could target both transmitters of messages and the receivers. This was at a time when CAN devices didn't provide access to the Rx and Tx error count registers.

Next tool was almost a decade later. The CAN CRC is designed to work best with an 11 bit ID message size and still does with the 29 bit ID. It's not an effective CRC for the longer messages that show up with CAN FD. I've been out of that world long enough now that I don't know if they use a different CRC when sending FD size messages. Back in 2000 when we used a custom CAN like protocol virtually identical to what CAN FD is now, IIRC we changed the CRC for the 2K sized messages that held Ethernet packets. (We were sending MPG4 over power line)

For that project I had to break the CAN bus in a different way by exploiting the CRC vulnerability. CAN handles single bit errors. It can even handle multiple bit errors that are contiguous as in the type caused by noise. The CRC cannot handle random errors across the entire message designed to corrupt only the data portion leaving the ID and CRC intact. Done correctly the appropriate bits are changed so the CRC is correct but the data bytes have been changed.

But even that can't be done deterministically because you can only actively inject dominant bits on top of recessive bits and there's no way to know that if you change this bit this time that it will cause an error not detected by the higher level protocol.

Finally to really do damage one needs access to the firmware of a module to modify the code or even replace it internally with different hardware so it becomes a bridge and then the sky is the limit. I don't know of too many MilCAN type products (tanks etc) that would allow someone to replace a module. Someone in a dealer service department could do this with your car. But they'd have to be really motivated to create a new module.

So let's not panic. CAN bus requires physical access in a way that is far beyond the WiFi and Iot world.

อีกท่านหนึ่ง

Fully agree.

One or two years ago, we had a same kind of discussion on the LinkedIn group.

I think we can be short about it. If a hack on the CANbus occurs, it can mean two things:

1. The developer has made a remote control input and did not include a correct "firewall". In my opinion it should include some kind of hardware switch.

2. The "hacker" made changes in the embedded hardware. Always lock your car.

Don't forget that CAN is a CONTROLLER Area Network. It simply replaces hard wiring of all sensors and actuators by a simple 2-wire (3 with the chassis included) system. It made the modern car much safer, however if you put it in an IOT infrastructure you can get security problems. These problems should be solved before data can reach the CANbus.

อีกท่านหนึ่ง

This just shows how sloppy the automotive industry is. When I designed can systems, the system node generated an alert state if there were more that one error frame in 10.000 messages. If there were more than one in 1000 messages, it went into a "safe critical" mode. The CAN feature of error counters is only for non-safety and non-time critical systems.

The first step in time- (and safety-) critical system design is to schedule every message that can be scheduled. Then you have a good start for a dependable system. A bonus is that you have made it at least an order of magnitude difficult to hack.

It is a shame that any car system could be hacked as showed! It shows that the system designer should have had another job, e.g., as a teacher in roman history.

ท่านนั้นอีกที

You are so right! Protocol is everything.

The authors didn't even mention the flaw in the CAN protocol that requires toggle messages to not be used since the target node may well miss the message and be error passive so it can't flag the message with a dominant error flag while others provide the ACK because they do receive the message.

And that's without any one doing something evil to the bus.