You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -134,6 +142,8 @@ Then all events can be viewed, and, if not already in it, access can be requeste
134
142
135
143
### 5.1 Insecure UUID Generation
136
144
145
+
#### Vulnerability
146
+
137
147
The User IDs and the Post IDs are both derived deterministically (in the classes `IdentifierGenerator.swift` and `PostIDGenerator.swift`, respectively).
138
148
139
149
The User ID is directly derived from a (padded or cut) username, while the PostID is derived from the User ID, a counter (initialized to 0) and a timestamp (with `minute` precision). These values are `XOR`ed together, and then form the (derivable) PostID.
@@ -157,4 +167,98 @@ return uuid()
157
167
158
168
This returns a secure uuid, from which the postID is then derived. For additional security, this could also be replaced by the same logic.
159
169
160
-
Alternatively, only the PostID generation could be made secure. In the current state of development for facepalm, the deterministic User ID does not have implications (that have been found).
170
+
Alternatively, only the PostID generation could be made secure. In the current state of development for facepalm, the deterministic User ID does not have implications (that have been found).
171
+
172
+
### 5.2 Cropped Keys
173
+
174
+
#### Vulnerability
175
+
176
+
When generating the key used to enter an event, a 32 char long random hex numbers is generated and used as the key. When storing this numbers in the DB, though, only the first byte of the key is stored - thus making the search space $2^{8}$ instead of $2^{32}$. Since multiple keys at once can be uploaded, a huge keyfile containing all keys that hash to the complete set of keys can be uploaded in one go, allowing access to all events.
177
+
178
+
#### Exploit
179
+
180
+
To exploit the vulnerability, the own keystore (which is in the DB for the user) needs to be filled with 32 char long strings that hash to `00` to `ff`. A brute force approach can be used, since the search room is relatively small. A file containing a variety of keys to get the flags is also stored in `checker/src`. These are used by the checker to automatically exploit the vulnerability if needed.
181
+
182
+
#### The Fix
183
+
184
+
The fix here is to simple store the entire key in the DB. This requires the removal of `prefix(1)` from every interaction with the keys. E.g. when storing the key in the DB, this is called, and needs to be changed as follows:
0 commit comments