SOME/IP는 "Scalable service-Oriented MiddlewarE over IP"의 약자입니다. 이 미들웨어는 일반적인 자동차 사용 사례와 최소 유선 형식 수준의 AUTOSAR와 호환되도록 설계되었습니다. http://some-ip.com/에서 공개적으로 액세스할 수 있는 사양이 제공됩니다. 이번 포스팅에서는 SOME/IP 사양의 기본 구조와 오픈 소스 구현 및 오픈 소스 구현에 대한 간략한 개요를 제공하고자 합니다.
먼저 SOME/IP 사양의 세 가지 주요 부분부터 살펴보겠습니다.
On-wire format
Protocol
Service Discovery
SOME/IP On-wire format
원칙적으로 SOME/IP 통신은 IP를 통해 devices 또는 subscribers 간에 전송되는 메시지로 구성됩니다. 다음 그림을 참고하세요.
두 장치(A 및 B)가 표시되어 있습니다. Device A는 B에 SOME/IP 메시지를 보내고 하나의 메시지를 반환합니다. 기본 전송 프로토콜은 TCP 또는 UDP를 활용합니다. 메시지 자체에는 큰 차이가 없습니다. 이제 Device B에서 이 메시지에 의해 Device A에서 호출되는 기능을 제공하는 서비스를 실행하고 있다고 가정하고, 그 답으로 메시지를 보냅니다.
SOME/IP 메시지에는 header와 payload의 두 부분이 있습니다. 그림에서 헤더는 주로 식별자입니다:
Service ID: 각 서비스의 고유 식별자
Method ID: 0-32767(방법), 이벤트의 경우 32768-65535
Length: 페이로드 길이(바이트)(다음 ID도 포함, 8바이트 추가)
Client ID: ECU 내의 호출 클라이언트에 대한 고유 식별자로, 전체 차량에서 고유해야 합니다.
Session ID : 세션 처리를 위한 식별자. 각 통화에 대해 증가시켜야 합니다.
Protocol Version : 0x01
Interface Version: 주요 서비스 인터페이스 버전
Message Type:
-- REQUEST (0x00) 응답을 기다리는 요청(공백도)
-- REQUEST_NO_RETURN (0x01) A fire&forget 요청
-- NOTIFICATION (0x02) 응답이 없을 것으로 예상되는 알림/이벤트 콜백 요청
-- RESPONSE (0x80) response message
Return Code :
-- E_OK (0x00) 오류 발생이 없을 시
-- E_NOT_OK (0x01) 지저오디지 않은 오류 발생
-- E_WRONG_INTERFACE_VERSION (0x08) Interface version 불 일치
-- E_MALFORMED_MESSAGE (0x09) 페이로드의 크기를 줄일 수 없도록 감도화 오류
-- E_WRONG_MESSAGE_TYPE (0x0A) 예상치 못한 메시지 유형 수신 (예를 들어 RE-QUEST_NO_RETURN)
정상적인 기능 호출과 클라이언트가 가입한 이벤트에 대한 알림 메시지에 "Requests" 및 "RESPONSE"가 있음을 알 수 있습니다. 오류는 정상적인 응답 또는 알림으로 보고되지만 적절한 반환 코드가 있습니다.
payload에는 직렬화된 데이터가 포함되어 있습니다. 위 그림은 전송된 데이터 구조가 기본 데이터 유형만 있는 중첩 구조라는 단순한 경우의 직렬화를 보여주고 있습니다. 이 경우, 구조 요소는 그냥 평평하게 됩니다. 즉, 단순히 적재물에 하나씩 기록된다는 뜻입니다.
SOME/IP Protocol
이 섹션에서는 주로 두 가지 사항이 중요합니다.
the so-called transport bindings (UDP and TCP)
the basic communication patterns publish/subscribe and request/response.
위에서 언급한 바와 같이 기본 전송 프로토콜은 UDP 또는 TCP일 수 있습니다. UDP의 경우 SOME/IP message가 분할되지 않습니다. message가 둘 이상 UDP 패킷에 있을 수 있지만 UDP 패키지는 최대 1400바이트일 수 없습니다. 큰 message는 TCP를 통해 전송되어야 합니다. 이 경우 TCP의 robustness가 사용됩니다. TCP 스트림에서 동기화 오류가 발생하면 SOME/IP 규격에서 다음 message의 시작을 다시 찾기 위해 magic cookies를 호출할 수 있습니다.
service interfaces를 인스턴스화해야 하며 동일한 인터페이스의 인스턴스가 여러 개 있을 수 있으므로 정의된 인스턴스(인스턴스 ID)에 대한 추가 식별자가 있어야 합니다. 그러나 인스턴스 ID는 SOME/IP 메시지 header의 일부가 아닙니다. 인스턴스는 전송 프로토콜의 포트 번호를 통해 식별됩니다. 즉, 동일한 인터페이스에서 여러 인스턴스가 동일한 포트에서 제공될 수 없습니다.
이제 기본 SOME/IP 통신 패턴을 보여 주는 다음 그림을 보십시오.
Remote Procedure Calls에 대한 표준 REQUEST/RESPONSE 메커니즘 외에도 이벤트에 대한 PUBLISH/SUBSCRIBE 패턴도 있습니다. SOME/IP 프로토콜의 이벤트는 항상 이벤트 그룹에 그룹화되므로 이벤트 자체는 가입할 수 없고 이벤트 그룹에만 가입할 수 있습니다. SOME/IP 사양도 "필드"를 알고 있습니다. 이 경우 Setter/Getter 방법이 REQUEST/RESPONSE 패턴을 따르고 있으며 변경사항의 알림 message는 이벤트입니다. Subscription 자체는 SOME/IP Service Discovery을 통해 수행됩니다.
SOME/IP Service discovery
SOME/IP 서비스 검색은 서비스 인스턴스를 찾고 서비스 인스턴스가 실행 중인지 탐지하고 publish/subscribe 처리를 구현하는 데 사용됩니다. 이것은 소위 말하는 offer messages를 통해 수행됩니다. 즉, 각 device는 이 device에서 제공하는 모든 서비스를 포함하는 메시지를 broadcast(멀티캐스트)합니다. SOME/IP SD messages는 UDP를 통해 전송됩니다. 클라이언트 애플리케이션에 서비스가 필요하지만 현재 제공되지 않는 경우 "find messages"도 보낼 수 있습니다. 다른 SOME/IP SD messages는 이벤트 그룹을 Publish/Subscribe하는 데 사용할 수 있습니다.
다음 그림은 SOME/IP SD messaged의 일반적인 구조를 보여줍니다.
vsomeip 간단 개요
도입 사례를 구현하기 전에 vsomeip이라고 하는 SOME/IP의 GENIVI 구현의 기본 구조에 대해 간단히 살펴보겠습니다.
그림과 같이 vsomeip은 기기 간 SOME/IP communication (외부 통신)뿐만 아니라 내부 프로세스 간 communication 도 포함합니다. 두 Device는 사용된 전송 프로토콜(TCP 또는 UDP)과 해당 매개 변수를 포트 번호 또는 기타 매개 변수로 결정하는 통신 endpoints 을 통해 통신합니다. 이러한 모든 매개 변수는 vsomeip 구성 파일에 설정할 수 있는 구성 매개 변수입니다(json 파일, vsomeip 사용자 설명서 참조). 내부 communication은 로컬 endpoint를 통해 이루어지며, 이 엔드포인트는 Boost.Asio Library를 사용하여 Unix 도메인 소켓에 의해 구현됩니다. 이 내부 통신은 D-Bus 데몬과 같은 중앙 구성 요소를 통해 라우팅되지 않으므로 매우 빠릅니다.
중앙 vsomeip 라우팅 관리자는 외부 디바이스로 전송해야 하는 경우에만 messages를 수신하고 외부에서 들어오는 messages를 배포합니다. Device 당 라우팅 관리자는 하나만 있으며, 아무것도 구성되지 않은 경우 실행 중인 vsomeip 애플리케이션도 라우팅 관리자를 시작합니다.
vsomeip은 데이터 구조의 직렬화를 구현하지 않습니다. 이는 CommonAPI의 SOME/IP Binding에서 다루고 있습니다. vsomeip은 SOME/IP Protocol과 Service Discovery을 포함합니다.
이는 SOME/IP 및 vsomeip에 대한 짧은 소개였습니다 그러나 처음 접하시는 분들에게는 충분할 것입니다. 더 자세한 것은 나중에 예제를 통해 설명하도록 하겠습니다.
Service ID : 서비스 unique ID Method ID : 0-32767(Method), 32768-65535 (Event) Length : Payload length Client ID : ECU 내의 unique ID=> 하나의 Service ID 안에 여러 Client 가 존재 할 수 있다. Session ID : Session ID, SOME/IP 통신 마다 증가해야 하며, SOME/IP sequence를 구별 하기 위해 사용한다. Protocol Version : 0x01 (현재 default 값은 1이다) Interface Version : Service Interface의 Major 버전이다.
Message Type : -- REQUEST (0x00) Response를 기다리는 요청 -- REQUEST_NO_RETURN (0x01) A fire&forget 요청 -- NOTIFICATION (0x02) Response 기대 없이 이벤트 형식의 data 만 전송 -- RESPONSE (0x80) Response message
-- E_WRONG_PROTOCOL_VERSION (0x07) Protocl version 불 일치
-- E_WRONG_INTERFACE_VERSION (0x08) Interface version 불 일치
-- E_MALFORMED_MESSAGE (0x09) 비정상 Packet 형태 -- E_WRONG_MESSAGE_TYPE (0x0a) Message Type 불 일치 -- RESERVED (0x0b - 0x1f) 페이로드의 크기를 줄일 수 없도록 감도화 오류 -- RESERVED (0x020 - 0x5e) 예상치 못한 메시지 유형 수신 (예를 들어 RE-QUEST_NO_RETURN)
-Payload Serialization
규격 참고
보통 Protocol의 Header 및 Serilization 부분은 규격을 자세히 읽어 보는 것이 좋은것 같다.
#Use TCP only if very large chunks of data need to be transported (> 1400 Bytes) and no hard latency requirements in the case of errors exists
#Use UDP if very hard latency requirements (<100ms) in case of errors is needed
#Use UDP together with SOME/IP-TP if very large chunks of data need to be transported (> 1400 Bytes) and hard latency requirements in the case of errors exists
#Try using external transport or transfer mechanisms (Network File System, APIX link, 1722, ...) when they are more suited for the use case. In this case SOME/IP can transport a file handle or a comparable identifier. This gives the designer additional freedom (e.g. in regard to caching).
TCP 사용 시 중요한 것은 Nagle's Algorithm이 off 되야 된다는 것이다.
SOME/IP 중요성 중에 하나가 실시간 성이기 때문이다.
Consumer 와 Provider 간은 하나의 Connection을 기반으로 통신해야 한다.(TCP는 Heavy 한 Protocol 이며 TCP Connection은 최소화 해야 한다.)
UDP 기반으로 MTU 이상 Packet을 전송 하기 위해서는 SOME/IP-TP라는 것을 이용해 보내게 된다.
결국 Data를 Segment하며 Header에 offset 정보를 담아서 보내게 되는 형식이다.
-Communication
규격에서 제안 하는 SOME/IP 통신 방법은 Request/Response(Method), Fire&Forget, Events, Field 총 4가지 이다.
아래 그림으로 충분히 설명이 가능 할 것이다.
-Error Handling
Error 발생 시 규격에서 제안 하는 방법은 총 2가지 존재한다.
Return codes in the Response Messages of methods.
Explicit Error Messgaes
Response Message의 Returen code에 Error code를 Returne 해주는 방법 과 Paload에 Error mesage(Message Type 0x81)을 담아서 보내는 방법이 있다.
후자는 Consumer Provider 간의 Error message 약속이 존재해야 한다.
글쓴이가 느끼기엔 Error Handling 관련 부분이 타 Protocol Spec(RFC, 3GPP) 대비 많이 부족한 부분인것 같다.
앞으로 많은 부분이 Update 될 것 같다.
3. SOME/IP Service Discovery(SOME/IP-SD)
각 Provider 와 Consumer는 시작 전 서로의 정보(Version, IP address, Port ...)들을 알고 있지 않는다.
SOME/IP Service Discovery라는 Step을 통해서 Provider 와 Consumer간 서로의 정보를 교환하게 된다.
경험상 SOME/IP-SD flow 다음과 같이 2가지가 존재 할 수 있다.
1) TTL 안에 OfferService가 오는 경우
2) TTL expired 된 후 FindService가 전송 되는 경우
Concept OfferService와 FindService를 통해 서로의 IP addres, Port 등등을 주고 받는 것이며,
주고 받은 정보 기반으로 SOME/IP 통신을 하게 된다.
SOME/IP-SD는 Mulitcast를 이용하기 때문에 무조건 UDP 를 사용해야 한다.
이와 관련된 자세한 내용을 알기 위해서는 규격의 StateMachine Diagram을 이해 하는 것이 좋다.
여기서 주의 할 것은 Subscribe는 Mandatory가 아니다, Event 혹의 Field의 Notication이 필요 없을 경우는 Subscription 과정을 생략 해도 된다.
1) TTL 안에 OfferService가 오는 경우
2) TTL expired 된 후 FindService가 전송 되는 경우
- Message format
SOME/IP의 Payload에 SOME/IP-SD Header와 Option이 위치하게 된다.
출처 : UN 유럽 경제위원회 정보부 면책 조항 :이 문서는 정보 제공만을 목적으로 합니다. 특정 문제 또는 사실적 상황에 대한 법적 의견 또는 법적 조언에 의존하거나 해석해서는 안됩니다. WP.29 의 궁금한 사항은 AUTOCRYPT 팀에 직접 문의 부탁드립니다. UNECE WP.29 체크리스트 2020 년 6 월 UN 은 자동차 사이버 보안에 관한 두 가지 새로운 규정을 공식적으로 채택했습니다. 이에 따라 자동차 산업에 종사하는 경우 조직에서 수행해야 하는 몇 가지 작업 (OEM, Tier-1 공급 업체, 소프트웨어 제공 업체 등)이 있습니다. CYBER SECURITY MANAGEMENT SYSTEMS (CSMS).. 일반 산업 / 부문 차량 설계에서 사이버 보안 위험 식별 및 관리 테스트를 포함한 위험관리 확인 위험평가가 최신 상태로 유지되고 있는지 확인 사이버 공격 모니터링 및 대응 사이버 보안 성공된 사례 분석 지원 새로운 위협 및 취약성 평가 제조업체 부문 CSMS 차량적용가능 확인 위험평가 분석 및 주요사항 식별 위험을 줄이기 위한 완화 조치 식별 완화 조치가 의도대로 작동하는지 식별 사이버공격에 대한 예방조치 확인 차량 유형별 활동 모니터링 모니터링 활동 보고서 승인기관 전송 SOFTWARE UPDATE MANAGEMENT SYSTEMS (SUMS).. 일반 산업 / 부문 차량유형에 대한 하드웨어 및 소프트웨어 버전 기록 형식승인과 관련된 소프트웨어 식별 소프트웨어 구성요소 확인 소프트웨어 업데이트 및 상호 종속성 확인 차량 표적 식별 및 소프트웨어 업데이트 호환성 확인 소프트웨어 업데이트가 매개변수에 영향을 미치는지 확인 소프트웨어 업데이트가 안전에 영향을 미치는지 확인 차량 소유자에게 소프트웨어 업데이트 알림 제조업체 부문 SUMS 차량적용가능 확인 소프트웨어 매커니즘 보호 및 무결성 보장 소프트웨어 식별번호 보호 차량에서 소프트웨어 식별번호 가능여부 확인 출처 : UN 유럽 경제위원회 정보부 면책 조항 :이 문서는 정보 제공만을 목적으로 합니다. 특정 문제 또는 사실적 상황에 대한 법적 의견 또는 법적 조언에 의존하거나 해석해서는 안됩니다. WP.29 의 궁금한 사항은 AUTOCRYPT 팀에 직접 문의 부탁드립니다. OVER-THE-AIR (OTA) SOFTWARE UPDATES.. 업데이트 실패 시 복원기능 전원이 충분한 경우만 업데이트 실행 안전한 실행 보장 사용자에게 업데이트 완료됨을 확인 필요 차량이 업데이트 실행이 가능한지 확인 필요 정비가 필요할 경우 사용자에게 알림 필요
아이템/시스템: SbW(Steer by Wire), IDB, MGH 등 제품군 혹은 제품의 Variant를 뜻하는 의미로 생각됩니다. 컴포넌트: 아이템을 구성하는 하위 Sub 시스템(파워팩, 센서 등등)들을 컴포넌트로 부르거나, SW 관점에서는 하나의 Unit 과 같이 특정 기능을 수행하는 Function 단위로도 컴포넌트라는 단어로 불리는 것 같습니다.
I hacked Toyota’s Global Supplier Preparation Information Management System (“GSPIMS”), a web app used by Toyota employees and their suppliers to coordinate projects, parts, surveys, purchases, and other tasks related to the global Toyota supply chain.
System Admin access achieved through accidentally introduced backdoor as part of a user impersonation/”Act As” feature.
Any user could be logged in to just by knowing their email, completely bypassing the various corporate login flows.
Read/write access to the global user directory containing 14k+ users was achieved.
Data access achieved: 14k+ corporate user account details, confidential documents, projects, supplier rankings/comments, and more. Data access was global and not limited to North America.
Issue was responsibly disclosed to Toyota in November 2022 and fixed in a timely manner.
Over the course of a slow week in late October 2022, I decided to explore the subdomains of various major companies to see if I could find any exploits worth reporting/writing about. I found several interesting Toyota websites. In 7 days, I reported 4 different security issues to Toyota, all of which were classified as “critical”. One of the reports had a remarkably severe impact and is one of the most severe vulnerabilities I have ever found (so far!)
I discovered what was essentially a backdoor login mechanism in theToyota GSPIMS website/applicationthat allowed me to log in as any corporate Toyota user or supplier just by knowing their email. I eventually uncovered a system administrator email and was able to log in to their account. Once that was done, I had full control over the entire global system. I used the word “staggering” to describe the amount of data I had access to in theJacuzzi SmartTub hack, but that was relatively minor compared to this. I had full access to internal Toyota projects, documents, and user accounts, including user accounts of Toyota’s external partners/suppliers. External accounts include users from:
Many more (note the various email domains in the screenshots below)
GSPIMS stands for “Global Supplier Preparation Information Management System”. It is anAngularsingle-page-application. Based on a license key embedded in the app forAG Grid, it was created bySHI International Corp – USAon behalf of Toyota. At first, I didn’t know what GSPIMS was. Google showed a few job listings about it, but otherwise seemed obscure. I didn’t think it was that important at first, but I decided to put some time into it to see what might be hiding behind the login screen. It wasn’t until I bypassed the login screen that I saw the “Global Supplier Preparation Information Management System” label. Sounds important!
Bypassing the login
The login screen features corporate Toyota and Supplier login options:
There should be a “Are you a Hacker?” option.🙂
Both options supply the same list of login methods:
TMNA = Toyota Motor North America
TME = Toyota Motor Europe
TMC = Toyota Motor Corporation (Japan)
TDEM = Toyota Daihatsu Engineering & Manufacturing (Asia)
Other Affiliates = Unknown, this button does not currently work
If you work for/with Toyota on any continent, it is likely you can log in to the system using one of these options. I do not work for Toyota, so I had to get past this login screen by patching the JavaScript code.
Developers control access to Angular routes/pages by implementingCanActivateandCanActivateChild. Basically, when a user attempts to navigate to a route/page, you would determine if they are allowed to view it, and then return true or false. By patching both to return true, you can usually fully unlock an Angular app:
The logout code also needed to be removed to prevent a redirect back to the login page:
With those patches applied, the app loads and can be browsed:
In theJacuzzi SmartTub case, patching the JavaScript was all that was needed to achieve full access, since their API was improperly secured. In GSPIMS’ case, no data would load from the API. All the endpoints would return HTTP status 401 – Unauthorized responses due to the missing login cookie. This was the case for every page I browsed. Toyota/SHI had seemingly secured their API correctly, and at this point I was about to write this site off as “probably secure”. I don’t bother reporting single-page-application bypasses unless it also exposes a leaky/improperly secured API.
JWTs for everyone!
Before abandoning work on the GSPIMS app, I looked through its code to see if there might have been any API keys, secret API endpoints, or anything else that might be interesting. I came across this function in the user service. Can you spot what is interesting about it?
JWT stands for JSON Web Token. Think of it as a session token that represents your valid authenticated session on a website. You typically get a JWT after logging into a website using your email and password. You then provide the JWT to secured parts of a website or API to prove your identity and what you are allowed to access.More information
It is interesting because it appears to be generating a JWT based on a provided email. No password required. I decided to compose this HTTP request to see if thatcreateJWTendpoint actually worked. Even if it worked, it wouldn’t be enough without a valid email, which could have been difficult to figure out, especially if the underlying userbase was small.
Corporate Toyota emails use a predictable format in North America:firstname.lastname@toyota.com. That made guessing a valid email easier, but I still had to find someone. I Googled for Toyota employees involved in the supply chain, hoping to find someone who may be registered in the GSPIMS system. I found a promising match and formulated their email address based on their name. Then I fired off thecreateJWTHTTP request, and it returned a valid JWT!
It seems like I had discovered a way to generate a valid JWT for any Toyota employee or supplier registered in GSPIMS,completely bypassing the various corporate login flows, which probably also enforce two-factor authentication options. The reasoncreateJWTexists will be revealed later in this post.
Utilizing the JWT was easy. The GSPIMS API authenticates via cookie, so I just added it through Chrome’s dev tools:
Escalating to System Admin
The user I logged in had the role of “Mgmt – Purchasing” which probably means they are in charge of organizing purchases of things from suppliers through this system. I had access to some data at this point, but I felt there was more waiting to be unlocked. Looking at the HTTP requests and responses, there is arolePrivilegesnode in theuser/detailsAPI response that returns information about the currently logged in user:
I wanted to try and find a user with the System Admin role. I noticed another API endpoint namedfindByEmailthat returned information about a user’s account by just providing a valid email. Conveniently, this also tells you who the user’s managers are:
Imagine having 3 different managers to report to!😱
Checking the managers of the managers, etc. made it easy to find accounts that had elevated access to the system. Eventually I found a North America Regional Admin. That gave me access to the User Administration section. I then poked around more and found users with even higher access, such as Supplier Admin, Global Admin, and finally, System Admin.
In the GSPIMS settings, the tabs that appear are dependent on your role. There’s Regional Settings for Regional Admins, Global Settings for Global Admins, and System Admin Settings for System Admins. System Admins can access all the tabs. I also noticed that System Admins had access to substantially more users in the User Administration section. Regional Admins are probably only able to manage users in their region, whereas System Admins could manage everyone. With a System Admin JWT, I basically had total, global control over the entire system.
A few screenshots of various sets of users. Take note of the user and page counts in the bottom right corner (there’s a lot – 14,063 users across 563 pages!) Click on any image to enlarge it in a new tab.
American users
Asian users
Japanese users
American System Admins
European users
More Japanese users
I could edit any of those users:
Or add a new user using the user import button above the columns. There is also an export users button you can use to download user information.
Exploring the impact
Having full access, I looked around the GSPIMS app to see what was available to me as a System Admin. I was very careful to not modify anything. Here’s the System Admin Settings if you are curious about what is there. Nothing too exciting – it just controls what roles can access certain features.
Now on to more interesting things. The Parts section has a list of parts associated with the various projects. You choose an affiliate at the top and then the project to see the list of parts. Here is the parts list for a project:
It’s worth noting the projects are in codenames/numbers. It didn’t say anything like “2024 Toyota Corolla”. With a lot more time I probably could have figured out the codenames, but that was outside the scope of this investigation. Speaking of projects, I had access to all the active, global, and inactive projects:
I could view the details of each project, including who is involved, the schedule and milestones, and some type of survey feature. Click on any image to enlarge it in a new tab.
Project Parts List
Add/Remove Users
Project Schedule
Surveys
System Management
Can’t forget about the documents! Classified documents are all the rage nowadays.
Reviewing the HTTP trace I captured, I noticed you can also see Toyota’s various comments about their suppliers. It’s probably also visible in the UI somewhere.
The HTTP trace was captured by just havingFiddleropen while browsing the app. The API is very generous with the amount of data it returns, in particular with the users list. You could download a lot of user information by increasing the page size and flipping through the pages.
You could also see all the suppliers and how Toyota ranks them regarding risk, delivery, and prep. There are almost 3,000 of them:
Finally, I discovered what thecreateJWTAPI was actually used for. There is an “Act As” feature that let me log in as any of those 14k+ global users. I could easily log in as anyone and get an idea of what projects they are working on, their tasks, surveys, etc. Whoever made the Act As system apparently didn’t realize they added a backdoor to the entire system. The Act As feature is only visible to certain users, like the System Admin user I was logged in as.
That is onelongdrop-down list.
If a threat actor had discovered this issue, the consequences could have been severe. Here’s a few bad things they could have done. Please note that these are just ideas and none of these were carried out.
Added their own user account with an elevated role, to retain access should the issue ever be discovered and fixed.
Downloaded and leaked all the data.
Delete everything or modify data in a way to be disruptive to global Toyota operations. Hopefully Toyota/SHI have working backups?
Craft a highly targeted phishing campaign to attempt to capture real corporate login details, which could have exposed other Toyota systems to attacks. There’s 14k+ users available to attack. It’s one thing to have 14k+ corporate emails, but it’s another to have 14+ corporate emails and know exactly what they are working on/have worked on. If a supplier user has a habit of reusing passwords, it’s possible their own infrastructure could be attacked too.
Reporting to Toyota
The issue was reported to Toyota on November 3, 2022, and they responded later that same day confirming they received the report. On November 23, 2022 they confirmed the issue was remediated, although I noticed it was fixed before that when I randomly tested. I then informed them I would publish my writeup after the industry standard 90-day period has passed.
Toyota/SHI fixed the issue by making thecreateJWTandfindByEmailendpoints return HTTP status 400 – Bad Request in all cases.
Out of all the security issues I have reported so far to various vendors, Toyota’s response was the fastest and most effective. I was very impressed with how quickly they responded and fixed the issue. Some companies can be slow to respond or fail to respond at all, so this experience was refreshing.
Thanks to this responsible disclosure, Toyota avoided what could have been a catastrophic leak of not only their own employees’ data, but the data of their partners/suppliers. Embarrassing internal comments and supplier rankings could have been published for the world to see.Toyota and their suppliers have been hit by cyberattacks beforeand it could have easily happened again.
Unfortunately, the reward for reporting this critical issue was $0. While it’s fun to find significant vulnerabilities like these, I will probably start shifting my efforts to companies offering monetary rewards help to sustain these often-lengthy investigations and writeups. PS: If you/your company’s security team are currently hiring, feel free tosay hello🙂.
LIN(Local Interconnect Network)이란, 자동차 네트워크에서 컴포넌트들 사이의 통신을 위한 직렬 통신 시스템입니다. LIN은 CAN과 같이 다중화되고 있는 네트워크를 보완하기 위해 고안된 저가형 임베디드 네트워킹의 표준이며, 자동차 업계에서 가장 보편적으로 사용합니다. 대부분의 현대식 저가형 8비트 마이크로컨트롤러에 내장된 표준 시리얼 유니버셜 비동기 송/수신기(UART)를 사용하면 비교적 저렴하게 LIN통신을 구현할 수 있습니다. LIN은 보통 CAN의 고대역폭과 다기능이 필요하지 않은 액추에이터와 스마트 센서들 사이의 통신에 사용됩니다. 파워윈도우 기능, 좌식조절기 기능과 같이 그다지 높은 성능을 필요로하지 않는 기능들을 CAN으로 구현하기에는 많은 비용이 요구되므로, 이러한 기능들을 구현할 때에는 LIN을 사용합니다.
1.2 LIN 적용 대상 애플리케이션
Application segmentsSpecific LIN application examples
Roof
Sensor, light sensor, light control, sun roof
Steering Wheel
Cruise control, wiper, turning light, climate control, radio
Seat
Seat position motors, occupant sensors, control panel
Engine
Sensors, small motors, cooling fan motors
Grille
Grille shutter
Climate
Small motors, control panel
Door
Mirror, central ECU, mirror switch, window lift, seat control switch, door lock
Illumination
Vehicle trim enhancement, sill plates illuminated with RGB LED
이 외에도 LIN 통신은 주차할 때 갑자기 나타나는 장애물을 감지해 운전자에게 경고하는 전후방 주차보조시스템(PAS, Parking Assist System)과 주변 상황을 위에서 보듯 내려다봄으로써 주차할 때 옆 차와의 접촉 사고를 피하게 해주는 어라운드 뷰 모니터(AVM, Around View Monitor), 핸들 조작 없이 엑셀과 브레이크의 조작만으로 주차를 가능하게 하는 주차 조향 보조 시스템(SPAS, Smart Parking Assist System) 등과 같은 운전자 보조 시스템에 적용되고 있습니다.
1.3 LIN 특징1.3.1 단일 마스터-다중 슬레이브 구조
LIN 버스는 단일 마스터-다중 슬레이브 구조로 되어있어, CAN 프로토콜과는 달리 LIN 프로토콜은 버스 중재(메시지의 우선순위에 따라 어떤 메시지가 먼저 버스에 전송될지를 결정하는 것)를 하지 않습니다. LIN 프로토콜에서는 하나의 마스터 노드가 LIN 버스 내 모든 통신을 제어합니다. 이 마스터 노드로 인해 LIN 통신이 시작(메시지 전송 초기화)되며, 모든 슬레이브 노드는 마스터 노드의 허가를 받아야만 마스터 또는 버스 내에 있는 다른 슬레이브 노드들에게 응답을 할 수 있습니다.
1.3.2 멀티캐스트 수신
마스터 또는 슬레이브 태스크로부터 메시지 프레임이 전송될 때, 네트워크상에 연결된 모든 노드들은 메시지를 읽을 수 있습니다. 식별자 바이트에 따라, 수신 노드는 동작을 시작할 것인지 여부를 결정합니다.
1.3.3 클럭 동기화 방식
Synch Break에 이어 마스터 노드가 전송한 Synch Field를 이용하여 모든 슬레이브 노드들은 마스터 클럭에 동기를 맞춥니다.
1.3.4 가변 데이터 프레임
식별자 필드(그림 3 참조)의 두 비트(ID4, ID5)는 메시지 필드의 길이를 나타냅니다. 이 비트들을 이용하면 데이터의 길이를 조절 할 수 있습니다. 또한 송수신 데이터의 양이 제한되어 있을 때 데이터의 오버헤드를 줄여줍니다.
1.3.5 데이터 체크섬과 에러 검출
메시지 프레임에 포함된 데이터는 inverted modulo256-checksum으로, 식별자 바이트는 XOR 알고리즘으로 에러를 검출합니다.
1.3.6 네트워크 내 손상 노드 검출
마스터 태스크는 메시지 프레임의 전송을 제어하므로 모든 노드에게 정보를 요청하고, 각 노드들이 올바르게 동작하고 있는지 점검합니다.
2. LIN 버스 동작 원리
2.1 마스터 슬레이브 구조
LIN 버스는 마스터 슬레이브 구조로 되어있습니다. 이 구조에서는 하나의 마스터 노드가 네트워크 내 모든 통신을 제어합니다. LIN 버스는 데이터를 요청하거나 제어 명령을 전송하는 마스터 노드와 마스터 노드로부터의 데이터 요청에 상응하는 데이터를 수집하여 응답하거나 마스터 노드로부터 수신된 제어 명령에 상응하는 동작을 수행하는 슬레이브 노드들로 구성됩니다. 마스터 노드와 슬레이브 노드의 역할은 다음과 같습니다.
구분역할
마스터 노드
– 통신 속도 정의 – 동기 신호 전송 – 데이터 모니터링 – sleep/wake up mode 전환
슬레이브 노드
– 동기 신호 대기 – 동기 신호를 이용하여 동기화 – 메시지 식별자 이해
LIN 버스는 하나의 마스터 노드와 여러 개(최대 16개까지)의 슬레이브 노드들로 구성되어 있습니다. 또한 아래 그림과 같이 마스터 노드는 마스터 태스크와 슬레이브 태스크로 구성되어 있으며, 슬레이브 노드는 슬레이브 태스크만으로 구성되어 있습니다.
2.2 LIN 메시지 프레임
LIN 버스에서 전송의 기본 단위는 프레임이며, 이는 헤더(header)와 응답(response)으로 나뉘어집니다. 헤더는 항상 마스터 노드의 마스터 태스크가 전송하며, 3개의 필드(SYNC BREAK, SYNC, ID)로 구성됩니다. 응답은 슬레이브 태스크가 전송하며, 데이터 페이로드(DATA 1~n)와 체크섬(CHECKSUM)으로 구성됩니다.
2.2.1 LIN 메시지 헤더
1) 동기 브레이크 필드(SYNC BREAK Field) 메시지 프레임의 시작을 나타내는 필드입니다. 이 필드는 마스터 태스크가 전송(마스터 태스크만 전송 가능)하며, 슬레이브 태스크가 동기 필드를 준비할 수 있도록 합니다.
2) 동기 필드(SYNC Field) 슬레이브가 마스터 클럭과 동기를 맞추는데 필요한 신호가 포함된 필드입니다. 슬레이브들은 이 신호를 이용하여 현재의 bit time을 측정하고, 슬레이브 내부의 baud rate을 다시 계산하여 동기를 맞춥니다.
3) 식별자 필드(ID Field) 메시지의 내용(메시지의 주소)과 길이에 대한 정보를 나타내는 필드입니다. 식별자 필드는 메시지의 목적지를 가리키는 것이 아니라 메시지 프레임의 내용을 설명하여, 궁극적으로 LIN 네트워크에서 어떤 노드가 이 메시지에 어떻게 반응할지(수신, 응답 전송, 무시)를 결정하는 필드입니다.
헤더를 수신하면 모든 슬레이브 태스크는 메시지의 식별자(주소)를 확인하며 패리티를 검증하고, 수신할 것인지를 결정합니다. 만약 이 메시지에 대해 응답을 해야 한다면 슬레이브 태스크는 데이터 페이로드와 체크섬을 LIN 메시지 프레임의 응답부분에 채운 뒤 버스에 전송합니다.
2.2.2 LIN 메시지 응답
1) 데이터 필드(DATA Field) 데이터 필드는 8비트로 구성된 2~8개의 필드로 구성됩니다. 데이터 필드는 헤더의 식별자에 응답하는 슬레이브 태스크에 의해 쓰여집니다. 이 때, 버스 중재가 없기 때문에 단 하나의 슬레이브 태스크만 각 식별자에 대해 응답할 수 있으며, 다른 모든 슬레이브 태스크는 응답을 읽는 것이 제한됩니다.
2) 체크섬 필드(CHECKSUM Field) 모든 데이터 바이트(식별자를 포함하지 않은 데이터 프레임)의 modulo-256 합을 포함합니다. 이를 이용하여 메시지의 유효성을 판단합니다.
2.3 마스터 슬레이브 동작 과정 정리
LIN 네트워크는 마스터 슬레이브 구조로 동작하며, 마스터 노드의 마스터 태스크가 모든 LIN 네트워크 통신을 제어합니다. 마스터와 슬레이브의 동작을 도식으로 표현하면 다음과 같습니다.
3. LIN 버스의 두가지 상태
LIN 버스는 두가지 상태(Sleep 모드, Active)를 가집니다. 데이터가 버스에 있는 동안, 모든 노드는 Active 상태에 놓여집니다. 그러나 특정 시간(4초 이상)동안 버스가 유휴상태이면, 불필요한 전력을 낭비하지 않기 위해 마스터에 의해 LIN 버스는 저전력 동작 모드(Sleep 모드)로 전환됩니다. 또한 LIN 2.0부터 마스터가 첫 번째 바이트가 0이고, 식별자(ID)가 0x3C인 진단 프레임을 전송하면 모든 슬레이브들은 자동으로 Sleep 모드로 전환됩니다. 이러한 진단 프레임을 go-to-sleep-command라 부릅니다. 이후 다시 데이터가 감지되면(WAKEUP 프레임이 LIN 버스에 전송되면) 다시 정상모드(Active)로 복귀합니다. WAKEUP 프레임은 Sleep 모드를 종료시키고 버스를 활성화시키기 위한 프레임입니다. WAKEUP은 버스가 sleep 모드이고, 노드 내부적으로 WAKEUP에 대한 요청이 있을 때 버스의 모든 노드(마스터, 슬레이브)에 의해 전송될 수 있습니다.
