commit 0af3518c5dbf5a03684991658f3711f3860da36d
parent a8f375bede6c397ae99558df3265a0f603f3dfd5
Author: Louis Burda <quent.burda@gmail.com>
Date: Fri, 25 Jun 2021 17:42:55 +0200
updated documentation
Diffstat:
1 file changed, 22 insertions(+), 72 deletions(-)
diff --git a/documentation/README.md b/documentation/README.md
@@ -2,7 +2,7 @@ STLDoctor
=========
STLDoctor is a plain-text protocol service, that allows users to upload STL files
-and generate reports that include information on the files..
+and generate reports that include information on the file's..
- model name
- binary header
@@ -10,17 +10,22 @@ and generate reports that include information on the files..
- file size
- triangle count
- bounding box size and position
+- validity
Uploaded models and generated reports are stored in a directory structure.
-Unregistered users have their files saved in a collective directory, which
-allows users to search for public models via model name. Registered users have
-their uploads saved to a private directory. This (theoretically) prevents other
+Unregistered user's files are saved in a collective directory, which
+allows users to search for public models via model name. Registered user's
+uploads are saved to a private directory. This (theoretically) prevents other
users from accessing their files.
The service is hosted with socat, one process per client.
-A cron job is used to periodically clean up models by using their *last modified* date.
+Models are periodically cleaned up using files *last modified* date.
+
+For both flagstores the **service returns the flag in plaintext**, which is
+vulnerable to detection by network filters and can lead to easy replication
+of exploits.
RCE Countermeasures
@@ -47,73 +52,18 @@ For this reason, additional security features are enabled via compilation flags:
Checker
=======
-The checker checks the following behavior:
-
-- File upload and search (for both bin and ascii):
- - Open a session
- - Upload a file of random, valid contents with random model name
- - Ensure file is listed in search
- - Open a new session
- - Ensure file is listed in search
- - Ensure file is not listed in search for different model name
-- Registering and private files (for both bin and ascii):
- - Open a session
- - Register with a random password
- - Upload a file of random, valid contents with random model name
- - Open a new session
- - Ensure file is not listed in search
- - Register with previous password
- - Ensure file is listed in search
-- Check upload ordering and accessing indeces != 0:
- - Open a session
- - Upload a file of random, valid contents with random model and solid name
- - Upload a different file of random, valid contents with same model name but different solid name
- - Open a new session
- - search for same model name and pick 1st entry
- - Compare returned solid name with expected (1st upload)
- - search for same model name and pick 2nd entry
- - Compare returned solid name with expected (2nd upload)
-
-
-The checker tenets:
-
-- A checker SHOULD not be easily identified by the examination of network traffic
- satisfied, because checker uses regular user interface and picks strings from a wordlist
- to appear more human (TODO)
-- A checker SHOULD use unusual, incorrect or pseudomalicious input to detect network filters
- satisfied, send various garbage bytes for model name and file contents (TODO)
-
-The checker does the following to upload the first flagstore's flag:
-
-- Open a session
-- Use `upload` to upload a file of random, valid contents with a
- the flag as the model name
-
-The checker does the following to upload the second flagstore's flag:
-
-- Open a session
-- Register as a premium user
-- Use `upload` to upload a binary STL with the flag as its solidname
- and a random model name chosen from a wordlist with numbers for
- collision resistance
-
-The checker should not be easily identifiable, since this could allow
-players to only enable certain service functions when the checker is
-detected.
-
-Notes on evading detection of the checker through traffic analysis:
-
-- File upload contents are randomly generated valid STLs and the model name is
- picked randomly from a wordlist to blend in with regular requests
-- The username used for premium user registration is chosen at random from
- a wordlist (with numbers appended for collision resistance) to blend
- in with other requests
-- The STL file which belongs to the second flagstore is not easily identifiable
- since the binary file format is used and viewing the file contents does not
- help identify the 3d model encoded
-- The first flagstore's flag IS easily identifiable, since it is sent in cleartext
- to the service, however, the checker makes sure to test upload and searching
- functionality of files with other model names in another session as well
+The checker is **not easily identifiable by the examination of network traffic**,
+because it uses the regular user interface and chooses random input in a way
+that appears human. This prevents players from only enabling certain service
+functions when the checker is detected.
+
+The checker **uses unusual, incorrect or pseudomalicious input to detect network filters**
+by replicating the same type of data sent in an exploit (negative chars) in other
+context, which avoids filtering.
+
+The checker **tests processing of many different valid and invalid inputs**
+to verify that the service can properly distinguish the two and verifies
+input as it should.
Vuln 1: Value Collision
