Jeff

view

PCI 4.0 Requirement 6.4.3 and 11.6.1

TL;DR

PCI 4.0 “best practices” 6.4.3 and 11.6.1 become requirements starting after March of 2025. While the language of those requirements is pretty straightforward, meeting those requirements might be a bit of a discussion between you and your auditor. I aim to shed some light on that, as best I can, and hopefully help you have that discussion.

⚠️DISCLAIMER⚠️

This is just my opinion. Beyond some time in the saddle doing security work (red and blue) and having a few audits under my belt, this is all just “Jeff's Opinion” on the subject. Your mileage may vary.

The Gory Details

If you're still reading this, you're a glutton for punishment, or worse, you're into this sort of thing. Lets get the ugliest bit out of the way right up front, the actual requirements:

6.4.3

All payment page scripts that are loaded and executed in the consumer's browser are managed as follows: • A method is implemented to confirm that each script is authorized. • A method is implemented to assure the integrity of each script. • An inventory of all scripts is maintained with written justification as to why each is necessary.

11.6.1

A change- and tamper-detection mechanism is deployed as follows: • To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser. • The mechanism is configured to evaluate the received HTTP header and payment page. The mechanism functions are performed as follows: – At least once every seven days OR – Periodically (at the frequency defined in the entity's targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).

My Opinion

I'm going to rephrase those in plain language and give some suggestions.

The Requirements (As Written) And What To Do About Them

6.4.3: This focuses on scripts on the payment page(s). You need to have a document that: • Lists every script on your payment page(s) • Explains why it is there • Validation that scripts aren't EOL'ed, have any CVE's, and are served via TLS from a trusted source. • For open source project scripts, a trusted source may require you to do a targeted risk assessment to support why you trust it. • Someone with some authority has reviewed and approved the above

Here are some things you can do to support your due diligence: • Run known/named scripts through a tool like Retire.js to see if common scripts are EOL or have vulnerabilities. (This is good for things like React, jQuery, etc.) • Check unknown javascript to see if they are bundled using a tool like Bundle Scanner. This will tell you if the script is a “bundle” of more than one common library, and what those are. You'll need to evaluate each of those individually. • Run the hashes of all scripts on your page against tools like VirusTotal and Hybrid Analysis to see if there are any detections from common AV engines.

11.6.1 This requirement basically ensures that you are validating the above regularly, and someone will be notified if the status changes. For this, there are a couple approaches: • Buy something that does this for you. • Build something that does this for you.

I won't go into products that will do this for you, but I'm positive someone out there will happily take your money. Hopefully after reading this you are better prepared to evaluate paid solutions. If they aren't detecting bundled scripts, skip it. That is, in my opinion, the most likely avenue for a supply chain problem.

The simplest DIY solution is to make a script that checks expected page headers and evaluates included scripts against the trusted list you created (and vetted) above, and alerts you if something new pops up or changes. Run that once a week, or as often as you decided in your TRA.

NOTE: The 11.6.1 requirement as it is currently written states as received by the consumer browser and evaluate the received.... This is worth noting because it specifically does not require things like dynamic analysis, sandboxing, DOM monitoring, etc. Those are great ideas, and you should know everything you can about what is running on your payment pages, but 11.6.1 does not currently require it.

Final Thoughts

My goal in this isn't to get you out of doing anything you should be doing. You should be taking every possible precaution to protect your payment pages. But, new requirements can lead to “blue sky thinking” and “inferred requirements”. Hopefully the above helps you to do the right thing without too much extra nonsense.

view

Over The Wire Natas Hints and Spoilers

This is a list of hints and spoilers for the Natas challenge from Over The Wire that I wrote up for some internal training. If you somehow found your way here, I hope this is helpful. I have notes through 25, I just haven't written them up in a Hint/Spoiler format. I'll call that a TO DO for the future.

Natas 0

Hint 1

View source is your friend.

Natas 1

Hint 1

Same as before, but this time they added some nonsense “right click” protection that probably doesn't even work.
View source and/or your browsers developer tools are your friend.

Natas 2

Hint 1

There's an image file, but what else lives in that “files” folder?

Spoiler 1

Try this: http://natas2.natas.labs.overthewire.org/files/

Natas 3

Hint 1

There's a clue in the source.

Hint 2

How would you tell a search engine where it shouldn't go?

Hint 3

Where would the “robots” look?

Natas 4

Hint 1

How would a page know where you're coming from? And, can you control that?

Hint 2

The “Copy as cURL” option in your browsers developer tools might help.

Natas 5

Hint 1

Spoiler 1

There's a cookie named “loggedin”. What can you do with that?

Natas 6

Hint 1

They have shared the source code for the page. What is it checking the secret value against?

Hint 2

Blank pages aren't always empty, remember to view the source.

Spoiler 1

Try this: http://natas6.natas.labs.overthewire.org/includes/secret.inc.

Natas 7

Hint 1

Look at the links for “Home” and “About”. They end with ?page={something}, like so: http://natas7.natas.labs.overthewire.org/index.php?page=home. Try replacing {something} with common file paths like “/etc/hosts” and see if you can dump files from the web server.

Hint 2

On the main Natas page they mention where the level passwords are stored.

Natas 8

Hint 1

View the source code. You can see the secret and the steps used to encode it.

Hint 2

You can use Cyber Chef to decode the secret.

Spoiler 1

CyberChef: “encodedSecret” –> From Hex –> Reverse –> From Base64

Natas 9

Hint 1

View the source code and look at how the search term is used.

Hint 2

The PHP passthru function executes OS commands. Can you chain commands and see the output?

Spoiler 1

Try using something like “aloof dictionary.txt; cat /etc/hosts;” or “aloof dictionary.txt && cat /etc/hosts;”. Are there more useful files you can try to retrieve?

Natas 10

Hint 1

View the source code. They took away some of the characters we can use. ([;|&])

Hint 2

The solution you likely used on Natas 9 might not work anymore because of the characters they're flagging on. They essentially blocked chaining commands. Can we read the password file only by manipulating the grep command they are using?

Hint 3

Can you get grep to return the whole contents of a file?

Spoiler 1

Try “-E “^” /etc/hosts #”.

Natas 11

Hint 1

Hint 2

The cookie contains a value, but it isn't usable plaintext. View the source and take note of the xor_encrypt and saveData functions. They show you how the cookie value was derived. We don't know the key, so we'll need to find a way to derive that from what we know.

Hint 3

With XOR, there are 3 pieces of information. The plaintext, the key, and the encrypted text. XOR-ing any two of those together will give you the third value. We can also brute force the key with a tool like this. Use the option for “Knowing the key size (in bytes)”, and start with 1 and work your way up. After each round finishes, search for “bgcolor” since we know that string will be in the properly decrypted JSON. (Note that the key value will be in HEX. Cyber Chef can help you convert that.) Alternately, you could use a tool like this to derive the plaintext of the cookie and use that to recover the key. Using the plaintext in CyberChef:

Spoiler 1

Now we know the cookie structure and the XOR key. We need to change the value of showpassword to reveal the password. This will require us to take the info from above and reverse it to get a new cookie value.

Spoiler 2

Spoiler 3

Edit the cookie value, using the new one, and refresh the page.

Natas 12

Hint 1

They're going to let us upload a file. (That can't possibly go wrong.) Maybe we can upload a PHP file.

Hint 2

By default, it changes the extension to .jpg. View the sourcecode and page source to see how you might be able to change that.

Hint 3

Using a PHP include statement, you can include the contents of other files on the filesystem.

Spoiler 1

In the HTML form, there's a hidden value called “filename”. The PHP backend uses the extension in that value to set the extension when it stores the file.

Spoiler 2

<?php include '/etc/natas_webpass/natas13'; ?>

Natas 13

Hint 1

This is the same as above, except they took an extra step to protect from uploading non-image files.

Hint 2

They are checking the “magic number” at the beginning of the file, using the PHP function “exif_imagetype”. We'll need to add that to our uploaded PHP file to fool this check.

Spoiler 1

This page specifically addresses how to add the “magic number” to your PHP file.

Spoiler 2

Don't forget to edit the hidden value that sets the extension like we did in Natas 12.

Natas 14

Hint 1

View the sourcecode. First item of interest is that there is a “debug” flag that shows your query. That could be handy.

Hint 2

You can add that debug flag to the HTML form action. NOTE: This trick works on many of the exercises from here on, so keep that in mind because I won't mention it again. Probably.

Hint 3

Now that we can see our query, we can see if we can manipulate our input to change our results. This is a (very) basic example of SQL Injection.

Hint 4

Can we change the query so that it is guaranteed to return something?

Spoiler 1

Using the sourcecode and/or trial and error with the debug flag, what would you need to input to get a query like “SELECT * from users where username=“natas15” and password=“” OR “1” = “1””?

Spoiler 2

Try: ” OR “1” = “1