Can using emojis make someone's password safer? I was just thinking about this the other day, after reading about making safe passwords, you have a few options:
The first would be, adding numbers, or something other than just a word

Password15068 or Pa55w0rd15068 or Passw0rd15068

But I believe the general consensus is that the more random, L337 speaky you get, the harder it is to remember.
The next method I read was taking 4-5 words and combining it to a phrase or a single word, say our 5 words are "dog" "walks" "in" "the" "yard". Possible passwords could be:

Dog walks in the yard or Dowainthya or some other jumbled combo...

But this poses the same issue of hard to remember. So it got me thinking, I don't think I'd ever do it, but is cracking software advanced enough to assume an emoji is 1 character? or would it read it out in unicode. Another thing is say I use this emoji:  this generates to this code xn--ss8h so would the password "Password" be read as 9 letters/nums? or 17?

Password or Passwordxn--ss8h

If it were to be read as the unicode, that would add an extra amount of letters for a cracker to have to guess. (assuming it's a brute force attack). Even in the event where the BF cracker finds the password Passwordxn--ss8h would entering that in a password slot not let you log in because it's not the matching emoji?
This is obviously a theoretical situation, I don't think i'd ever actually condone this, but I think it could definitely help in the future when, instead of the password happyfacemoneybags you could use:  or xn--ss8h7u but the system would only let you log in if the correct icons are in the slot.

Update 1
This is in reference to running the possible passwords through a password checker.
Control Password: hellohello
hellohello generates a score of: 0% and a complexity of "very weak".
Some key things to note:

I gain a bonus of +40 due to length
I am deducted a total of -52 due to letters only, consecutive lowercase and repeat words

hellohello generates a score of: 42% and a complexity of "good".
Some key things to note:

I gain a bonus of +64 due to symbols, lowercase, and length
I am deducted a total of -24 due to consecutive lowercase and repeat words

HelloHello generates a score of: 80% and a complexity of "very strong".
Some key things to note:

I gain a bonus of +94 due to symbols, lowercase, uppercase, and length
I am deducted a total of -18 due to consecutive lowercase and repeat words

HeLLoHeLLo generates a score of: 88% and a complexity of "very strong".
Some key things to note:

I gain a bonus of +98 due to symbols, lowercase, uppercase, and length
I am deducted a total of -10 due to consecutive lowercase and repeat words

Based on this password, clearly adding the symbol  is making it a little bit more secure, but I am not sure what algorithm this password checker is based off of.

The difficulty of cracking a password is measured by the entropy in the process used to generate it. This can be measured for most passwords by taking the base-2 logarithm of the number of symbols raised to the power of the number of symbols used. For instance, a randomly-chosen password consisting of 8 lowercase letters has log2(26 ^ 8) ~ 38 bits of entropy in it.

This method can be extended to "correct horse battery staple"-style passwords. In this case, each word is itself a symbol, chosen from a dictionary of the 10,000 most common words. A password generated randomly this way would have log2(10,000 ^ 4) ~ 53 bits of entropy, and be significantly harder to break.

Hopefully by seeing these two examples, you can see that dramatically increasing the base has a far, far smaller effect on password entropy than modestly increasing the exponent. This is important, because by adding additional symbols to choose from (uppercase letters, digits, symbols, and at the extreme, non-Latin Unicode code points like emoji, RTL markers, kanji, etc.), you're increasing the base and not the exponent. This will generally make your password harder to crack, and may even make it more memorable to you, but increasing the length (and thus the exponent) will help even more.

For instance, by including lowercase letters (26), uppercase letters (26), digits (10), common symbols (32), and a handful of emoji (say 200, for example's sake), a random eight-character password will have log2(26 + 26 + 10 + 32 + 200) ^ 8) ~ 66 bits of entropy. On the other hand, simply doubling the length of a password consisting only of lowercase letters would result in a password with log2((26 ^ 16) ~ 75 bits of entropy, which is over five hundred times more difficult to crack.

While adding emoji can make a password stronger, it's not as effective as simply increasing the length. It won't turn a terrible password like Password15068 into something meaningfully more difficult to crack. And it simply won't work in many real-world password input fields (some will reject it outright, and worse, many others will silently ignore the character). Furthermore, a two-character password like  will never be secure, for the simple reason that there are only a handful of emoji to choose from; even if you assume ten thousand of them, you're left with a password with only log2(10,000 ^ 2) ~ 27 bits of entropy.

Your best bet is to simply use a password manager. Humans are terrible at memorizing complex passwords, but computers are great at it. Password managers give you the benefit of strong, unique passwords for every site you visit and remove the weakest component from the chain: the human.

Update: I didn't make this clear in the original post, but linear increases in entropy represent exponential increases in difficulty to crack. A password with n bits of entropy requires 2^(n-1) operations on average to crack, so each time the entropy increases by one, the effort required to break the password doubles.


Which tool (apart from nmap) can I use to scan a range of IPv6 addresses? When I try to use nmap:

# nmap -sP -6 FE80::1-234
[...]
Failed to resolve given IPv6 hostname/IP: FE80::1-234.  Note that you can't use '/mask' or '[1-4,7,100-]' style ranges for IPv6.[...]

What other tool can I use?

There was an interesting presentation from Metasploit on this recently (blog post is here)

From that there are a number of techniques that nmap can use to identify IPv6 hosts on the local network which could be of use to you

Scanning your local subnet for all IPv6-enabled systems in one shot:

nmap -6 --script=targets-ipv6-multicast-*

Port scanning the top 10000 ports on these assets:

nmap -6 --script=targets-ipv6-multicast-* --script-args=newtargets -PS --top-ports=10000


Yes, this is possible.

The XAdES standard uses regular expressions to describe the various forms. This is how the SignedInfo field of the XAdES-X forms is described:

< ds:SignedInfo >

  < ds:CanonicalizationMethod/ >

  < ds:SignatureMethod/ >

  (< ds:Reference URI? >

    (< ds:Transforms >)?

    < ds:DigestMethod >

    < ds:DigestValue >

  < /ds:Reference >)+

  < /ds:SignedInfo >

The '+' after the reference field means that this field may appear once or more times.


Why does the NodeJS Crypto docs use CBC instead of GCM for RSA key-pair? I have read that GCM is almost always more secure than CBC when implemented correctly.

However, in the documentation of NodeJS, CBC is being used as an example instead. The key-pair will be stored in the node environment.

Since the private key is being stored locally and CBC is an acceptable encryption for local files according to this answer,  is it a secure enough implementation, or should GCM be used such as in this sample code?

The Cipher-Block-Chaining Mode becomes problematic if your threat model includes an attacker who actively manipulates the encrypted data. This allows an attacker to flip specific bits in the cipher to flip the same bits in the resulting plaintext - a property called malleability. If not paired with a MAC to ensure integrity, CBC is not very secure.

When encrypting a private key to be stored on a local device, the only requirement is confidentiality. An attacker could flip specific bits, but it is most likely that this will result in the private key becoming unusable instead. CBC is still good enough at providing confidentiality, and without the AES-NI extension, it's a lot faster than AES-GCM, as you can see in the following graphic:

Source: kazoo.ga

To give a succinct answer: Node.JS uses AES-CBC because for this case, the extra benefits offered by AES-GCM don't matter and AES-CBC is usually faster.

In the above graphic, the performance of AES-CBC without AES-NI is used as 100% performance. The relevant other category is AES-128-GCM w/o AES-NI. Of course, if NodeJS supports AES-NI, then AES-GCM is a better choice.


The use of DES-CBC3 for TLS When researching some TLS compliant software I found some mentions of DES-CBC3. Further research shows that it is probably simply a name of OpenSSL for 3DES-EDE-CBC (under section "CIPHER SUITE NAMES" which I cannot directly link to).

It seems to me that executing 3DES-EDE in CBC mode is significantly different from performing DES-CBC three times so the name doesn't make any sense.

I've got the following related questions:

Is the string DES-CBC3 only specific to (software using) OpenSSL?
Is it somehow tied to a specific version of SSL / TLS?
(Optionally) Does anybody know why it is called DES-CBC3?

DES-CBC3, is a shorthand for a few suites in OpenSSL (that doesn't always have an exact one to one mapping between the name used and the suite used, it constructs it from the name and the type of key used for authentication). Nowadays, this name almost always means a suite documented in RFC 6101 where it is called, a slightly better name : SSL_RSA_WITH_3DES_EDE_CBC_SHA. I have no idea how OpenSSL came with its shorthand (and I suspect it dates from before OpenSSL was OpenSSL), but it's a pretty bad one.

The RFC name gives you the hint that it's using 3DES (Triple-DES) in EDE mode.

3DES-EDE is using 3 56 bit keys, the first used in Encryption, the second in Decryption, the third in Encryption. This construct has the advantage that if all three keys are identical, you have DES, which is nice as it permits to reuse the same hardware to do DES and 3DES.

To answer each point

Only OpenSSL calls it that, not the name used in the actual standard
Valid from SSLv3 and up
You'd need to read the history of OpenSSL back when it was libeay, this is extremely old code, this was likely a mistake but it stuck.


How to bypass tcpwrapped with nmap scan I ran a scan with
nmap -n -vv -A x.x.x.x --min-parallelism=50 --max-parallelism=150 -PN -T2 -oA x.x.x.x

With the following result:
Host is up (0.032s latency).
Scanned at 2012-10-25 16:06:38 AST for 856s
PORT      STATE SERVICE    VERSION
1/tcp     open  tcpwrapped
3/tcp     open  tcpwrapped
4/tcp     open  tcpwrapped
.
.
19/tcp    open  tcpwrapped
20/tcp    open  tcpwrapped
21/tcp    open  tcpwrapped
22/tcp    open  tcpwrapped
23/tcp    open  tcpwrapped
.
.
64623/tcp open  tcpwrapped
64680/tcp open  tcpwrapped
65000/tcp open  tcpwrapped
65129/tcp open  tcpwrapped
65389/tcp open  tcpwrapped

Scan methodology was
I'm sure that this is a firewall's or load balancer's game.
I tried many ways, such as change source port, source IP, fragmentation, etc..

Do you have any idea/suggestion to bypass this case?
On another hand, do you know how to do that in a firewall policy (on any firewall)?

"tcpwrapped" refers to tcpwrapper, a host-based network access control program on Unix and Linux. When Nmap labels something tcpwrapped, it means that the behavior of the port is consistent with one that is protected by tcpwrapper. Specifically, it means that a full TCP handshake was completed, but the remote host closed the connection without receiving any data.

It is important to note that tcpwrapper protects programs, not ports. This means that a valid (not false-positive) tcpwrapped response indicates a real network service is available, but you are not on the list of hosts allowed to talk with it. When such a large number of ports are shown as tcpwrapped, it is unlikely that they represent real services, so the behavior probably means something else.

What you are probably seeing is a network security device like a firewall or IPS. Many of these are configured to respond to TCP portscans, even for IP addresses which are not assigned to them. This behavior can slow down a port scan and cloud the results with false positives.

EDIT: Since this post was flagged as plagiarism and deleted, I would like to point out that the assumed source (this page on SecWiki.org) was also written by me. This Security.StackExchange answer (October 31, 2013) predates that page (November 12, 2013) by nearly two weeks.


How effective would a heartbeat sensor be at stopping spam? Making an android app (for fun) that communicates with a server I am trying to come up with out of the box security ideas, one of them would be to use a heartbeat sensor instead of a captcha for avoiding spam. How effective would it be? It is not a password, just a mean to prove me as human. For my app it doesn't need to be very strong (just a competition between siblings) but would this be usable in large scale apps?

As the comments say, security needs to be done server-side, not client-side.

If somebody wanted to send spam to your server, they would not use your app to do it, they would sniff the data packets that your app is sending to the server and then build their own app that sends those same packets with their message instead.

For this reason, in security analysis we always treat the client as if it is malicious and make sure the server is not relying on the client to perform the security checks. In the case of a captcha, the results are sent to the server to be verified before it will process your request. You could send the heartbeat data to the server, but I'm not sure what that accomplishes because the spammer could just record a heartbeat and send that over and over. You could also probably make a heartbeat generator pretty easily based on a random number generator.

Inventing new security technology is hard, it takes a lot of people and a lot of failed attempts to get it right. There's an old saying "Anyone can create something that they themselves can not break, but creating something that nobody can break is much harder". I like that you are thinking outside the box and asking questions. Keep exploring :)


Preventing JavaScript execution with JavaScript? In a comment on this question dealing with XSS prevention, @dandavis suggested:

  if your script runs first, it's easy to break following scripts

The idea is to provide a fallback that prevents (inline) JavaScript for browsers that do not support CSP.

I know that it is possible to overwrite existing functions, but it's not clear to me how exactly this would work. Is there a trivial solution that 100% prevents any further script execution? If not, are there solutions that work in most contexts or for most browsers (and ways to bypass them for other contexts/browsers)?

The idea is to provide a fallback that prevents (inline) JavaScript for browsers that do not support CSP.

Bear in mind that CSP is not to be used as a first line of defense. You should properly encode per context to prevent XSS in your application. OWSAP has good information on this.

That being said, CSP can be a good fallback to make XSS much less serious, should an XSS vulnerability (i.e. wrong or no encoding somewhere on your page) be found in your application and exploited.

  I know that it is possible to overwrite existing functions, but it's not clear to me how exactly this would work.

It is very easy to do. For example, XMLHttpRequest = myFunction, or XMLHttpRequest = null would prevent scripts from using XMLHttpRequest directly.

The problem is that if an attacker may not be using that particular function, and if the attacker knows you are doing this, he could easily use an alternative method.
While it might be possible to overwrite all functions, it is not recommended as a reliable solution.

  Is there a trivial solution that 100% prevents any further script execution?

If you have a syntax error in your <script>, then nothing in that <script>...</script> will run. Unfortunately, with XSS, the attacker could easily start a new <script> that would work just fine.

Also there are many many ways to inject JavaScript besides <script>, for example <img onload> or onerror.

To my knowledge you cannot reliably stop all following HTML from containing XSS execution.

  If not, are there solutions that work in most contexts or for most browsers (and ways to bypass them for other contexts/browsers)?

CSP version 1 browser support is starting to get good, and since CSP was designed as a backup anyway (not a first line of defense) you may be able to stop your search there knowing that browser support will be a shrinking problem.

That being said, I think the idea of overwriting functions could go a long way towards success. It seems like that could work reliably in theory. While this is not recommended, I think it would be an interesting study. I wonder how complex it would be to implement.


Are auto-type features of password managers actually effective against keyloggers? Of course if you think of a "keylogger" as a program that can only read keystrokes, then copy-pasting on the clipboard is going to be enough. But we know that keyloggers are not really only "logging keys" anymore, and they can even follow mouse movements, take screenshots, etc.

I think KeePass for example uses some kind of obfuscation, but it's nothing really secure. Here's what they wrote on the official website:

  Anyway, it's not perfectly secure (and unfortunately cannot be made by theory). None of the currently available keyloggers or clipboard spies can eavesdrop an obfuscated auto-type process, but it is theoretically possible to write a dedicated spy application that specializes on logging obfuscated auto-type.

I don't know when that was written, but I bet in the meantime lots of keyloggers that target this kind of obfuscation have been written, have they?

Then there's KeePassXC, which if I'm not wrong uses a totally different way of sending data to applications, without relying on simulated keystrokes or the clipboard. I don't know the details, but I wonder if that method is actually secure and if in the meantime any keyloggers that target it have been created.

So the question: are any of those auto-type methods of password managers actually effective, or is it like fighting a losing battle?

First of all, if you have malware in your computer, it is kind of futile to try secure anything against it, especially if it manages to get admin privileges. A process with admin privileges can read pretty much whatever it wants.

If the "key-logger" does not have privileges, there may be a way to securely type in passwords, if the browser supports it. In essence, let's say Chrome allows extensions to detect input fields and type into them. That would allow KeePass to input passwords without simulating anything and without ever going outside the Chrome process. If in addition the password is exchanged between KeePass and the extension securely (which chromelPass already does), then the passwords are safe from non-privileged key-logger.

That being said, this is kind of a perfect world scenario. First of all, I don't believe extensions can actually input data into input fields in any browser. I am not sure, but think it is possible to input and chromelPass does it. However, if you have malware in your PC, it is unlikely it would not be able to gain admin privileges.

So in a way, it is futile in theory, but in practice, most people only need to be protected against common types of key-loggers and you should always do your best not to get infected in the first place.


Keyboard firmware hack - Linux vulnerable? I see that Apple patched OS X to mitigate against K. Chen's famous Apple keyboard firmware hack.

However:

Apple keyboards can be used with computers running other operating systems; and
in any case, other manufacturers' keyboards may be similarly vulnerable.

What protection does Linux have against:

A remote attacker attempting to deploy malware onto a computer's keyboard (e.g. would the attacker be unable to do this without root)?
A compromised keyboard being plugged in to a clean computer?

Nothing.

If you cannot trust your hardware, you cannot trust it.

There does not exist a universal way of updating keyboard controllers, and certainly there is no universal introspection for them.  While you could reflash those keyboards that are reflashable every time the system boots or a keyboard is plugged in, you'd have to come up with a way to do this for every flashable keyboard, not to mention trust the "clean" firmware, and then you'd have built into your system a way for an attacker to flash the keyboard.  This is likely not a productive use of time.

The hack described merely causes the keyboard to act as a hardware keylogger, if I read correctly.  Apple's patch requires that users have elevated privileges to update the keyboard's firmware, as it should be.  Linux, to my knowledge, doesn't have widely-used drivers for doing such an update, and if you don't want one to ever be done, don't compile such things into your kernel (or load modules for it).  You already need root to load modules or update the kernel (typically).

The best way to guard against such things as these is to protect access to your hardware (to prevent retrieval of logged keystrokes).  If there were a way to inspect the data in the keyboard remotely without the user noticing, that would be its own bug to be patched.

This problem is somewhat unique to Apple, who have created a high level of homogeneity for attackers, given attackers access to exploit it with only normal user rights (since patched, as cited), and created keyboards complex enough to facilitate such an attack.  You could guard against it by using a simpler keyboard without flashable firmware, if you're worried about such things as this.


WLFriends encrypted login risk I recently had created on WLFriends.org which is presented by Wikileaks, I noticed a big thing there that the process of signing up at WLFriends was very distinct from the other normal sites. There, they asked my language, place, contact details, my short bio and email and after completing these tasks they provided me a key, which was having the mixture of both capital alphabets and numbers, So I want to ask that that isn't there is any risk of getting my ID hacked if someone randomly try to put any numbers or letters. By chance if someone tries to randomly type any letters or number wouldn't the hacker would be able to acquire mine or someone else key?

How long is the key they provided? The strength of that key is the strength of any alphanumeric password of that length. Theoretically, anyone that random types characters may be able to guess your gmail password or any other password, but because the number of possible values is very large, the chance of doing so is very small (unless your password is "12345").

By having a key consisting of only letters and numbers, the possible password set is reduced, but if the key is long enough and random enough, you should be ok.

The strength of the password protection is actually given by many factors, the password strength being just one of them. A few others are:

Does the account block if you try a lot of keys? Are the keys associated with usernames, or they are the single information you need to access the website? Is https used (I saw that it is)?


VM vs System Call Interposition vs Software Fault Isolation I have an exe file that I don't trust (maybe its infected with malware). I know that running it in a VM will isolate the exe file from my system, but what about using mechanisms such as System Call Interposition or Software Fault Isolation?

Is either of them suitable for sandboxing the exe file?
Are there any advantages or disadvantages between them and using the VM?

This may depend on what you are trying to do.  Analyse the binary to determine if it truly is malware or just run the code without letting it affect your system.

I think with SFI you might run into a problem where the suspected malware uses an undocumented opcode and the SFI therefore refuses to run the code as it cannot analyse it.

With System Call Interposition you can rewrite operating system calls but unless you use interpositon to create a complete container you need to be able to identify which system calls are dangerous before allowing them through. This may not be obvious.  Even using Interposition to create a container may fail if the code exploits a subtle kernel bug.

I think VMs would present a smaller attack surface than OS kernels and since modern cpus provide hardware support should protect even against undocumented opcodes.

In the days of Spectre, Meltdown and Rowhammer you probably still need to be wary though.


How to safely display html emails? I'm building a webmail application using php at the moment. I'm getting the email content from gmail using Imap and wanted to display the email as close as I can to how gmail shows it. Is it safe to display the raw html body from the email or is there additional steps I should take to ensure my application is secure from attacks?

I also looked at this question "how-to-safely-display-html-emails-like-gmail-does-it" but its from 5 years ago and couldn't find any recent sources on the topic.

You need to sanitize the content before embedding it in your HTML output, otherwise you are guaranteed to have XSS vulnerabilities in there.

Please do not reinvent the wheel, as there are great sanitizers out there, that you can utilize. I highly recommend using DOMPurify, which is also integrated in several widely used JS frameworks to reliably protect against XSS. It aims at being secure by default, but also offers capability for configuration and fine tuning.


How does union select statement output vulnerable columns How does union select statement output vulnerable columns in sql injection

Consider a SQL vulnerable site.

Let the number of columns in the query be 3.

So the statement goes, www.test.com?php.id=-1' union select 1,2,3 --+-

My understanding of this statement is like this.

There are 2 statements
Union is used to join both statements.
(-) is used to null the value of the first statement.
' is used to break the query and input a second statement and --+- is used to comment out the rest of the statement.
Upon inputting this statement, The website displays 2 and 3 as vulnerable columns.

What I don't get is that how a select statement displays the vulnerable columns.

This crafted query allows you to distinguish which fields resulting from the original query are actually displayed on the page.

At a latter step, you will indeed replace some of these numbers by more specific requests in order to get some information. However you will obviously prefer that this information will be displayed by the vulnerable app and not consumed in some internal treatment.

If you know that the first column value is not displayed, but the value contained in the second and third one are, you can proceed by using these second and third column to collect some information regarding, for instance, the database structure.


What vulnerabilities do distros categorize as causing a program to "crash, resulting in a denial of service, or possibly execute arbitrary code"? When reading distro security list mails, I frequently see that a discovered vulnerability could cause foo to "crash, resulting in a denial of service, or possibly execute arbitrary code".  This exact phrasing is used verbatim across quite frequently, but usually there's not much additional info.

What kind of vulnerability are they talking about?  Is this a buffer overread?  Use after free?

The label is pretty transparent, but yes, I think you are right in assuming it's mostly memory management problems. These are the most frequent cause of crash, as it will either cause the OS to kill the buggy process, or the program itself to crash trying to process corrupted data.

In most FOSS projects, you will be able to get more details on each vulnerability. When you encounter one, look closer to discover which type of bug it is.


Attaching the same file to two separate email, does it compromise security of the "message" When using (Thunderbird and) GnuPG to send a PGP/MIME message to two separate recipients, with the text body different in both messages, but the same file attached to both of them, does this give an outside attacker that observes the traffic any additional advantage without knowledge of the plain text?

I realize that this allows attacker to guess I sent the same file (emails beyond a certain size can be guessed to contain attached files anyway). But what I am interested in is whether this gives an attacker a tangible advantage of any kind that could allow to retrieve the plain text?

Keys used are RSA, recipient key is 2k, mine is 4k.

Update: I retract that. PGP uses symmetric encryption for the payload. So the real reason that both messages are different, is that each e-mail is encrypted using a different symmetric key (session key), which is in turn asymmetrically encrypted.

Without having checked that, I think it is safe to assume that GnuPG uses padding with RSA (OAEP probably). This padding will make sure that the two identical files are not encrypted identical in both messages. You should see that when comparing the ciphertexts.

Also see this particular question on OAEP and RSA for more clarification.


SCADA, ICS Specfic Testing Tools and Methodologies I have been contracted to perform a security risk assessment that relates specifically to ICS and SCADA systems. I have performed many IT security risk assessments, however, I am new to assessing these types of environments specifically. I am familiar with ICS like devices and I believe I have a cursory understanding of functionality and some of their inherent challenges.

My question is for those who do this everyday, work in such an environment or have assessed an ICS environment before.

Are there specific tools that are useful in this type of assessment that are not obvious? I have done some searching and have read through the NIST standards for assessing ICS. I have also found the DHS tool CSET (which looks to be more of a self-assessment tool, but may have some useful features like the diagramming tool).

Also, is there a specific standard that is generally followed for this type of engagement?

Before anyone steps up on their security guy soapbox, this entity is well aware that this is my first ICS engagement and that I have been assessing unique IT environments for many years. I also have strong back-support from my team that is highly experienced in this type of engagement. I'm sure they will have many ideas for me as well, I just wanted to put this out there for public comment.

Thanks!

Reader's Digest:

What specific tools exist for Scada / ICS assessment?

What specific standards are generally acceptable for a Scada / ICS risk assessment?

Obviously, I recommend the SamuraiSTFU project for study, including the Penetration Testing with SmartGrid & SCADA training. Took mine from Justin Searle last week.

What I learned is that domain knowledge in several areas is key.

Security posture audits, e.g., BITS FISAP, CIP CVA, IT COBIT, COSO, VisibleOpsSec. Typically, the cliche CISSP fits well here as a prerequisite (i.e., 5 years of experience in information security management and risk management with the capability to be driven by continual learning/improvement and possessing a strong ethical framework/backbone)
Network capture assessments (the new Syngress Press title, "Applied Network Security Monitoring" and the past summer's release from NoStarch, "The Practice of Network Security Monitoring" are great places to start as they explain how to implement SecurityOnion, an Ubuntu distro specially designed for these engagements). Reliable, repeatable FPC (e.g., Netsniff-NG) to gather Tenable PVS and PRADS data that feed Squert might be all that is necessary, although certainly you can take this much further with the CERT NetSA Security Suite, NetWitness, Lancope, Arbor, 21CT, et al
Network penetration testing (many books and resources on this subject, particularly popular and relevant is Offensive Security -- the team that makes Kali Linux). CAVEAT EMPTOR: you probably want to convert any production networks to lab networks by using VMware Converter or similar. Testing on live, production industrial control or automation systems is contraindicated
Web and application penetration testing (many books but I usually recommend TAOSSA -- the Art of Software Security Assessment -- and resources such as OWASP). In my opinion, it does not matter which tools you use but if you plan to fault inject then you should be an expert at OWASPBWA and Web Security Dojo (e.g., Checkmarx, Contrast Security, Burp Suite Professional, NTOSpider, Netsparker, Appscan, sqlmap, et al) and if you plan to fuzz then you should be an expert on the OSCP/OSCE labs and CertifiedNOP (e.g., Zulu, GPF/EFS, PFF, ImmDbg, Sulley, gdb, MSF, et al). By "expert", I mean that you should be able to find 95 percent or more of the whole-system vulnerabilities and be able to take them to full exploitation (typically about one thousand practice sessions per target). Additionally, I should note that some platforms and frameworks require even more specialized knowledge and tools (e.g., mobile apps, Flash/Silverlight, Ajax, Web Services, etc)
Embedded systems and Radio frequency reversing and penetration testing (to get started you might want to check out the Bus Pirate for serial sniffing or RTL-SDR/HackRF plus GNURadio/RFCat for RF MIJI -- meaconing, interference, jamming, and interception). Note the most difficult piece of this process is the actual hardware acquisition. RTU, PLC, and similar device testing can be a budget sink. Carefully select a sampling of devices by putting them into a lab (as described under Network penetration testing above) and never putting them back into production (i.e., an "early retirement")
Firmware reversing and penetration testing (strong knowledge of cryptography as well as self-modifying/integrity-checking code is usually necessary -- tools such as binwalk, IDA Pro or other disassemblers/decompilers, and related tools/resources)


Web server interaction with a database server It is common knowledge that any servers exposed to the internet needs to be placed in a DMZ. However, a web application sometimes need to get user input and updates to backend database tables etc. How and where would you place the database server. In the DMZ, or allow database connections through the DMZ firewall back to the internal network where the database server is housed.?

What if this database server needs to be accessed also from internal users, eg maybe they need to query who has registered at the website..etc..
How would you design where to place this DB server? thanks

For a reasonable level of security, the answer is really neither.  The database should be housed in it's own zone, not the DMZ with the web server, or in the internal network zone.   This allows additional levels of protection both against intrusion from the public Internet should the web server or web application be compromised, and against attacks from the internal network which are a very real problem.  It also offers a defense in depth mechanism to protect the internal network should an attacker who penetrates the DMZ figure out how to piviot into the DB zone...While they own the DB at this point, you don't want to them to own the internal network as well.

So, something like this:


How to get private keys for traffic decryption? We are a huge organization with hundreds of web servers in a DMZ. We have appliances (a few of them in each location) where all incoming traffic from outside of the network is decrypted (well it should be, but more on this later) and sent to an IDS/IPS.

The problem is that right now we are in a TAP mode, so we are only able to decrypt RSA - about 9% of all traffic. We would love to go inline (to decrypt DH as well) but the problem is our private certificates. We use a cloud Public Key Infrastructure (PKI) solution to sign our Certificate Signing Requests (CSRs) but the private key never leaves its server.

What would a process look like to get them all? Should I go and ask each of the server owners to give me the private key?

DH is point to point key exchange.  The best method is to break the encryption and rebuild a different tunnel to the end point of the network. This will cause high load.
Most corporations, as soon the packet enters in their secure network, they are forwarded decrypted to allow analysis without performance impact.

I think most of the devices cannot sniff that type of traffic, só you will need to break the tunnel.
Even if you have the private key, the key pair generated by DH is between the origin and destination, middle systems will not be able to get the key.

What I mean in breaking the tunnel is for your devices to have their own certificates and private keys in the same way as servers and act as endpoint for the communication.

[added]

Generate your tool csr and request certificates for each site you have. If you own the sites it won’t be a problem and you will be able to read trafic. Same way as if your appliance was a web server.
Many tools do not allow it. Others allow it but restrict this to a small number of virtual servers hosted.

Collecting the private keys from the web servers might  not be sufficient. You have to break the tunnel and not eavesdrop at it.

To get the private keys from each site. The site certificate needs to be exportable, you need to know the password if any and export it to a file(private key), then in your ids you should proceed importing it. But that is probably what you already have done due to the fact that your statement says you can read trafic only some specific DH is not possible... :)
The process of exporting the keys changes a bit if you have a windows or a Linux, easy to find in the internet.

Why you can read TLS_ECDHE_RSA_WITH_AES_256_GCM_S HA384  they are not using Diffie-Hellman Ephemeral (DHE/EDH) or RSA Ephemeral cipher suite to exchange keys but ecliptic curve. if you snif the packets and see if the cipher suite specified begins TLS_DHE or SSL_DHE, you will not be able to decrypt the data.


Is possible for a vulnerability search engine to detect the ipv6 adresses? Using IPV4 protocol, vulnerability search engines can detect and index Internet connected devices. It will be easy for a hacker to collect a lot of information about some devices and perform an attack. Is that possible for The new Internet protocol IPv6 to give us more privacy? And is that immune to the types of systematic scans?

Sort of. The IPv6 range is big. Really big. You just won't believe how vastly, hugely, mind-bogglingly big it is. I mean, you may think it's a long way down the road to the chemist, but that's just peanuts to space the IPv6 range. (with apologies to Douglas Adams)

There are 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses in the IPv6 space. There are 4,294,967,296 addresses in the IPv4 space. A standard single user allocation of IPv6 addresses includes enough addresses for each user to run their own IPv4 space.

As a result, it becomes impractical to run full scans of the entire space. Assuming it took you 1 nanosecond to scan each address (or detect that it didn't exist), it would take you 10,790,283,070,806,013,952 millenia to scan the full range. Multiply by 1000 for the number of years.

However, most of the interesting ones are likely to be in predictable clumps. For example, a given company may choose to assign devices within their IPv4 size  range, in which case it would be possible to scan through that if you can find the appropriate prefix to look at - it might be published in a DNS record for a web or email server. It might be included in the headers of emails from the company. In those cases, you can scan and potentially get useful information.

The general idea with IPv6 was that end-users never need to look at it. They should be able to make a request for a specific device - "the lightbulb in the living room", say - and the local equivalent of a DNS server supplies the correct address. Currently, this isn't quite the case. However, if this did become the case, you'd better hope that the DNS equivalent systems are secure, else they'll publish all your device details to the world, and if any of them leak, you can bet someone will be trying to spot the data.


Somebody gained access to MySQL database Somebody emailed me this morning informing me that they gained access to my clients MySQL database and offered to fix the issue in exchange for money. I've been doing some testing with a real estate listing site. The way the site is set-up it currently has property.php?estateID=103 and doing property.php?estateID=103 union select 1,useraccounts(),3,4,5,6,7 pulls an error back FUNCTION database_table.useraccounts does not exist and I am assuming that is what is helping this hacker gain access to my database. How can I prevent this? Will simple sanitize help? The database is MySQL 5.5.

The vulnerability you describe is called SQL injection. It can be prevented by using parameterized queries. In this specific case it is also a good idea to do input validation, to make sure estateID is a number. This site explains how to prevent SQL injection for several programming languages.


Is there any defense against Brute-Force done on a local encrypted file? Let me start off by saying I don't know very much about encryption, hashing, cracking, etc. I'm just a typical computer enthusiasts, programmer and researcher with many questions.

So, I've discovered that there's a thing called "Distributed Cracking" which is when many systems cluster together to focus-fire a Brute Force processing on a single target.

I assume, in the case where the target is a local file on a computer, with enough time and resources, Brute Force has a 100% success rate. Please correct me if this assumption is false.

The only dependent object in this system is the software used to decrypt the encrypted source file. Brute Force has to go through this program to decrypt the contents.

Is there anything the program can do to defend against Brute Force? Could the program maybe destroy the targeted encrypted source file, and then self-destruct if the number if subsequent login attempts exceeds some ridiculously high number? Though, this will require that the program keep a running count of how many failed attempts there have been, which can be spoofed... It has to write and read the value from somewhere. That or the self-destruct feature can just be completely removed in a cracked and recompiled version.

I can't think of anything that would work.

If all else fails, does just having a ridiculously long password help at all? Something like 500-characters? I guess it should still get cracked. It'll just take exponentially longer. But just adding more cracking botnets to the equation can nullify that.

If the file is retrieved from the filesystem to the attacker's system, there is no longer any gateway. The brute force can continue without any impediment.

More complex keys or passwords do increase the time/cost of brute forcing, but 'eventually' (hopefully before the heat death of the universe), it could be cracked.


Percentage of 0-day vulnerabilities used as vectors for infections? I chose that title, but there are probably several ways to ask this question. It's all about understanding how a computer (especially desktop, but you could generalize this to servers I guess) can get infected if it's always up to date (daily updates) and if you are not stupid enough to explicitly allow execution of untrusted software. For example, everybody says you should not open suspicious attachments in emails, but why not? If there is code or macros in the attachments, the application should warn you and ask if you want to execute it (at least that should be what LibreOffice does). If you connect a USB key to your computer, no software in that key should be executed automatically (that's what Linux does, and I hope Windows today asks you for confirmation anyway). Same thing for "drive-by downloads", if you don't accept to download a file, install a plugin, etc. then how can anything happen just by browsing a website?

UNLESS...

Unless attachments, USB keys, websites, etc. exploit a 0-day vulnerability. Then yes, everything can happen without your consent, and everything is possible in theory. But how common is this? So, going back to the question in the title: what percentage of infections are due to 0-day vulnerabilities? My impression, which might be wrong of course, is that it's a very small percentage, almost zero, and that all the infections are due to people not updating their software regularly, people clicking "ok" to give permission to execute something that should have no reason to be executed (like document.doc.exe, do you want to execute the following program? Of course! Click), people accepting to download updates for whatever software or plugin from unofficial websites, and so on.

So I'm asking about 0-days because that seems to me the only class of vulnerabilities that makes sense considering. If you don't update your software you can't say "I got infected just by browsing a website", but you should rather say "I got infected just by forgetting to update my browser/OS/etc". My reasoning basically made me come up with 3 classes of vulnerabilities (out-of-date software, explicit consent to run untrusted software, and 0-day vulnerabilities) and since the first two classes can be easily neutralized I'm just focusing on the likelihood of the third. Unless of course all my reasoning is wrong.

It's a valid question, and I can't find data to answer it precisely.  The Verizon DBIR does not seem to single out zero-day vulnerabilities used, and I'm not aware of any study that does.  I do believe the chances to be small, however.

I think you're looking at a very narrow slice of things, however, since it sounds like you're mostly focused on isolated home workstations.  Yes, those are basically going to be compromised by:

Users executing things (including document macros, files on flash drives, downloads, whatever)
Known (and patched upstream, but patch not deployed) vulnerabilities
Known (and unpatched upstream) vulnerabilities
Unknown vulnerabilities (0-day)

I completely agree that for home users, the last category is a small percentage of infections.  However, there is a non-trivial lag time between an 0-day being "burned" (i.e., the vendor becomes aware of it, and it becomes a 1-day), and the general availability of a patch.  During this time, a compromised user is not compromised by an 0-day, but is also unable to stop it via patching.

However, in the enterprise, things get different very quickly.  Firstly, we have to add "lateral movement" and "stolen credentials" to our list of vectors.  Secondly, we add enterprise applications, many written in house without attention to security, to our threat landscape.  These may have "0-days" by the dozen, and are commonly used to breach enterprises.  Finally, most enterprises roll out patches quite slowly in comparison to the rate of malware appearing that exploits a vulnerability.  Malware authors may not care if their malware crashes 50% of the time, but you better believe an enterprise cares if 50% of their workstations start crashing due to a bad patch.


Why is the SSL handshake not shown in Wireshark? I am trying to figure out if some Android applications with login functions are vulnerable to man in the middle attacks or not.
I have set up a MITM proxy (as an attacker) on my lubuntu machine and set my cell phone to connect to the proxy before connecting to each app's server. Besides, I use Wireshark to see the traffic.
If an app is vulnerable, the app should easily connect to its server after the login was successful and show the data in that account. I should also be able to see in Wireshark that the cell phone, the proxy and the app's server were connected to each other and finished the SSL handshake process successfully.
Now my question is why (for only a few vulnerable apps) I can easily connect to the app's server while the app itself does not show any warning when connecting to the proxy, but there is no "finished" packet or "cipher key changed" packet in Wireshark? In other words, it seems that this app is connected to its server through the proxy so it is vulnerable, but Wireshark does not show any connection with the server, or cipher key changed, or finished frame; and as a result, based on observation in Wireshark, seems that the app, proxy and server do not finish the SSL handshake process completely, and I am still doubtful if the app is really vulnerable (note that the proxy's certificate is not configured on the phone, otherwise, the proxy was considered as a trusted party). Any answers or ideas would be helpful and appreciated!

To really know what is happening, you should not set your Linux machine as a proxy but as a router. The "proxy" really is an HTTP proxy. Applications which want to do HTTPS (HTTP-within-SSL) may use the system settings and use a CONNECT method to make your proxy forward the traffic in both directions; but they may also connect directly to the serve, completely ignoring your proxy setting. Applications which want to use SSL but not HTTPS (they do "something else" than HTTP within the SSL tunnel) are unlikely to use your proxy at all.

I suppose that this is what you observe: with your HTTP proxy, you only see part of the communications, and not the parts that you are interested in.

A typical low-tech Man-in-the-Middle will setup a fake WiFi access point, which will be the router for all IP packets exchanged by the cell phone. This is both easier for him than trying to convince you to use a custom HTTP proxy, and it gives him more actual attacking power.


A company has requested scans of identity documents. What should I do? A company that I do business with (e.g. Uber, Google) has requested scans of identity documents. How should I respond? For example:

Should I provide the documents? What risks are associated with this? What steps (e.g. watermarking) can I take to reduce these risks?
Should I refuse? If so, what are good ways to persuade the company to continue doing business with me?

Context: People in real life sometimes ask me for advice when they encounter this. I generally just advise to provide the documents and move on, but it would be good to have a detailed answer that I could refer to.

I suggest removing the parts (by taping them before scanning) that are not necessary to match your picture with your name, i.e. the passport and serial numbers. Ask the party requesting the password scan about the purpose of this to figure out which parts are essential to them, why they would need them, how they would store the scan and when they would delete it from all their media. Maybe even the picture is not relevant to them or you can have a webcam session showing it to them.

In Germany, there is actually a law that forbids electronically scanning ID cards: the "Personalausweisgesetz" (§ 20 PAuswG). It is only allowed to use a copy machine (basically to "store it on paper"), but the company/person requesting a copy must inform you that you have the right to black out the serial numbers. The copy must be destroyed as soon as its purpose is fulfilled.
Find all guidelines summarized here.
But you have to know that Germany has the best data protection laws worldwide, so don't be surprised if other countries don't follow this example.

Note: first answered here, didn't look for this question. Thanks @paj28 for his remark.


How safe is WebCryptoAPI these days? The 1Password Tool (software) introduced the 1Password for Teams.

I thought this is a great piece of Software, but now they can show Passwords in the Browser.

They do say:

  We encrypt everything on the client and do not have a copy of your
  encryption keys.

and they use WebCryptoAPI to do so. Has anyone an idea if this can really be safe?

How secure this is depends on the implementation.

Keys can be stored as WebCryptoAPI key objects and stored locally in an IndexedDB. These can then be used to encrypt and decrypt data without the server needing the key. You can even mark keys as unextractable - this means the underlying key can never be exported (ignoring of dev tools built into the browser).

Browser storage is segregated using scheme (http/https etc.), port (443 for https) and domain. So if keys are stored from a page served via https://1password.com they can then only be accessed by pages served from that domain.

However there is a caveat. 1Password need access to the encrypted data (to serve it to you if you login elsewhere). If a malicious party can control either your DNS system of the 1password.com site they would be able to serve you a page which pulls down the encrypted passwords, decrypts them using the key object and then reuploads them to a malicious server. This means at any point in the future 1Password could obtain your passwords.

Further to this the ability to share vaults makes me sceptical that keys would be marked as unextractable. It is technically possible but a system that securely shares the vault key would be far simpler to implement.

In short if you trust 1Password this should be safer than the passwords being sent in plaintext to the server. However it still relies on trusting 1Password.

One further note. Their site states -

  even allow teammates to log in to sites without being able to see the passwords.

I would be surprised if this is done in a way that wouldn't allow a sufficiently technical teammate to extract the password in plaintext. I can't think of a way to do it that wouldn't A. not work reliably accross all sites and B. require either trusting a 1Password server with the password in plaintext or requiring your PC to be always connected.


Would XSS in the local storage be considered "Stored" I am wondering what kind of category cross-site-scripting would be if it's injected in the local storage. Would it be "stored", "reflected" or maybe something else?

An example of what I mean:

I found a website that is vulnerable for reflected XSS (lets refer to it as vulnerable.com).
Using this reflected XSS I edit some JSON in the localStorage.

I changed a part of the JSON to this: "imgUrl":"https://vulnerable.com/products/some-product.jpg\" onload=\"alert(1)",

When the user restarts the browser and opens vulnerable.com, an alert will popup.

OWASP states that it's not "stored" (source):

  Stored attacks are those where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc.

But OWASP also states that it's not "reflected" (source):

  Reflected attacks are those where the injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request.

Is there anyone who knows?

Updating my answer based on information @AviD provided (Thank You! I learnt something new).

From the OWASP XSS page:

  For years, most people thought of these (Stored, Reflected, DOM) as
  three different types of XSS, but in reality, they overlap. You can
  have both Stored and Reflected DOM Based XSS. You can also have Stored
  and Reflected Non-DOM Based XSS too, but that’s confusing, so to help
  clarify things, starting about mid 2012, the research community
  proposed and started using two new terms to help organize the types of
  XSS that can occur:

  Server XSS
  Client XSS

It does not look like a Stored Server XSS based on what you've described. If the data in the local storage is not sent to the server in every request (or specific requests) and it is not "reflected" back in the HTTP response from the server, it should not be considered a Reflected Server XSS.

In this case, the payload (JS) is being stored on the client (browser) in the local storage, it should be considered as a Client Stored XSS (again, I agree with @AviD here). Now if this payload was merely inserted back in the DOM and not being stored on the client (browser), it should have been a case of a Client Reflected XSS.

Just a small note on Self XSS - something not mentioned on OWASP site: If you are only able to change that on your own browser and you cannot "remotely" trick this JS code insertion in some other user browser's local storage, for example: by asking them to click on a URL, I'd consider it as a Self XSS. Attackers tend to exploit Self XSS mostly through scams like posting/sharing malicious payloads on social media network and asking users to paste them in their browser JS consoles to see some magic happen.


Why is tunneling so important in pen testing? I am curious why tunneling is so important in pen testing.

If one has control of one machine in a network, then using that machine, one can run nmap and web apps and try to find out vulnerabilities..

So why would there be any need to use tunneling?

Tunnelling is useful because it allows you to connect to any other machine on the network. Once you compromise one internal machine, you can use it as a platform for other attacks. Simply installing tools such as nmap on the compromised machine won't allow you much freedom in terms of actually exploring the network, beyond preliminary scans.

Getting a VPN connection on a network is pretty much the holy grail of tunnelling. It's the logical equivalent of actually being connected to that network directly. As such, tools that can't easily be run over a proxy, or on a remote system, can be run with relative ease. Most VPN protocols operate as an abstraction of the link layer, such that arbitrary network protocols can be translated onto the remote network. This is extremely useful for tools like ARP spoofing, where a normal SOCKS proxy won't allow arbitrary packets to be sent across. This makes it very convenient to just fire up your BT5 instance (or whatever pentesting box you're using) and jump right into the network. Furthermore, VPN traffic is encrypted and likely to be completely ignored by a firewall.

Alternatively, you might use a SOCKS proxy or even a Tor hidden service to facilitate your tunnelling needs. These are more limited, due to the level at which they relay traffic, but are easier to set up and easier to customise in order to hide traffic from a firewall / IDS.


Does a Virtual Machine stop malware from doing harm? I would like to know if it is safe for the host system of a virtual machine (VM - VirtualBox OSE in my case) to execute malware.

Can a virus break out and read or write data from the host system? Can it establish an Internet connection if I disable it in my VM?

Is a VM a safe environment to try to find out what a virus does?

Can a fork bomb "kill" the host system if I reduce the memory to about 1/4 of my total real memory? How much CPU-time/resources can it use?

Theoretically, the guest system is totally isolated by the VM and cannot even "see" the host, let alone attack it; so the guest cannot break out of the VM. Of course, in practice, it has occasionally happened (web archive link). An attack requires exploiting a security issue (i.e. a programming bug which turns out to have nasty consequences) in the VM implementation or, possibly, the hardware features on which the VM builds on. There are few exit routes for data out of the VM; e.g., for Internet access, the VM is emulating a virtual network card, which deals only with the lowest level packets, not full TCP/IP -- thus, most IP-stack issues remain confined within the VM itself. So bugs leading to breakout from VM tend to remain rare occurrences.

There are some kinds of attacks against which VM are very effective, e.g. fork bombs. From the point of view of the host system, the VM is a single process. A fork bomb in the guest will bring to its knees the scheduler in the guest OS, but for the host this will be totally harmless. Similarly for memory: the VM emulates a physical machine with a given amount of RAM, and will need about that amount of "real" RAM to back it up efficiently. Regardless of what the guest does, the VM will never monopolize more RAM than that. (You still want to limit VM RAM size to, say, at most 1/2 of your physical RAM size, because the extra "real" RAM is handy for disk caching; and the host OS will want to use some, too.)


How to ensure JWT security in authentication? I have implemented a backend as a REST API. To maintain the statelessness in REST, I intend to use JWT to verify that that a user has logged in or not.
(A user is logged in if a valid token is present in headers. Not logged in if a token is not present.)
But even with expiration times are set, an attacker can access the REST api by simply copying the JWT from the web browser.
What are the methods available to stop this without killing the statelessness?

While theft of the access tokens is a concern for all kinds of tokens, a special concern for stateless ones is that they can be used even after the user has logged out.  As the receiving API does not have a source of truth apart from the token itself, it accepts any token that has not expired or otherwise been "globally invalidated" (for instance by revoking the signing key).  And there are some things you can do to protect against damage from the loss of tokens in this case:

Make the token short lived, so that it will expire before attackers can steal and use it.  You can set the expiry time to (for instance) 60 seconds, and keep refreshing it as long as the user is logged in.
Store the token in the browser in a manner that makes it more difficult to steal. For instance, using the session store makes it much less likely that someone can get it from a "hot desk" computer later.
Consider narrowing the scope of the token, so that if someone actually manages to steal it, they can't do as much damage. For instance, the Authorization Server could limit the roles in the token to a few necessary for the job the user is currently doing. This is complex, and thus is more important in a complex environment though.

The latter item can be adapted to limit any damage from misuse through XSS vulnerabilities to. Though those generally ruin your whole day anyway.


How to write down user credentials? Sometimes we cannot avoid to write down usernames and passwords internally in our organisation. This is mainly for personal usage, not for reading by programs.

There are several ways to do this, e.g.

username/password
username, password
"username","password"

All of them and more are used in the field. What is the "best" way to do this we can recommend internally in our organisation? Are there pros/cons for each alternative or should we leave users create their own style?

There is no best practice for writing down passwords (or credentials in general). This mostly depends on your own company and how you decide to write them down, I don't see any reason to have rules in place for standardized credential writing. The advise in general is to not write down credentials at all. If you must write down credentials, there are a couple steps you can take to improve security.

Use two factor authentication so that if credentials are leaked, your accounts are still somewhat secure;
Make sure to have a standard when it comes down to writing down credentials and the disposal of papers with credentials on it. You can for example have a standard paper for writing down credentials and a special bin to remove then;
Fold paper with credentials on them so other people cannot as easily read them by looking at them from a distance.

One of your main problems will be a violation of 'clean desk policy' which you can look and why it is important and things like bin diving.


Reverse shell using XSS If a certain web application is vastly vulnerable to XSS attacks, is it possible for the attacker to gain a reverse shell using an certain XSS payload without uploading any mallicous files to the web server? or should the owner of the web server only worry about the vulnerability impacting the end users of the web application?

The answer is no... at least not how you're thinking of it working.  XSS attacks actually happen on the client's browser.  You could use an XSS to attack the site administrator.

I mean, theoretically, the answer is yes, but not as you likely envision it happening.  There are a lot of IFs involved, but only if you could store a XSS attack on that web application; if victim has disabled their client's default security controls and allows the browser to make calls back to a server you control. However, the default controls in place in modern browsers that would likely prevent this from being successful.

That said, this is basically one of the methods drive-by malware is delivered.  Target users with administrative privileges and you gain access to their machines.

You don't need a full reverse shell to compromise the application.  If you know the application well, your XSS attack, could in fact be a CSRF attack that targets admin user rights to perform administrative actions on the server on your behalf.


Is all the alarmism around BadUSB really called for with respect to host devices? I can understand why there was such a furor about BadUSB and indeed it poses a rather earthshaking threat to the base assumptions of many in their cyber security threat models. Things which many of us use regularly for routine tasks can now barely be trusted at all. However, is it not so that it is only USB thumb drives that can never be trusted again after they are plugged into untrusted workstations, as the presence of a BadUSB infection is very easy to convincingly disguise and not easy to reliably or formulaically detect. That said, it's Vector of infecting host workstations to which carrier USB devices are connected is to covertly register as an input device like a keyboard and then spoof authorized user input, but in fact issue malicious commands.

So, in theory, a terminal emulator would need to be opened, and a window would thus have to at least initially be normally, candidly displayed on the screen until commands are issued to obscure the window by moving or resizing it before measures to more thoroughly infect the host can be more discretely undertaken. An attentive user would then have at least a brief opportunity to notice unusual and unprompted behavior from the behavior, and malware authors must rely on hopes of the user not paying close attention, right?

It would be the same as an evil gnome crawling under the desk and plugging a normal USB keyboard into one of the desktop tower USB ports with the cord leading to his master's outpost where he can blindly issue keyboard inputs without necessarily any view of the user's movements like for instance visits to the bathroom.

If the user does leave his host unattended to use the bathroom with a malicious/untrusted device connected, upon returning his device may as well have been subjected to an evil maid attack.

Which brings me to my question.

If I present a computer for forensic examination that has been left unattended in a potentially hostile hotel room, I believe it is possible to detect most forms of software-residing malware infections. Would rebooting at the least not be required to alter a workstation's boot sequence, firmware, BIOS, or other systems that cannot be completely sanitized simply by reinstalling one's operating systems?

The USB devices themselves, once infected, or even just connected to untrusted hosts, would seem impossible to ever trust again under any circumstances, impossible to knowably sanitizer or re-bless with confidence that there wasn't some deeply hidden, and thus undetected, malware infection still present on the device.

I don't think the situation is so dire, however, for hosts, particularly if one is confident that they did not leave the host unmonitored for sufficient periods of time as to allow for unseen rebootings of the machine. I mean I guess it's still not good because they can alter the boot sector and love repartition the main drive and then queue an un deterministically deferred infection entrenchment that requires a reboot on the (random) Nth next user-executed reboot in order to accomplish whatever else is required to cement the infection beyond the reach of simple drive-reformattings, after which lots is possible.

But, the question remains, what is the salvageability of a host device's trustworthiness after being left unattended in the care of an evil maid, and is the situation any different following a device being connected to untrusted USB devices entirely while under owner-supervision in the age of BadUSB, and if so, how do the two situations differ?

In short, I am seeking validation of my conjecture that the dire need for retirement from production, security-critical employment of USB devices that leave owner control or connect to untrusted hosts is not applicable to workstation hosts which are connected to by untrusted USB devices.

BadUSB is largely overrated. It is a very, very old attack that simply got a lot of recent press coverage, like IDN homograph attacks or filename unicode reversal (or has that one not gotten press yet?). It's an issue, sure, but it is nothing new.

So, in theory, a terminal emulator would need to be opened, and a window would thus have to at least initially be normally [...]

Actually, there are quite a few ways to more covertly execute code. There was a DEF CON talk on this subject recently, showing ways that custom keyboards and mice could cheat at high-stakes video game tournaments by triggering the execution of cheat codes on the computer, despite the monitors being diligently monitored to ensure no one cheats.
There are other things malicious USB devices can do than just emulate an HID, such as attempting to exploit any of your multiple class drivers. How often do you think some obscure karaoke microphone driver has been audited for security issues?

Would rebooting at the least not be required to alter a workstation's boot sequence, firmware, BIOS, or other systems that cannot be completely sanitized simply by reinstalling one's operating systems?

Modification of the BIOS can compromise a system even without rebooting it. After resuming from suspend, the system re-reads several ACPI tables, including the executable DSDT. A modified DSDT might be able to trigger arbitrary code execution as a computer resumes from sleep. I believe there are also ways to trigger execution of code on certain ACPI events such as plugging in a HDMI cable.
An emulated USB keyboard could, in theory, trigger such a reboot through key combos, and can perform malicious acts like disabling secure boot in the BIOS, assuming a BIOS administration password is not set. This is not likely an issue for anything but targeted attacks due to the variability of BIOSes.
Another issue is USB bus sniffing. USB (2.0) is a half-duplex broadcast protocol, which means that a USB slave addresses the host directly, but the host sends the response to all USB devices, and politely asks only the recipient to listen to it. Because of this, a malicious USB device can receive any data sent from the host to a USB slave on the same hub. This may or may not be a problem for you. If USB devices sniffing, say, data being sent to a USB WiFi antenna or an external USB hard drive is problematic for your threat model, then this is yet another thing USB device can do.

This is not an issue for USB 3.0 (SuperSpeed). According to this website, USB 3.0 is a dual-simplex unicast bus, meaning the xHCI hub is not exactly a hub so much as a switch. It will route USB packets to their intended destination rather than broadcasting them. This is meant to be a performance improvement, but it has an unintended security benefit as well.

The USB devices themselves, once infected, or even just connected to untrusted hosts, would seem impossible to ever trust again under any circumstances, impossible to knowably sanitizer or re-bless with confidence that there wasn't some deeply hidden, and thus undetected, malware infection still present on the device.

Assuming you don't open it up and read the firmware from the microcontroller, that is true. Compromised firmware can only be detected by reading it directly from hardware, with very few exceptions. It actually is not necessarily as stealthy as a software infection, as software can be made volatile, given advanced anti-debugging features, highly obfuscated, and delete individual components of itself after executing them. This is contrasted with maliciously modified firmware which is, fundamentally, completely inert and helpless when it is being analyzed. Simply checking the firmware against a known good copy is enough to verify that it has been modified.

But, the question remains, what is the salvageability of a host device's trustworthiness after being left unattended in the care of an evil maid

This seems like a different question from the one in the title. The answer depends on your threat model, so you need to take into account the capabilities of your adversary. Is the evil maid particularly skilled? How valuable are your assets? In China for example, corporate espionage is ubiquitous. Bringing a company laptop to a hotel in China can lend itself to a literal evil maid attack, sometimes with very high levels of sophistication. If you are simply bringing your laptop with your personal files to a friend's house, at most you would just want to make sure the drive is encrypted.
Note that you are able to perform measured boot, which mitigates evil maid attacks. This is done by having the TPM measure a read-only part of the BIOS called the CRTM. This chain of trust continues upward until the kernel itself is verified, which can then verify your filesystem. This technique makes it exceedingly hard to tamper with a system, even if you can modify the BIOS, option ROMs, the bootloader, etc. A TPM-based chain of trust:

is the situation any different following a device being connected to untrusted USB devices entirely while under owner-supervision in the age of BadUSB

Yes, for multiple reasons. First off, your computer's BIOS is extremely trusted, meaning that it is highly sensitive to tampering. A modified BIOS can inject code into your kernel, trap events using SMM, or even communicate over the network. A USB device on the other hand is limited to what class drivers your system supports. An emulated keyboard will not be able to guess your admin/root password or do anything that could not be done by a blind person on your computer.

In short, I am seeking validation of my conjecture that the dire need for retirement from production, security-critical employment of USB devices that leave owner control or connect to untrusted hosts is not applicable to workstation hosts which are connected to by untrusted USB devices.

Again, this depends entirely on threat model. USB device are far more likely to be abused to exploit a filesystem driver or partition table parser, despite such vectors involving advanced software exploitation. It is only a dire issue when using modern systems that support DCI, a form of low-level JTAG debugging ("probe mode", lower even than the Intel ME's "ring -3", although the ME can also be compromised using DCI) which can be done over USB on some systems whose BIOS vendors have forgotten to disable DCI support.
In summary, malicious USB devices can do any the following:

Emulate HID devices like keyboards and mice ("BadUSB"). Mitigation involves configuring your computer to only accept USB devices acting as an HID from limited sources, e.g. using udev.
Passively sniff content being sent from the host to a USB slave on the same hub. Isolate individual USB devices on different hubs if you do not want them to be able to sniff traffic going to them. Note that some newer computers' EHCI root hub is actually a virtual hub, part of the same physical xHCI root hub. The virtual hub operates in broadcast mode.
Control the system with low-level debugging for BIOSes which do not lock DCI. Older firmware or a BIOS whose vendor locks the IA32_DEBUG_INTERFACE MSR is not directly affected, but may still be vulnerable to hijacking of the ME over DCI.
Attempt to exploit filesystem drivers or USB class drivers through malicious input. Using a hardened kernel or reducing the amount of kernel drivers you support reduces this risk.

Whether or not this is a dire situation depends entirely on your threat model. You should not be plugging untrusted devices into your computer, regardless of the interface they use, and you should not assume an uncompromised device will remain that way when plugged into untrusted hosts. Using a USB device with read-only firmware can help reduce this specific risk.


Are phone calls normally recorded? A person borrowed a cellphone and made a prank call and the following day the police contact the owner of the phone. The constable said "I can pull your call logs and you would have no say in it". My question is by call logs did he mean the fact that a phone call had been made from the phone to the restaurant or a recording of the call itself? If it's just the fact that the phone had called the restaurant what would that prove?

Can the police pull the "call logs" without the owners permission? Without a warrent? Rogers, the service provider, said they weren't sure if the police could do this and said the owner had to write to their legal department (not phone).

This incident took place in Victoria, B.C., Canada.

Storing all phone call conversation recordings would be infeasible. Phone companies keep logs to bill you from (from, to, time, duration, etc) and within jurisdiction they can be court ordered to disclose such information (to an extent).

With that said it may also be perfectly legal for the restaurant (a participant in the the call) to record all calls for training purposes. I know in Australia it is legal if disclosed at the beginning of the call.

Unless the pranks are violent, sexual or repetitive to an extent of harassment, or to an emergency service (police, fire, medical) I really don't think the police or anyone else in that matter will care enough to follow it up- They hopefully have more important things to worry about.

If you are concerned consult legal advice as recommended by Terry Chia.


MobileIron Access, clarification needed Running Android 6.0

Got a reminder to update Mobile Iron 9.1.0.1. According to description it Mobile Iron has access to SMS, Browsing History etc. This notification directly contradicts with what they say

The facts: what the employer cannot see:

 - Information in apps – unless the app has been built to transmit
 - information to a corporate server
 - Personal email and attachments
 - Texts
 - Photos
 - Videos
 - Web browsing activity
 - Voicemails

And latest updates is asking me to give app access to Photos too? What's going on here? Please help me understand.

In addition, MobileIron SPECIFICALLY calls on that Photos, Video etc is not being monitored by MobileIron or Enterprise IT

Very confused here.

Disclaimer: My organization uses MobileIron, but I am not my organization's MobileIron administrator.  However I have some experience with other MDM solutions.

I would suspect that MobileIron still needs to monitor for activity in various areas.  Also, it needs to allow for containerization of corporate email, files, photos, etc. separate from personal content.  Just because MobileIron is asking for permission to view and get its fingers in those areas, doesn't mean that the MobileIron administrator will be able to view all the photos on your phone that are not in the container.


Prevalence of offshoring in the Information Security Industry? After having been a regular code monkey in the US for 6 years now with readily offshoreable skills, I feel like I am fighting an uphill battle against third world wages. While I am not prepared for a drastic career change that will be completely incompatible with my Computer Science background, I was wondering if investing money and resources in getting a degree in Information Security would be worthwhile to get a job that can't easily be offshored.

I would welcome insights from the industry insiders on the level of offshoring that they have witnessed in this industry (in the US) and the barriers-to-entry for someone with an undergrad in Computer Science.

I am interning at a security company in Switzerland as a penetration tester. Funny thing, I had this exact discussion with my boss (who is in the field for 20 years now). Basically, you can't compete with the coding monkeys in Russia and India, they pump out code as much as you breath. That being said, it is believed that outsourcing security related jobs will not take place any time soon. For the sole reason that jobs in security are based on trust. And trust, you can't outsource.


Number of certificates in a PKCS#12 archive Is there command to find the number of certificates in a PKCS#12 archive?

I have the .pfx file sent by a client but need to find out how many certificates it contains. I don't need any of the corresponding private keys.

Oracle Wallet Manager could be used but that requires converting the .pfx into an .p12 wallet.

Quick & Dirty:

$ openssl pkcs12 -in <CERTFILE> -nokeys -password pass: 2> /dev/null | grep -c "BEGIN CERTIFICATE"

Please be aware, that this assumes that there are no password(s) set. Otherwise you'll have to fiddle around with the password argument.


How to prevent DirBuster to stop listing apache server side files I have deployed a php project on apache. When I use DirBuster tool to scan my site, it lists all server side files. I want to stop this listing.

I have modified the permission. When I give the less permissions, which are necessary to open site on browser, DirBuster still lists the files. When I provide less than these permissions, it stops listing file using DirBuster but I am not able to see the site on browser, it shows access forbidden error.

Please suggest me a way to prevent file listing by this tool but site should be running smoothly on the browser.

There are a few ways to stop this, but they aren't always recommended.

The first option is to go through all your files, with something like sed, and append all href links with a random string and then rename all the files with that string...
Basically, quickly change all names to like "randomstringfile.txt" instead of "file.txt". This can make it hard to find the files for normal people who memorize websites though.

Also you could make rules in your server to block people for a set amount of time if they request more than 100 requests in a minute or something. This breaks it severely, but not forever. A permanent ban isn't suggested, but not the worst idea either. Sort of like password guess limitations that lock you out for 5 minutes.

A final option is to break any dirbuster-like useragent. This won't stop people who understand, but will break script-kiddies, and automated scans people don't monitor.


How can IPSec provide confidentiality between two hosts on private networks? Can you use transport mode with IPsec processing to provide confidentiality between two hosts in geographically separate private IP networks?

I have read somewhere that transport mode is the default mode to use to provide end to end confidentiality using IPsec processing which makes sense when the two end hosts have public IP addresses.

But what if the end hosts have private IP addresses? Surely the "use transport for end to end" doesn't apply in this case as private IP packets from private network X are tunnelled to private network Y?

I'm very confused. My question is...

how can IPsec  be used to
provide confidentiality for communications between two hosts A and B in geographically separate private IP networks

Let's explain the two modes, how they differ, and clear the air:

Tunnel mode:

Protects internal routing information by encrypting the IP header of
the original packet. The original packet is encapsulated by a another
set of IP headers.
Allows for NAT traversal

Transport mode:

Transport mode encrypts only the payload and ESP trailer
NAT traversal is not supported with the transport mode.

Then there is GRE/L2TP for tunneling. But let's clarify what you mean by confidentiality. On #3, you will notice the bolded term only the payload which means your DATA is confidential. Not your connection information. So define what you mean by confidentiality? Is it the confidentiality of the connection, or the confidentiality of the data? Two separate things to think about it. If you are confused, I suggest reading "Understanding IPSEC Tunnel Mode" Unless you clarify what you mean by "confidentiality" the answers you get may vary.


How should output of fail2ban postfix-sasl look like I want to be sure that fail2ban is properly banning failed postfix SASL login attempts.

When I do iptables -L I can see list of banned hosts for SSHD, but I can't figure out a way to see banned hosts for SASL.

postfix SASL is enabled, which I can confirm with:

fail2ban-client status
Status
|- Number of jail:  4
`- Jail list:   dovecot, postfix, postfix-sasl, sshd

And I can confirm there are failed login attempts, from mail.log, for example:

Aug 31 22:23:49 host2 postfix/smtpd[35397]: warning: hostname systemip3.example.com does not resolve to address 91.200.12.100
Aug 31 22:23:49 host2 postfix/smtpd[35397]: connect from unknown[91.200.12.100]
Aug 31 22:23:52 host2 postfix/smtpd[35397]: warning: unknown[91.200.12.100]: SASL LOGIN authentication failed: authentication failure
Aug 31 22:23:52 host2 postfix/smtpd[35397]: lost connection after AUTH from unknown[91.200.12.100]
Aug 31 22:23:52 host2 postfix/smtpd[35397]: disconnect from unknown[91.200.12.100] ehlo=1 auth=0/1 commands=1/2

Looks like I've found answer to my own question, apparently fail2ban-client status will say that service is enabled, even if there is no filter rule for that particular ban.

The solution was to create postfix-sasl.conf in /etc/fail2ban/filter.d/postfix-sasl.conf
With following contents:

# Fail2Ban filter for postfix authentication failures
#

[INCLUDES]

before = common.conf

[Definition]

_daemon = postfix/smtpd

failregex = ^%(__prefix_line)swarning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed(: [ A-Za-z0-9+/]*={0,2})?\s*$

# Author: Yaroslav Halchenko

and reload configuration with

fail2ban-client reload

Then after a while iptables -L confirms it's working and banning IP's

Chain f2b-postfix-sasl (1 references)
target     prot opt source               destination
REJECT     all  --  systemip8.example.com  anywhere             reject-with icmp-port-unreachable
REJECT     all  --  systemip8.example.com  anywhere             reject-with icmp-port-unreachable
REJECT     all  --  12.215.34.226        anywhere             reject-with icmp-port-unreachable
RETURN     all  --  anywhere             anywhere


If someone bought the .local TLD could that be a security risk? Now that the ICANN is allowing custom Top Level Domain names and often corporate IT workers like to use .local as the TLD for internal networks, if someone does buy the .local TLD what are some possible dangers a user could encounter?

The main example I can think of is spear-phishing attacks. If a company has computers like SuperSecureServer.local on their LAN and a malicious attacker makes TotallyARealCorporateServer.local would TotallyARealCorporateServer.local resolve to the attackers IP? If it did, the attacker could send a bad link then could impersonate a real server and get domain login credentials.

To answer your specific question, .local has already been reserved by ICANN as an internal gTLD.  Please see section 2.2.1.2.1 "Reserved Names" in the ICANN Applicant Guidebook.

The full list of reserved gTLDs are:

AFRINIC  IANA-SERVERS  NRO   ALAC  ICANN  RFC-EDITOR   APNIC  IESG  RIPE  ARIN
IETF  ROOT-SERVERS  ASO  INTERNIC  RSSAC  CCNSO  INVALID  SSAC  EXAMPLE*  IRTF
TEST*  GAC  ISTF  TLD  GNSO  LACNIC  WHOIS  GTLD-SERVERS  LOCAL  WWW  IAB
LOCALHOST  IANA  NIC

*Note that in addition to the above strings, ICANN will reserve translations of the terms
"test" and "example" in multiple languages. The remainder of the strings are reserved
only in the form included above

(There is an addendum to the above to state that "similarity" metrics are applied to make sure that gTLDs like .1ocal are not abused, either.)


Wifi penetration testing: Why aireplay-ng de-authentication does not work? I am trying to pentest the security of the password of my wireless network. It is a WPA2 with pre-shared-keys. My current computer is connected to the wifi router and I try to de-auth my own machine.

Steps

1) I created a monitoring interface:

sudo airmon-ng start wlan0

2) Now I use airodump-ng to find the channel and MAC of the access point:

sudo airodump-ng mon0

3) My access point has the channel 10 and the MAC ACCESS_POINT_MAC. I can record packets now:

sudo airodump-ng -c 10 --bssid ACCESS_POINT_MAC mon0

4) I try now to deauthenticate my computer from the network with aireplay-ng, but it does not work:

sudo aireplay-ng -0 1 -a ACCESS_POINT_MAC mon0

13:50:47  Waiting for beacon frame (BSSID: ACCESS_POINT_MAC) on channel -1
13:50:47  Couldn't determine current channel for mon0, you should either force the operation with --ignore-negative-one or apply a kernel patch
Please specify an ESSID (-e).

What the de-authentication with aireplay-ng does not work?

Update
after feedback from @BadSkillz

I added --ig and -e ssid_string to my command. However, it could not find the BSSID:

14:11:56 Waiting for beacon frame (BSSID: MAC_ADDRESS) on channel -1
14:12:06 No such BSSID available.

On the same time I can find the MAC_ADDRESS|BSSID with airodump-ng. Moreover,
I tried to use another interface when specifying the channel:

sudo airmon-ng start wlan0 10

resulting in mon1. Nevertheless, the aireplay-ng still does not look at a specific channel.

I had the same problem and after some research I found that everything worked fine when I disabled the wlan0 interface before running the attack.

To disable the wlan0 interface, I used the following command:

ifconfig wlan0 down

Then I tried the following command again:

aireplay-ng --deauth 1111 -a macadress-of-ap -c macadress-of-client mon0


Malware which can bridge air gaps The following statement is made on the Qubes website:

  Malware which can bridge air gaps has existed for several years now
  and is becoming increasingly common.

Can someone provide an example of Malware that can bridge air gaps?  Are they talking about a virus on a thumb-drive or something more insidious that I am as of yet unaware of?

Have there been any proof of instances where these practices have been used outside of a lab environment?

There are many aspects of malware that may be considered to bridge air gaps. But it is important to note that it isn't very common 'in the wild'. There aren't many examples of this being done in the real world, and it is mostly an academic demonstration of concepts.

To name two:

Infection through physical access - Like you said, thumb-drives are a well known method to infect machines with malware. Also pretty common are HID attacks that can inject a malicious payload that loads malware to the machine, DMA attacks using DMA enabled physical devices and more...
Air gapped data exfiltration - see here and here for examples. These are methods of extracting data from air gapped machines using side channels.


Where to find Google Authenticator backup codes? I'm slightly confused about obtaining Google Authenticator backup codes.

I can find my Google Account backup codes at:
https://myaccount.google.com/signinoptions/two-step-verification

But have no idea if those are the ones I should use to restore Google Authenticator and recover all attached accounts in case I lose my phone.

Thank you

P.S. Feel free to suggest other services with better/enhanced security and easier (but secure nonetheless) backup procedure.

You need backup codes to "an account" not to Authenticator itself.

Authenticator has one entry for each 2FA-enabled account of yourself - without needing an account for its own use. So the concept of backup codes for GA doesn't apply.

If for example, you have an account (say GMail) that you've protected with GA-based 2FA, then you could generate backup codes for GMail, from GMail Account Management / Security menus. Since the backup codes need to be recognized by GMail, they are generated in GMail - not GA.

Same logic applies for any other account that you need backup codes for.

Edit: To backup all the accounts you have on GA, you need to backup the "App-specific secret" (usually a long hex string; or a QR Code that has the string) for each account/app. AFAIK, GA doesn't use online storage to backup your GA-enabled accounts.


scans for WIFI access points PCI DSS requirement 11.1:

"Implement processes to test for the presence of wireless access points (802.11), and detect and identify all authorized and unauthorized wireless access points on a quarterly basis"

My qustion is :

where should i perform the scan ? near the server room ? near the backup site in every room in my company ? and if i had several location that as a self service machine that customers can swipe their credit card ? around the building parameter ?
In case i don't want to purchase a wireless IPS\IDS, which scanning options can i use for a valid scan? can i use my WIFI network discovery from my mobile \ laptop ? is there a certain app for it ?

1: You should scan everywhere a wireless client in-scope may reach, but also everywhere near all locations that are in-scope. Outdoor scans is not neccessary if you don't also have wifi clients operating outside, like in-scope workers being on the outside locations with their laptops and surfing. But a scan along the inside of the perimeter of the PCI DSS zone is a must, but also somewhere in the middle regions so you don't miss out a AP that transmit weakly in the middle.

This effectively means you also need to, if you have remote workers:

Implement a mandatory VPN or encryption, that cannot be turned off by the remote workers, that will take the airspace out of scope. Note that its not enough to just enforce VPN/encryption while working with card data, as a malicious individual might insert malware while the computer is off-VPN. This method will mean captive portals will not work. (WLAN encryption does not count)
OR, Programmatically disable the wifi card on remote workers using some device management, while they are off-site.

Else, every location that the device visits, effectively becomes in-scope. Good luck enforcing PCI DSS for a hotel lobby or hotel room.

However, self-service locations as you say, does not neccessary need to be scanned. If you make the solution P2PE (Point-to-Point Encryption) and UPT (Unattended payment terminal) approved, and ensure the personell at the self service location does NOT have access to encryption keys, you have taken the local end of the self-service location off-scope, and no Wifi scan is neccessary. However, the actual P2PE/UPT terminal is still in scope.

You need to think "What happens if someone puts a rogue access point here - eg a malicious access point, that either distributes malware, or steals data, and tricks a machine or human to connect to it, perhaps by having the same SSID". Same with a malicious individual that inserts a access point in the in-scope network.

2: A PC with decent wifi will work, but you also need tools that allow you to record or monitor the MAC adress of the AP, and also watch all access points reachable (eg multiple access point with same SSID should not be consolidated into one). You also need a decent antenna, as a built-in antenna in a laptop might be not enough to detect APs far enough away.
You need to prepare for the worst, like a worker putting a decent antenna and accesses a rogue access point.
The solution must also be able to record P2P access points, so a Android mobile is not sufficent, as viewing P2P access points on a android requires root.

And to elaborate your question/answer too:

You also need an action program, IF a rogue or unauthorized AP is found. For a unauthorized AP, its easy as just tracking it up and then disconnecting it from your network. (unauthorized AP = a AP that is connected to a network without authorization from the network admin, regardless of SSID)

A rogue access point (which is defined by a access point having the same SSID or MAC as an "authorized" access point, but may be located anywhere) is a bit more difficult to deal with. As a rogue access point might not be in your network/facilities at all, it might be at the neighbor's facilities, you may need to resort to legal actions to get rid of that. You could begin tracking it, and when its rough location is located, send a cease and desist letter to the manager of that building, and even send FCC or Police on that location.

Naming a AP same as a someone involved in payment cards, in an effort to get those to connect to that, its a clear computer misuse violation and could be classified as fraud too.

Another solution may be spoofing deauth packets for that rogue access point (some rogue AP scanners can do this automatically after detecting a rogue one) to prevent a authorized in-scope client from connecting to the rogue one, but this may have its own legal complications, as you are interfering with equipment you don't own or have authorization to operate.