NOTE: This Post For Education and Security Research Only.
SecurityLab is a collection Program vulnerabilities, OpenSSL, and web app attacks.
—Explaination—
Lab1:
sploit1
The vulnerability is: strcpy() does not check the number of bits which will be copied into “char buf[96]”, so we overflow the return address of “lab_main()” and redirect the execution of the program to the shellcode we provide which runs a shell terminal.
example-sploit1 in gdb
sploit2
The vulnerability was that the len specified in the program was set to a max of 272. This allowed the attack string to overwrite i and len. The i variable was first overwritten such that it would remain small, so just the last byte of its four was overwritten with 0xb. Then len was overwritten 0x0000011c to enable i to index into buf to reach where the return address laid in memory. The environment variables were necessary to split up the attack string whenever a null byte was needed.
sploit3
The vulnerability is: “char buf[64]” is only 64 bytes, but “bar ( arg, buf, 88 )” allows us to write 88 bytes into it, therefore, we overflow the return address of “foo()” and redirect the execution of the program to the shellcode we provide which runs a shell terminal.
sploit4
Similar to sploit2, len could be set to a max of 169 and so len and i could be overwritten. The difference for sploit4 is that there is no indexing into the array using i. Thus, len first has be overwritten to allow enough iterations to overwrite i. The new value of i to be written needs to be at least such that len – i = number of iterations needed to fully overwrite all four bytes of the return address. The environment variables were necessary to split up the attack string whenever a null byte was needed.
sploit5
The vulnerability is: passing a certain number of “%x’s” to the “snprintf()” function allows us to change the argument pointer to point to the beginning of the “formatString”. At the beginning of the “formatString” we insert the location of the first 4 bytes of the return address of foo() seperated by NULL bytes. We then pass “%##u%hhn” to “snprintf()” four times to change the first 4 bytes of the return address one at a time. We then let the program continue to run, and once it returns from foo(), it will jump to the beginning of “char buf[1024]” and start executing the shellcode we inserted in there.
sploit6
The solution required two fake chunk tags. The first was located on the 8 bytes before the address of q where the double free was called and the second was placed a short distance away. The first tag’s next pointer pointed to the second fake tag. The second tag’s next pointer had the address of the return address, which was copied to the first’s next. It was then dereferenced and overwritten with a value in tmalloc.c’s “arena”, redirecting program execution. Placing the shellcode somewhere after the q region allowed a new shell to be spawned.
Lab2:
client
To build upon the sockets already in place, we used SSL, BIO, and CTX objects. The CTX object allowed the client to communicate with SSLv3 and TLSv1 only via SSLv23_method and SSL_OP_NO_SSLv2 parameter. SSL_CTX_set_cipher_list set SHA1 as the class of cipher suites to be used. SSL_get_verify_result, the CA_LIST “ece568ca.pem”, and SSL_get_peer_certificate was used to verify the certificate. Failing a SSL_connect causes the client to output errors from the BIO. X509_NAME_get_text_by_NID, X509_get_subject_name, NID_commonName, and NID_pkcs9_emailAddress was used to extract and check the common name and email from the certificate. SSL_write sent the secret and SSL_read got the server response and checked for errors, whether to continue reading, and when the server finished (closed the connection). Upon connection close, the client responds with its own SSL_shutdown. For cleanup, SSL_free and SSL_CTX_free were used. The buf had to be null terminated at the number of bytes read, otherwise unexpected garbage characters could show up.
server
It is very similar to the client. Notable differences are that there is child spawned for every client connection to try SSL_accept and output errors from the BIO if it failed. The SSL_read is done first to react to the client’s SSL_write and needs to be iterated until the secret has been completely read. The buf that stores the client’s message needs to be null-terminated at len due to possible unexpected garbage characters. Then the server does an SSL_write to give the answer to the client. The server-side shutdown is a bit different. The first SSL_shutdown will send a close_notify to the client, but not look for the client’s. Next, shutdown is called to send a TCP FIN required for certain clients and then server calls SSL_shutdown a second time.
Client-Server
Lab3:
Attack A. Cookie Theft
For this attack, we insert the “email script” javascript text after “http://zoobar.csl.toronto.edu/users.php?user=”>” so that it will be executed. It must be URL encoded or else it won’t work. The payload is set to “document.cookie” to get cookie information. We quickly reload the page to hide the errors from the user.
Attack B. Cross-Site Request Forgery
For this attack, we create a form with fields identical to the “http://zoobar.csl.toronto.edu/transfer.php” “transfer_form” and specify the transfer of 10 zoobars to “attacker” in the form. We submit the form to an <iframe> instance of “zoobar.csl.utoronto.edu” and imitate a “send” button click. Finally, we listen for when the form is submitted and quickly redirect to “http://ece568.csl.toronto.edu/”.
Attack C. Password Theft
For this attack, we create a form with fields identical to the “http://zoobar.csl.toronto.edu/login.php” “login_form” and submit it with a “special” “username.value” string. The “special” string is constructed such that its content will be evaluated and it will listen for a “Log in” button click and send the “username”,”password” using the email script. Certain sections of the string must be escaped for it to process without errors. We use “event.preventDefault();” to stop all actions until email script has been processed. We also have “image.onerror” to listen for when email script is starting to be processed, and then remove listener and click login button so that everything appears as normally would for the user.
Attack D. Profile Worm
The vulnerability is that there is an eval on document.getElementById(‘zoobars’).className. The malicious profile text consists of a span element that contains the same id ‘zoobars’ as an existing element. Since this inserted span element comes first, the eval will now be passed an arbitrary string as the class name. Two iframes are created, one to transfer 1 zoobar to the attacker and the other copies the attacker profile to the viewer profile. To set the attacker profile to appear to have 10 zoobars, the string contains “total = 10;”. This initializes total and since the later assignment to total will fail, total remains unchanged.
Lab4:
4.1
For this part, we specify the email_scope to be “email” so that we have access to the client’s email information and also the principle of least privilege is satisfied.
4.2
Before calling getPeopleInfo(), a new, similar function validateToken() is used. An XMLHttpRequest is created to get the token info for a particular access token. On a good request (status 200), the request’s responseText is parsed into JSON and the value for the audience key is compared with the client ID. If it matches, the given access token was actually for that client and getPeopleInfo() can be called to display profile information. Otherwise, no profile info is shown and the validity check is shown to have failed.
4.3
For this part, we implemented drive() to handle the authentication process. We first check if the client already has an authentication code, if not, we redirect them to the Google Login API which will prompt the client to log into their account and grant access based on the SCOPE we provide. Once the client is successfully authenticated, we retrieve the client’s credentials by providing their authentication code and store the credentials in a file locally.
4.4
Extending drive() after 4.3, the access token from credentials is applied to an Http object. A Google+ API service object is created to get the person info of the authenticated user (‘me’) and write it to profile.out. Then, a Google Drive service object is created to upload (insert) a file with the body containing specified metadata and the media_body containing profile.out.
Usage:
Source:https://github.com/hanwang92