Report NeoGames Michigan 0215 v1 00 PDF

Applicative Penetration-Test Report
For
NeoGames
Version: 1.0
Date: 23 February 2015
Confidential and Proprietary
Limitations on Disclosure and Use of This Report

This report contains information concerning potential NeoGames Lobby Website and BackOffice
Application vulnerabilities.
Comsec Consulting recommends that special precautions be taken to protect the confidentiality of
both this document and the information contained herein.
Vulnerability assessments are an uncertain process, based on past experiences, currently available
information, and known threats. It should be understood that all information security systems, which
by their nature are designed by and therefore dependent on human beings, are vulnerable to some
degree. Therefore, while Comsec considers the major security vulnerabilities of the systems that
were analyzed to have been identified, there can be no assurance that any exercise of this nature
will identify all possible vulnerabilities or propose exhaustive and operationally viable
recommendations to mitigate these exposures.
In addition, the analysis set forth herein is based on the technologies and known threats as of the
date of this report. As technologies and risks change over time, the vulnerabilities associated with
the operation of NeoGames's systems described in this report, as well as the actions necessary to
reduce the exposure to such vulnerabilities will also change. Comsec makes no undertaking to
supplement or update this report on the basis of changed circumstances or facts of which we
become aware after the date hereof, absent a specific written agreement to perform supplemental
or updated analysis.
Security Penetration Test

NeoGames Lobby Website and BackOffice application
Page 2 of 27
Version 1.0
COPYRIGHT NOTICE
Copyright 2015 by Comsec Consulting and NeoGames.
All rights reserved. No part of this document may be reprinted, reproduced, or transmitted, in any
form or manner, without the prior written consent of the copyright owner.
First published and distributed in February 2015.
ACCEPTANCE AND RELEASE NOTICE

This is a managed document. Changes will only be issued upon approval of both parties. This
document cannot be released for use until authorized by both Comsec Consulting and NeoGames.
AUTHORIZED:
DATE:
(Comsec Consulting)
APPROVED & ACCEPTED: _____________________ DATE:_____/_____/_____
(NeoGames)

Page 3 of 27
Version 1.0
Changes Record
Date
Author
Version
Change Reference
17- 02 -15
RR
0.9
Working Draft: No previous document
23- 02 -15
LR
0.91
Review
23- 02 -15
RR
0.92
Second Working Draft
23- 02 -15
LR
0.93
Second Review
23-02-15
NS
1.00
Version 1.0
Approvals
Name
Department
Mr. Nadav Shatz
PCI Program Manager
Reviewers
Name
Department
Mr. Ran Rozenberg
Information Security Consultant
Mr. Lior Rokni
Information Security Consultant (QA)
Initials
Project Member
Initial
Mr. Ran Rozenberg
RR
Mr. Lior Rokni
LR
Mr. Nadav Shatz
NS

Page 4 of 27
Version 1.0
TABLE OF CONTENTS
[1]
1.1.
1.2.
1.3.
1.4.
[2]
2.1.
2.2.
[3]
3.1.
3.2.
3.3.
3.4.
3.5.
3.6.
3.7.
3.8.
Executive Summary ........................................................................................................ 6

Introduction ..................................................................................................................... 6
PCI DSS Requirement 11.3 ............................................................................................ 6
Breach Description Structure .......................................................................................... 7
Conclusions and Recommendations ............................................................................... 9
Information .................................................................................................................... 10
Objectives ..................................................................................................................... 10
Scope of Work & Methodology ...................................................................................... 10
Security Review Findings .............................................................................................. 12
User Harvesting ............................................................................................................ 12
Auto-complete in the Deposit Page is not Disabled (CVV) ............................................ 14
VIEWSTATE Parameter Is Not Encrypted .................................................................... 16
The System Does Not Properly Secure its Cookies ...................................................... 19
The System Does Not Inform the User of Last Login Time ........................................... 21
Multiple Login Enabled Simultaneously ......................................................................... 23
Lack of Forgot My Password Mechanism ................................................................... 25
Information Disclosure .................................................................................................. 26

Page 5 of 27
Version 1.0
[1] Executive Summary

1.1. Introduction
NeoGames has retained the services of Comsec Information Security to perform an applicative
security penetration test for NeoGames Public website and Back Office application as part of the
Security remediation requirements for PCI DSS certification.
This document describes the results of the penetration test performed during February 2015 onsite
at NeoGamess offices.
The penetration test relies on information gathered from interviews with platform architects and
developers, in addition to the results of manual testing of specific threat scenarios. The review
considered theoretical and practical methodologies, and techniques of attacks performed by a
malicious entity (e.g. hacker, spyware, virus, etc.) operating on a local or remote unit. It also
considered the use of well-known security best practices that are common among the industry and
used to mitigate potential threats.
This document provides a security status report on NeoGames Public website for Casino players
and Back Office application for managing the Casino, and will assist in meeting the requirements,
standards, controls, and configuration options that must be considered and exercised for securing
NeoGames's application.
1.2. PCI DSS Requirement 11.3

The PCI DSS (Payment Card Industry Data Security Standard) is a global security standard,
intended to enhance cardholder data security and facilitate the broad adoption of consistent data
security measures globally. The standard provides a baseline of technical and operational
requirements designed to protect cardholder data.
Because vulnerabilities are being discovered continually by malicious individuals and researchers,
and being introduced by new software - System components, processes, and custom software
should be tested frequently to ensure security controls continue to reflect a changing environment.
In order to achieve compliance and per requirement 11.3 of PCI DSS, Penetration Tests
(Applicative and Infrastructural) are required to be performed at least annually, and after any
significant infrastructure or application upgrade or modification to the cardholder data environment.

Page 6 of 27
Version 1.0
1.3. Breach Description Structure

This report includes a detailed description of breaches detected during the security check. Each
breach description consists of the following elements:
Breach Description: Detailed description of the nature of the breach and of the risks derived from
the specific breach.
Risk Level: Classifying the breach into one of three risk levels:
High (Level 3), Medium (Level 2), or Low (Level 1)

The Risk Level is composed of two components:
1.
Risk Impact: The business damage the organization might suffer, if the breach was
exploited. The following considerations are taken into account when deciding on the impact
level:
Asset sensitivity The higher the sensitivity of the asset, the higher the damage might be.
Confidentiality, integrity and availability considerations The level of the potential damage is
defined based on the potential impact on each of the three Information Security
components. For each breach, three questions are posed:
a. What will be the damage regarding information confidentiality?
b. What will be the damage regarding information integrity?
c. What will be the damage regarding system availability?
Direct and indirect damages Direct damages relate to breaches that, if exploited, will cause
immediate damage to the organization. Indirect damages relate to breaches that, if
realized, are not sufficient for causing damage without taking additional steps.
Breaches that might cause direct damages receive higher impact levels.
Types of business damages Both financial damages and reputation damages are
considered when deciding on the risk impact level.
2.
Risk Probability: The probability that the breach will be realized. The following
considerations are taken into account when deciding on the probability level:
The level of knowledge required to exploit the breach.
The frequency of the breachs exploitation in reality (based on statistics and on Comsec
experience).
3.
Risk Level: The evaluation of the total risk level is based on the following stages:
a. Each breach is assigned both an impact level (low, medium, or high) and a
probability level (low, medium, or high), based on the considerations defined above.
b. The total risk level is calculated and presented based on the following matrix:

Page 7 of 27
Version 1.0
Low
Medium
High
Probability (1)
Probability (2)
Probability (3)
Low
Low
Low
(Risk level 1)
(Risk level 1)
(Risk level 1)
Low impact (1)
Medium impact
(2)
Low
Medium
High
(Risk level 1)
(Risk level 2)
(Risk level 3)
High impact (3)
Medium
High
High
(Risk level 2)
(Risk level 3)
(Risk level 3)
The risk level will be the basis for defining the priorities and timetable for dealing with the different
breaches:
High (Risk Level 3): Breaches that must be addressed immediately.

Medium (Risk Level 2): Breaches, which must be addressed within a year (based on
a predefined plan).
Low (Risk Level 1): Breaches that could be addressed within more than one year.
Initial Recommendations: An outline of the required measures to secure the detected breach and
avoid its risks. Estimated costs in terms of time and materials will be provided where relevant and
possible.

Page 8 of 27
Version 1.0
1.4. Conclusions and Recommendations

Below are Comsec recommendations regarding issues that should be addressed to mitigate the
majority of the vulnerabilities found.
Launch a fundamental discussion regarding the appropriate solution for essential vulnerabilities.
Resolve the vulnerabilities discovered in the audit, based on the recommendations provided in
technical report and on industry best practices.
Comsec recommends using the risk level of the findings as the basis for defining the priorities
and timetable for dealing with the different breaches and consequently transforming the
recommendations into a concrete mitigation plan.
In order to complete the remediation process, and continue the security maintenance of the
systems it is recommended to reassess the systems after the vulnerabilities have been
addressed.

Page 9 of 27
Version 1.0
[2] Information
2.1. Objectives
The main objective of this project was to perform a security penetration test in order to identify
vulnerabilities on the application level that may expose NeoGames's systems and customers to
security risks. This was done by inspecting the application security controls from the perspective of
both an external attacker and a malicious user.
Other objectives include:
Verifying that authorization controls are implemented properly in the application.
Inspecting business logic at the design level.
Detecting security breaches at the application level, which jeopardize NeoGames's systems,
and the data that is processed and/or stored in the system.
Recommending measures for enhancing the level of security at the implementation,

configuration and design levels.
The system must provide secure, availaable, and reliable data for the customers. This document
will assist NeoGames in meeting the requirements, standards, and options that must be in place for
securing the tested applications.
2.2. Scope of Work & Methodology

The Security Assessment was performed in a White-Box security assessment approach. White-Box
security testing is an approach in which the system owner (NeoGames at this case) openly shares
extensive information regarding the design and implementation of the systems in the assessment
scope. This approach is proven to be time-efficient and to enable deeper and more thorough
analysis, while significantly reducing the costs of the security testing.
Each security element was inspected for potential and actual security flaws that may enable various
attacks by external attackers or malicious system users, such as:
Unauthorized access to sensitive information
Unauthorized modification of information
Unauthorized deletion of information
Unauthorized handling of audit information
Performing of unauthorized operations or transactions
Illegal impersonation of different users or entities
Performing of unauthorized operations that will cause a Denial of Service (DoS)
Exploitation of existing security controls to perform fraudulent activity

Page 10 of 27
Version 1.0

The tests used the following attack techniques to accomplish the aforementioned goals (for the
Penetration Test and High Level Review):
Hidden field manipulation
Parameter tampering
Cookie poisoning
SQL command injection
Buffer overflow
Cross Site Scripting
Forceful browsing
Third-party misconfigurations
Unauthorized browsing
Backdoors and debug options
Configuration subversion
Vendor-specific vulnerabilities
User privilege escalation
Session management
Input manipulation
Cryptography usage
Secure transport mechanisms
Protection mechanisms against Denial of Service attacks
Platform & technology-related mechanism usage

Page 11 of 27
Version 1.0
[3] Security Review Findings

3.1. User Harvesting
Revealed In:
Lobby
Vulnerability Description:
NeoGamess Lobby application includes Forgot Password mechanism which is based on username
in order to ensure that users information is protected against a malicious user. It is best practice to
implement a generic error messages mechanism at the case of authentication failure - Due to the
fact that by showing detailed error messages to the end user, about the application users, an
attacker can know if a user is valid or not.
However, NeoGamess Lobby application enables an attacker to gather information regarding valid
users. This includes information such as usernames via feedback messages generated by the
application.
Risk Level: Medium

By Brute Force attack and few attempts using the "Forgot Password" mechanism for each user, an
attacker could learn the names of subscribers to the system. If the user is invalid receive the
message: "The mail address is not registered", otherwise it can be concluded that the user exists.
An attacker can try to connect the application in a systematic way and thus to reveal the
usernames. This vulnerability can also help the attacker to make a DOS (denial of service) attack
on Lobby operators and internal users
Initial Recommendations:
At username failure, the application must return a generic error messages without the error reason.
For example:
Replay sent to the required email address.
The system should log any and all attempts to lock users.

Page 12 of 27
Version 1.0
Technical Details:
The following screenshot displays the error message that the application returns after entering the
wrong user name.

Page 13 of 27
Version 1.0
3.2. Auto-complete in the Deposit Page is not Disabled (CVV)

Revealed In:
Lobby
The Lobby application implements a login and registration pages, where the user is required to
supply a valid user name and password to authenticate in the application. This is done to prevent
unauthorized users, who do not possess the password, from accessing sensitive and private data in
Lobby application.
Most common browsers, including Microsoft Internet Explorer and Firefox, allow the use of an autocomplete mechanism. This mechanism is used for the user's convenience by saving them the
information that will have to enter from time to time when using the application.
However, the auto-complete mechanism is also considered a security risk because if a malicious
user gains access to a legitimate user's local-end computer, he may be able to use the deposit
functionality without knowing the CVV.
During the security review it became clear that the Lobby application does not disable the autocomplete mechanism at the CVV input parameter.
Risk Level: Medium

While the auto-complete mechanism is a convenient tool, it also helps an attacker to access the
system without supplying the proper authentication credentials. An attacker who has gained access
to a legitimate user's local-end computer will help him a lot when required details of the user and
they will be completed automatically by the system.
Disable the auto-complete mechanism in the deposit form, specifically in the sensitive input text
boxes, by adding the attribute Autocomplete=Off to these sensitive form.

Page 14 of 27
Version 1.0
Technical Details:
The following screenshot shows that auto-complete mechanism is enabled in DEPOSIT page.

Page 15 of 27
Version 1.0
3.3. VIEWSTATE Parameter Is Not Encrypted

Revealed In:
Lobby
BackOffice
The system is based on ASP.NET technology. This technology produces dynamic pages on the
server side and sends them to the user's browser. The Web page is saved user transmitted
character string representing the "page mode" (ViewState). This string contains some of the data
sent to and displayed in the browser and other data of the status page, and returned as a
parameter to the server when an operation by the user. This string is used for the server-side
components for maintaining the state of the data server-side controls.
Risk Level: Medium

In general, the end user can change the contents of the ViewState on the client side and send it
back to the server. The system receives data and to which the application performs various
resolutions. To avoid this problem, there is support environment. NET digital signature on the
ViewState and encryption is preventing be changed, but the system does not implement this
mechanism.
The system being tested is that the parameter the ViewState, which is stored in a hidden (Hidden),
encoded using BASE64 and using URL Encoding. This is not a coding and encryption using simple
tools to view data stored sensitive to this hidden parameter or change (see technical details)

Page 16 of 27
Version 1.0

There are two levels of security in the VIEWSTATE can be made:

o
Prevention change - can be set in ASP.NET add a signature (hash code) field on the
VIEWSTATE by setting the (attribute) EnableViewStateMAC system pages.
To do this we must add the following instruction:
<% @ Page EnableViewStateMAC = true%>
EnableViewStateMAC directive can be defined at any level of any page or app.
ASP.NET system will generate a hash code for any VIEWSTATE data that are sent to
the client side and compare it with the hash code which returns the server from the user.
If these data do not match, the request is rejected and the state of controls on the back
to its original state.
Define the signature using SHA1 algorithm in Machine.Config file in the Web server's
system - using the definition: <machineKey validation="SHA1">
Encryption - set the VIEWSTATE values to encrypt by the following settings:

Set EnableViewStateMAC = "true" as explained before.
Setting the Validation property in the configuration file Machine.Config for using
algorithm Triple DES symmetric encryption: <machineKey validation="3DES">
Do not move in VIEWSTATE data used to identify the user. Test data should be performed on
the server side only.

Page 17 of 27
Version 1.0

Technical Details:
Lobby: The following screenshot displays that the parameter VIEWSTATE is not encrypted, but
only using BASE64 encoding.
Back Office: The following screenshot displays the parameter VIEWSTATE is not encrypted, but
only using BASE64 encoding.

Page 18 of 27
Version 1.0
3.4. The System Does Not Properly Secure its Cookies

Revealed In:
BackOffice
After the initial authentication phase the General application identifies the end user by his private
session identifier.
The application stores the session identifier within client side cookies that are transmitted back and
forth between the customer's local end computer and NeoGames server.
During the audit, it was detected that the application sets a cookie without the "Secure" attributes.
Since this cookie does not contain the "Secure", it will be sent to the site during an unencrypted
session.
As the application sends some of the data through unencrypted this breach poses a real threat to
the users.
Risk Level: Low

A user who sends a cookie over a non-secure channel (HTTP) will become vulnerable to sniffing
attacks. Malicious attacker eaves dropping the channel could gain access to the cookie and the
sensitive information it stores such as their victim's session ID. This enables them to impersonate
their victim and gain access to all sensitive information as well as perform any action in the victim's
name.
Since the cookie's value could be viewed outside of the communication channel, a malicious
attacker may use other breaches to view the cookie's value and possibly impersonate their victim.
As a result, the attacker could gain access to all of his sensitive information as well as perform any
action in the victim's name.
The secure attributes of all client-side cookies should be set in order to make sure they are only
sent over a secure channel (HTTPS).

Page 19 of 27
Version 1.0
Technical Details:
The following screenshot shows cookie that set by the BackOffice application without the Secure
attribute:

Page 20 of 27
Version 1.0
3.5. The System Does Not Inform the User of Last Login Time
Revealed In:
Lobby
It is a common security practice to inform each user who logs on to an application the time and date
of their previous connection. This is important to raise user awareness in case their account was
hijacked by attacker. For example, a user can log on to the application and notice that the previous
connection occurred during a time when they were unavailable and therefore the customer
becomes aware that a malicious attacker has taken over their account.
Risk Level: Low

An attacker or a malicious user that has succeeded in gaining access to a legitimate user account,
by exploiting another system breach, may be able to continue to do so without being discovered.
Since the attacker is using legitimate credentials it is nearly impossible for NeoGames personnel to
uncover the attack. Without the required information regarding their previous connection, a user is
also unaware of any impersonation events.
Consequently, no mechanisms are in place to stop an attacker abusing the victim's account on a
regular basis.
It is important that the application displays to the user the time and date of their last login to the
application as soon as they logs on. This will provide an additional layer of protection for the
customer.

Page 21 of 27
Version 1.0
Technical Details:
The following screenshot displays the home page of the application, where the user is not informed
on his last login time:

Page 22 of 27
Version 1.0
3.6. Multiple Login Enabled Simultaneously

Revealed In:
BackOffice
A common security practice is to prevent a customer from making a second login attempt from a
different workstation unless they had previously logged out of the system. However, NeoGames
enables multiple user login sessions to the Lobby and BackOffice applications, using the same
username and password. This could be carried out using one or more remote computers. The
system does not alert when such an event happens.
The multiple user login sessions can be initialized using the same username and password and
from different computers or IP Addresses. This fact might compromise a user's account due to the
fact that a user is unaware of other users that can be logged on to his account.
Risk Level: Low

A legitimate user is unaware of any other action preformed on his account by other (possibly
malicious) factors.
The non-blocking of simultaneous multiple logins into the system, and the lack of an alert
mechanism may enable a malicious entity (who had obtained user credentials) to log on to the
system without the knowledge of the legitimate user. The consequence of this act is that the
legitimate user will not know that his account has been compromised and is being used.
Consider disabling the possibility of multiple user login by checking (on the server side) if the
user is already logged on to the site and does not allow a second instance of the same user
with the same credentials to log into the system.
The system should track and audit any attempt to perform simultaneous logons using
different computers.
The system Administration and security personnel should be notified of such an event.
All proper alert/message should be displayed to the user in case of a double login attempt

Page 23 of 27
Version 1.0
Technical Details:
The following example shows a scenario where the user is logged in simultaneously from different
machines to the BackOffice Application:

Page 24 of 27
Version 1.0
3.7. Lack of Forgot My Password Mechanism

Revealed In:
BackOffice
Users of the NeoGames BackOffice are required to supply a username and password in order to
login to the application. This identification mechanism is used in order to ensure that only those who
possess the proper credentials are able to login to the application, while unauthorized users cannot.
Users who have forgotten or misplaced their password are not able to request that their password
be reset.
Risk Level: Low

A malicious user might impersonate a legitimate user and call the system's support in order to reset
his/her victim's password.
Consider adding a Forgot Password mechanism to the website.
:

Page 25 of 27
Version 1.0
3.8. Information Disclosure

Revealed In:
Lobby
It is common practice not to reveal internal information about the servers and application
components to visitors of websites. This is important since visitors to the website have no need for
information regarding the type and version of servers. While this information is relevant to System
Administrators and developers, it can be used by malicious attackers to uncover security breaches
in the system.
During the security audit it was revealed that the system divulges information through the HTTP
responses within its headers. These headers reveal the servers type and version, thus making an
attackers job of infiltrating the system an easier task.
Risk Level: Low

Knowledge about the system infrastructure and the development tools used to create it, help an
attacker attack a system using known methods and vulnerabilities. There are many ways in which
an attacker can achieve this; however, the easiest way is simply by querying a search-engine (such
as www.securityfocus.org) and researching the name and version of the disclosed products.
Many products have known security flaws in them. Once discovered and published on the internet,
the flaws become public knowledge, and anyone can use them. It is also within the attackers
capabilities to verify whether or not the products used within the website and the web server are the
latest versions available. If not, an attacker may read about problematic issues that have been fixed
in the latest versions of the products, and thus, still exist in the older versions used by the
application and exploit them.
The application servers should be hardened so that they will not reveal any internal information to
the visitors of the web site.
Configure the web servers to remove the server-specific and version-specific headers.

Page 26 of 27
Version 1.0
Technical Details:
The following screenshot displays a detail about the type of response is sent from the server.

Page 27 of 27
Version 1.0

Report NeoGames Michigan 0215 v1 00 PDF

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Report NeoGames Michigan 0215 v1 00 PDF

Caricato da

Copyright:

Formati disponibili

Applicative Penetration-Test Report

Confidential and Proprietary

Limitations on Disclosure and Use of This Report

Security Penetration Test

Confidential and Proprietary

ACCEPTANCE AND RELEASE NOTICE

Security Penetration Test

Confidential and Proprietary

Working Draft: No previous document

Second Working Draft

Mr. Nadav Shatz

PCI Program Manager

Mr. Ran Rozenberg

Information Security Consultant

Mr. Lior Rokni

Information Security Consultant (QA)

Mr. Ran Rozenberg

Mr. Lior Rokni

Mr. Nadav Shatz

Security Penetration Test

Confidential and Proprietary

Executive Summary ........................................................................................................ 6

Security Penetration Test

Confidential and Proprietary

[1] Executive Summary

1.2. PCI DSS Requirement 11.3

Security Penetration Test

Confidential and Proprietary

1.3. Breach Description Structure

High (Level 3), Medium (Level 2), or Low (Level 1)

Security Penetration Test

Confidential and Proprietary

Low impact (1)

High impact (3)

High (Risk Level 3): Breaches that must be addressed immediately.

Security Penetration Test

Confidential and Proprietary

1.4. Conclusions and Recommendations

Security Penetration Test

Confidential and Proprietary

Verifying that authorization controls are implemented properly in the application.

Inspecting business logic at the design level.

Recommending measures for enhancing the level of security at the implementation,

2.2. Scope of Work & Methodology

Unauthorized access to sensitive information

Unauthorized modification of information

Unauthorized deletion of information

Unauthorized handling of audit information

Performing of unauthorized operations or transactions

Illegal impersonation of different users or entities

Performing of unauthorized operations that will cause a Denial of Service (DoS)

Exploitation of existing security controls to perform fraudulent activity

Security Penetration Test

Confidential and Proprietary

Hidden field manipulation

SQL command injection

Cross Site Scripting

Backdoors and debug options

User privilege escalation

Secure transport mechanisms

Protection mechanisms against Denial of Service attacks

Platform & technology-related mechanism usage