Malicious NPM Package - Does it fit into OWASP Top Ten 2017? On various security forums I have seen links to a post about a fictive malicious NPM package harvesting information. The posts title:

  I’m harvesting credit card numbers and passwords from your site.
  Here’s how.

The best quote in the post in my opinion:

  Lucky for me, we live in an age where people install npm packages like
  they’re popping pain killers.

This led to a discussion at our company whether or not a malicious NPM Package would fit into OWASP Top Ten 2017 or not. I think it could fit into the following categories:

A6:2017-Security Misconfiguration
The description says: "Not only must all operating systems, frameworks, libraries, and applications be securely configured...". If you have a malicious library that can do something because your CSP is not configured correctly for example I would have it fall under this category.
A7:2017-Cross-Site Scripting (XSS)
If the library enables an XSS vulnerability it would fall under this category.
A9:2017-Using Components with Known Vulnerabilities
If the library is known to be malicious it would fall under this category.
A10:2017-Insufficient Logging&Monitoring
If the attack is not detected it means we are not logging enough. There are various libraries for logging Client-Side JavaScript and outgoing requests could be checked here. Of course the malicious library could try to disable this but it could still fall under this category.

Is this correct or is a malicious NPM package outside the scope of OWASP Top Ten 2017?

It seems clear to me that a maliciously coded library is perfectly covered by A9:2017-Using Components with Known Vulnerabilities. I thought that A9 was created for this very use case.

Although the wording from OWASP talks about older libraries that have vulnerabilities discovered over time (Heartbleed) and replaced, there is nothing in the wording that suggests that this must be the reason for the vulnerability. Intentional malicious coding works just as well as a reason.

A debate might arise over whether or not "malicious coding" can be equated to a "vulnerability" since the malicious code could be working as intended without unintended effects. I think this debate is a little pedantic and the spirit of the OWASP Top 10 is supported by equating the two ideas.

Maliciously coded libraries are not a "misconfiguration". A misconfigured library is one that is not vulnerable, per se, but introduces vulnerabilities due to misuse.

Maliciously coded libraries could introduce XSS vulnerabilities, but A7 is too specific in this case.

Insufficient Logging and Monitoring is a meta issue that affects all potential situations and is too broad to be applicable to this threat scenario.


What could MitM'ed U2F do? Google has now released their "Titan" keys to the general store (albeit via a waitlist). When they first announced their product, Yubico, their chief competitor, decried the use of Bluetooth:

  Google’s offering includes a Bluetooth (BLE) capable key. While Yubico previously initiated development of a BLE security key, and contributed to the BLE U2F standards work, we decided not to launch the product as it does not meet our standards for security, usability and durability. BLE does not provide the security assurance levels of NFC and USB, and requires batteries and pairing that offer a poor user experience.

This aspersion came some time after revelations of a flaw in the Bluetooth stack, namely the Blueborne vulnerability.

However, if U2F relies on Public Key Cryptography, does it matter if someone can see every part of the data exchange? I thought that was part of the point of U2F.

I do not worry about an evil ISP intercepting my HTTPS connections; should I worry about an evil bystander when I use U2F over Bluetooth?
If not, is Yubico concerned about compromise of the U2F device itself, or are they just throwing Fear, Uncertainty, and Doubt (A.K.A. "FUD") at a competitor's product?

If the transport security between the User Agent and the Authenticator is broken there are some (debatably minor) issues:

The AppID is disclosed when you log into a site (this is usually the domain of the site)
If the attacker is nearby and knows your password he might be able to submit the token's signature of the website's challenge before you (depending on the server's implementation this might also require him to know your session cookie, which seems unlikely)
An attacker might be able to submit his own challenges to your token, which if timed properly (i.e. right before you submit your own challenge) could allow him to log in (again assuming he knows your password)


What tools exist to help me monitor OCSP certificate validation failures? The discussion at Why isn't OCSP required by default in browsers? notes that many browsers by default simply ignore failure to check web site TLS certificate revocation status via the Online Certificate Status Protocol (OCSP).

Is there a simple way (e.g. a tool) for users who care about it, or are just curious, to monitor OCSP requests and detect or log when connections fail?  E.g. a browser extension would be handy.

I'm curious about all the popular platforms and browsers.

Update: Poking around a bit more found this explanation of the basic OCSP flow and how to do it step-by-step with openssl: OCSP verification with OpenSSL.

-----BEGIN WHINE-----
back in the good old days before HTTP became a crufty swiss army knife, I'd just have to capture all packets for the "OCSP port".  But no - OCSP is layered on top of HTTP, so I need more than a simple pcap-based tool: I need to figure out which HTTP URLs out there are OCSP-related, and parse the more wordy conversations....
-----END WHINE-----

Most of my experience lately has been with the Tumbleweed Desktop Validator (now Axway?)- it'll plug into browsers as well as work standalone with a bunch of configuration options.  It checks OCSP and pops up a warning when something bad has happened.  I think you can configure it to deny access as well.

It's not the only product, just the one I've worked with most recently and most heavily.  Many of the OCSP server makers have a client side offering, since it's just the other half of the equation.  I'm afraid I don't know of any free ones.


How to test dmarc in a closed environment? I would like to setup email authentication for my company Exchange server. Since this is production I don't want to break something. I want to test this first in virtual machines and when I am sure it works fine, I can then deploy it on the production server.

I have a VirtualBox (windows server 2016) with Exchange 2016 installed. Can I deploy my spf, dkim and dmarc on this Windows so that I am confident that every thing works properly before going to prod?

Does my idea make sense (I new in this technologies)?

For testing your DMARC for your own domain, there is no need to deploy in a test environment. It comes with a built-in pre-prod testing function.

Set your config to:
p=none pct=100 and set up the reporting emails to review for a month. This has 0 impact on the receipt of emails from your domain, but you get error reports.

Then, once you have fixed the various issues:
p=quarantine pct=10

This sets the policy to quarantine but only for 10% of the emails each receiver gets (the rest are p=none). As you get error reports (and user feedback), you slowly increase the pct to 100, then switch to

p=reject pct=10

and slowly ramp that up.


How expensive is it to guess a 15 character password, and should I be worried? I'm currently using AES encryption (at home) on GNU/Linux (one of LUKS AES-256 variants with xts) and on Windows 7 (Truecrypt) with a 15 characters password (alphanumeric lowercase only plus _).

Should this be enough or would it be better to change towards a longer password. How long should it be? Recently viewing the results with GPU cracking I got a little worried. The thing is that I don't want to choose a password so long so that I'd forget it and get locked out.

A quick calculation:

First my assumptions:

I assume the attacker has $1,000,000 to spend over the course of two years. He's using standard graphics cards, and pays 10ct/kWh.

I assume that the KDF consists of 2*n SHA256 invocations, where n is the iteration count, and can be implemented with similar efficiency on graphics cards as plain SHA256. 1

A current graphics card gives around 6MHash/s/$ and around 4MHash/J. 2

Calculation

Electricity cost for 1 Hash: ($0.10/kWh) / (4MHash/J) = 7*10-15 dollars
Hardware cost for 1 Hash: 1 / (6MHash/s/$ * 1yr) = 5*10-15 dollars
Total cost for 1 Hash: 1.2 * 10-14 dollars
Hashes for 1 Dollar: 8*1013
Hashes for 1,000,000 Dollars: 8*1019

This corresponds to a 66 bit password, protected with plain SHA256. TrueCrypt uses PBKDF2 with 1000 iterations, which gives us a factor 2000 bonus, so we can subtract 11 bits, and we arrive at 55 bits.

Conclusion

An attacker willing to spend one million dollars can crack TrueCrypt passwords up to 55 bits of entropy. Estimate the value of your secrets, and adjust it appropriately.

A sophisticated attacker might use custom hardware, which would make the attack even cheaper. But I don't have any numbers at hand for how much energy custom hardware requires per hash.

A completely random password of length 15 chosen from 37 different characters has an entropy of 78 bits, and thus is safely out of range for graphics card based attacks. Note that this only applies if the password is completely random. If it has some exploitable structure, such as words or keyboard patterns, the entropy might be considerably lower.

1 PBKDF2 uses 1HMac per iterations, which in turn has 2 hash invocations

2 I base this on Bitcoin Mining hardware comparison using that one bitcoin hash consists of 2 SHA256 invocations.


Is encryption less resistant to brute-forcing compared to hashing? I understand that a hashing algorithm like bcrypt uses several rounds of hashing to make it computationally expensive for a brute-force attack. How does encryption work against a brute-force attack? I was wondering if a stolen encrypted file such as one encrypted with GnuPG can be cracked much much faster than a bcrypt hash of the same password assuming it is 10 char long using A-Za-z0-9!~?

To encrypt a piece of data, you need an encryption key. An encryption key has to be a long, random string. Passwords do not fit this criteria. So if you want to use a password as an encryption key, you need to use a key derivation function. Strong password hashing algorithms like pbkdf2, bcrypt and scrypt are key derivation functions.

So to answer your question, it depends. It depends on which KDF the application is using to stretch the password into an encryption key. GnuPG does use a KDF function (controlled by the --s2k-* set of flags).


Why do password requirements exist while limiting the upper character count? I do not quite understand why it is common practice to require a difficult to remember password with alphanumeric and special character requirements, while also having an upper limit of 32 characters. Wouldn't it be easier for everyone to remember the password if the lower character requirement was 32 and there was no requirement for special characters, numbers, and capitalization?
The fact that dictionary attacks exist means that the different character requirements are mostly useless anyways; many people just prepend or append a number or special character to a short password, or use substitutions such as "leet speak".

Cargo Cult
It is no secret that a lot of people who are tasked to design security for systems know very little about information security and are ill equipped for the task. As a source for that claim, I will take years of personal experience as pentester, and the absolute bewilderment for the things I have seen people develop over the years. Not because the developers are bad developers - on the contrary - but because information security has different requirements than normal software development. It's like asking a painter to paint a blueprint of a house.
As such, developers who lack the understanding of what is required of a system that handles authentication and authorization often fall back to the most primitive form of learning: Imitation. We see other people do things, and without understanding why these things are done, we imitate them. "After all, it's done that way for a reason." This process has a name: Cargo Cult Programming.
Originally, cargo cults were cults of tribespeople, who saw modern soldiers receive air cargo with supplies. They thought that this air cargo was a gift from a divine entity, and that the activities of the soldiers were a ritual to summon said entity to bring gifts. As a result, after the soldiers had left, the tribespeople began to immitate their activities to the best of their understanding, making makeshift uniforms and marching up and down, in hopes that this would summon some divine favour.
Cargo Cult Programming is a similar process, in which some developer does something in a particular way, due to some circumstance. The other programmers then blindly implement their solution in the same way, without understanding why the solution was implemented in said way, and what problem it aimed to solve.
About Password Lengths
For example, "DES crypt" would only allow for a maximum of 8 bytes for password length due to export restrictions - which was primarily a legal problem. So any system that used DES crypt would require a maximum character length of 8. Someone who saw this implemented may not know the reason why 8 was chosen for this, and may blindly copy this implementation, possibly not even using DES crypt in the background. So they are not limited by a maximum password length of 8, yet still arbitrarily impose it, simply because they have seen someone else do the same thing.
Misinformation
As for why companies require short, complex passwords rather than long, easy-to-remember phrases? That one is unfortunately on us. For a very long time, security experts tried to get people to make "better" passwords. And in a sense, it's true: <3BZg2Ck is a better password than ILoveNYC.
However, security experts are not infallible and we too learn painful lessons, such as AviD's Rule of Usability:

Security at the expense of usability comes at the expense of security.

Short, highly complex passwords are really difficult to remember for people, and people started to use "systems to make good passwords", like tGbHuJm! (I'll leave it up to the reader to figure out why this is a bad password). Experts changed their advice, instead advocating for long passphrases, like It's monday again and the coffee still tastes like wet socks, but "common wisdom" is difficult to change. When people hear that passphrases should be complex, they see the half-truth how a complex password is better than a simple one, and urge their users to make passwords as complex as possible.
Recommendation
In a system that requires passwords, users should be urged to use a password manager to create a safe, new password. A sufficiently long, randomly generated password will always beat any long, easy-to-remember passphrase, and it's more easily usable too if the browser automatically fills it in for the user.
If that is not a possibility, users should be urged to make long passphrases. Phrases are generally easier to remember for people, and length is king when it comes to strength. However, users can stick to phrases that are publicly known and not secure at all, such as In the beginning God created the heaven and the earth. - any automated check will tell you that this is an amazing password, but my wordlist on my cracking machine will beg to differ. As such, you can try to generate a memorable sentence for the user, or just believe that they know what they are doing.
Finally, after a user has entered a passphrase, it is recommended to check that passphrase with a database like Have I Been Pwned? to ensure that password isn't already known to be insecure.


Secret Santa implementation that does not require a participant to trust the server In the Christmas spirit I read Cryptographic Secret Santa from MathOverflow, and then followed the link to another page titled Cryptographic Secret Santa.
On this latter page the author explains an algorithm he would use to assign Secret Santas without need for trust to a central authority.
In the end however the author writes:

Although it's feasible for this mechanism, being used by a group of hacker friends, to be implemented with command line tools (pgp, ssh-keygen) and email lists for publishing - it's very desirable to have some sort of application (web application) to make it easier for non hacker friends to join the game.

Now when we reach the notion of Web Application, the absence of the need to trust goes out of the window: you will have to trust the Web Application. Even if you have the source code, you cannot be sure that the Web Application is compiled from the same version of the source code made available to you.
At this points, let depart from the realm of practical, and consider purely theoretical case. Let's assume that all clients do their own encryption, decryption, signing and verification, so they do not need to trust the server.
In this theoretical case the idea described in the article might work, but there is at least one hiccup that I can spot.

To make sure this process is correct where each participant have one and only one anonymous public key published. The number of keys should be equal to the number of participants, and each one should confirm that he/she has published the key and it's being listed (never pointing out which one is it though).
At the end of the publishing we should have an associated list with the identity public keys and the participant names, and a separate list of anonymous public keys that only each participant know which one is his/her public key, but not the others.

Stated like this it appears that the keys need to be submitted anonymously, but then an anonymous party can supply redundant keys and there will be no way to tell which keys are legit, and which are submitted by a malicious participant. Note, that a person that was invited to participate legitimately still can maliciously submit multiple anonymous key, and no one would know - that is if the server is not to be trusted with the information which anonymous key is whose
As such, it looks like this breaks down the entire proposed algorithm.
Questions:

Is my reasoning sound and the algorithm is no good in a sense that there is no way around trusting the web application if we use it as described?
Is there an "easy fix" that would allow it to work?

You always need a secure way to distribute public keys. I believe the paper assumes you are able to do this.

However having that mechanism does not mean you can trust any single entity. You might trust me to give you my public key but you do not trust me not to rig the secret santa. Hence why this is still useful - you trust each individual to pass you their public keys but this is the only trust you have to have.


Are ServerHello, ClientHello, ServerKeyExchange messages encrypted In process of SSL handshake, several message like ServerHello, ClientHello, ServerKeyExchange messages are exchange before the actual encryption starts.

Are these messages encrypted?
If not then can a bad guy make illicit use of it? If yes, then how?

I am wondering if these messages are not encrypted then bad guy can take for example take session id from ServerHello, or key exchange from ServerKeyExchange message and make illicit use of it.

I know that after "Change Cipher Spec Message" communication is encrypted but what happens to the SSL handshake communication before that.

As stated in RFC 5246:

  The TLS Handshake Protocol involves the following steps:

  Exchange hello messages to agree on algorithms, exchange random
    values, and check for session resumption.
  Exchange the necessary cryptographic parameters to allow the
    client and server to agree on a premaster secret.
  Exchange certificates and cryptographic information to allow the
    client and server to authenticate themselves.
  Generate a master secret from the premaster secret and exchanged
    random values.
  Provide security parameters to the record layer.
  Allow the client and server to verify that their peer has
    calculated the same security parameters and that the handshake
    occurred without tampering by an attacker.

To answer your questions:

a. ServerHello and ClientHello aren't encrypted. (No critical information.)

b. ServerKeyExchange is not encrypted. (No critical information)(To understand how a key exchange without an encryption works, see DHKE)
There is a verification to detected an attacker.


Meterpreter pivot with a bind_named_pipe I have a pivot setup on a compromised windows 10 box and am trying to get an SYSTEM shell on a separate machine in the target network. I have successfully done this abusing an unquoted service path via a meterpreter/reverse_named_pipe that connects to my pivot but can this be done using bind_named_pipe? I may be thinking of it wrong but I want my pivot meterpreter shell to connect to the bind_name_pipe that is now running as listener via the abused service. In this scenario I don't think I would be able to use a multi/handler because my attacking machine doesn't have direct access to the target machine unless through the pivot. Or am I thinking about this wrong? Is the multi/handler aware of the pivot and will use it to access the target network?

If you are using Meterpreter, you can set up port forwarding (or even routing) through your existing sessions. Then, when you want to connect to another host on that network, you can point your multi/handler at the tunnel entrance or route.


UK online bank card reader identification entropy In the UK it's common to use a smart card and reader to log in to online banking.  You insert the card, enter the PIN and get back an 8-digit code from the reader to enter into the online bank website.  Note that it's not seeded in anyway from the bank, all you need is the card and the PIN.

I'd always thought that the 8-digit code returned wasn't very random (in particular the first two digits were the same), so I started keeping track.  Basically the 8-digit code is monotonically increasing by about 60,000 to 90,000 each time.

This doesn't seem right based on how I understood this to work.  Obviously there's very low entropy in seeding the identification algorithm (only uses an internal counter on the card if I understand things right) but I thought the 3DES on the card would result in a noise-like sequence of 8 digit codes.

Is this really how the system is supposed to work?

The protocol is discussed in Optimised to Fail:
Card Readers for Online Banking - Drimer, Murdoch and Anderson 2009

The paper shows images of readers from Natwest & Barclays as well as mentioning HBOS. Visually they are also identical to readers used by Nationwide, Coop and i'm sure others. As far as I am aware these devices have not changed since 2009 - I have one from back then that still works.

The bit filter seems to vary based on the bank. The first few bits seem to be the "Cryptogram Identification Data(CID) type code" which i imagine would be constant accross transactions. The next few bits (the number of which vary) seem to come from the "application transaction counter (ATC)" - which you would expect to increment with each transaction. I expect this is where the large increment you see comes from.

The Issuer Application Data is also not a source of entropy.

This leaves the "Application Cryptogram (AC)". This is a MAC (a form of hash - usually 3DES CBC) involving a session key on the card. It looks like 10-20 bits of this are taken which would be the primary source of entropy.


How to identify which SMB host can communicate one another? I would like to know which hosts (on a local network) can communicate with one another.

That is to say: who is the server? who can communicates with him? Is it all the hosts with ports 139 and 445 open which can talk to the server, or are there some SMB sub-networks (defined with membership of a group, for instance) inside the network?

SMB is a client-server setup, whereby the system hosting the share or service is the server, with TCP ports 445 and/or 139 open. The client (e.g. the system mounting a shared folder) connects to the server's open port(s).

Technically speaking you don't need to involve port 139, since that's the older NetBIOS approach, and you can directly do SMB over 445.


How is VPN tunneling actually implemented? I am new to VPNs, have used them a few times, have read about "how they work" (which is all very high level), and am now confused about how this is actually implemented (so I can come full circle and understand what kind of security they are providing me).
It sounds like a VPN is something you install on your computer. You then perform your actions in the VPN UI (whether it's a terminal or a GUI). These "local" actions are then encrypted (what is the encryption method/protocol?) locally. Then, say I am at my house using WIFI or at the coffee shop. It uses my newly allocated public IP address (the one I've been assigned for only the past few hours), to send this encrypted data across the public internet, in the public WIFI at the coffee shop. So people can tell I am sending something over the internet, just not sure what (because it's encrypted). The way these articles sound, they make it sound like magic and that you get a static IP address locally which no one can see. That's not the case right? It is doing exactly what I'm saying. I ask this question to clarify and make sure I'm understanding correctly.
So then the encrypted traffic (going across the public internet, using my publicly known IP address), is sent to some remote server. That server then performs the real actions I was typing at my VPN terminal/GUI. It makes whatever internet requests and whatnot, or SSH's into some computer I'm targeting, and pipes the info back, encrypted, over the public internet, to decrypt it locally on my computer. Hopefully I'm still on the right track. Then that remote computer I sent my encrypted traffic to, what does it do to obscure my message or secure my message from its standpoint? Does it dynamically change its IP address? Is it situated in some remote wilderness guarded by gates so no one can intercept the traffic? How does it stay secure in sending messages to the actual target location? Or is it just the fact that the requests are no longer coming from my computer, so no one can know its me, all the security its accomplishing?
Basically, I'm wondering if this is sort of how it's implemented.

Roughly speaking, when you do anything on the Internet, you do so through a network interface. That is the thing that "has an IP address". You can have several interfaces on your system (for example Ethernet, WiFi, and the "loopback" interface that allows two programs to talk to each other through the "internet" even if you are offline.
VPN software simply tells the system there is another interface, let us call it "vpn0". The system asks the interface, "do you have an IP address?" and the VPN software answers "Yessirree, it's 150.217.256.35" (yes, that 256 is both impossible and intentional).
Then, the VPN software (usually) also publishes a route, i.e., it says, "addresses from 150.217.0.0 through 150.217.511.511 are reachable through this interface" .
So whenever some program on the system wants to reach, say, 150.217.432.234, the packet will get sent to vpn0.
If the published route is the default route for anywhere, then all packets (except loopback and local ethernet and wifi) will be routed through vpn0.
The VPN software might also publish new DNS servers, so that if some program such as Google Chrome wanted to reach www.nekkidgals.org (haven't checked, but it probably exists), it would ask that DNS instead of, say, 8.8.8.8. So also the packet asking "what is the IP of www.nekkidgals.org?" would go through vpn0.
Now vpn0 is actually a software driver, and this driver encrypts the packet. It can do this in any of several ways.
For example, before vpn0 even exists, it could connect (through eth0 or wlan0, both insecure) to a known VPN server and ask for a public key. Then it could choose a very large symmetric key for, say, AES-256 algorithm, and send this key to the server after encrypting it with the server's public key. So, even if someone was to listen on the insecure wlan0, it could not decrypt the AES256 key since it would not possess the private key. The server, meanwhile, having that private key, is now in possession of the AES256 key. VPN client and VPN server start exchanging packets protected by AES256 through wlan0.
Each time the user believes he's sending unencrypted data through vpn0, that data gets encrypted and sent to the VPN server via wlan0. There it gets decrypted and continues its journey, but now it appears as if it originated inside the network of the VPN server.
As you can see, it is important that not only the connection is encrypted, but all the routes must be covered and DNS needs also be tunneled through VPN. Otherwise, someone could still guess what you're doing from the DNS queries sent in the clear.
Apart from this detail, your computer remains unchanged, so for example if you have spyware or malware aboard, it will still work; if you or some software can be tricked into not using the VPN for something, you can be traced; and your browser is still your browser, with its cookies, its supercookies, its audio-context fingerprint, its unique combination of versions, fonts, resolution and whatever; so it can be recognized.


How can I create and use self signed server certificate? In development of a web service, I can use self signed server certificate for testing under HTTPS. How can we make a client (possibly run in the same host, but maybe a different host) work with the service in HTTPS?

On Ubuntu 18.04, I try to run a gRPC service in ASP.NET Core. https://stackoverflow.com/a/59702094 says

  On Ubuntu the standard mechanism would be:

  dotnet dev-certs https -v to generate a self-signed cert
  convert the generated cert in ~/.dotnet/corefx/cryptography/x509stores/my from pfx to pem using
  openssl pkcs12 -in <certname>.pfx -nokeys -out localhost.crt -nodes
  copy localhost.crt to /usr/local/share/ca-certificates
  trust the certificate using sudo update-ca-certificates
  verify if the cert is copied to /etc/ssl/certs/localhost.pem (extension changes)
  verify if it's trusted using openssl verify localhost.crt

Does it only mention about creating and self signing a server certificate for a service, but not setting up for a client? I heard that a browser will warn about self signed server certificates, so wondering how to prepare a web service client to handle self signed server certificates?

Can  dotnet dev-certs https -v be replaced with some general command which doesn't depend on .NET Core?
Note: dotnet dev-certs https -v actually doesn't work on Ubuntu, but only on Windows and Mac. See the link for workaround.

Thanks.

If you're just trying to get trusted certs for local Web development that browsers won't reject, this works pretty well:

create a directory called [www.mysecuredomain.com] (make that custom to your project)

paste the following into a file named host.conf inside the directory:

[req]

default_bits       = 2048
default_keyfile    = server.key
distinguished_name = req_distinguished_name
req_extensions     = req_ext
x509_extensions    = v3_ca

[req_distinguished_name]

countryName                 = Country Name (2 letter code)
countryName_default         = US
stateOrProvinceName         = State or Province Name (full name)
stateOrProvinceName_default = [Your State Name Here]
localityName                = Locality Name (eg, city)
localityName_default        = [Your City Name Here]
organizationName            = Organization Name (eg, company)
organizationName_default    = [Your Org Name Here]
organizationalUnitName      = organizationalunit
organizationalUnitName_default = [ Your Org Unit Here ]
commonName                  = Common Name (e.g. server FQDN or YOUR name)
commonName_default          = [ www.mydevdomain.com ]
commonName_max              = 64

[req_ext]

subjectAltName = @alt_names

[v3_ca]

subjectAltName = @alt_names

[alt_names]
DNS.1   = [ www.mydevdomain.com ]

throw this in a shell file (example: create-trusted-cert.sh) above the directory you just created:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout "./$1/server.key" -out "./$1/server.crt" -config "./$1/host.conf"
certutil -d sql:$HOME/.pki/nssdb -D -n $1
certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n "$1" -i "./$1/server.crt"
certutil -d sql:$HOME/.pki/nssdb -L | grep "$1"

type this at the commanline:

  > ./create-trusted-cert.sh [www.mysecuredomain.com]

Be sure to modify the values in the directory, host.conf and command line args to fit your project.

Happy developing.


Prove log files weren't tampered with? Say I have some Apache logs that show brute force attempts on a login page. I've singled out the IP, and found out who the culprit was. How can I show to a third party that I didn't makeup the entries in those logs?

Is there a way to systematically prove through some means of hashing, or system verification that the logs aren't edited in any way?

The scenario I gave above is purely hypothetical. But was wondering if you could verify logs like that somehow.

No, you cannot prove to someone else, that logs on your system have not been tampered with. Clearly, if you own that given system, you can do whatever you like with it, including the manipulation of all files.

In the end it's a question of trust. Therefore that third party would have to define, what they would require to trust your data.
A possible solution for them could be to deploy a third party system between your server and the internet, so that they can observe the network traffic themselves.

There are however tools, that regularly check file integrity, but those usually aim for more or less static file contents like config files and are probably not applicable for log files. Still, if they would do the job, they would still run on your system and do not change the scope of trust, the third party would have to accept.


Hydra on ssh does not work even with correct pass I'm testing out hydra, for this purpose I started sshd on a Raspi with Kali 2 running as a target machine. The attacker is a Kali 2 VM on a Macbook. I verified that connecting manually via SSH to the target works.

Now I generated a password list of several thousand permutations with john the ripper's rule option, then reduced it with pw-inspect (to those with at least 8 characters). They all follow the same rules, e.g.:

Peter1234!
Peter1234%
Peter1235!

and so on.

Now I made sure the correct password is in this file. However, when I run hydra it reports in the end that it could not find the password. If I reduce the list in volume to about 30 entries around the correct pass it will work.

I'm at a loss what the reason might be and this way I can't pentest since I will not know if the password has really not been found or if it's my problem.

By default THC-Hydra does not have SSH support and unless you install ALL of the following libraries it will behave exactly as you describe.

libssl-dev libssh-dev libidn11-dev libpcre3-dev libgtk2.0-dev libmysqlclient-dev libpq-dev libsvn-dev firebird2.1-dev libncp-dev libncurses5-dev

More specifically if you install all the libraries at once you won't see the failure of one of them in the middle followed by the last few succeeding. Problem I run into frequently when installing it on different systems.

If you install each one of these libraries one by one you can catch which one didn't install correctly, correct it, and then Hydra will start working again.

Finally also ensure that you use the following syntax with the port number at the end after the IP address IP:Port

hydra -l testuser007 -P top500.txt ssh://184.100.123.123:22


Why does VirusTotal have two different reports for the same hash depending on FILE vs URL submission? Why would the same SHA256 Hash of a file have totally different VirusTotal results at the same time?

Submitting a file to VirusTotal via File upload results in numerous hits for malware.
Submitting the exact same file but via URL submission results in a totally safe and clean submission.

I understand that these files are accessed in different ways, so AV software might look at the file in a different context, but ultimately the endpoint is at risk regardless.

As i see, both are not files are not same. When you download file it may be added header or other vulnerable code.

Otherwise, Some virus are harmful when it is in online. When you download it, it become deactivate. Vice Versa also possible. Javascript virus are not activated when it is in local computer(Not all javascript based viruses).


Design of Initialisation Vector I understand that an IV (initialisation vector) should be both unique and unpredictable, but I have found little guidance as to which is most important.

For an AES cipher I have a block size of 128 bits to use. I was considering the following scheme:

Bits 0 to 39 : Least significant 40 bits of milliseconds since epoch. This repeats approximately once every 34 years. A time frame that probably exceeds the time for which current ciphers will be considered secure, and therefore unique within the life span of the encrypted data.

Bits 40 to 63 : A 24 bit counter starting at a random value and incremented for every IV. In order to guarantee uniqueness only one thread of execution can access the counter at a time, and hence the maximum number of accesses per millisecond is limited by the clock speed of a single CPU. This application will be used on normal CPUs where clock speeds are currently plateaued well below the 16GHz speed it would take to exhaust this counter within 1 millisecond.

Bits 64 to 95 : I have concatenated information about the hardware and process and then used a SHA-256 upon this data. I am using the first 32 bits of the resulting hash as a way of uniquely identifying the source process. This reduces the possibility that 2 processes on different servers could generate the same IV. The birthday paradox suggests that if I have 65000 simultaneous processes, there a 0.5 probability of two of them sharing the same 32 bits here, but with my envisaged maximum of 1000 processes, the probability is less than 0.00001.

Bits 96 to 127 : 32 random bits drawn from a secure random number generator.

This IV would be transmitted alongside the cipher text.

My first question: is this scheme reasonable for use with the block cipher modes: CBC, PCBC, CFB, OFB and CTR?

My second question: is there any advantage to passing the 128 bits through MD5 before using them? This would be to "improve" the IV by interweaving the fixed and variable parts of the input.

My third question: alas I also have to support 64 bit block ciphers such as DES, DESede and Blowfish. I don't believe any users actually use such ciphers, but they have to be supported. Such ciphers require a mere 64 bit IV. I see nothing from the above that I can reasonably remove whilst still providing reasonable guarantees of non-repeatability and non-predictability. What can one do? All I can think of doing is taking the first 64 bits of a secure hash. Does that suffice?

My fourth question: For CBC, PCBC and CFB only, if I use the first 64 bits as a true IV, and then feed the second 64 bits into the cipher as if they were the first block of the message but discarding the output - does that work as well as using a 128 bit IV even though the cipher's block size is only 64 bits?

As a further point, the initial 32 bits of the plain text of some tens of messages could reasonably be known to an attacker. They would not be able to control the IVs generated for those messages but could identify them by other means from within some tens of thousands of messages. The prime requirement of this cipher system is to prevent an attack with such information from accessing any part of the plain text of any other message. If either the IV scheme or the cipher block modes I've mentioned would be weak in such circumstance, I would be grateful if people could point it out.

Each encryption mode has its own requirements for the IV.

For CBC, the IV must be random, uniform (all block values have the same probability of being selected), and unpredictable for the attacker. The latter is necessary to defeat attackers who get to choose part of the data which is to be encrypted. This is the mechanism of the BEAST attack on SSL: in SSL 3.0 and TLS 1.0, the IV for a record is the last block of the previous encrypted record, so it can be predicted by the attacker (he saw it). Note that this IV is still, from the point of view of the attacker, random and uniform (the MAC and encryption of the previous record act together as a random number generator). Unpredictability is thus crucial.

Some other modes are less picky. For instance, EAX only requires a non-repeating IV: for a given key, you should never use the same IV twice. But there is no need for randomness, and a simple counter will do the trick.

The safe IV generation method is to use a cryptographically strong PRNG (/dev/urandom, CryptGenRandom(),... all decent development platforms offer one) to produce the full IV (all 128 bits for a 128-bit block cipher like AES). This produces adequate and secure IV for all modes. You cannot get it wrong that way. CBC, PCBC, CFB and OFB require such a random, uniform and unpredictable IV.

If you want to use something else than a fully random IV, then you must take care of the precise needs of the encryption mode. Not using a random IV may have the benefit of not requiring a PRNG, which can be a nice thing on some embedded platforms which do not have a good source for random numbers. To some extent, CTR can use a predictable IV, but you must be cautious. CTR works by encrypting successive values of a counter, and the IV is just the starting point for that counter. You must never reuse the same counter value twice (with a given key), so when you use an IV for CTR encryption, you actually "burn" a range of IV values.

Your method:

is overly complex,
does not completely fulfill the uniformity and unpredictability requirements that most block cipher modes require,
and still needs a secure PRNG to be available.

As such, it is weak and pointless. If you have a secure PRNG, just use it for the whole IV. This will give you the best you can hope for: it will be fine for 128-bit block ciphers, and mostly fine for 64-bit block ciphers (and you cannot really get anything better for 64-bit block ciphers: weaknesses implied by the short block size when you encrypt more than a few dozen gigabytes with the same key are structural). Don't throw additional algorithms and structure and other gimmicks at your protocol; in cryptography, complexity is your worst enemy.


Is there any processor that could decrypt encrypted data and machine instructions? Is there any processor that could decrypt encrypted data and machine instructions and then execute the instructions on the data then encrypt the results?

There are quite a few processors that support encrypted memory. Such processors transparently decrypt whenever they read from memory (code or data) and encrypt before writing back to memory.

This has been supported for many years in processors used in smart cards and USB tokens. For example, according to this product brief, Infineon's SLE78 supports "Full CPU, Memory, Bus and Cache encryption". This processor is the subject of What's the State of the Art of Homomorphic Encryption?.

Over the last few years support for RAM encryption has been added to processors used in consumer electronics devices such as game consoles and set top boxes. A good example of this is the XBOX 360, in which the RAM encryption was a significant challenge for hackers as described in this classic presentation by Felix Domke and Michael Steil (video).

To minimize the impact on the processor performance, the RAM decryption algorithm will probably not be a strong block cipher like AES but a synchronous stream cipher.

Such memory encryption technology is intended to defend against an attacker who does not control the CPU but can access the physical memory directly, e.g by probing the bus that connects the CPU to the physical memory.


Local admin permissions for MMC Do I really need local admin permissions on my own laptop on order to access MMC to check/verify things like asset ownership for a certain object, group structure, etc ?

On the internet found contradicting information so I was wondering if there there is a possibility to access this information without them.

mmc.exe can be run with limited user permissions; this just prevents it from doing most of the things you might want it to do. For example, with non-admin permissions, you can edit your personal certificate store, but you will have read-only access to the system (machine) certificate store. Some snap-ins will be completely useless with limited permissions (for example, diskmgmt.msc, the Disk Management snap-in, requires connecting to the Virtual Disk Service and I don't believe you can do that without elevated privileges; try running the command-line equivalent diskpart.exe and if you don't elevate it'll return Access is denied).

Basically, it depends what the snap-in does. If it supports both user-specific and system-wide settings, there's a decent chance you'll be able to use it (for the current user only) without elevated privileges. If it makes changes to some data store directly (for example, by editing the registry or file system using the relevant APIs) or indirectly (for example, certificates are typically stored in the registry, even though you usually access them through crypto APIs that call the required registry APIs behind the scenes), then you can do whatever the ACLs on that data store permit your current user to do (for example, read-only access to system-wide certificates). On the other hand, if it makes some kind of inter-process communication, then you won't be able to use the snap-in at all if the IPC channel requires more privileges than you have. Similarly, if it requires an NT privilege (for example SeImpersonatePrivilege, which lets you tell the OS to pretend you're a different user), then of course you can't use it if you don't have that privilege.


Telling the backend where to go from client side I have a system with three layers: two client web apps, one Backend, and two DBs.
The two DB and client app instances represent prod and test environments.
The backend has only one instance that should serve both environments. Say I have prod-client.myapp.com, test-client.myapp.com, prod-db.myapp.com, and test-db.myapp.com but only one API service api.myapp.com.
The backend exposes one API, but it should match the client app and the DB environment. My current implementation is to send the environment code prod or test from the client app to the backend so it will know which DB to query.
Duplicating the backend for each environment is not an option.
But I'm wondering if sending the environment code from the client app is a good idea... Is there some security risk with that approach?

I'm not sure I follow, but in any case, you need someway to authenticate they webapps.  The web app that is for "test" should never be able to send a code that it is asking for the "prod" data.
A safer way of doing this is to handle that mapping in the backend.  The webapps are registered with the backend and the backend knows where to send the queries based on the registration information.  This makes it hard to accidentally (or maliciously) query prod data from the test app.


Detect Bitcoin Mining So, me and a network administrator friend were discussing about bitcoin mining. With so many portable bitcoin mining software, we wanted to find the different ways to detect them in the network.

How can we detect if a certain host is running a bitcoin mining software? All the different miners I tried are portables. They can be saved and executed independent of their path, ruling out the Program Files, bin folder.

Any more ideas as to how do we detect bitcoin mining?

You can look for traffic patterns and the like, but there's significant crossover between the crowd that mines bitcoins, the crowd that knows how Tor works and the crowd that goes to amazing lengths to protect their privacy. That means: detection on the network isn't all that reliable. That it doesn't use a whole lot of bandwidth makes it especially hard.

What they likely can't hide is CPU and GPU usage. If you have access to the machine via SNMP, you can remotely watch for CPU spikes, or you can use the Get-Process PowerShell cmdlet against the machines on your network to look for things running up CPU time. For GPU time; you're not that likely to be able to actually spot the usage unless you can somehow monitor power draw.

Unfortunately, since you allow people to install software they want to arbitrary paths, you're not likely to be able to come up with a reliable, repeatable method - the people you're looking for could change miner, change path, etc. to change their signature.


How safe is Two Factor Authentication (TOTP)? If someone gets my phone and saves the values my authenticator generates, will that person be able to find out the shared key (to be used to generate codes themselves)?

If so, how many codes will they need to generate to get my shared key? (Roughly, as it can change according to they solving algorithm)

You might want to note that I mean the TOTP algorithm used with a 16 characters-long key (lower case letters, numbers) here.

Authentication relies on the following: (source)

Something you know
Something you have
Something you are

A good reason to use TOTP is to increase security by using multiple factors from the list above. For example, if your password becomes known to someone else, they would still need access to your TOTP device to authenticate.

However, that does not mean that TOTP devices are invulnerable to attack.

RFC 6238 states that:

  The keys MAY be stored in a tamper-resistant device and SHOULD be protected against unauthorized access and usage.

This means that TOTP implementations are not required to protect the shared secret to be RFC compliant. However, you might consider looking for a TOTP application that requires a password to decrypt the shared secrets. This provides some additional protection, but if your phone's security is compromised by an exploit or malicious physical access, keylogger attacks become possible.

You also asked how many keys an attacker would need to see to discover your shared secret. From RFC 4226, Appendix A.4.3:

  No matter what strategy the adversary uses, and even if it sees, and tries to exploit, the authenticators from authentication attempts of the user, its success probability will not be above that of the brute force attack -- this is true as long as the number of authentications it observes is not incredibly large.

So, in general, a brute force attack is the best that could occur. However, if the adversary can generate the codes at will (and for some reason they do not already have the shared secret), this does not hold. More information about what influences this attack are available in the RFC.


Command Injection DVWA (1.0.7 iso version) High Security level I am practising on an older version of DVWA (1.0.7 iso image). In High Security settings, I am trying to perform command injection and this is the source code snippet I saw

$target = stripslashes( $target );

$octet = explode(".", $target);

if ((is_numeric($octet[0])) && (is_numeric($octet[1])) && (is_numeric($octet[2])) && (is_numeric($octet[3])) && (sizeof($octet) ==4) ) {
    $target = $octet[0].'.'.$octet[1].'.'.$octet[2].'.'.$octet[3];

    //rest of the code....
}

I tried various ways and I found that

Spaces before the IP address, example, "    192.169.4.4" does not affect the server from executing the ping command.
Space right after the IP address will cause an error about invalid IP.
I read up on is_numeric function and found that hexadecimal and binary notations are not allowed (https://www.php.net/manual/en/function.is-numeric.php)
I used Burp Suite to try various encodings but they don't seem to work.
stripslashes function is used to remove backslashes but I am not sure how I can make use of this code, if it is possible.

Has anyone worked on this challenge? Any advice is appreciated.

The code snippet in your question is actually from the impossible level, not high. I'm not sure which one you're trying to beat.

The high level uses a blacklist approach:

    $substitutions = array(
        '&'  => '',
        ';'  => '',
        '| ' => '',
        '-'  => '',
        '$'  => '',
        '('  => '',
        ')'  => '',
        '`'  => '',
        '||' => '',
    );
    // Remove any of the charactars in the array (blacklist).
    $target = str_replace( array_keys( $substitutions ), $substitutions, $target );

There are a few ways to beat high, however at a quick glance the impossible level might not be beatable without additional bugs. You could still beat it via something like shellshock on an older system though as it forks to run ping.


Can a company see your old Google Searches I am signed into my personal Gmail account through Safari on my phone. If I simply sign into my personal Gmail account on my work computer, can they see any old searches made on my phone or personal computer from home? Or can can they only see what I’m actively searching while on my work computer?

can they see any old searches made on my phone or personal computer from home?

Depending on the network setup, they could inspect your network traffic, get your login details and use it later. That would require you to install a CA certificate on your phone or personal computer, or to log in ignoring your browser warnings about invalid certificates. But logging private credentials can be considered a crime on some jurisdictions, so I doubt they would ever do that. But if they own the network, they can intercept your communications, steal your credentials, log back and see what you have.

But if you haven't installed any CA certificate on your phone or private computer, they cannot. That's exact the point of certificates: prevent any third party to read or change any of the requests you make.

  Or can can they only see what I’m actively searching while on my work computer?

Your work computer is different, as they usually have jurisdiction over it. If they have an interception proxy (common on enterprise networks), they can see everything. It does not mean they will see, but they have the capability.


Yubikeys & SSH - which option is best for lockdown? My company has a few dozen servers hosted on a cloud provider. All but one (OpenVPN host) is closed to the internet. We're using OpenVPN AS which uses certs + Google Authenticator for login.

We are very interested in security and we want to minimize the potential damage in case of infiltration of one our employees' computers. To that end, we've mandated employees lock down their personal machines via Yubico-PAM.

I also want to use the Yubikeys for SSH access. Now, the Neo supports SSH/GPG keys via its JavaCard support. I like this option because it doesn't require significant modification of any of our existing servers, just their authorized_keys files.

I have also seen integration of Yubico-PAM via password (type password, touch yubikey). This is nice but we don't use passwords, we use keyfiles, and unless there was a compelling security reason to switch, I'd rather keep it that way.

The third option I've seen is AuthenticationMethods in the newest versions of sshd (more here). This properly allows you to use a keypair and the Yubikey. Upon login with a correct key, the user is prompted to press the button on their yubikey. Unfortunately it looks as though the server needs to ping Yubicloud.

In both cases I would likely build and query an LDAP server for Yubikey auth so we can easily revoke / add keys without having to ssh into every machine.

In my opinion, the first option is best (generate keys on the Yubikey Neo itself), as it requires the most minimal configuration of our servers, doesn't rely on the Yubicloud service to prevent replay, and wouldn't require an LDAP server.

Have any of you integrated Yubikeys (or other hardware tokens) into your administration flow? If so, which method did you choose, and why did you choose it?

Yubikey can either be cloud-based with Yubi providing the "yes/no" answer or you can run it locally. Run locally and benefit from the OTP.


How much can someone see from my iPhone by connecting to my wifi How much can someone see from my iPhone by connecting to my wifi and can they copy my messages files documents etc

If you are transmitting anything through WiFi then an eavesdropper can capture all the transmitted packets and analyze the data. Thus, anything you transmit should be encrypted (using TLS preferbly).

And dont rely much on the WiFi encryption as most of the time (other than WPA2 enterprise), as it can be cracked by someone who knows the pre-shared key and recorded the handshake.

Otherwise, if there is an app that allows remote access or file sharing then someone may be able to hack into your phone. Especially if your iPhone is jailbroken, then  1 out of 20 iPhones/iPads can be hacked in less than a minute.

And lastly viruses, trojans and malware can also intrude on your privacy once you are connected to the Internet. Again, this happens only if your phone is jailbroken. Because according to here, there are no known iOS viruses that can infect an iPad or iPhone that has not been jailbroken.

Because iOS implements something called sandboxing, which restricted the resources that each app can use. So, a malicious app will have a hard time accessing data stored in other apps unless it is jailbroken.


Is it a bad idea to provide a "testing" OAuth ID and secret? I'm working on a web app, and I may eventually want to bring others onto the project. I have two sets of GitHub credentials: one called Foo that calls back to foo.com/endpoint, and one called Foo -- TEST CREDENTIALS that calls back to foo.local/endpoint. The idea is that I can share the test credentials with other developers, and they can modify their /etc/hosts for local testing.

I'm generally a trusting person, but is there any way a malicious user could reasonably use these test credentials for evil? In my understanding, they'd have to:

Make sure that DNS for the victim's connection to foo.local points to their server.
Ensure that the victim accesses foo.local instead of foo.com.
Hope that the victim blindly grants access and does not notice the -- TEST CREDENTIALS in the application name on the GitHub authorization screen.

This seems fairly far-fetched to me, so I'm going to assert that it's safe to hand out these test credentials to coworkers. Can somebody prove me wrong by providing a more viable attack method?

It's a perfectly reasonable use. We actually have localhost as the endpoint for our testing API keys, and our OAuth provider allows plain http for localhost callbacks, so it makes testing very straightforward.

You can easily revoke the credentials if they're compromised and you don't really need your company name on the display name either.


What threats come from CRLF in email generation? I have an application where a code scanner has identified CRLF injection possibilities in some classes related to email generation.

I understand how CRLF injection could be used against me on URL-based attacks, but google has been kinda silent on threats coming from email.  Are we concerned with injecting different addresses in SMTP conversations like this:

http://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol#SMTP_transport_example

?

Or something else?

Depending on how your application creates the actual RAW email request, it may be possible to insert line feeds to modify the recipients, CC, BCC etc.

Check out this example:

  In this context, the target is to be able to send anonymous emails to
  other recipients. There are numerous additional fields that can be
  specified in the mail headers (see [ RFC 822 ]). For example 'Cc'
  (Carbon Copy), which sends a copy of the message to the email
  addresses given as arguments. A better choice is to use the 'Bcc'
  (Blind Carbon Copy) which sends a carbon copy of the message just like
  with the 'Cc' header, except that the recipiends email addresses given
  as arguments are not shown to the multiple recipients' headers. As
  specified in the [ RFC 822 ], one must add a line feed for every
  header. The  (line feed) char has a hexadecimal value of 0x0A.

  Sender: "sender@anonymous.www%0ACc:recipient@someothersite.xxx%0ABcc:somebloke@grrrr.xxx,someotherbloke@oooops.xxx"

  Subject: ahem
  Message: "My Message"

will result in

 To: recipient@victim.xxx
 Subject: ahem
 From: sender@anonymous.xxx
 Cc:recipient@someothersite.xxx
 Bcc:somebloke@grrrr.xxx,someotherbloke@oooops.xxx

 My Message...

Also, check out some OWASP Guidance, and some examples under CWE-93.


Disabling external DNS lookups - is this really so beneficial for security? I have recently started working for a company which disables external DNS resolution from the machines inside the network by not adding external forwarders to the internal DNS servers - the reasoning behind this is for security.

It seems a bit heavy-handed to me and it's causing me issues as the company moves towards more cloud services.

Can anyone suggest a way that I could reach a compromise to provide security? I was thinking we should use external forwarders but apply filtering e.g https://docs.microsoft.com/en-us/windows-server/networking/dns/deploy/apply-filters-on-dns-queries

When firewalls are correctly configured, DNS is our way into and out of the network. Depending on your security level, blocking DNS where it is not needed can be useful hardening.

As a security consultant, it is not that uncommon to find yourself in a system with a limited server-side request forgery or some other server-side vulnerability. Some customers have very well-configured firewalls which prevent us from using it to get much further, but through DNS we can typically still learn more about the network and sometimes setup useful data tunnels. In such a case, disabling DNS would be the final nail in the coffin.

  it's causing me issues

That is the risk: if you disable DNS and someone does need it (for example for apt update), you risk that sysadmins use ugly workarounds, making the network less secure instead of more secure. If you can't do your work properly, then disabling DNS altogether is not the right choice.

Might a limited resolver be a solution? It could run on localhost or perhaps on a dedicated system, and it could be configured to only resolve a whitelist of domains. Since you mention you're moving your data and applications to other people's computers ("the cloud"), it sounds like you might only need to resolve the domains belonging to whatever SaaS/*aaS service your company uses.

The pitfall there is that whitelisting something like *.cloudCorp.example.com probably allows an attacker to buy a VPS at cloudCorp and get a matching domain name. That would be something to watch out for. But even if this is unavoidable (and that's not a given), it's better than allowing all DNS queries.


SELinux and text relocations exploitability I have been assigned the task of adopting and implementing a certain backup software solution for our GNU/Linux farm.
As per my deparment defined requirements, this solution should support SELinux enabled systems to be valid. After a not too thorough research, it was quite obvious that this product did not support SELinux, or needed the system administrator to punch a hole in the SELinux policy because some libraries needed to perform text relocations to be able to operate (not to mention the correctness -or lack thereof- of the commands suggested in their knowledge base).

It is not new that SELinux is proven to expose bugs, but my concern here was to be able to explain to Management to what extent denying text relocations is a major security feature.

Management counteract my reasoning claiming no CVEs are published for this specific product related to its need to perform text relocations.

Is the need to perform text relocations exploitable enough as to represent a CVE elegible vulnerability?

There are two major points to make. The first is that a major strength of SELinux policy is to prevent exploitation of unknown vulnerabilities. Given that they are unknown, a CVE will not exist.

The second is that permitting text relocation also permits an exploit to write and execute whatever code it would like to execute, or allows it to modify existing code in memory. You reference Ulrich's short blurb which also contains his "fixing the problem" article; both of which are excellent and explain the problem.

The "need to perform text relocations" is not itself a vulnerability; it just makes some vulnerabilities in the program or libraries easy to exploit.


is g-zipping assets a security concern? I recently noticed that the assets sent to clients aren't gzipped or minified on either my companies intranet or its public facing website.

I brought this to the attention of the networking department (who maintain the server) and asked if they could add the appropriate code to the server config.

My co-worker initially saw no problem and thought it was a good idea, but today he said that after he inquired further, he found out that it was a security concern and that's why they don't do it.

This baffles me.

I asked how it could possibly be a security concern if we compress the assets sitting on our server prior to sending them to the client.

He told me that it made it easier for hacked content to slip through the clients antivirus scanner. We use HTTPS though, so there's no way our code could be tampered with on the way to the client's browser without their browser noticing, right?

Further more, even if we did send the assets in plain text, if they get intercepted, the hacker could just gzip them himself and send that, so I'm really confused now.

Are there any legitimate reasons NOT to gzip/minify content sent to client's computers?

EDIT:
  The content is static, essentially just a marketing website for the company

I've been pondering this and I don't think your networking department is justified in this opinion. It does all depend on your threat model, but given the threat model of "hacked content to slip through the clients antivirus scanner", this opinion makes no sense.

First, let's drop minification, because it's in plain text. There is no security reason or threat model that could be addressed by not minifying.

Now, let's look at the "hacked content". Because you are using HTTPS, the malicious content has to come from your server, and not a MitM. This excludes hacked ad networks or 3rd party content, because that's being served from elsewhere. This opinion also suggests that this threat (hacked content being served from your own servers) is credible enough to not gain the operational benefits of compressing the content. I doubt this is actually the case.

The other issue here is the concern for the end client. Besides being an odd concern for a web service, antivirus scanners on the client can still scan the content once it is uncompressed. Even a perimeter scanner will decompress content in order to scan it.

In addition to all this, you're right about having no control over the hacked content anyway. The hacker can choose to compress or not if they have access to your servers (which would be required in this threat model), so choosing not to compress static content is not justified.

In the end, it sounds like there is more to the story, the architecture, and odd decision than meets the eye.


What is the best practice to secure an unattended Raspberry Pi? I'm working on a project which involves mounting a Raspberry Pi on a self-moving vehicle. I'm looking for the best way to encrypt the Pi (entire file-system, swap, etc.), with the minimum possible impact on performance, in case it falls in the wrong hands.

I also need it to be unlockable via SSH, and ideally, I need it to create a WiFi AP that I will connect to and then unlock it via SSH.

What is the best way to achieve this?

I Have a few suggestions but no definitive best go to solution since it really depends on your specific use case.

First off look into BerryBoot, it offers full disk encryption out of the box.

A second alternative is to use any of the TrueCrypt like applications such as VeraCrypt It offers a bunch of options to either perform full disk encryption or make sure that specific vulnerable files are safely encrypted.

A third option, similar to the second is encrypting directories on the disk

If you are more technically inclined and would like to manually perform certain taks it is also possible to use LUKS/dm-crypt yourself.

You will have to keep certain things in mind though: The computational power of the Pi is limited so any form of encryption on the devices will cause a performance hit.

Secondly you will have the problem that you will need to manually enter the key each time the device wants to perform an operation, since storing it in a physical form on the device makes it vulnerable to anyone with physical access.


Verifying credit card ownership When a fraudulent credit card CNP (Card Not Present) transaction is made, merchant is liable for the chargeback.

For that reason, our company implemented a policy where we ask a photo of customer's card only showing the last 4 digits before we clear the payment. We ask them to send it via email which I think is a security risk because it could be unencrypted.

Our company provides electronically delivered financial services. So we only ask for billing address, we never deliver physical goods.

What's the better approach of verifying card ownership? (complying to PCI-DSS)

I would suggest implementing Verified by Visa and Mastercard 3DSecure.

Ask your acquirer about enabling these services on your merchant account.
Those 2 services will shift the liability to the customer provided that the correct VbV/3DS password/OTP authentication passed.

You could also select to reject cards that do not have VbV/3Ds enabled, or you could pass those transactions and take the chargeback risk.

If the financial services you provide only are "useable" in a specific country due to laws and such, I would suggest putting a geoIP lock on your site, and also ask your acquirer (or set it up in your merchant Control panel if they provide such facility) to lock so only cards issued in country X is accepted.

If you also want to use AVS (Address Verification System), I would suggest the user has to enter their billing address at sign-up, then you send a physical snail-mail with a one-time code required to activate account. Then only this billing address can be used. Changing of billing address deactivates account and sends a new snail-mail code to the new address.
This also both adds convenience to the customer (he does not need to enter his billing address all the time), auditability (you have a real address for the customer to give to the police in case of fraud), and security (since the address is both verified by snail-mail and against the credit card).


LDAP StartTLS encryption - which TLS versions are supported? I am looking to set a third party application to authenticate with our domain. The application supports LDAPv3 and we have opted to use the start StartTLS extension to encrypt the credentials from the source host application towards the domain server.
Having said this, I am at a loss as to what TLS version is used in StartTLS. Given the older versions are less acceptable, we would like to opt to allow only the later version (1.2, 1.3) of TLS be accepted.
My question therefore is;
What TLS version is used/supported for StartTLS?

I don't have an LDAP server to test this with, but if you have openssl 1.1.1, then you should be able to use opensssl s_client to connect to your LDAP server and then proceed with the protocol to upgrade the connection to SSL/TLS using STARTTLS, using a command along the lines of:
 openssl s_client -starttls ldap -crlf -connect host.domain.tld:port

See https://www.openssl.org/docs/man1.1.1/man1/openssl-s_client.html for more info.
Then, you can use options with the above command such as -ssl3 -tls1 -tls1_1 -tls1_2 -tls1_3 -no_ssl3 -no_tls1 -no_tls1_1 -no_tls1_2 -no_tls1_3, etc. to restrict/allow openssl to connect using various SSL/TLS protocols in order to see which ones the server supports.  Referring to the above reference at openssl.org, you can see that there are also options that you can use to restrict/allow various ciphers as well.

As I mentioned above, I don't have an LDAP server to test this on, but the process would be similar to that of using openssl s_client to test the versions of SSL/TLS supported by an SMTP server configured for STARTTLS.  For example, the following command initiates a connection to Gmail's SMTP server on port 587, then upgrades the connection to SSL/TLS via STARTTLS:
openssl s_client -starttls smtp -crlf -connect smtp.gmail.com:587

You can see from the output of the command that the connection is secured using TLS1.3.  So, now we know that Gmail's SMTP server supports TLSv1.3.  So, next, run a similar command, but add the -no_tls1_3 option to prevent openssl from using TLS1.3:
 openssl s_client -starttls smtp -crlf -connect smtp.gmail.com:587 -no_tls1_3

You'll see from the output of the command that TLS1.2 was used to secure the connection.  Now we know that Gmail's SMTP server supports TLS1.3 and TLS1.2,  So, next, run a similar command, but add -no_tls1_2 in addition to -no_tls1_3:
openssl s_client -starttls smtp -crlf -connect smtp.gmail.com:587 -no_tls1_3 -no_tls1_2

You'll see that the connection was secured using TLS1.1.  If you keep repeating the process, eventually you'll get to a point where you've eliminated all of the TLS/SSL versions that the server supports, and the connection will fail.  At that point, you'll know all of the TLS/SSL versions that the server supports.

From the openssl reference that I linked to above, it seems that in openssl 1.1.1, they've added support for LDAP with openssl s_client -starttls.  So, you ought to be able to follow a procedure similar to the above to use openssl to see which TLS versions are supported by your LDAP server.


Is a 2047-bit prime weaker than a 2048-bit prime? I have a safe prime generator I'd like to speed up.  I can benefit from a significant performance gain if the high order bit in the returned prime can be either 1 or 0.  The returned prime would be randomly either 2048- or 2047-bit.

Would this be a problem?  Is the possibility of a 2047-bit prime less secure enough to be concerned about?

This is not for RSA; I will not be multiplying the prime with another.  It's more along the lines of Diffie-Hellman.

Strictly speaking, a 2047-bit prime (with regards to discrete logarithm and the Diffie-Hellman problem) is theoretically very slightly weaker than a 2048-bit prime, since resistance to discrete logarithm increases with the prime size. However, both 2047 and 2048 bits are sizes in the range of "cannot break now, cannot break in 15 years either" (unless a new major, qualitative scientific discovery is done, whose existence and consequences cannot be, by nature, predicted). Stating that 2048 bits are stronger than 2047 bits implicitly assumes that 2047 bits can be attacked in some way, which is not the case. In other words, you cannot compare infinites.

A prime generation algorithm which cannot target a given, specific bit length is strange, though.


Are any container solutions secure enough to run fully un-trusted code, particularly as a VPS service? A number of answers here on this Stack Exchange argue that containers are inherently insecure and one should never run untrusted code in a container, let alone run a container built entirely by someone else.

And yet, there are a number of companies currently offering AWS-style VPS services that use containers instead of virtualization.

Of course, unless you run your own private datacenter with armed guards and don't connect it to the internet, no VPS or rented server is perfectly secure. For containers to be relevant, the possibility of attack doesn't need to be zero, it just needs to be sufficiently small compared to the attack vectors of alternative services.

So the question is: just how safe can containers be? Are there container systems (if so, which ones) which have no known exploits currently, and for which exploits are likely to be fairly hard to craft?

And one specific aspect of the question: At worst, is there any container system in which running an untrusted container can be considered as safe as running un-containerized code as an unprivileged user?

It's quite difficult to discuss containerization security in isolation as essentially the isolation features provided are functions of the Linux kernel (assuming we're talking here about projects like LXD, Docker and Rkt).

It's fair to say that an application in a container on a host is not likely to be less secure than the same application running on outside the container on the same host.

I'd suggest that a well configured container can add considerable security to the overall solution when compared to uncontained processes.

Features such as Linux namespaces, cgroups, capabilities, syscall filtering and Mandatory access control systems (such as AppArmor or SELinux) can all be utilized to help secure processes running in a container.

In a lot of cases it depends on how much effort the operator is willing to put into configuring the container security.  The defaults of these projects tend to favour ensuring that most apps will work seemlessly rather than focusing on absolute security, so there's quite a bit of scope for hardening to be done.


Detecting code source variants of the same function Suppose I have this JavaScript malicious function f1() :

<SCRIPT type="text/javascript">
function f1(){
 a=1;
 b=2;
 c=a+b;
}
</SCRIPT>

This function is embedded within a larger JavaScript program called myScript.
I use a Python script called myScanner that reads myScript and warns me if f1() is present or not.
myScanner works well. But I have no idea how to check all the possible forms of this malicious function in myScript in the case I  change the name of those variables, or simply write the source code of f1() in an other way but that performs the same task.
My question is: how could myScanner detect f1() whatever the changes made on it as long as it performs the same action ?

It is an undecidable problem. It is as difficult as the halting problem.

You can see the question and answers in https://stackoverflow.com/questions/23487045/can-an-algorithm-analyze-the-behaviour-of-a-function-and-say-if-another-function


Is mattermost encryption for group messaging and file transfer secure? Mattermost is an open source group messaging and file transfer service, designed as an alternative to Slack. Their account of their security setup is detailed here. Are the encryption options it offers for the group messaging and file transfer services it offers secure, if it's set up on a secure, internal server?

After reading the security details it seems very secure for me. Just to remark some details:

Using AES-256 Algorithm: AES (Advanced Encryption Standard) is the Standard and most widely used private key algorithm.
RSA with 2048 bit is the most widely used public key algorithm in data transmissions.
TLS: is a high security transmission protocol used widely too.

Logging, History, Updates... also makes mattermost so secure.


Can I sign a new certificate with a previously paid for certificate For the last few months, I have been using self signed certificates to provide ssl for a system that I have been building. We are now getting ready to start getting external users on the system, but this will require purchasing a certificate.

This system will be one of several others that will be running on a sub-domain, but may move to its own domain later on. There will also be several other secured systems running in a similar fashion.

We would also like to put our main site on ssl only too.

So, although I know I can use a wildcard certificate, could I purchase an ssl certificate for the main site, then create a signing request for the sub-domain, and sign it with the purchased certificate, and would that validate for visitors to the sub-domain?

No, the certificates you purchase for SSL are not valid for certificate signing.  This is enacted via usage extensions.

It is possible to buy signing certificates which can be used for that purpose, but it is prohibitively expensive - the certificate authorities do not, after all, wish to put themselves out of business.


I have registered a .com domain and received an e-mail from domainadmin.com I have registered a .com domain and received an e-mail from domainadmin.com, it looks extremely like a phishing e-mail, but after a research I am ultimately confused whether this thing is legitimate or not, it seems as something new for sure.
It basically asks you to click a button, where you agree to some terms and conditions that I don't want to read, as I've got other work to do. There is the contract: http://approve.domainadmin.com/registrant/index.cgi?action=contract
And this is the e-mail I received:

Please read this important e-mail carefully.
Recently you registered, transferred or modified the contact information for the following domain name:
domain.com
In order to ensure your domain name remain active, you must now click the following link and follow the instructions provided.

Did anyone come across?

As Polynomial mentioned, this is part of ICANN-mandated WHOIS verification. The reason it goes to domainadmin.com is that ICANN doesn't actually run the verification -- rather, like just about all ICANN things, they set policies that are then implemented by others (remember, your .com domain is in a registry operated by Verisign, and was registered by a registrar who was neither ICANN nor Verisign). It's the registrar's job to verify certain WHOIS info; the relevant policy is here, and they must suspend your domain if they can't verify the info.

The reason you're seeing domainadmin.com is that whoever you bought your domain from is likely reselling them from OpenSRS (which basically exists as a platform for domain resellers), which is a label of Tucows. As the registrar, Tucows is responsible for WHOIS verification on domains bought from them; because OpenSRS is mostly a platform for resellers, they generally do so via domainadmin.com (which they own, and which is intentionally white-label). Source 1, and a discussion on their site about this domain choice.

So, this email is likely legitimate, and you need to do what it says or your domain will be suspended. domainadmin.com isn't affiliated with ICANN, it's affiliated with your registrar (you actually bought your domain from a reseller of this registrar). It's intentionally generic because some resellers want a generic thing; resellers who want non-generic have the option to make it non-generic, but most resellers don't want it showing OpenSRS or Tucows prominently.


Security against local attack for remote FDE decryption? Is there any remote FDE decryption that is resistant to an attacker that has local physical access?
Tools like dracut-sshd need to store the private key used for the sshd server on the unencrypted boot partition, so a local attacker has the ability to become a MITM and sniff the decryption password.
Can using a TPM to protect the sshd key foil this attack?
Does clevis-tang have essentially the same problem? At the bottom of the tang README.md is this list of security considerations:

Man-in-the-Middle
Compromise the client to gain access to cJWK
Compromise the server to gain access to sJWK's private key

Problem (1) is not a concern according to this document. I assume you avoid problem (3) by running the tang server on a FDE itself or storing the key on a HSM. Problem (2) sounds impossible to protect against if the attacker is local - is that correct?
The tang documentation stresses that the...

client protect cJWK from prying eyes. This may include device
permissions, filesystem permissions, security frameworks (such as
SELinux) or even the use of hardware encryption such as a TPM

Is the TPM option the only way to foil an attacker with physical access to the unencrypted boot partition?
Is there any work-around that allows remote unattended FDE decryption that a local attacker cannot compromise?

According to this helpful blog about using TPM to auto-decrypt FDE disks, a local attacker can replace initramfs (because it resides on the unencrypted boot partition) and decrypt the disk even though the key is in TPM. I think this means all methods (dracut-sshd, clevis/tang, etc) suffer the same weakness.
(Anyone care to point out which method they consider lowest risk?)
The article claims there is no fool-proof way to accomplish what is being asked by this question -- yet. It lays out a couple ideas that people are working on for future iterations of the technology.


TLS 1.2 and enable only AEAD ciphers suite list A company have made a vulnerability scan and give us a report that, recommends to use TLS 1.2 and enable only AEAD ciphers suite, but they aren't giving more information about what I need to achieve this.

I haven't found the list of this ciphers suites, that are compliant with this requirement. Also want to know if there is way to identify, with the name of the suit if a suite is compatible with AEAD.

Don't do this.   At least, don't do this on any system where you don't know for sure that it's not going to break things.

AEAD stands for "Authenticated Encryption with Additional Data" meaning there is a built-in message authentication code for integrity checking both the ciphertext and optionally additional authenticated (but unencrypted) data, and the only AEAD cipher suites in TLS are those using the AES-GCM and ChaCha20-Poly1305 algorithms, and they are indeed only supported in TLS 1.2.   This means that if you have any clients trying to connect to this system that don't support either TLS 1.2, or even those that do support TLS 1.2 but not those specific cipher suites (and they're not mandatory...Only TLS_RSA_WITH_AES_128_CBC_SHA is mandatory, and it isn't an AEAD cipher suite) then those clients will not be able to connect at all.

It is true that these are the most secure options, and indeed the only options that will be supported for TLS v1.3, but for most systems today, this is not a realistic configuration.   You do certainly want to enable TLS v1.2 and these cipher suites if you have an option to do so (configuring them is going to be specific to your system, so check your documentation) but as a rule, you should not require them unless you really know what you're doing and understand both your environment and the effects.


I use VPN+Socks5 proxy for torrents in Utorrent. What is the security risk? So my setup is essentially

MyPC -> VPN Server -> Remote SOCKS Server in Utorrent -> Destination torrent swarm

The VPN server is a well known "no-logs" provider, the country is the Netherlands and i have a different gateway/entry and exit ip when i connect.

I use the "elite" Socks5 proxy (which supposedly omits the header) ONLY for Utorrent, nothing else.

And it works perfectly with good speeds, its a simple IP:Port addition in Utorrent, and i do all hostname lookups and p2p everything only through the proxy server in Utorrent.
(I know and have ticked all the right tabs in bittorrent and connection tabs, and i use forced encryption thats in Utorrent, which i know, means very little but nevertheless i select it.)

I have verified that during torrents download, the IP that appears in the peer swarm, is this Socks5 server in another EU country, like Czech Republic.

So, my Utorrent traffic is a tunnel nested in an encrypted VPn tunnel, and at no point is the VPN ip exposed in Utorrent swarm. Although i understand that the proxy server knows and can see my VPN IP in the Netherlands. That doesnt bother me, because its not my home IP.

Is there any security risk in this nesting of socks5 Utorrent proxy in the VPN tunnel that makes me MORE vulnerable, instead of using simply the OpenVPN tunnel for torrents?

Running a SOCKS5 proxy inside of a VPN is a pretty common setup, and can provide pretty good security since in theory you wouldn't be relying on a single entity for your anonymity.

If you pay for the SOCKS5 proxy, and some authentication is used, then that may be a week spot if that could be connected to an identity.

DNS leaks are one thing to be careful of, since they aren't always tunneled correctly. WebRTC is usually another thing to look for, but as long as you're only using BitTorrent traffic on the VPN it's not an issue.

One last thing to note is that this VPN should only be used for BitTorrebt traffic. If you have any unencrypted HTTP traffic you increase your risk from an attacker who is monitoring the VPN output (before it hits the SOCKS5). An attacker could use WebRTC or a browser fingerprinting technique to at least track and coorolate your traffic. Then if you ever connect without the VPN, and the attacker compare the fingerprints your IP may be exposed.

Overall VPN+SOCKS5 is going to be good enough protection for the vast majority of people seeking for privacy in their BitTorrebt traffic.


Why does my home Ubuntu installation says my chosen hostname resolves to an external IP? I am installing Ubuntu 16.04.3 on a desktop. When I get to the step where I am prompted for a hostname, I randomly type in "fortknox" but the Ubuntu installation says "That name already exists on the network."

Here is some background that may be relevant. My fiber connection to the Internet was installed by AT&T a few days ago. The modem is an Arris BGW210-700. All of my computers are behind the router's firewall and are assigned IPs by the router's dhcp such as 192.168.1.84 and so on. I confirmed the IP address 192.168.1.84 was assigned to the new Ubuntu box by looking at the modem's HTTP device webpage.

The router/modem is located in another room. I am using a USB wifi dongle to connect to the router on the Ubuntu box. When I got the message saying the hostname "fortknox" already exists on the network, I went to another Linux box and did 'ping fortknox' and got a response back from IP 104.239.207.44.

Did an ARIN lookup (https://whois.arin.net/rest/net/NET-104-239-128-0-1/pft?s=104.239.207.44) and found that the IP address is owned by a big datacenter here in town named Rackspace. This raises a number of questions for me.

Is my wifi dongle on my new Ubuntu box getting spoofed? Since I am able to confirm the IP was assigned by the ATT router/modem, I don't think so.

Is my new Ubuntu box visible from the Internet?

I don't have in-depth understanding of networking protocols but it seems very suspicious that my new Ubuntu installation inside of my home network can't use a hostname on an entirely different network.

The way hostnames work in GNU/Linux is kinda silly.  The system itself only knows of the hostname, not the fully qualified domain name (FQDN).  In your example, your hostname is 'fortknox'.  To get the FQDN, for example, if you run the 'hostname -f' command, what happens is it uses the resolve to resolve the address of your hostname, then uses the resolver to get the reverse of that to translate the address back into a domain name.  Since you don't have your hostname in your '/etc/hosts' file, it is using DNS and looking at /etc/resolv.conf.  It will search any 'domain' or 'search' listings in '/etc/resolv.conf' until it finds an address that matches that name.  For example, if you had "search example.com" and "fortknox.example.com" matched an address "256.0.0.1", it would then go on to reverse lookup that address and find "fortknox.example.com" or it may even find another FQDN that has nothing to do with either "fortnox" or "example.com".

In order to solve your problem, there are a few options.  Most people just add their hostname to their "/etc/hosts" file so that it resolves to "::1" or "127.0.0.1".  Another thing you can do is edit your "/etc/resolv.conf" and take out the "domain" and "search" entries that you don't want to be searching.  Since you are getting this error during install of the operating system, you are probably getting your "domain" and "search" from your DHCP server.  In that case, you can edit those settings on your DHCP server.  If you don't have access to the DHCP server, the easiest thing you can do it just choose a different name.


Identity exposure by using same proxy? I read several times it is a very bad idea and a huge lack of security to use the same proxy for logging into facebook or other sites containing information about real personal details e.g. linkedin and other sites e.g. Stackexchange.

What is the issue with that? E.g. I use an browser plugin and a desktop client Premium-VPN as well, both from the same company. So I am behind two encrypted proxies. And as far as I understand the technology, many other VPN-users are using the same end-node, too. E.g. I log into Facebook, linkedin and stackexchange at the same time with the same two proxies. How can this data linked together and directly point to me, my real location and identity?

Edit: Because someone asked "where I read this": One example was this german youtube video at 9:00
He says, that's stupid to login into facebook via tor, because this definitely identifies you.
But why is this stupid? Because you are not the only one using this end-node.

Basically I don't get why am I traceable, when using the same proxy for multiple actions.

Think about it from the point of view of a law enforcement agency. They want to show that you, a suspect, might have accessed an illegal site, but all they know is that someone coming from a Tor node at a given time did it.

If no-one using that Tor node accessed any sites which require login, all they can say is that "someone" did it. If on the other hand, they ask various social media networks for data of people who logged in from a given Tor node at a specific time, they can link the use of that node to specific people. Now, they can't be sure that any of these users are the same as the one who visited the illegal site, but you can be pretty certain that those people are going to be much higher up their lists than anyone who isn't known to have been using the node at that time.


What questions should I ask a prospective vendor that handles billing and fulfillment? My company is currently looking to integrate a third-party vendor into our billing and fulfillment process. The vendor will be assuming responsibility for processing orders in our merchant account and handling sensitive customer information (including cardholder data).

When interviewing potential third-party vendors, I want to ask them probing questions to gauge how effective their security is. Obviously I could ask them if they are pci-compliant and just leave it at that; but I've  encountered several vendors that claimed to be pci-compliant, only to find out that their security was atrocious (see: plaintext cardholder data).

Instead, I would like some ideas for tough questions that only a real security-minded company could adequately answer. For instance: do you have a disaster recovery plan, or can we see the results from your last system vulnerability scan? Basically something where they can give me a tangible response that shows compliance.

What questions would you recommend for vetting the security practices of a third-party vendor who will be handling sensitive customer information?

First if they claim to be PCI Compliant ask for the latest version of a filled out questionnaire and their current quarters scan results. Based on the depth of how they filled out the questionnaire you should have some understanding of how competant they are.

Also press if they have external audits? Do they employ external companies to do manual pentests and more importantly social engineering?

If they are handling billing and processing they will be handling customer data. Ask them about how they encrypt it. What are their access control policies? Do they use two factor authentication?

Check if there is a training regimen for their order processing staff on security. Typically people doing billing and order processing are not technical or savvy on security. These are low/mid wage users with little care as to your companies data. If I called in and claimed to be customer X how hard would it be for me to get their information?

Also ask for al ist of their senior management. Who is their CTO, CSO etc? Research their backgrounds. See if they have a history in companies that are security oriented or if they hopped around a ton and seem to be fly by night mercenaries.

Ultimately see how willing and comfortable they are to share all this. SOme might hide behind a "We can't show you because it would violate security" excuses but if they are serious about handling your data you have a right to inspect their security on the surface.

A real good quickie is to see if they ask for an NDA or MNDA if they just hand over information chances are they won't be that diligent. If they ask for an NDA before handing all this over at least they have a documented legal process behind the scenes which is always a good first start.