1. A7 – Insufficient Attack Protection
2. A10 – Under protected APIs

This blog discusses the first.

A7 – Insufficient Attack Protection

OWASP stated the reason for the addition as being:

For years, we’ve considered adding insufficient defenses against automated attacks. Based on the data call, we see that the majority of applications and APIs lack basic capabilities to detect, prevent, and respond to both manual and automated attacks. Application and API owners also need to be able to deploy patches quickly to protect against attacks.

An application must protect itself against attacks not just from invalid input, but also involved detecting and blocking attempts to exploit the security vulnerabilities. The application must try to detect and prevent them, log these attempts and respond to them.

What are some examples of attacks that should be handled?

• Brute force attacks to guess user credentials
• Flooding user’s email accounts using email forms in the application
• Attempting to determined valid credit card numbers from stolen cards
• Denial of service by flooding the application with many requests
• XSS or SQL Injection attacks by automated tools

A more complete list can here found here but the ways in which they are handled are all very similar.

Prevention

The first step is to prevent these types of attacks.

Consider using some built-in steps for preventing attacks to the application. This includes:

• Remove or limit the values of the data accessed using the application; can it be changed, masked or removed?
• Create use (abuse) cases that simulate automated web attacks.
• Identify and restrict automated attacks by identifying automation techniques to determine is the requests are being made by a human or by an automated tool.
• Make sure the user is authenticated and authorized to use the application.
• Consider using CAPTCHA when high value functions are being performed.
• Set limits on how many transaction can be performed over a specified time; consider doing this by user or groups of users, devices or IP address.
• Consider the use of web application firewalls that detect these types of attacks. Another alternative is using OWASP AppSensor or similar; it is built into the application to detect these types of attacks.
• Build conditions into your terms and conditions; require the user not to use automated tools when using the application.

Other items to consider to use include:

• Networks firewalls
• Load balancers
• Anti-DDoS systems
• Intrusion Detection System (IDS) and Intrusion Prevention System (IPS)
• Data Loss Prevention

Detection

An application must determine if activity is an attack or just suspicious.  The response must be appropriate based on which of these is true.

• Could the user have made a mistake when entering the data?
• Is the process being followed for the application or is the user trying to jump past steps in the process?
• Does the user need a special tool or knowledge?

If any two of the above items are true, then it is most likely an attack and not suspicious activity.

Is it possible that the requests are coming in at a very high rate? A typical user may make one request every couple of seconds, whereas a tool such as Burp Suite Pro or WebInspect may make many more requests per second. The application should also detect these types of attack or attempts to find vulnerabilities in the application.

Response

The application can handle detected attacks or even the suspicion of attacks in a variety of ways.

The first should be a warning to the user. This will deter a normal user that their activities are being monitored. It would also warn a malicious user that certain events are being monitored, though it will probably not deter the latter person.

The application could, based on further activity after the warning, either logout the user or lockout the user. If a logout is performed, automated tools can be programed to automatically re-authenticate the user. If lockout is chosen, then all activity will stop.

In any of the above cases, a legitimate user may end up calling the help desk, so the application must log this type of activity and notify the application’s administrators. The log must be reviewed to determine if the response was appropriate.

Choosing which action to perform would depend on the sensitivity of the data within the application. A public website must be more forgiving to prevent overreaction to suspicious activities; whereas an application with highly sensitive data must respond quickly to suspicious activity.

Conclusion

The OWASP Top 10 2017 A7 – Insufficient Attack Protection requires the application to prevent, detect, and respond to attacks. This could affect other regulations such as PCI, which base their standards on the OWASP Top 10.

References

• OWASP Top 10 2017:  https://github.com/OWASP/Top10/raw/master/2017/OWASP%20Top%2010%20-%202017%20RC1-English.pdf
• Insufficient Anti-automation: https://projects.webappsec.org/w/page/13246938/Insufficient%20Anti-automation
• OWASP Automated Threats to Web Applications: https://www.owasp.org/index.php/OWASP_Automated_Threats_to_Web_Applications
• OWASP AppSensor Project: https://www.owasp.org/index.php/OWASP_AppSensor_Project
• OWASP Automated Threat Handbook: https://www.owasp.org/images/3/33/Automated-threat-handbook.pdf

The post Application Self Protection – A New Addition to the OWASP Top 10 appeared first on NetSPI.

Many companies use OSS to develop their applications, but yet do not know what dangers exist in it. There may be legal ramifications stemming from the licenses that are being used by the OSS or security vulnerabilities that can exist in the software itself. Do you even know what OSS you are using in your application? Have your developers pulled the source into your application instead of using the binaries? If not, the first step is to find out what OSS you are using and what versions. The next step is to find out what license this software is using.

Licenses

There are many different open source licenses, some of them good (permissive) and some not so good. A “permissive” license is simply a non-copyleft open source license — one that guarantees the freedoms to use, modify, and redistribute, but that permits proprietary derivative works. As of last count, the Open Source Initiative (OSI) has 76 different licenses, some permissive and some not so permissive. There are also some that OSI does not recognize, such as the Beerware license. It says “As long as you retain this notice you can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return.  Poul-Henning Kamp”. This is considered a permissive license. Copyleft is a copyright licensing scheme where an author surrenders some, but not all rights under copyright law. Copyleft allows an author to impose some restrictions on those who want to engage in activities that would more usually be reserved by the copyright holder.

“Weak copyleft” licenses are generally used for the creation of software libraries, to allow other software to link to the library and then be redistributed without the legal requirement for the work to be distributed under the library’s copyleft license. Only changes to the weak-copylefted software itself become subject to the copyleft provisions of such a license, not changes to the software that links to it. This allows programs of any license to be compiled and linked against copylefted libraries such as glibc (the GNU project’s implementation of the C standard library) and then redistributed without any re-licensing required.

Copyleft licenses (GPL, etc.) become an issue if the OSS source is actually pulled into your application. The developers can do this without anyone’s knowledge, but would require you to release your source code. All of your intellectual property then becomes open source under that license.

The licenses on the OSS you are using can have many or few restrictions on your software. Make sure you are aware of the license(s) that is applied to each OSS you are using and have a lawyer review all of them.

What if you do not comply with the license? I am not a lawyer, but I believe if a company finds out you are using their software out of compliance with the license, you may end up with a lawsuit. In fact, the lawyer I was working with at a previous job was adamant that the company not use any copyleft software. He would not sign off on the software release unless it was free of copyleft software.

Security Vulnerabilities

As you are aware, all software has bugs and from a security perspective, the OSS you are using contains them as well. Over the last couple of weeks I was doing a web application penetration test and discovered that the software was using about 80 different open source libraries (JAR files). Among them were the Apache Commons Collections (ACC) and Apache Standard Taglibs (AST). Each of these have security vulnerabilities that are considered high risk (CVSS score of 7.5 or above). For example, ACC is vulnerable to insecure deserialization of data, which may result in arbitrary code execution.

If the application is using OSS that is out-of-date by many months or years, it may have undiscovered or unreported vulnerabilities. Older software tend to have security vulnerabilities that go undetected or unreported.

What vulnerabilities you allow in your software is up to your company policy, so you need to determine if you will allow the release of software that is old or contains security vulnerabilities.

Solutions

You can do research on each OSS you use. This means visiting the website for the OSS or opening up each JAR file and reviewing the license information. Make sure you track this because OSS can change licenses between releases. Under one version it could be released using the aforementioned BEER license and the next one could be under a copyleft license.

For security vulnerabilities, going to the vendors web site might give you some information, but also review the following:

• https://seclists.org
• https://www.cvedetails.com
• https://www.securityfocus.com
• https://www.osvdb.org/

Also consider using software to scan for these issues. The two that I am most familiar with are:

• https://info.blackducksoftware.com
• https://www.sonatype.com (CLM)

I am most familiar with CLM, which we installed in a previous company that I worked for; it discovered many issues in the OSS we were using in our products. The software teams had to scramble to fix the issues that were discovered. As I mentioned before, the lawyer did not allow the release of any software with certain licenses. They ended up either upgrading the OSS or removing it completely from the software.

The post Open Source Software – Is It the Death of Your Company? appeared first on NetSPI.

Fortunately, there are other options to GDB and extracting memory from an Apple iPhone running iOS 8+ could not be easier. It requires the following pieces of software.

• LLDB (https://lldb.llvm.org/)
• Debugserver (part of Xcode)
• Tcprelay.py (https://code.google.com/p/iphonetunnel-mac/source/browse/trunk/gui/tcprelay.py?r=5)

Of course you will need a jailbroken iPhone or iPad. I will not cover that part of the operation here.

Start tcprelay so you can connect to the device over a USB connection:

$ ./tcprelay.py -t 22:2222 1234:1234

Forwarding local port 2222 to remote port 22

Forwarding local port 1234 to remote port 1234

Incoming connection to 2222

Waiting for devices…

Connecting to device <MuxDevice: ID 17 ProdID 0x12a8 Serial ‘0ea150b00ba3deeacb42f399492b7990416a0c87’ Location 0x14120000>

Connection established, relaying data

Incoming connection to 1234

Waiting for devices…

Connecting to device <MuxDevice: ID 17 ProdID 0x12a8 Serial ‘0ea150b00ba3deeacb42f399492b7990416a0c87’ Location 0x14120000>

Connection established, relaying data

The command “tcprelay.py -t 22:2222 1234:1234” is redirecting two local ports to the device. The first one is used to SSH to the device over port 2222. The second one is the port the debugserver will be using.

Then you will need to connect to the iOS device and start the debug server (I am assuming you have already copied the software to the device). If not, you can use scp to copy the binary.)

$ ssh root@127.0.0.1 -p 2222

root@127.0.0.1’s password:

Then, if the application is already running, verify its name using ‘ps aux | grep <appname>’ and connect to the application with debugserver (using the name of the application not the PID):

root# ./debugserver *:1234 -a appname

debugserver-@(#)PROGRAM:debugserver  PROJECT:debugserver-320.2.89

for arm64.

Attaching to process appname…

Listening to port 1234 for a connection from *…

Waiting for debugger instructions for process 0.

The command ‘./debugserver *:1234 -a appname’ is telling the software to startup on port 1234 and hook into the application named ‘appname’. It will take a little time, so be patient.

On the MAC, startup LLDB and connect to the debugserver software running on the iOS device. Remember, we have relayed the device port 1234 that the debugserver is listening on to the local port 1234.

$ lldb

(lldb) process connect connect://127.0.0.1:1234

Process 2017 stopped

* thread #1: tid = 0x517f9, 0x380f54f0 libsystem_kernel.dylib mach_msg_trap + 20, queue = ‘com.apple.main-thread’, stop reason = signal SIGSTOP

frame #0: 0x380f54f0 libsystem_kernel.dylib mach_msg_trap + 20

libsystem_kernel.dylib mach_msg_trap:

->  0x380f54f0 <+20>: pop    {r4, r5, r6, r8}

0x380f54f4 <+24>: bx     lr

libsystem_kernel.dylib mach_msg_overwrite_trap:

0x380f54f8 <+0>:  mov    r12, sp

0x380f54fc <+4>:  push   {r4, r5, r6, r8}

Now you can dump the information about the memory sections of the application.

(lldb) image dump sections appname

Sections for ‘/private/var/mobile/Containers/Bundle/Application/F3CFF345-71FC-47C4-B1FB-3DAC523C7627/appname.app/appname(0x0000000000047000)’ (armv7):

SectID     Type             Load Address                             File Off.  File Size  Flags      Section Name

———- —————- —————————————  ———- ———- ———- —————————-

0x00000100 container        [0x0000000000000000-0x0000000000004000)* 0x00000000 0x00000000 0x00000000 appname.__PAGEZERO

0x00000200 container        [0x0000000000047000-0x00000000001af000)  0x00000000 0x00168000 0x00000000 appname.__TEXT

0x00000001 code             [0x000000000004e6e8-0x000000000016d794)  0x000076e8 0x0011f0ac 0x80000400 appname.__TEXT.__text

0x00000002 code             [0x000000000016d794-0x000000000016e5e0)  0x00126794 0x00000e4c 0x80000400 appname.__TEXT.__stub_helper

0x00000003 data-cstr        [0x000000000016e5e0-0x0000000000189067)  0x001275e0 0x0001aa87 0x00000002 appname.__TEXT.__cstring

0x00000004 data-cstr        [0x0000000000189067-0x00000000001a5017)  0x00142067 0x0001bfb0 0x00000002 appname.__TEXT.__objc_methname

0x00000005 data-cstr        [0x00000000001a5017-0x00000000001a767a)  0x0015e017 0x00002663 0x00000002 appname.__TEXT.__objc_classname

0x00000006 data-cstr        [0x00000000001a767a-0x00000000001abe0c)  0x0016067a 0x00004792 0x00000002 appname.__TEXT.__objc_methtype

0x00000007 regular          [0x00000000001abe10-0x00000000001ac1b8)  0x00164e10 0x000003a8 0x00000000 appname.__TEXT.__const

0x00000008 regular          [0x00000000001ac1b8-0x00000000001aeb20)  0x001651b8 0x00002968 0x00000000 appname.__TEXT.__gcc_except_tab

0x00000009 regular          [0x00000000001aeb20-0x00000000001aeb46)  0x00167b20 0x00000026 0x00000000 appname.__TEXT.__ustring

0x0000000a code             [0x00000000001aeb48-0x00000000001af000)  0x00167b48 0x000004b8 0x80000408 appname.__TEXT.__symbolstub1

0x00000300 container        [0x00000000001af000-0x00000000001ef000)  0x00168000 0x00040000 0x00000000 appname.__DATA

0x0000000b data-ptrs        [0x00000000001af000-0x00000000001af4b8)  0x00168000 0x000004b8 0x00000007 appname.__DATA.__lazy_symbol

0x0000000c data-ptrs        [0x00000000001af4b8-0x00000000001af810)  0x001684b8 0x00000358 0x00000006 appname.__DATA.__nl_symbol_ptr

0x0000000d regular          [0x00000000001af810-0x00000000001b2918)  0x00168810 0x00003108 0x00000000 appname.__DATA.__const

0x0000000e objc-cfstrings   [0x00000000001b2918-0x00000000001ba8d8)  0x0016b918 0x00007fc0 0x00000000 appname.__DATA.__cfstring

0x0000000f data-ptrs        [0x00000000001ba8d8-0x00000000001baf1c)  0x001738d8 0x00000644 0x10000000 appname.__DATA.__objc_classlist

0x00000010 regular          [0x00000000001baf1c-0x00000000001baf4c)  0x00173f1c 0x00000030 0x10000000 appname.__DATA.__objc_nlclslist

0x00000011 regular          [0x00000000001baf4c-0x00000000001bafa0)  0x00173f4c 0x00000054 0x10000000 appname.__DATA.__objc_catlist

0x00000012 regular          [0x00000000001bafa0-0x00000000001bafa4)  0x00173fa0 0x00000004 0x10000000 appname.__DATA.__objc_nlcatlist

0x00000013 regular          [0x00000000001bafa4-0x00000000001bb078)  0x00173fa4 0x000000d4 0x00000000 appname.__DATA.__objc_protolist

0x00000014 regular          [0x00000000001bb078-0x00000000001bb080)  0x00174078 0x00000008 0x00000000 appname.__DATA.__objc_imageinfo

0x00000015 data-ptrs        [0x00000000001bb080-0x00000000001e0d40)  0x00174080 0x00025cc0 0x00000000 appname.__DATA.__objc_const

0x00000016 data-cstr-ptr    [0x00000000001e0d40-0x00000000001e4420)  0x00199d40 0x000036e0 0x10000005 appname.__DATA.__objc_selrefs

0x00000017 regular          [0x00000000001e4420-0x00000000001e442c)  0x0019d420 0x0000000c 0x00000000 appname.__DATA.__objc_protorefs

0x00000018 data-ptrs        [0x00000000001e442c-0x00000000001e4ab8)  0x0019d42c 0x0000068c 0x10000000 appname.__DATA.__objc_classrefs

0x00000019 data-ptrs        [0x00000000001e4ab8-0x00000000001e4e48)  0x0019dab8 0x00000390 0x10000000 appname.__DATA.__objc_superrefs

0x0000001a regular          [0x00000000001e4e48-0x00000000001e6184)  0x0019de48 0x0000133c 0x00000000 appname.__DATA.__objc_ivar

0x0000001b data-ptrs        [0x00000000001e6184-0x00000000001ea02c)  0x0019f184 0x00003ea8 0x00000000 appname.__DATA.__objc_data

0x0000001c data             [0x00000000001ea030-0x00000000001ed978)  0x001a3030 0x00003948 0x00000000 appname.__DATA.__data

0x0000001d zero-fill        [0x00000000001ed980-0x00000000001edce0)  0x00000000 0x00000000 0x00000001 appname.__DATA.__bss

0x0000001e zero-fill        [0x00000000001edce0-0x00000000001edce8)  0x00000000 0x00000000 0x00000001 appname.__DATA.__common

0x00000400 container        [0x00000000001ef000-0x0000000000207000)  0x001a8000 0x00015bf0 0x00000000 appname.__LINKEDIT

The next step is to convert that output into LLDB commands to actually dump the data in those memory sections. You can probably skip the sections named zero-fill or code. For example, the take the following output:

0x00000003 data-cstr        [0x000000000016e5e0-0x0000000000189067)  0x001275e0 0x0001aa87 0x00000002 appname.__TEXT.__cstring

Into the LLDB command:

Memory read –outfile ~/0x00000003data-cstr 0x000000000016e5e0 0x0000000000189067 –force

This command is telling LLDB to dump the memory from address 0x000000000016e5e0 to 0x0000000000189067 and put it into the file 0x00000003data-cstr.

(lldb) memory read –outfile ~/0x00000003data-cstr 0x000000000016e5e0 0x0000000000189067 –force

You will (or should) not see any output from this command other that the file being created. Once you have all of the files, search them using your favorite search tool or even a text editor. Search for sensitive data (i.e. credit card number, passwords, etc. The files will contain information similar to the following:

0x0016e5e0: 3f 3d 26 2b 00 3a 2f 3d 2c 21 24 26 27 28 29 2a  ?=&+.:/=,!$&'()*

0x0016e5f0: 2b 3b 5b 5d 40 23 3f 00 00 62 72 61 6e 64 4c 6f  +;[]@#?..brandLo

0x0016e600: 67 6f 2e 70 6e 67 00 54 72 61 64 65 47 6f 74 68  go.png.TradeGoth

0x0016e610: 69 63 4c 54 2d 42 6f 6c 64 43 6f 6e 64 54 77 65  icLT-BoldCondTwe

0x0016e620: 6e 74 79 00 4c 6f 61 64 69 6e 67 2e 2e 2e 00 4c  nty.Loading….L

0x0016e630: 6f 61 64 69 6e 67 00 76 31 32 40 3f 30 40 22 4e  oading.v12@?0@”N

0x0016e640: 53 44 61 74 61 22 34 40 22 45 70 73 45 72 72 6f  SData”4@”EpsErro

0x0016e650: 72 22 38 00 6c 6f 61 64 69 6e 67 50 61 67 65 54  r”8.loadingPageT

0x0016e660: 79 70 65 00 54 69 2c 4e 2c 56 5f 6c 6f 61 64 69  ype.Ti,N,V_loadi

0x0016e670: 6e 67 50 61 67 65 54 79 70 65 00 6f 76 65 72 76  ngPageType.overv

0x0016e680: 69 65 77 52 65 71 52 65 73 48 61 6e 64 6c 65 72  iewReqResHandler

0x0016e690: 00 54 40 22 45 70 73 4f 76 65 72 76 69 65 77 52  .T@”EpsOverviewR

0x0016e6a0: 65 71 52 65 73 48 61 6e 64 6c 65 72 22 2c 26 2c  eqResHandler”,&,

0x0016e6b0: 4e 2c 56 5f 6f 76 65 72 76 69 65 77 52 65 71 52  N,V_overviewReqR

0x0016e6c0: 65 73 48 61 6e 64 6c 65 72 00 41 50 49 43 61 6c  esHandler.APICal

Have fun looking at the iOS application memory and use this process for only good intentions. As stated in the previously mentioned blog:

This technique can be used to determine if the application is not removing sensitive information from memory once the instantiated classes are done with the data. All applications should de-allocate spaces in memory that deal with classes and methods that were used to handle sensitive information, otherwise you run the risk of the information sitting available in memory for an attacker to see.

The post Dumping Memory on iOS 8 appeared first on NetSPI.

I thought it would be interesting to perform an automated code review on it using CheckMarx, to see how they did related to security. The source consisted mainly of C++ code (376,545 lines of code) as well as code written in assembler. The assembler code was not scanned because CheckMarx (or any other automated code scanners) does not support assembler. What came out of the tool was interesting.

CheckMarx indicated that the risk in the code is:

The distribution of risk from Informational to High:

You have to remember that this code is from the 1980s. Many people did not have a concept of secure code and the development tools did not address security at all.

The top five vulnerabilities are as follows:

From the code that I looked at, most of the issues come from the use of unsafe functions. For example:

	if (!strcmp(szClass, "BEGDATA")) 		strcpy(szNameSeg, "Data"); 	else 		strcpy(szNameSeg, szName); 	nSegCur = nSeg;

The function strcpy has been replaced by a safe function strncpy. The function strncpy combats buffer overflow by requiring you to put a length in it. The function strncpy did not exist in the 1980s. The code also contains 123 instances of the goto statement. For example:

LError:  		cmdRet = cmdError; 		goto LRet; 		} 	pdod = PdodDoc(doc);

From the MSDN web site, Microsoft states, “It is good programming style to use the break, continue, and return statements instead of the goto statement whenever possible. However, because the break statement exits from only one level of a loop, you might have to use a goto statement to exit a deeply nested loop.” I am not sure of the C++ syntax back in the 1980s, but maybe break, continue, and return statements did not exist.

You can get a copy of the code for both MS Word and MS-DOS from here: https://www.computerhistory.org/press/ms-source-code.html. Just remember there now are better ways to write code.

Below is the complete list of issues found in the code:

This code is a good example of what not to do.

Programming languages and tools have evolved to make your application much more secure, but only if you teach your developers the concepts of secure coding.

The post The Way Back Machine – Microsoft Word for Windows 1.1a appeared first on NetSPI.

What’s Been Added

Req. 3.4 Payment application must limit access to required functions/resources and enforce least privilege for built-in accounts:

• By default, all application/service accounts have access to only those functions/resources specifically needed for purpose of the application/service account.
• By default, all application/service accounts have minimum level of privilege assigned for each function/resource as needed for the application/service account.

Your application setup needs to make sure that it is using or setting the privileges needed to do the work and not grant excessive permissions. This is intended for built-in accounts as well as service accounts.

Make sure you have documented the permissions needed by any default or service accounts. The auditor will need to verify documentation against what was implemented.

Req. 5.1.5 –Payment application developers to verify integrity of source code during the development process

You need to make sure that any source control tools (i.e. Visual SourceSafe, etc.) is configured so that only the people that do development can make changes to the code. This does not preclude giving other users read access, but you need to minimize who has write access.

Req. 5.1.6 – Payment applications to be developed according to industry best practices for secure coding techniques.

You must develop the application with least privilege to ensure insecure assumptions are not introduced into the application. To prevent an attacker from obtaining sensitive information about an application failure including fail-safe defaults that could then be used to create subsequent attacks. You must also ensure that security is applied to all accesses and inputs into the application to avoid an input channel being left open to compromise.

This includes how the sensitive data and the PAN is handled in memory, the PCI Council it trying to prevent capture of this data by screen scrapping. Try to encrypt this data in memory and keep it there only for a short period of time.

Req. 5.2.10 – Broken authentication and session management

You need to make sure, in your web application, that:

• Any session cookies are marked as secure.
• The session is never to be passed on the URL. This would allow them to be logged in the web server.
• The web application must time out the session after a certain number of minutes. Once timed out, the user must re-authenticate to get access to the application.
• The session id must change when there is a change in permissions. For example, a session id is set when an anonymous user accesses the login page and after successful authentication, the session id must change to a different value.
• If a user logs out of the application, you need to delete the session on both the client and the server.

Req. 5.4 – Payment application vendors to incorporate versioning methodology for each payment application.

This is not a change in the way you write your code but a process change and, like so many other requirements, has to be documented both internally and in the Implementation Guide. Many companies already do this but make sure you have a defined method of changing the version numbers.

• Details of how the elements of the version-numbering scheme are in accordance with requirements specified in the PA-DSS Program Guide.
• The format of the version-numbering scheme is specified and includes details of number of elements, separators, character set, etc. (e.g., 1.1.1.N, consisting of alphabetic, numeric, and/or alphanumeric characters).
• A definition of what each element represents in the version-numbering scheme (e.g., type of change, major, minor, or maintenance release, wildcard, etc.)
• Definition of elements that indicate use of wildcards (if used). For example, a version number of 1.1.x would cover specific versions 1.1.2 and 1.1.3, etc.
• If an internal version mapping to published versioning scheme is used, the versioning methodology must include mapping of internal versions to the external versions
• You must have a process in place to review application updates for conformity with the versioning methodology prior to release.

Req. 5.5 – Risk assessment techniques (for example, application threat modeling) are used to identify potential application security design flaws and vulnerabilities during the software-development process. Risk assessment processes include the following:

• Coverage of all functions of the payment application, including but not limited to, security-impacting features and features that cross trust-boundaries.
• Assessment of application decision points, process flows, data flows, data storage, and trust boundaries.
• Identification of all areas within the payment application that interact with PAN and/or SAD or the cardholder data environment (CDE), as well as any process-oriented outcomes that could lead to the exposure of cardholder data.
• A list of potential threats and vulnerabilities resulting from cardholder data flow analyses and assign risk ratings (for example, high, medium, or low priority) to each.
• Implementation of appropriate corrections and countermeasures during the development process.
• Documentation of risk assessment results for management review and approval.

What the PCI Council wants is to make sure that risks in your application are assessed appropriately and that the process covers all aspects of your application including any third party tools (DLLs, etc.).

You will need to document the threat modeling you have done against your application. If you have never done one or are unsure how to do it, Microsoft has a good process and provides a free tool. The out this page for more information: https://msdn.microsoft.com/en-us/library/ff648644.aspx

Req. 5.6 Software vendor must implement a process to document and authorize the final release of the application and any application updates. Documentation includes:

• Signature by an authorized party to formally approve release of the application or application update
• Confirmation that secure development processes were followed by the vendor.

Make sure to record the approval of the release of the software and patches. This is to confirm that your secure development processes were followed.

Req. 7.3 – Include release notes for all application updates, including details and impact of the update, and how the version number was changed to reflect the application update.

Make sure you are publishing your release notes and that they include the customer impact.

Req. 10.2.2 – If vendors or integrators/resellers can access customers’ payment applications remotely, a unique authentication credential (such as a password/phrase) must be used for each customer environment.

This one is simple enough; your support people cannot use the same password to access different customers. Avoid the use of repeatable formulas to generate passwords that are easily guessed. These credentials become known over time and can be used by unauthorized individuals to compromise the vendor’s customers.

Req. 13.1.1 – Provides relevant information specific to the application for customers, resellers, and integrators to use.

The Implementation Guide must state the name and version for the software it is intended for. It must also include the application dependencies (i.e. SLQ Server, PCCharge, etc.)

Req. 14.1 – Provide information security and PA-DSS training for vendor personnel with PA-DSS responsibility at least annually

These training materials are for your personnel involved in the development and support of your application. The materials must be about PA-DSS and information security.

Req. 14.2 – Assign roles and responsibilities to vendor personnel including the following:

• Overall accountability for meeting all the requirements in PA-DSS
• Keeping up-to-date within any changes in the PCI SSC PA-DSS Program Guide
• Ensuring secure coding practices are followed
• Ensuring integrators/resellers receive training and supporting materials
• Ensuring all vendor personnel with PA-DSS responsibilities, including developers, receive training

You must assign one or more people to be responsible for meeting the requirement in PA-DSS. This person must keep up to date on the changes in PA-DSS as well as make sure the requirements are met.

Ensure that each person or persons’ responsibilities are documented.

What’s Been Removed

Req. 2.4 – If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control mechanisms (for example, by not using local user account databases). Decryption keys must not be tied to user accounts.

All of the PA vendors I worked with did not do disk encryption but use file, table/column encryption. It makes sense to remove this requirement. In addition, disk encryption is only effective at preventing data loss due to physical theft, which is not a significant concern in the majority of datacenters.

What’s Been Significantly Changed

Req. 3.3.2 – Use a strong, one-way cryptographic algorithm, based on approved standards to render all payment application passwords unreadable during storage. Each password must have a unique input variable that is concatenated with the password before the cryptographic algorithm is applied.

It appears that encrypting the password is no longer acceptable. In your application, you must use a strong, one-way cryptographic algorithm (hash) as well as a salt value. Review your application storage to make sure that you are using a hashing algorithm with a salt. They do note that the salt does not have to be unpredictable or a secret.

Req. 4.2.5 – Use of, and changes to the application’s identification and authentication mechanisms (including but not limited to creation of new accounts, elevation of privileges, etc.), and all changes, additions, deletions to application accounts with root or administrative privileges.

Any changes to accounts in the application must be audited.

The post PA-DSS 3.0 – What to Expect appeared first on NetSPI.

In any development process, either in-sourced or out-sourced, security needs to be considered. The developers need to be trained in secure coding techniques, and the architects have to have some training and experience on implementing security throughout the software development life cycle. In fact, these should never be excluded or glossed over. The development company you are considering needs to prove this and these requirements must be written into the contract. Have them show you the classes that these people have taken, and make sure they are up-to-date on the latest security vulnerabilities. You cannot have a developer take a course five years ago and consider their skills current.

What about after the code is completed? Do your contracts specify a security review? Both an application penetration test and code review must be done before the release of the application. The contract must also specify that any security vulnerabilities must be mitigated. It must also specify that the test will repeat until all high and medium level vulnerabilities are mitigated. Also, have the security testing done by your own company or a third party. It does not matter where the developers are from; it could be India, China, or the United States, there are bad or malicious programmers out there and you must trust them but verify their work.

The post Outsourcing application development – what is missing? appeared first on NetSPI.

The QSA who performed their last PCI audit should not have passed them because this vulnerability is in violation of Requirement 6.5.6. The requirement states:

Prevent common coding vulnerabilities in software development processes, to include all “High” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.2).

Please note, according to PCI Requirement 6.2, a CVSS score of 4 and above is considered to be a “High” risk vulnerability.

Because of this vulnerability and because the company has not fixed it, they could be fined by their bank. Furthermore, this vulnerability could pose financial liability and reputation risk for the company. If customers find out about this vulnerability, they may question the company’s ability as a trusted vendor.

So why did the previous QSA pass them? Without discussing this with the QSA, one can assume that since the issue was closed, it was fixed. You have to remember that when the auditor is performing the audit, they are presented with a lot of information. This is a lot like trying to drink from a fire hose.  Things like this vulnerability could have been missed; it was one finding out of many or possibly the auditor assumed that since the finding was closed, that it had been remediated.  Another reason may be the way an auditor interprets the PCI Requirements. This person may not have understood the requirement and made the wrong interpretation.  In many cases, one auditor’s interpretation may be different from another auditor.

It does not really matter now, why the company passed their audit, even though they did not fix the vulnerability.  The issue now is that they need to fix it before moving forward.

The post Why does one QSA pass me and another would not? appeared first on NetSPI.

6.3.2 Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability. Note: This requirement for code reviews applies to all custom code (both internal and public-facing), as part of the system development life cycle. Code reviews can be conducted by knowledgeable internal personnel or third parties. Web applications are also subject to additional controls, if they are public facing, to address ongoing threats and vulnerabilities after implementation, as defined at PCI DSS Requirement 6.6.

NetSPI has reviewed and used a number of automated scanning tools. These tools include HP’s Fortify SCA, Ounce Labs (now part of IBM’s Appscan toolset), Veracode, and Checkmarx. These tools do a fine job for what they were built for, performing an automated scan of the source code. All of these tools meet the 6.3.2 requirements, but they simply are not enough. The tools are missing many of the problems that the manual review finds, such as authentication and authorization vulnerabilities, among others. In addition, many companies are providing software as a service (SAAS) solutions for code reviews. By using this service, a company meets the requirement. These services make it easy to do the code reviews; you upload the binaries and in a few days, you get a report with many findings. So now what do you do with this report? Many organizations throw the report back at the developers and say “fix it”. The developers look at the overwhelming number of findings and start applying resources to fix them. What many companies have experienced is that these reports contain so many false positives that the developers just give up. Are you really meeting the requirement? Of course you are, but how many vulnerabilities are you missing? Based on what NetSPI has experienced, maybe half of them.

The post Code Review – is automated testing enough? appeared first on NetSPI.

• Do you know if the developers, either internal or third party, have put a back door in the application?
• Do you know if your application is storing passwords or keys on its file system in the clear?
• How about someone putting a malicious application on the Google or Apple stores and this application starts collecting this information?
• How would your companies reputation be changed because of this, once it gets out to the press?

At a minimum, have the application tested by someone not involved in the development of the application; this can be internal personnel or an external company. At best, have the application and code reviewed for security flaws. What are your reasons you are not doing this? We do not know how We do not have the manpower There is not enough time These are just excuses. Learn the processes, call a company (such as NetSPI) to do the testing for you, but get it done and get it secured.

The post Mobile Application Testing – Where is it? appeared first on NetSPI.

The post Oracle’s stealth password cracking vulnerability appeared first on NetSPI.