Jaypee Institute of Information Technology

Secure Design of Software Systems

Project - Threat Modelling and Pen Testing on Google Gruyere

Team Members :

Enrollment No. Name Batch

19103213 Tushar Garg B7

19103223 Abhinav Verma B7

19103231 Manan Agarwal B7

19103237 Radhika Mittal B7

Submitted to Department of CSE/IT

 2022 Security Assessment Report Prepared for :

Website Link:
https://google-gruyere.appspot.com/568860512498095063413804550609963150136/

Report Issued : 26-11-2022

Threat Modeling
Threat modeling identifies the types of threat agents that harm an application or computer
system. We need that perspective to see how much damage a malicious hacker can do. In threat
modeling, organizations perform a thorough analysis of software architecture, business context,
and other artifacts such as functional specifications, user documentation, and so on.
This process allows us to better understand and discover important aspects of the system.
Typically, during the design phase (although it can also occur at other stages), organizations
perform threat modeling of new applications to help developers find vulnerabilities and impact
security on design, code, and configuration decisions. Make impact visible.
A web application threat analysis can identify a large number of threats. Some of these threats
are application specific. Others are related to underlying infrastructure software such as: B. Web
or application servers, databases, directory servers, etc.
Analyzing and modeling the potential threats your application faces is an important step in
designing a secure application. Some of these threats are very application-specific in nature and
we can only provide very general guidelines on how to identify such threats. Other threats,
however, are directly or indirectly related to underlying platforms, technologies, or programming
languages. Therefore, it makes sense to identify and document these technology-specific threats
and provide guidelines to software vendors to mitigate the associated risks.
Steps:
1. Collect Background Information
2. Decompose the application
3. Discover and rank threats
4. Determine countermeasures and mitigation

Systematically enumerate threats according to STRIDE's threat taxonomy. This section generally
describes threats that exist in the single web service consumer and single web service provider
scenario.
1. Spoofing: Whenever the line of communication between a consumer and a web service
provider crosses a line of trust, there is always the risk of spoofing. Both providers and
consumers can be spoofed.
2. Tampering: Operations can be performed when the data is on the communication channel,
when the data is on the consumer machine, or when it is on the provider machine. Specifically
for web services, the object of manipulation is the SOAP file and the WSDL file, executing code
on both the consumer and provider side, and application specific data on either the consumer or
provider side.

3. Repudiation: Denial threats are application-specific in nature and will not be discussed further
here. Web services offer countermeasures such as XML signatures.

4. Disclosure of Information: Information may be leaked while in transit or while stored on the
consumer's or provider's computer. Similar to manipulation threats, information disclosure
targets are SOAP and WSDL files, code executed on both the consumer and provider sides, and
application-specific data on either the consumer or provider side.

5. Denial of service Denial-of-service attacks attempt to disrupt service by overloading

communication lines or forcing consumers or providers to crash or undue degradation.

6. Escalation of Privilege: Privilege escalation can occur on both consumer and manufacturer
computers.

Threats and Remedies

Cross-site scripting (XSS) is a vulnerability that allows an attacker to inject code (usually HTML
or JavaScript) into the content of websites not under the attacker's control. When a victim views
such a page, the injected code is executed in the victim's browser. Thus, an attacker can bypass
the browser's same-origin policy and steal the victim's personal information associated with her
website in question.
 ● File Upload XSS

To exploit, upload a .html file containing a script like this:

<script>

alert(document.cookie);

</script>

To fix, host the content on a separate domain so the script won't have access to any content from
your domain. That is, instead of hosting user content on example.com/username we would host it
at username.usercontent.example.com or username.example-usercontent.com. (Including
something like "usercontent" in the domain name avoids attackers registering usernames that
look innocent like wwww and using them for phishing attacks.)

● Reflected XSS

To exploit, create a URL like the following and get a victim to click on it:

https://google-gruyere.appspot.com/123/<script>alert(1)</script>

To fix this, you need to escape user input that is displayed in error messages. Error messages are
displayed using error.gtl, but are not escaped in the template. The part of the template that
renders the message is {{message}} and it's missing the modifier that tells it to escape user
input. Add the :text modifier to escape the user input:

<div class="message">{{_message:text}}</div>

This flaw would have been best mitigated by a design that escapes all output by default and only
displays raw HTML when explicitly tagged to do so. There are also autoescaping features
available in many template systems.
Client-State Manipulation

When a user interacts with a web application, it's done indirectly through the browser. When a
user clicks a button or submits a form, the browser sends the request back to her web server.
Since the browser runs on a computer that could be controlled by an attacker, your application
should not trust any data sent by the browser.

Elevation of Privilege

You can convert your account to being an administrator by issuing either of the following
requests:

● https://google-gruyere.appspot.com/123/saveprofile?action=update&is_admin=True
● https://google-gruyere.appspot.com/123/saveprofile?action=update&is_admin=True&uid
=username (which will make any username into an an admin)

If you visit this URL, your account will be marked as an administrator, but the cookie will
display a message that you are not an administrator. So logout and login again to get new
cookies. After logging in, notice the Manage this Server link in the upper right corner.

The problem here is that the server side cannot validate that the request is authorized. The only
code that restricts the changes a user can make is in the template, hiding parts of the UI that the
user can't access. The correct thing to do is to check authorization on the server upon receiving
the request.

Cross-Site Request Forgery (XSRF)

XSRF is a type of malicious exploitation of a website or web application in which unauthorized

commands are sent by a user trusted by the web application. [2] There are many ways a
malicious website could send such a command. For example, specially crafted image tags,
hidden forms, JavaScript fetches or XMLHttpRequests all work without user interaction or
knowledge.

To exploit, lure a user to visit a page that makes the following request:

https://google-gruyere.appspot.com/123/deletesnippet?index=0
To be especially sneaky, you could set your Gruyere icon to this URL and the victim would be
exploited when they visited the main page.

To fix, we should first change /delete snippets to work via a POST request since this is a state
changing action. In the HTML form, change method='get' to method='post'. On the server side,
GET and POST requests look the same except that they usually call different handlers. For
example, Gruyere uses Python's BaseHTTPServer which calls do_GET for GET requests and
do_POST for POST requests.

Then we need to pass a unique, unpredictable authorization token to the user and require that it
get sent back before performing the action. For this authorization token, action_token, we can
use a hash of the value of the user's cookie appended to a current timestamp and include this
token in all state-changing HTTP requests as an additional HTTP parameter. The reason we use
POST over GET requests is that if we pass action_token as a URL parameter, it might leak via
HTTP Referer headers. The reason we include the timestamp in our hash is so that we can expire
old tokens, which mitigates the risk if it leaks.

Path Traversal

Most web applications expose static resources such as images and CSS files. Applications often
simply provide all their files in one folder. If an application is not careful, users can use path
traversal attacks to read files from other folders that should not be accessed. For example, ..
represents the parent directory on both Windows and Linux, so if you can put ../ in your path,
you can "escape" it to the parent directory.

If an attacker knows the structure of your file system, then they can craft a URL that will traverse
out of the installation directory to /etc. For example, if Picasa was vulnerable to path traversal (it
isn't) and the Picasa servers use a Unix-like system, then the following would retrieve the
password file:

https://www.picasa.com/../../../../../../../etc/passwd
 ● Information disclosure via path traversal

To exploit, you can steal secret.txt via this URL:

https://google-gruyere.appspot.com/123/../secret.txt

To fix this, we need to prevent access to files outside the resources directory. Validating file paths
is a bit tricky as there are various ways to hide path elements like "../" or "~" that allow escaping
out of the resources folder. The best protection is to only serve specific resource files. You can
either hardcode a list or when your application starts, you can crawl the resource directory and
build a list of files. Then only accept requests for those files.

● Data tampering via path traversal

To exploit, create a new user named .. and upload your new secret.txt. You could also create a
user named brie/../...

To fix, you should escape dangerous characters in the username (replacing them with safe
characters) before using it.

As a general rule, you should never store user data in the same place as your application files but
that alone won't protect against these attacks since if the user can inject ../ into the file path, they
can traverse all the way to the root of the file system and then back down to the normal install
location of your application (or even the Python interpreter itself).

Denial of Service

A denial of service (DoS) attack is an attempt to trick a server into not processing normal
requests. A common form of DoS attack is sending more requests to a server than it can handle.
The server spends all its time servicing the attacker's requests and very little time servicing
legitimate requests.
 ● DoS - Quit the Server

To exploit, make a request to https://google-gruyere.appspot.com/123/quitserver. You should

need to be logged in as an administrator to do this, but you don't.

This is another example of a common bug. The server protects against non-administrators
accessing certain URLs but the list includes /quit instead of the actual URL /quitserver.

To fix, add /quitserver to the URLS only accessible to administrators:

_PROTECTED_URLS = [
"/quitserver",
"/reset"
]

To exploit, use https://google-gruyere.appspot.com/123/RESET. The check for protected urls is

case sensitive. After doing that check, it capitalizes the string to look up the implementation.
This is a classic check/use bug where the condition being checked does not match the actual use.
This vulnerability is worse than the previous one because it exposes all the protected urls.

To fix, put the security check inside the dangerous functions rather than outside them. That
ensures that no matter how we get there, the security check can't be skipped.

● DoS - Overloading the Server

To exploit, create a file named menubar.gtl containing:

[[include:menubar.gtl]]DoS[[/include:menubar.gtl]]

and upload it to the resources directory using a path traversal attack, e.g., creating a user named
../resources.

To fix, implement the protections against path traversal and uploading templates discussed
earlier.
Code Execution

If an attacker can execute arbitrary code remotely on your server, it's usually game over. They
may be able to take control over the running program or potentially break out the process to open
a new shell on the computer. From here, it's usually not hard to compromise the entire machine
the server is running on.

To exploit, make a copy of gtl.py (or sanitize.py) and add some exploit code. Now you can either
upload a file named ../gtl.py or create a user named .. and upload gtl.py. Then, make the server
quit by browsing to https://google-gruyere.appspot.com/123/quitserver. When the server restarts,
your code will run.

Preventative measures:

● Least Privilege: Always run your application with the least privileges it needs.
● Application Level Checks: Avoid passing user input directly into commands that evaluate
arbitrary code, like eval() or system(). Instead, use the user input as a switch to choose
from a set of developer controlled commands.
● Bounds Checks: Implement proper bounds checks for non-safe languages like C++.
Avoid unsafe string functions. Keep in mind that even safe languages like Python and
Java use native libraries.

Buffer Overflow and Integer Overflow

This codelab doesn't cover overflow vulnerabilities because Gruyere is written in Python, and
therefore not vulnerable to typical buffer and integer overflow problems. Python won't allow you
to read or write outside the bounds of an array and integers can't overflow. While C and C++
programs are most commonly known to expose these vulnerabilities, other languages are not
immune. For example, while Java was designed to prevent buffer overflows, it silently ignores
integer overflow.
SQL Injection

Just as XSS vulnerabilities allow attackers to inject scripts into web pages, SQL injection
vulnerabilities allow attackers to inject arbitrary scripts into SQL queries. When a SQL query is
executed it can either read or write data, so an attacker can use SQL injection to read your entire
database as well as overwrite it.
This codelab doesn't cover SQL injection because Gruyere doesn't use SQL.
Pen Testing
Confidentiality Notice

This report contains sensitive, privileged, and confidential information. Precautions should be
taken to protect the confidentiality of the information in this document. Publication of this report
may cause reputational damage to Gruyere or facilitate attacks against Gruyere. Our team shall
not be held liable for special, incidental, collateral or consequential damages arising out of the
use of this information.

Disclaimer

Note that this assessment may not disclose all vulnerabilities that are present on the systems
within the scope of the engagement. This report is a summary of the findings from a
“point-in-time” assessment made on Gruyere’s environment. Any changes made to the
environment during the period of testing may affect the results of the assessment.
Table of Contents

Executive Summary

High Level Assessment Overview

Observed Security Strengths
Areas for Improvement
Short Term Recommendations
Long Term Recommendations

Testing Methodology

Classification Definitions
Risk Classifications
Exploitation Likelihood Classifications
Business Impact Classifications
Remediation Difficulty Classifications

Assessment Findings

Appendix A - Tools Used

Executive Summary

Our team performed a security assessment of the internal corporate network of Gruyere on 26th
November, 2022. Our team's penetration test simulated an attack from an external threat actor
attempting to gain access to systems within the Gruyere corporate network. The purpose of this
assessment was to discover and identify vulnerabilities in Gruyere’s infrastructure and suggest
methods to remediate the vulnerabilities. Our team identified a total of 4 vulnerabilities within
the scope of the engagement which are broken down by severity in the table below.

The highest severity vulnerabilities give potential attackers the opportunity to perform fuzzing.
After intercepting responses via Burp Proxy and sending one of the login requests to Burp
Interceptor, we entered a list of common payloads and then started our Fuzzing Attack. After the
attack was completed, we found no discrepancies in the responses we received. So, we
concluded that the application was performing normally for infectious and malformed inputs
also, thus the web application was not vulnerable to this attack.
Then, after performing manual and automated SQL Injection we can conclude that the website is
not vulnerable towards SQL Injection.
From the results, we saw that, entropy of session/token id is very low, so CSRF is possible.
An XSS attack was performed which resulted in stored XSS and file based XSS being possible.
Admin level privileges were given to normal users on login and easy information disclosure is
possible.
In order to ensure data confidentiality, integrity, and availability, security remediations should be
implemented as described in the security assessment findings.
Note that this assessment may not disclose all vulnerabilities that are present on the systems
within the scope. Any changes made to the environment during the period of testing may affect
the results of the assessment.
HIGH LEVEL ASSESSMENT OVERVIEW
Observed Security Strengths
We identified the following strengths in Google Gruyere’s network which greatly
increases the security of the network. Google Gruyere should continue to monitor these
controls to ensure they remain effective.
1. SQL Injection was not possible
2. Application was secure towards infected or malformed inputs

Areas for Improvement

We recommend taking the following actions to improve the security of the network.
Implementing these recommendations will reduce the likelihood that an attacker will be able to
successfully attack Google Gruyere information systems and/or reduce the impact of a successful
attack.

Short Term Recommendations

We recommend taking the following actions as soon as possible to minimize business risk.
1. Don't allow files without validation to be uploaded on the server
2. Improve randomness of the token/session ids.

Long Term Recommendations

We recommend the following actions be taken to fix hard-to-remediate issues that do not pose an
urgent risk to the business.
1. Don't allow admin rights to normal users
2. Avoid access to dump.gtl
Testing Methodology

Our team’s testing methodology was split into three phases: Reconnaissance, Target Assessment,
and Execution of Vulnerabilities. During reconnaissance, we gathered information about
Gruyere’s network systems.Our team used port scanning and other enumeration methods to
refine target information and assess target values. Next, we conducted our targeted assessment.
Our team simulated an attacker exploiting vulnerabilities in the Gruyere network. We gathered
evidence of vulnerabilities during this phase of the engagement while conducting the simulation
in a manner that would not disrupt normal business operations.
The following image is a graphical representation of this methodology.
Assessment Findings

Sr. No. Tests Risk Score Risk

1 Stored XSS 9 High

2 CSRF 8 Medium

3 File based XSS 8 High

4 Escalation of privilege 8 High

5 Information Disclosure 6 High

6 Malformed Inputs 2 Low

7 SQL Injection 1 Low

Vulnerability Finding

1. Malformed Inputs

Risk Low Risk (2/10)

Exploitation Likelihood Unlikely

Business Impact Minor

Remediation Difficulty Easy

Security Implications
Fuzzing was performed on the application, to check the presence of any malicious or malformed
inputs. If the application performs normally towards all kinds of inputs then we can say that the
application is secure from invalid inputs.

Analysis
After performing Fuzzing, we can conclude that the application is secure from the injection of
malicious inputs, thus this vulnerability is not present in the application.
 2. SQL Injection

Risk Low Risk (1/10)

Exploitation Likelihood Unlikely

Business Impact Minor

Remediation Difficulty Easy

Security Implications
The application doesn’t use SQL for storing information, as a result performing SQL Injection
will yield no fruit.

Analysis
After performing both manual and automated SQL Injection, we were able to conclude that the
application is secure from this attack, because it is not using any kind of database to store the
data of the users, thus the hacker cant take advantage of it.
 3. CSRF

Risk High Risk (8/10)

Exploitation Likelihood Likely

Business Impact Major

Remediation Difficulty Hard

Security Implications
If the application is not secure towards this attack, the hacker can use the session ids of the users
to hijack the sessions and then gain access to the user's sensitive data.

Analysis
The application is vulnerable to CSRF Attack, as the token ids are not randomized and the
hacker can guess them easily using brute force.

Recommendations
1. Improve the entropy of session ids.
2. Check for session ids at every step
3. Use an extremely generic and random mathematical function to generate session ids.
 4. Stored XSS

Risk High Risk (9/10)

Exploitation Likelihood Likely

Business Impact Major

Remediation Difficulty Moderate

Security Implications
If it is possible to inject executable infectious scripts into the browser, then the hacker can do it,
and then make the user perform unwanted actions on the website.

Analysis

Stored XSS is possible here, as the application is not validating the snippets that the user is
uploading, thus scripts can be executed.

Recommendations
1. Validate data before input
2. Encode data (URL/HTML Encoding)
 5. File based XSS

Risk High Risk (8/10)

Exploitation Likelihood Likely

Business Impact Moderate

Remediation Difficulty Easy

Security Implications
While uploading files, they should be authenticated by the application, otherwise hackers can
upload malware or trojans also.

Analysis
File based XSS is also possible, as the files are not validated or checked by the application.

Recommendations
1. Check format of file before input
2. Check size of file before input
 6. Information Disclosure

Risk Moderate Risk (6/10)

Exploitation Likelihood Possible

Business Impact Moderate

Remediation Difficulty Easy

Security Implications
If the hacker gets information about the users or the application, it can be used in a wrong way.

Analysis

To exploit, you can use the debug dump page dump.gtl to display the contents of the page
https://google-gruyere.appspot.com/568860512498095063413804550609963150136/dum
p.gtl

Sensitive information was disclosed after some analysis.

Recommendations

1. Add 2 way user authentication

2. Show this data explicitly to admin only
 7. Escalation of privilege

Risk High Risk (8/10)

Exploitation Likelihood Possible

Business Impact Major

Remediation Difficulty Moderate

Security Implications
If a normal user gets admin level rights, they can do anything on the application, which should
be avoided at all costs.

Analysis
A normal user was able to gain admin level rights/accesses. As a result, now they can manipulate
the data of the entire application as they wish.

Recommendations
1. Add a password policy, or content secure policy
2. Regular updates and patches
3. Automated tools to check for change of privileges at both horizontal and vertical level
Conclusion

Google Gruyere suffered a series of control failures and cyber security vulnerabilities, which led
to a complete compromise of critical company assets. These failures would have had a dramatic
effect on Google Gruyere operations if a malicious party had exploited them.

A targeted attack against Google Gruyere can result in a complete compromise of organizational
assets. Multiple issues that would typically be considered minor were leveraged in concert,
resulting in a total compromise.

Google Gruyere suffers from a majority of vulnerabilities which are common and easy to exploit
by hackers nowadays. Appropriate recommendations have been provided under each
vulnerability section and should be considered with utmost priority.
Appendix A: Tools Used

Tool Description

Burp Suite Used for testing the web applications

Burp Suite Browser Used for analyzing the web applications