Tags:
Node Thumbnail

นักวิจัยจาก Politecnico di Milano, Linklayer Labs, และ Forward-looking Threat Research ของ Trend Micro ค้นพบข้อบกพร่องที่เกิดจากโปรโตคอล CAN (Controller Area Network) ที่ใช้ในการสื่อสารระหว่างอุปกรณ์ต่างๆ ในรถยนต์สมัยใหม่

ข้อบกพร่องนี้เกิดจากมาตรฐานของ CAN ในการจัดการกับ error ของ message หรือ frame ที่วิ่งอยู่ใน CAN bus โดยถ้าอุปกรณ์ใดส่งข้อมูล error ออกมามากจนเกินไป ก็จะเข้าสู่สถานะ Bus Off หรือถูกตัดออกจาก CAN โดยอัตโนมัติ

ทีมนักวิจัยใช้คุณสมบัตินี้ของ CAN ในการโจมตีระบบในรถยนต์สมัยใหม่ โดยต่ออุปกรณ์สำหรับโจมตีเข้ากับรถยนต์ และทำให้เกิด error โดยใช้ข้อมูล frame ที่วิ่งอยู่ใน CAN อยู่แล้ว และสามารถทำให้อุปกรณ์ใดก็ตามที่ต่อกับ CAN เช่น ถุงลมนิรภัย, ระบบเบรก, หรือเซ็นเซอร์บอกระยะหน้า-หลัง เข้าสู่สถานะ Bus Off ซึ่งอาจทำให้เกิดอันตรายถึงแก่ชีวิตของผู้โดยสารได้

ในรายงานนี้เป็นการโจมตีแบบที่ต้องเข้าถึงตัวรถยนต์ (require local access) แต่ทีมนักวิจัยระบุว่าสามารถทำการโจมตีด้วยวิธีดังกล่าวผ่านช่องโหว่อื่นที่ทำให้ผู้โจมตีสามารถ reprogram firmware ของ ECU เช่น ระบบ infotainment จากระยะไกลได้ด้วย

ข้อบกพร่องนี้ไม่สามารถแก้ไขได้โดยการ patch ซอฟต์แวร์ของรถยนต์ เพราะเกิดจากรูปแบบการทำงานในระดับล่างสุดของมาตรฐาน CAN เอง หากต้องการแก้ไขข้อบกพร่องดังกล่าวให้หมดไป จะต้องมีการปรับปรุงมาตรฐาน CAN ใหม่

ที่มา – BleepingComputer, TrendLabs

Get latest news from Blognone

Comments

By: lew
FounderJusci's WriterMEconomicsAndroid
on 19 August 2017 - 10:57 #1003076
lew's picture

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

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


lewcpe.com, @wasonliw

By: kong
WriterAndroidUbuntuWindows
on 19 August 2017 - 11:07 #1003079 Reply to:1003076
kong's picture

ฮ่า... นั่นสิครับ เค้าใช้คำว่า flaw ผมไม่รู้จะแปลว่าอะไรดี


suksit.com

By: lew
FounderJusci's WriterMEconomicsAndroid
on 19 August 2017 - 11:10 #1003080 Reply to:1003079
lew's picture

แนะนำให้เปลี่ยนเป็น "นำเสนอความเสี่ยง" แทนครับ เขาพูดถึงว่าอุปกรณ์บางตัวมันต่อกับ can แล้วต่อเน็ตด้วย

ผมเข้าใจว่าผู้ผลิตรถบางราย ก็คิดถึงความเสี่ยงประมาณนี้อยู่แล้ว ระบบ infotainment บางตัว ซึ่งแสดงข้อมูลรถก็ถูกกำหนดเป็น read only แต่ดันโดนแฮกแล้วเปลี่ยนโหมดได้อีก

แนวทางแบบนี้อาจจะบอกได้ว่าผู้ผลิตต้องถือเป็น best practice ที่จะป้องกันอุปกรณ์ความเสี่ยงสูงที่เชื่อมต่ออินเทอร์เน็ตไม่ให้ส่งข้อมูลเข้า CAN bus ของรถได้ (อาจจะกั้นระดับฮาร์ดแวร์เลย)


lewcpe.com, @wasonliw

By: kong
WriterAndroidUbuntuWindows
on 19 August 2017 - 11:22 #1003082 Reply to:1003080
kong's picture

ลองเปลี่ยน title กับข้อความข้างในละครับ น่าจะดีขึ้น :3


suksit.com

By: lew
FounderJusci's WriterMEconomicsAndroid
on 19 August 2017 - 20:48 #1003128 Reply to:1003082
lew's picture

ผมขออนุญาตตัดเรื่องเสี่ยงถึงชีวิตออกนะครับ ลดโทนให้ตรงกับระดับความร้ายแรงของตัวงานวิจัย

งานวิจัยแนวๆ นี้ผมมองว่ามันเหมือนพวกการเสนอความเสี่ยงเช่น SELinux ที่มีการเสนอให้แยกระบบออกเป็นส่วนๆ ขาดจากกัน ระบบใหม่ๆ ถือเป็น best practice แอดมินลงระบบใหม่ถูกสอนให้เปิดระบบพวกนี้เอาไว้

แต่การไม่ได้เปิดระบบพวกนี้ไม่ได้เป็นช่องโหว่แน่ๆ ระบบที่มีความปลอดภัยสูงอาจจะมีเหตุผลบางอย่างที่มีบางส่วนไม่ได้แยกส่วนย่อยเอาไว้


lewcpe.com, @wasonliw

By: tekkasit
ContributorAndroidWindowsIn Love
on 19 August 2017 - 11:10 #1003078
tekkasit's picture

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

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

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

By: kong
WriterAndroidUbuntuWindows
on 19 August 2017 - 11:34 #1003081 Reply to:1003078
kong's picture

ในบทความมันว่าประมาณนี้ครับ น่าจะคล้ายๆ ที่คุณ lew คอมเมนต์ไว้ข้างบน

Often, many car hacking proof-of-concepts and vulnerabilities are disregarded because they require having local access to the car. First, our attack can be enabled with any remotely exploitable vulnerability that allows the attacker to reprogram the firmware of an ECU (e.g., the infotainment system). Secondly, even local attacks should be taken seriously. Traditionally, the scenario in which an attacker could access a car that way is not only rare, but is also very risky to the attacker. This may have been true back then, but with current transportation trends such as ride-sharing, carpooling, and car renting, the scenario where many people can have local access to the same car is now more commonplace. As such, a paradigm shift in terms of vehicle cybersecurity must happen.


suksit.com

By: Dino
iPhoneSymbian
on 19 August 2017 - 16:04 #1003106
Dino's picture

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

By: sdh on 20 August 2017 - 11:42 #1003164

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

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.

By: lew
FounderJusci's WriterMEconomicsAndroid
on 21 August 2017 - 09:50 #1003288 Reply to:1003164
lew's picture

ไป copy ข้อความมาไม่บอกต้นทางทั้งดุ้นแบบนี้ผมจะลบทิ้งเร็วๆ นี้นะครับ ผมให้เวลาอ้างอิงภายในวันนี้


lewcpe.com, @wasonliw

By: sdh on 21 August 2017 - 11:11 #1003305 Reply to:1003288

https://groups.yahoo.com/neo/groups/CANbus/conversations/messages