Some tests and some ideas/suggestions. #39
Conversation
|
I've only had a brief look at the first commit. My first request would be to split up the file into multiple files that each encompass their broad categories. I am not a big fan of the commented out tests that just say See "T0XX". I would rather just have as part of the description in T0XX an explanation that the scenario modelled also covers T0YY, T0ZZ, etc. I understand that the helper functions were useful to write so many tests quickly, but because this batch of tests looks different than what our regular unit tests this makes them less legible at first glance. I will address the specific missing coreLang functionality after I get a chance to dig deeper into those issues. |
|
Ok, I will clean it up when I have time. |
| compromised(1, parentApp.read); // because HXXExploit | ||
| compromised(1, parentApp.modify); // because XHXExploit | ||
| compromised(1, parentApp.deny); // because XXHExploit | ||
| compromised(1, parentApp.fullAccess); // because HHHExploit |
There was a problem hiding this comment.
These 4 comments don't make sense given the new vulnerability system.
| compromised(1, parentApp.read); // because HXXExploit | ||
| compromised(1, parentApp.modify); // because XHXExploit | ||
| compromised(1, parentApp.deny); // because XXHExploit | ||
| compromised(1, parentApp.fullAccess); // because HHHExploit |
There was a problem hiding this comment.
These 4 comments don't make sense given the new vulnerability system.
What do you mean by '"Trust Stores" in mitre', are you referring to https://attack.mitre.org/techniques/T1553/004/ ? |
This feels to me like it is already covered by the man-in-the-middle attack steps and defences in coreLang. |
Exactly. CoreLang does not distinguish between the credentials used to authenticate and the credentials used by the authentication mechanism to verify that authentication attempt. For example, a client may use a password (Credentials) to authenticate to a server. The server verifies the password against a stored password hash (Credentials/Identity). CoreLang treats the password and the password hash as the same thing (or only models the hash, depending on how you see it).
This can matter in models where the credentials are reused since overwriting the password hash is not the same as learning the password -- although there are of course (slow) offline attacks for that too. Certificates in TLS work in a similar way, where the server certificate is verified against a root-certificate on the client. So if the attacker can replace the root-certificate file on the client, then they do not need the server private key. A possibly related issue: #17. Perhaps there is some way to model this using e.g. parent and child identities or by using credentials to encrypting other credentials? If so it might still be good to write some documenting examples since it is not obvious.
Not really, because the man-in-the-middle attack steps do not work on encrypted and/or authenticated data. |
|
As a summary of the excellent conversation with @jesajx yesterday.
If I have missed or misinterpreted some points feel free to comment so that we amend that. If you have any other suggestions now or in the future please add them to this pull request. |
In short: the issues I pointed out would require a finer level of granularity than what is intended for Corelang. So these ideas will go into IoTLang instead. |
|
(Some cleaning work still remains on my side.) |
- prepare for con(x,y) inlining - inline con(x,y) - inline con(x,y,z) - inline conbi(x,y,z) - inline transferData(x,y) - remove final commented out tests - inline execCode(x,y,z) - inline aOwnsB(x,y) - prepare inline of API helpers - inline mkReadWriteApi(x,y,z) - inline mkExecApi(x,y) - inline mkReadApi(x,y,z) - inline mkWriteApi(x,y,z) - fix indent - remove debug code remainder - move functionality out of attack(...) - make attack(attacker, ...) take one attack step - inline attack(x,y) - inline compromised(x,y) - inline appExecAs - inline class VulnerabilityBuilder - remove autoconbi(x,y,z) - move functionality out of autocon - rename autocon overloads - inline autocon1 - inline autocon2 - inline autocon - inline containerAdd(x,y) - inline class Base - fix indentation - remove spurious spaces
|
I hope that does it for the clean up. |
Thank you very much! I will go through them as soon as I get the chance. I also remembered another suggestion you made that should be documented somewhere, we should create an association between the PhysicalZone and Network assets. |
|
Speaking of PhysicalZone -- it would also be nice if System could be part of multiple PhysicalZones at the same time. Intuitively this would mean that PhysicalZones can overlap. I currently have to use ugly workaround to get around this in IoTLang since it is not possible to override associations in MAL. That is: |
As discussed previously, here are some test cases (roughly 46). You should be able drop it in to use as regression tests right away. Some of the tests may also be useful to use as documentation (notably
test_T048_*on various kinds of privilege escalation).The tests are based on a list of IoT weaknesses from an upcoming IoT pentesting methodology ("PATRIOT") paper by Emre Süren et al. Some of the weaknesses can also be seen here. For each weakness I've tried to model at least one example scenario of that weakness in CoreLang (at least for the weaknesses that made sense to model). I have added Emre's explanations for each weakness as comments, and have also added some clarifications and examples of my own.
The tests gives some ideas on what CoreLang might lack (in the context of pentesting IoT). I've made some TODO-comments on the things I think might be worth implementing in CoreLang (rather than in IoTLang - which I'm working on). To summarize:
It would be nice to model TLS in more detail to cover more attacks on it. For example, there are attacks based on overwriting or adding CA-certificates on the victim to enable TLS MITM attacks (see e.g. "Trust Stores" in mitre). CoreLang does not really model credentials being overwritten. I chose to not go into too much detail on TLS in IoTLang, but given how fundamental TLS is it might make sense to go into more detail in coreLang (or perhaps in a TLSLang?).
Replay attacks can be used to circumvent authentication and encryption. This can easily be implemented by introducing a
replayattack step toDatathat would behave similarly toData.write. Secure protocols like TLS (and notably DTLS) would have areplayProtection-defense enabled, while insecure protocols would not.It might be good to model cryptographic signatures, verification and authentication in more detail. IoT firmware updates sometimes are sent without transport encryption but are instead verified using hashing and signatures (e.g. using a PGP-signature and a preshared public key). While this would prevent the attacker from installing firmware, the firmware may still contain sensitive information that they can read (like hardcoded passwords). You could use
Data.authenticatedto express this, but we are also interested in attacks on the firmware verification mechanism. For example, if the attacker obtains the private key they should be able to replace the firmware in transit (i.e. breaking the defense). I think it would make sense to adjustData.authenticatedto mirror howData.encryptCredsworks (i.e.authenticatedshould depend on a certificate that the attacker could potentially attack).CoreLang (and MAL in general) does not really model changing states that well. It would be good to have mechanisms to model for example rollback attacks. For example, an attacker may not be able to install arbitrary firmware, but they could perhaps downgrade to older firmware. The older firmware may have vulnerabilities that are absent in newer versions. Currently this can be worked around by creating multiple models -- one model of the scenario leading up to the rollback attack and another model showing the situation after a successful rollback attack.
I experimented with the following association:
-
Data [copySrc] * <-- Copy --> * [copyDst] Dataand it was quite useful. For example, it can be used to model a situation where multiple IoT device each run a copy of the same firmware. If the attacker overwrites the firmware on one of the devices it should not overwrite the firmware on the other devices. If the attacker reads the firmware on any device they are in effect reading the upstream version (in the cloud). Similarly, the copy association can model more complex data flows when interacting with APIs (e.g. to show how the data flows around the systems behind the API -- which can be used to illustrate injection attacks).