IDOR's in NCIA ANET v3.4.1
Written by: Andy Olchawa, Milenko Starcik
Background
The Advisor Network ("ANET") is a platform designed to monitor the connections between advisors and their advisees. It was initially developed by the Defense Digital Service to aid the USFOR-A and Resolute Support missions in supporting the Afghan government by providing a structure for training, advising, and assisting. The NATO Communications and Information Agency (NCI Agency) continues developing it, with the code available on GitHub.
While ANET was created for a specific mission, its utility extends beyond its initial scope. Essentially, ANET tracks reports and associates them with their authors, organizations, and objectives, streamlining the management of relationships within and between entities.
Vulnerability Assessment
As part of our ongoing review of open-source software in the aerospace and defence industry, we have done a vulnerability assessment that resulted in the following findings:
Both are forms of the Insecure Direct Object Reference (IDOR) vulnerability.
Authorization Bypass Through User-Controlled Key
The ANET system allows users to create engagement reports. The reports require several different types of fields to be filled in; however, every report gets a unique ID. Additionally, a report can be in a different stage; in particular, a report can be saved as a draft (see Figure 1).
Figure 1 also shows that the author of the report is Erin. Reading the report details, we can access the ID of that object, in this case, 530b735e-1134-4daa-9e87-4491c888a4f7, as shown in Figure 2. Since Erin created this report and saved it as a draft, it should be visible only to her; namely, given that Erin hasn't published her report when logging in to the system as another user (e.g., username: Advisor), they can't see that report [MS1]?(see Figure 3). However, if the user Advisor tries to access the report directly via the URL https://localhost:3000/reports/530b735e-1134-4daa-9e87-4491c888a4f7, they can now see Erin's report (see Figure 4).
Recommendations
This vulnerability is a classic Insecure Direct Object Reference (IDOR), and in this case, it is classified as CWE-693 – Authorization Bypass Through User-Controlled Key. It is recommended that an additional check be added to verify that if the report is in the draft stage, it should be visible only to the author (or/and involved parties of a particular engagement).
Incorrect Ownership Assignment
The ANET system allows users to create engagement reports. The reports require several different types of fields to be filled in. One of those fields is "Advisors". By default, this field is set to the report's author, and the system functionality prevents this field from being changed (see Figure 5). By editing and saving this report by Erin, we can intercept the GraphQL POST request with the report details using Burp Suite (see Figure 6). Reviewing the request, we can see that it contains Erin's UUID. At this point, we can replace this value with another user's UUID (in this case, the UUID of the user Advisor) and forward the request to the server. Figure 7 shows that the server accepted the request, and we received a 200 OK response. In the response from the server, we can also see that the author's UUID value has indeed been set to the user Advisor.
Going to Erin's dashboard, it's noticeable that the draft reports this user was the author of have disappeared (see Figure 8). However, when logging in to the system as an Advisor user, we can now see that this user has a new report (see Figure 9). To verify this is the same request, we compare the UUID we get from the browser with the one sent in the GraphQL request (see Figure 10).
Recommendations
This is another example of IDOR vulnerability; however, in this case, we classified it as CWE-708: Incorrect Ownership Assignment. It is recommended that the check done on the front end be extended to the back end of the ANET application.
Further readings
If you'd like to learn more about space software security, read our articles on vulnerabilities in NASA's AIT-Core, Open MCT (first and second) and SAS's YAMCS (first and second).
To highlight the importance of the software supply chain, we have further published exploits for the OSGi console and Apache Karaf console.
This was our first review in the defence sector, so if you have any suggestions on where to look next, please let us know in the comments!