Xe của bạn chính là một máy tính di động — và mã nguồn của nó có thể bị hack
Chúng tôi không đùa khi nói về ô tô như các trung tâm máy tính di động có bánh xe. Nếu bạn ghé qua Glassdoor, thậm chí có một câu hỏi phỏng vấn, “Một chiếc ô tô Tesla có bao nhiêu dòng mã nguồn?”
Tôi không chắc chắn, nhưng thậm chí cách đây một thập kỷ, các dòng xe cao cấp chứa 100 đơn vị điều khiển điện tử (ECU) dựa trên vi xử lý, thực hiện cùng lúc hơn 100 triệu dòng mã nguồn. Sau đó là các hệ thống telematics, phần mềm hỗ trợ lái xe và hệ thống giải trí, chỉ là một số thành phần khác yêu cầu mã nguồn.
Your car’s infotainment system is just one way that the security of your car can be attacked. Image: SubaruNhững gì tôi biết là với sự gia tăng về khả năng kỹ thuật số và tự động của ô tô, tính toàn vẹn của mã nguồn đó sẽ càng quan trọng hơn — đặc biệt là tính bảo mật của nó.
Mỗi chiếc ô tô đều đi kèm với nhiều thành phần, và mỗi thành phần này có thể có mã nguồn khác nhau, nếu được kiểm thử hoặc bảo mật kém, chúng dễ bị lỗi, sai sót hoặc mã độc hại. Nhưng nếu chúng ta có thể bảo mật ô tô trước khi chúng rời khỏi nhà máy?
Gần đây, tôi đã nói chuyện với Matt Wyckhouse, người sáng lập và CEO của Finite State, để tìm hiểu làm thế nào các nhà sản xuất ô tô bảo mật tất cả mã nguồn đó. Ông ấy cũng sở hữu một chiếc Tesla nên cá nhân ông ấy đầu tư vào an ninh ô tô.
Thường thì, việc tích hợp bảo mật vào toàn bộ chu trình phát triển là điều phổ biến. Tuy nhiên, Finite State đẩy bảo mật “đến càng phải càng tốt.” Điều này đảm bảo rằng mã nguồn của bản build cuối cùng là an toàn, đảm bảo không có thay đổi nào giữa quá trình kiểm thử và ô tô đến tay khách hàng.
Những lỗ hổng bảo mật phổ biến là gì?
Mã nguồn viết kém có thể bị lỗ hổng bảo mật hoặc hoạt động độc hại. Những triệu dòng mã nguồn trong vi xử lý của ô tô đều có nguồn gốc riêng. Ví dụ, phần mềm firmware hệ thống nhúng, bao gồm firmware được sử dụng trong các phương tiện kết nối, được tạo thành từ 80-95% thành phần của bên thứ ba và mã nguồn mở.
Và, khi bạn bắt đầu sử dụng phần mềm từ bên thứ ba có thể không chia sẻ sự cảnh báo về bảo mật của bạn, rủi ro tăng lên. Một số ví dụ phổ biến:
Lỗ hổng Log4J
Một ví dụ về lỗ hổng Log4j gần đây — một lỗ hổng bảo mật zero-day trong thư viện đăng nhập Java dựa trên Apache Log4j.
Nhà phát triển chính có thể đã tích hợp phần mềm Log4j như một phần của thực hành phát triển của họ. Hoặc nó có thể được bao gồm trong một thành phần của bên thứ ba, thứ tư hoặc thứ năm được xây dựng bằng Java và rơi vào phần mềm cuối cùng.
Điều này đe dọa an ninh của bất kỳ máy chủ ô tô nào sử dụng thư viện. Dữ liệu được thu thập và lưu trữ ở các địa điểm khác nhau theo thời gian. Điều này tăng nguy cơ ảnh hưởng đến phần mềm của xe ô tô.
Why hack one Tesla when you can hack 25? Image: TeslaVào tháng 1, nhà nghiên cứu an ninh mạng David Colombo đã có thể truy cập từ xa vào hơn 25 chiếc xe Tesla do một lỗ hổng bảo mật được phát hiện trong phần mềm của bên thứ ba được sử dụng bởi các tài xế Tesla.
Điều này không cho phép anh ta ‘lái’ các chiếc xe. Nhưng anh ta có thể khóa và mở cửa sổ và cửa, tắt hệ thống bảo mật của xe, bấm còi, và bật tắt đài radio của các chiếc xe.
Vấn đề bảo mật của thông tin đăng nhập được đặt cứng cố
Một ví dụ khác là thông tin đăng nhập được đặt cứng cố. Đây là nơi mật khẩu và dữ liệu bí mật trong văn bản thô được đặt trong mã nguồn. Điều này cung cấp một lối vào sau cửa cho việc kiểm thử và gỡ lỗi sản phẩm.
Nếu để lại trong mã cuối cùng, kẻ tấn công có thể đọc và sửa đổi các tệp cấu hình và thay đổi quyền truy cập người dùng. Nếu cùng một mật khẩu được sử dụng mặc định trên nhiều thiết bị khác nhau, thì bạn đang gặp một vấn đề lớn hơn nhiều.
Năm 2019, thông tin đăng nhập được đặt cứng cố trong ứng dụng di động MyCar đã tạo điều kiện cho kẻ tấn công truy cập vào dữ liệu người tiêu dùng và có quyền truy cập không được ủy quyền vào xe mục tiêu.
Vậy, làm thế nào để bảo vệ phần mềm khỏi lỗ hổng và tấn công?
Công việc của Finite State bắt đầu từ giai đoạn kiểm thử, tập trung vào bản sao nhị phân cuối cùng và quá trình xây dựng. Họ làm ngược lại, tự động hóa quá trình phân tích ngược mã nguồn, giải mã, dịch ngược và kiểm thử các yếu điểm và lỗ hổng. Sau đó, họ chia sẻ những thông tin này với đội an ninh của khách hàng.
Wyckhouse giải thích rằng cuối cùng, việc kiểm thử cho phép họ xem xét làm thế nào một sản phẩm phần mềm đã thay đổi theo thời gian:
Và nếu có sự thay đổi không chủ ý mà không thể rõ ràng về hành động của nhóm phát triển, đó là một lý do để điều tra sâu hơn.
Khi nghĩ về an ninh mạng và di động thực sự, chúng ta chỉ mới bắt đầu. Nhưng theo Wyckhouse, các nhà sản xuất ô tô đang liên tục đầu tư vào an ninh, không chỉ để tuân thủ các tiêu chuẩn ngành mà còn để đạt được lợi thế uy tín và cạnh tranh so với đối thủ mà liên tục phải đối mặt với các vấn đề an ninh.
Tuy nhiên, mỗi tuần không qua mà không có một báo cáo về một cuộc tấn công hoặc một lỗ hổng được phát hiện bởi các nhà nghiên cứu trắng. Và khi tự động hóa xe cộ ngày càng tăng, rủi ro cũng tăng lên.
