INTRODUCTION & CHANGES IN PCI-DSS v3.2

INTRODUCTION & CHANGES IN PCI-DSS V3.2

The Payment Card Industry Data Security Standard (PCI- DSS) was developed to follow the policy and standards of cardholder data security which consistent data security measures globally. PCI- DSS provides a minimum of technical and operational requirements to protect data of the cardholders. PCI -DSS applies to all operation which involved in payment card processing of cardholder data.

The below describes the changes in PCI-DSS v3.2 from version 3.1.

AREAS EMPHASISED IN V3.2:

• CHANGE MANAGEMENT PROCESS:

  • The Change Management Process is done to perform the secure changes during the process based on the business requirement.

• ADMINISTRATIVE ACCESSING:

  • The Administrative privilege is given only to the single user were the particular can gain the read, write and execute access to the changes in the environment.

• INCIDENT RESPONSE:

  • Incident response is nothing but when there is an issue raised in the environment the action is taken based on the severity of the problems.

• E-COMMERCE – A-EP ENVIRONMENTS:

  • the “Expected Testing” column is based on the testing procedures in the PCI DSS and provides a high-level description of the types of testing activities should be performed to verify that a requirement has met.

SAQ VERSION	# QUESTIONS V3.1	# QUESTIONS V3.2	DIFFERENCE
SAQ D-SP	347	369	+22
SAQ D-MER	326	331	+5
SAQ C	139	162	+23
SAQ A-EP	139	193	+54
SAQ B-IP	83	84	+1
SAQ C-VT	73	80	+7
SAQ B	41	41	0
SAQ P2PE-HW	35	33	-2
SAQ A	14	22	+8

MASKING THE PAN NUMBER

• DISPLAYING THE PRIMARY ACCOUNT NUMBER

  • First six and last four digits of PAN can be displayed based on the current requirement.

For a legitimate business need the pan number must be encrypted. Follow Requirement 3.3 for further reference.

CHANGE CONTROL

• CHANGES IN CHANGE CONTROL IN V3.2

  • Maintain proper documentation when any change control issued.
  • Implement all the necessary control in all the new and existing systems or devices.
  • Change control processes must include verification of PCI DSS requirements impacted by a (significant) change. Fallow Requirement 6.4.6 which is effective from Feb 1, 2018.

HIGH-RISK VULNERABILITY MANAGEMENT

• INTEGRATE VULNERABILITIES INTO THE RISK ASSESSMENT PROCESS

  • Ensure all “high risk” vulnerabilities must be addressed for internal scans and resolved.
  • By the vulnerability ranking as per Requirement 6.1 and 6.2 in PCI-DSS scope.
  • After resolving the vulnerabilities ensure the risk has been cleared by rescanning.

REMOTE ADMINISTRATOR ACCESS TO CDE

• ANY NON-CONSOLE ADMINISTRATOR ACCESS TO CDE

  • All the non-console access into CDE for personnel with administrative access must implement the multi-factor authentication.
  • The current requirement for multi-factor authentication for remote access to CDE for personnel with administrative access still applies according to the PCI-DSS scope.
  • Fallow PCI-DSS scope 8.3.1 and 8.3.2 mandatorily from Jan 31, 2018.

RESOURCE

• Refer the following document for the PCI-DSS scope.
• LINK: pcisecuritystandards.org/document_library?category=pcidss

AUTHOR

Dharmesh B

Security Engineer

Briskinfosec Technology and Consulting Pvt Ltd.,

https://www.linkedin.com/in/dharmeshbaskaran/

SSRF (SERVER SIDE REQUEST FORGERY)

SSRF (SERVER SIDE REQUEST FORGERY)

INTRODUCTION

Server-Side Request Forgery (SSRF) refers to an attack wherein an attacker can send a crafted request from a vulnerable web application. SSRF is mainly used to target internal systems behind WAF (web application firewall) that are unreachable to an attacker from the external network. Additionally, it’s also possible for an attacker to mark SSRF to access services from the same server that is listening on the loopback interface address called (127.0.0.1).

Typically, Server Side Request Forgery (SSRF) occurs when a web application is making a request, where an attacker has full or partial control of the claim that is sent. A typical example is when an attacker can control all or part of the URL to which the web application makes a request to some third-party services, and here I have captured the parameter of file= URL, and I tried to perform this server-side forgery attack

tried to perform this server-side forgery attack

In the above figure, the perpetrator forges a request for a fund transfer website, and he embeds it into the visitor site. when the visitor logs the website for the transaction and clicks the perpetrator created a link, it redirects to Perpetrator site, and the amount is transferred to his account

SSRF IMPACTS:

By this attack, an attacker can gather information about ports, IP addresses, Remote code execution and it also discovers the IP addresses of servers running behind a reverse proxy etc.

For Example, I have tried SSRF attack on a testing site for your reference

Vulnerable site: http://testphp.vulnweb.com/

POC 1:

In Burp Suite I have checked for some different redirection parameter other than URL=, and in the search field I have tried with various parameters and using this parameter of file= and here I have captured the request of the particular path and sent it to the repeater

POC 2:

Request Captured from the search file in the repeater and here in file feed a .jpg file is available, now I removed the file and entered a third party URL on file Redirected URL: https://www.expressvpn

POC 3:

Once I click on Go to capture response the response is changed to expessvpn.com, and you can see the IP of the testphp.vulnweb.com, but in render page, you can see the expressvpn.com site gets loaded as follows.

POC 4:

PREVENTION FROM SSRF:

• Generic error messages should be displayed to every client as unhandled responses might end up revealing sensitive information or data leakage about the server when any other raw response or different parameter is used.
• URL schemas other than HTTP and HTTPS should be blacklisted. Instead, these two mentioned protocols should be whitelisted thereby not allowing different schemas which are not in use like file:///, direct://, feed://, touch://  and FTP:// which might prove to be dangerous for SSRF.

CONCLUSION:

Hence, the Server Side Request Forgery attack has been made from the server side and the required web page has been redirected to some other web pages and to prevent from such types of attacks allow only the particular subdomains of the required web page and whitelist the other web pages which they are not in use.

REFERENCE LINKS:

• https://dzone.com/articles/the-server-side-request-forgery-vulnerability-and
• https://medium.com/poka-techblog/server-side-request-forgery-ssrf-attacks-part-1-the-basics-a42ba5cc244a

AUTHOR

Ram Kumar

Security Engineer

Briskinfosec Technology and Consulting Pvt Ltd.,

follow me @https://www.linkedin.com/in/ram-kumar-3439b511a/

APKiD tool — Detecting Malware And Tampered Android Apps

APKID TOOL — DETECTING MALWARE AND TAMPERED ANDROID APPS

INTRODUCTION:

APKiD Tool finds what type of packers, obfuscator and compilers are used in the APK file. Using APKiD, We can analyse an APK file whether it is malware or pirated version of an original APK so it will be a useful tool for a malware analyser or security researcher who cares about analysing malware in android. Before getting into the APKiD installation let’s examine how APKiD tool is detecting compilers, packers and obfuscators by looking into APK or DEX file.

Mostly, we install the Android app from google play store from the original version, but in case of third-party app stores, we can download the same application which is available in google play store but can’t be trusted because there are chances of the app containing virus or malware. So what makes the differences between the original and modified APK file apart from the tampered code, the difference is in the compiling process. The original file is disassembled and recompiled by using the APKTOOL. APKTOOL uses smali, and they are part of the same dexlib project. So any android app which had malware injected code into original or pirated will have probably been disassembled and recompiled by dexlib. dexlib is a compiler, like dexlib there are several compilers available which is listed below:

• dx – standard Android SDK compiler
• dexmerge – used for incremental builds by some IDEs (after using dx)
• dexlibx
• dexlibx beta
• dexlibx

APKid tool looks into the APK or Dex file for detecting the type of compilers.

APKID INSTALLATION:

There are two ways you can install the APKiD tool, by configuring Yara-python and installing APKiD tool or through Docker, you can install which is natural and works fine for me. Here, I will introduce through Docker:

INSTALLATION REQUIREMENT:

• Docker
• git

INSTALLATION STEPS:

After installing docker and git Start the docker and follow the below types in terminal:

git clone https://github.com/rednaga/APKiD

cd APKiD/

docker-compose build

cd docker/

./apkid.sh ~/example/example.apk

it can scan APK, DEX, ELF file formats to detect the compilers.

USAGE:

STEPS TO SCAN THE APK:

• cd APKiD/

• cd docker/

• ./apkid.sh ~/example/example.apk

Here, I have scanned a vulnerable Apk called insecure bank application. As shown, below result is giving the details about its compiler, manipulator and its checking mechanisms.

CONCLUSION:

From this blog, we have discussed how we can detect the compilers, packers and obfuscators of an Android app through APKiD tool and also APKiD is developing a slack bot version of its tool which allows users to upload an APK file for analysing.

Briskinfosec provides the best mobile Security solutions. For further doubts and security, solution advice reach us@ Contact@briskinfosec.com

REFERENCE LINK:

https://github.com/rednaga/APKiD

AUTHOR

Dinesh C

Security Engineer

Briskinfosec Technology And Consulting Pvt Ltd.,

follow me @https://www.linkedin.com/in/dineshdinz/

HTML INJECTION ATTACK

HTML INJECTION ATTACK

INTRODUCTION:

HTML injection is an attack which occurs in web applications that allows users to insert an HTML tag attributes via using any specific parameters like,  <h>, </h1>, <td>, <tr>, <a href> tags are used as one of the sources to perform this HTML based injection attack.

These strategies provided with untrusted input, at that point there is a high risk of XSS, specifically an HTML injection one. If strings not sanitised efficiently, the issue could prompt XSS based HTML injection. This HTML injection could lead the attacker to modify the web content easily.

POSSIBLE ATTACK SCENARIO:

In this way, how we can perform an HTML injection attack using the following steps,

•  In this beginning process, an attacker can find the injection flaw and try to make an HTML injection attack.
• Attacker crafts the malicious links, including his infected HTML injection code and sends it to a client through an email
• When the client visits the web page because of the page located within a trusted domain
• The attacker can inject an HTML code is rendered and presented to the client requesting valid credentials like username and password
• The client enters a username and password, which are both sent to the attacker server.

HTML injection attack also have two different types, there are

• stored HTML injection attack
• Reflected HTML injection attack

STORED HTML INJECTION ATTACK

In this stored HTML is also known as persistence (always stored in the backend database), the attacker can give the credentials inserting in the web server it can be stored in permanently, and the application server gives out it to the user when the user visits the targeted website. Here I have to give a sample HTML code for the stored HTML injection.

When the client clicks the payload, it gets redirected to the official part of the website; the injected HTML code will get executed by the browser.

REFLECTED HTML INJECTION

The reflected HTML is known as Non-persistence (It does not store in the backend database, it will get immediately indicated). Whenever the backend server processes any HTML input without proper sanitisation and validation of the given HTML input,  it will lead to HTML injection in the web application.

Here I have to give the input like <h>you are hacked</h>, and it will reflect as ‘you are hacked “ class=” colourbox” title=” help me with page”>

MITIGATION FOR HTML INJECTION:

Here we used parameterised queries to block unwanted scripts for the HTML injection using special characters like <, >, “, ‘, %, &, / to appropriately sanitised in the given input fields. The favoured choice is to utilise a protected API which stays away from the utilisation of the translator entirely or provides a parameterised interface. Be careful of APIs, for example, put away methods, are parameterised.

If a parameterised API isn’t accessible, you should carefully escape unique characters utilising the appropriate escape grammar for that translator.

CONCLUSION:

HTML injection is similar to cross-site scripting vulnerability (XSS), which affects the client side. So, HTML injection can exploit in the same way as that of cross-site scripting which includes adding HTML data to the web application, temporary defacement of website etc… hence it is necessary to prevent web applications from HTML injection.

AUTHOR

Aravindan S

Security Engineer

BriskinfoSec Technology and Consulting  Pvt Ltd.,

https://www.linkedin.com/in/aravindhan-s-90b98787/

PCI-DSS VS ISO 27001 STANDARDS

PCI-DSS VS ISO 27001 STANDARDS

INTRODUCTION:

PCI-DSS and ISO 27001 are organized in sets of requirements for the cardholder data process. PCI-DSS has 12 sets of elements; there are about 250 controls based on securing credit card information. In ISO 27001, there are 11 sets of elements with 114 controls based on improving an ISMS, planning, running, implementing, monitoring. In this article, I’m going to discuss and examines the interoperability of PCI-DSS and ISO/IEC 27001 and also some of the pros and cons of the PCI-DSS and ISO/IEC 27001 standards.

PCI-DSS STANDARD:

PCI-DSS is a standard of data security for the credit card organizations, and it also applies only to companies that have the process, store, or transmit credit card data. Compliances with the standard are mandatory, though depending on the full range of cards processed. PCI-DSS is a card data security standard developed by a council consisting of Visa, MasterCard, American Express, Discover and JCB to protect the payment card and cardholder’s sensitive information processed by organizations.

ISO 27001 STANDARD:

ISO 27001 is a standard that includes seven main titles within the scope, such as organization, leadership, planning, support, operation, performance evaluation and improvement. It’s a worldwide recognition, which lays down the requirements for the establishment of an ISMS. It applies to any organization.

HIGH-LEVEL MAPPING OF PCI AND ISO27001
PCI-DSS REQUIREMENTS	ISO27001 CLAUSE
1. Install and maintain a firewall configuration to protect cardholder data.	A-12: Operations Security A-13: Communications Security
2. Do not use vendor-supplied defaults for system passwords and other security parameters.	A-12: Operations Security A-13: Communications Security
3. Protect stored cardholder data.	A-12: Operations Security A-13: Communications Security
4. Encrypt transmission of cardholder data across open, public networks.	A-14: System acquisition, development and maintenance.
5. Protect all systems against malware and regularly update antivirus software or programs.	A-14: System acquisition, development and maintenance.
6. Develop and maintain secure systems and applications.	A-14: System acquisition, development and maintenance.
7. Restrict access to cardholder data by business need to know	A-12: Operations Security A-13: Communications Security
8. Identify and authenticate access to system components.	A-12: Operations Security A-13: Communications Security
9. Restrict physical access to cardholder data.	A-11: Physical and environmental security
10. Track and monitor all access to network resources and cardholder data.	A-12: Operations Security A-13: Communications Security
11. Regularly test security systems and process.	A-14: System acquisition, development and maintenance A-6: Organization of Information security A-18: Compliance
12. Maintain a policy that addresses information security for all personnel.	A-5: Information security policies

COMPARISON OF PCI-DSS AND ISO 27001

It is recommended and required that both PCI-DSS and ISO27001 provides better solutions for risk management to Card data Industry and other organizations. The ISO 27001 is better than that of PCI-DSS standards as all the controls have been written at a high level. There are compliance levels in PCI-DSS to measure the maturity level of the company, but no compliance levels exist in ISO 27001. “The organizations have to determine the boundaries and applicability of the information security management system to establish its scope.” When comparing the scope of the two standards, scope selection in ISO/IEC 27001 depends on the company; however, the scope is exactly the credit cardholder information in PCI-DSS.

The controls in ISO 27001 are a suggestion to all the organizations, and also it is important to note that the controls in PCI-DSS standards are mandatory to payment and Cardholder data organizations.

Were the ISO 27001 contains more requirements than PCI-DSS, it is easier to comply with the ISO 27001 standard to the organizations.

According to the costs, establishing a partial (ISMS) audit and PDCA cycle which cost more to the organization as it a mandatory.

In an organization, the re certification auditing of ISO 27001 is performed in every three-year cycles, and internal scope auditing is conducted. There are also surveillance audits that are done at least once. In every PCI-DSS auditing, there are four network scanning audits and a Level 1 onsite audit.

MAPPING OF PCI-DSS AND ISO 27001
PARAMETER	ISO27001	PCI-DSS
Creator	ISO	PCI Council
Flexibility	High	Low
Scope	Depends on the company	Credit cardholders information
Controls applied	Flexible	Tight
Controls	High-Level	Low-Level
Compliance	Easy	Hard
Number of Controls	114	224
Auditing	Three-year cycles and a small-scope audit performed every year	Four network scanning audits and an onsite audit for level 1
Certification	Maybe given to all companies	Any companies that provide information security for critical paying processes
Compliance level	Does not exist	Exists

CONCLUSION:

PCI-DSS is a standard which handles Security for Cardholder data, whereas ISO 27001 is a specified to the Information Security and Management of the Organization. Mapping of PCI-DSS and ISO/IEC 27001 standards is optional information for managers who are assigned with ensuring to either standard in their organizations. It is recommended that PCI-DSS and ISO/IEC 27001 must be combined to give a better solution to risk mitigation and secure the organization of Cardholder data.

REFERENCE:

ISACA: https://www.isaca.org/

PCI-DSS: https://www.pcisecuritystandards.org/

ISO STANDARDS: https://www.iso.org/standards.html

AUTHOR

Dharmesh B

Security Engineer

Briskinfosec Technology and Consulting Pvt Ltd.,

https://www.linkedin.com/in/dharmeshbaskaran/