As a pentester automation makes up about 1% of what I do and is only useful because it can catch low hanging fruit.  Firing off Nessus or some webapp scanner takes less than an hour.  The remaining time is spent actually hacking the application.  I look the source code for security critical components,  and fuzz strange API's with burp.  Be observant,  attention to detail.  A finding start as simple as a strange error message,  a "Huh, that is funny"  moment.

The tools I commonly use are (no specific order):

The scientific method
grep
python
burp
a decompiler
a debugger
nmap

In any case I suggest getting some findings under your belt before your start writing hacking tools.  There are already some great tools out there.


How is the strength of a key/Password determined

I think you might be confusing "size/length" with "entropy". The text string 123456, when encoded in either UTF8 or other common encodings (ISO-8859-1 or "Latin", etc.), will be 8 x 6 = 48 bits in length. However, its entropy will be... ridiculous. I can't even estimate it, all I know is that any script kiddie will definitely be able to attack you successfully with such a weak password. The "size/length" in bits is related to the encoding using for the text. The "entropy" on the other hand is related to the randomness, or in other words the number of possible combinations that an attacker will have to try to be able to guess it.

A key is just a series of bits: 011001100010101011101... In a 128-bit key of course there are 128 bits. If those bits are truly random, then you will have an extremely strong key, containing 128 bits of entropy. But in reality keys are often (but not always and not necessarily) generated starting from a password or passphrase, because people will need to remember them. How can you remember 128 bits easily? That's impossible.

So people will just pick a password, and then an algorithm called "key derivation function" will transform the password into a key (a series of random bits). So what happens is that an attacker won't try to bruteforce the generated password, because they know that it's impossible to bruteforce 128 random bits in a reasonable time. So what the attacker does is try to bruteforce your password, generate the related key for each password, and try. Your password is very likely to contain much less than 128 bits of entropy, that's why the attacker will try to bruteforce the password instead of the key. For example, a 12-character password containing random uppercase/lowercase characters and numbers is going to have 62^12 = 3.23 x 10^21 = about 2^71 = about 71 bits of entropy.

Attackers usually have dictionaries and are going to bruteforce passwords using the most common words and patterns, rather than trying all the possible combinations at random. So for example they might try abc123, dogcatbird11, 5tr0ngPa55w0rd, etc. They might try to include some common symbols in the possible character set, for example question marks, exclamation marks, etc. but leave out other less common characters. In the end, it all depends on how much time and resources the attacker is willing to waste. Bruteforcing all the possible 8-character passwords might be feasible, but as soon as the complexity increases the attacker will have to make some specific choices, unless they feel like waiting for centuries in front of their computer.


You usually don't know what is in the cookie, as its information is to be only used by the server. Some servers encrypt the cookie to protect its contents and to prevent the user from changing it.

Now, for the HttpOnly flag.

It was something "invented" by Microsoft on IE6. It's an extra flag intented for the browser to not allow client-side scripts to access the cookie. If the flag is not set, document.cookies will return its contents and a XSS exploit can compromise the user cookies. With the flag set, browser will not allow any client-side scripts to read its contents, and will only send its contents to the webserver.

If the cookie data is useful for the client (like the language, or sorting preferences, or any client side preference), don't set HttpOnly flag. If the data is used only on the server side (like PHPSESSID, ASPSESSION or anything the client side does not use), set HttpOnly and make harder to a XSS exploit to steal the cookies.


Allowing customer to generate a secret key for securing RDS instance on AWS

It really depends on your requirements as Vinay pointed out. However I can give you some options:

You setup an IAM role which allows to change the master password of the RDS instance. Whenever you start the server you set this credential via the application. The AWS account has to be configured in a way that the developers are not able to do that. Issues: You cannot easily access anymore the database instance. You may have some issues with the scaling since you do not want to that two instances changes the password at the same time.
You setup the developer users within the AWS account in a way that they are not able to change the password of the RDS instance. The application access an S3 bucket to which the developers do not have access to. However the application can read the data from the S3 bucket. You can do this by using IAM roles which you assign to the application EC2 instances. Within the bucket you store the RDS password. You may allow from within the application to change the password. This way you can setup the whole thing initially and allow the client to change it once (or more). This way you can lock yourself out.
Eventually you can setup on the network level with security groups rules which prevents an access from the outside and you prevent that the developers can access the environment. This is eventually problematic since you may need to access the environment since you need a way to maintain the EC2 instances.


Are any container solutions secure enough to run fully un-trusted code, particularly as a VPS service?

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

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

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

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

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


What are BitLocker requirements against computer theft?

The benefit of having Bitlocker with a TPM in that scenario is that the hard drive is encrypted at rest. If the computer is stolen, for the thief to get any benefit, it would have to be stolen while the computer was turned on, with the password or key entered at boot time. But if the computer was turned off at the time it was stolen, there would be no use sticking in a USB with its own OS on it and trying to read the hard drive, because the hard drive is encrypted. The only other avenues of attack might be for the thief to guess the password, or steal the bootup key (plausible if the rightful owner stored the bootup key on a USB stick in the laptop case), or possibly a direct attack on the TPM hardware.


Possible ways to track down anonymous mail senders?

If the service is working right, you can't.

You can just work with the information that is supplied to you, unless you can gather access to the anonymous mail sending service. This could be possible if you work for a LEA or are able to break into the service (but that would be illegal, of course).
The information that is supplied is the body of the mail, the headers of the mail and attachments. Metadata in attachments can expose somebodies identity.

For example tormail has mailservers working as hidden services and some in the normal internet, so, if you send a mail, you are connected to the hidden service so your IP isn't exposed. Unless he gives the hidden service any information that would compromise his identity, you can't get anything to track him down.


Which Master degrees offer the most web application security courses?

I think your best bet is to build your own master's - I don't know of any programs with that specific focus.  My strategy would be to hunt down universities that are strong in both Info Security and Software Engineering, and then work out a program with your adviser that combines the two.

I could be closed minded, but IMO, you're not going to get enough material specifically on web app security to form an entire degree.  You're going to have to branch out either into web app development or general Info Security.  Also, in terms of careers, you probably need more than just web app security and either being a solid web app developer, or an overall InfoSec guy with a strength in web apps will give you a broader base for the job hunt.


Is it possible for a file that is non-executable and read-only to run malicious code?

Yes, something just has to execute it. The X flag hints to the shell that it can be directly executed, but that doesn't stop other programs from executing it if they know how.

For example, if you have a file a.sh which is not executable to the shell, you can execute it by calling bash a.sh (which tells bash explicitly to execute it). If you have a non-executable file a.py, you can execute it by calling python a.py. I'd imagine there's also a way to tell the OS to execute a binary ELF file, but I don't know the command off hand.

There are also a whole class of things which don't require you to do anything in particular to make it execute malicious code. PDFs and Adobe Flash files in particular have had some well-known holes which allowed the simple act of reading a file to execute malicious code. There are also some files which, in specific places, and be auto-executed (especially on Windows). Also, if the file is compressed, it may contain a buffer-overflow virus for the decompressor. The file also may be even more malicious, taking advantage of a yet-unknown bug in the file system or something else really low-level.

Bottom line: the only way to guarantee something won't infect your computer is to never do anything with anything.


What is the simplest way for a Proxy/UTM to block HTTPS traffic using URL filtering?

The orthodox way to accomplish this would be to use SSL interception, such as SSLBump, with Squid.

If you don't want to intercept SSL traffic, you can do this via DNS.  This would have the effect of blocking the entire website regardless of protocol, e.g. http vs https vs ftp, based on DNS.  So you could blacklist "facebook.com" and have your DNS server redirect it to a "This page is blocked" site hosted on an internal IP.  An example of a service for such DNS filtering is OpenDNS.

Such a DNS workaround could be avoided by users if they have the ability to edit their workstation DNS settings to use another DNS server, or edit a hosts file.  They could also use a number of web sites which offer a proxy to facebook and other sites (which are questionable since they may intercept the users' password) to relay the connection.

Because of the weaknesses of using a DNS-based setup, when looking to inspect HTTPS traffic it is generally more effective to use your squid proxy as a ssl-man-in-the-middle engine and inspect traffic decrypted, this will lead to much better filtering.


Well if you are using Firefox you can use NoScript but right now "Canvas Fingerprinting" is really a new buzz word but when more people know about it the more developers will make addons to counter Canvas Fingerprinting.

There are several options to block Canvas fingerprinting

TOR web browser.
Yesscript.

More info here Canvas Fingerprinting


MsChapV2 authentication and Evil Twin attack

TL;DR - You can trivially brute-force the DES keys used in the challenge/response mechanism. In order to reverse the challenge/response mechanism you only have to brute-force two DES iterations that have a 56-bit key.

In order to obtain the NT hash, you will need to concatenate the challenge & the first two-thirds of your response and K3 as Base64.

NTLM is a challenge-response authentication protocol essentially what this means is, one party will present a challenge and the other party must provide a valid response - if this doesn't happen then authentication will not take place.

A good way of picturing this would be a security question - imagine if to unlock your account you had to provide the correct answer to the following security question; What  was the name of your childhood pet? While this is not exactly what this would look like it's a nice way of picturing it.

High-Level Overview

NTLM has three messages to authenticate a client, these messages are defined in the following Microsoft document NTLM Messages

NEGOTIATE_MESSAGE
CHALLENGE_MESSAGE
AUTHENTICATE_MESSAGE

These messages are sent in the order they are listed in, we will change the notation of these messages to be NM, CM and AM.

Firstly the client will send the NM to the server this will allow the client to inform the server what NTLM options it supports, upon negotiating this the server will then send a CM to the client. The idea behind the CM is so that the client can prove it's identity to the server. Finally, the client will send an AM back to the server after the CM has been processed by the client.

Hashing

NTLM uses two hashed passwords which are stored on the server and while they are salted before they are sent over the wire they are not salted in the machine's memory, this is an issue because if you obtain the hash value from the server you can use it to authenticate without even needing the password.

The first hash is known as the LM and the other is known as the NT. The LM uses a DES-Based function and the NT uses MD4.

LM

The linked diagram shows how the LM hash is calculated using the example of "napier" alternatively the below steps follows the same premise.

Convert user's password to uppercase, then pad the provided password up to 14 bytes using NULL-padding
Split the 14 byte password into two 7-byte halves
Create two 64-bit DES keys using the 7-byte halves (with the addition of a parity bit for every seven bits)
Each key is used to encrypt the string KGS!+#$% which returns two 8-byte cipher values.
The resulting two values are concatenated to give a 16-byte hash.

It is not certain why "KGS!+#$%" is chosen however as per the below on the LAN Manager Wikipedia page it would seem the reason is related to the writers of RFC 2443.

  The string “KGS!+#$%” could possibly mean Key of Glen and Steve and then the combination of Shift + 12345. Glen Zorn and Steve Cobb are the authors of RFC 2433 (Microsoft PPP CHAP Extensions). - LAN Manager Note 2.

NT

With the NT hash each character is converted into UTF-16 and uses a Little Endian format, I am not going to go into detail about Endianness here so, unfortunately, it will require research if you're unsure of what that means.

Lets look at another diagram using the "napier" example again in the following diagram you can see we take the word napier and after every character we have a null-byte for example "napier" becomes 'n' 0 'a' 0 'p' 0 'i' 0 'e' 0 'r' 0 as shown in the linked diagram, this is the result of encoding "napier" with UTF-16-LE. Then we use an MD4 signature taken from the string which returns a 128-bit code that in our example would be 307E40814E7D4E103F6A69B04EA78F3D you can try this out yourself using this MD2/MD4 encryption site. In essence, the function would look like this to get the NT hash: MD4(UTF-16-LE(password))

Low-Level Overview

Now that we have discussed the hashing and a high-level overview of the challenge/response authentication method we will look at the low-level overview of how this works.

Both of the hashes above produce a 16-byte value, 5-bytes of 0s are appended to reach 21-bytes. Those 21 bytes are separated into three 7-byte values. Each 7-byte value is used as a key to DES encrypt the 8-byte challenge we send to the client. The three encryptions are then used to form the 24-byte response.

The server will authenticate by sending an 8-byte random number
known as the challenge. (See above)
The client will perform an operation involving the challenge and a
secret which is shared between the client and the server, this secret will be one of the two password hashes we described previously.
The client then returns a 24-byte result from the computation. It's
typical in NTLMV1 that both hashes will be used for the computation and thus both 24-byte results are sent back.
The server will then verify that the client has computed the correct
result, if they have the server will infer possession of the secret
and hence the client's authenticity.

In essence, the below code-block shows how the steps performed look with the mathematical notation.

C = 8-byte server challenge, random
K1 | K2 | K3 = NTLM-Hash | 5-bytes-0
Response = DES(K1,C) | DES(K2,C) | DES(K3,C)

Hashing/Encryption weaknesses

NTLM is a very old protocol - usually, older protocols don't survive (if there are issues with them). NTLM is one of those older protocols that didn't survive the test of time. Firstly the functions that are used are too weak/cheap for modern day hardware.

Let's look at DES, DES was first published in 1975, it's a very old protocol, one of the main issues with DES is how weak it is against brute-force attacks, especially in the modern age. In fact as per DES Strengths and Weaknesses it would seem that even in 1977 with enough money it would be possible to brute-force DES.

  In 1977, Diffie and Hellman proposed a machine costing an estimated US$20 million which could find a DES key in a single day.

  So it is arguable that DES was never strong against brute force
  attacks (the standardized post-NSA consultation version anyways -
  originally the designers did propose a "real" key size).

If you're wondering about the maths behind how long it would take to find a DES key compared to an AES key see: How long does it take to crack DES and AES?, the top answer clearly presents the length of time it would take, just be aware post is from '11, things do change and so does computing power so that is something to factor in, see that answer as a guideline rather than an exact figure.

In essence, the time it would take to brute-force a DES key (especially with today's computing) is way too short for it to be considered up to the modern standards and thus it's become obsolete.

What about MD4? Let's take a look at Message Digest 4. As you may be aware we now have MD5 which like MD4 is still pretty weak for things such as password-hashing due to its speed.

Whilst MD4 is a relatively "new" hashing function, it is still weak. It was first published in 1990 by Ronald Rivest who is incredibly well-versed in Cryptography and well-known to Cryptographers.

MD4's problem (and MD5's in-fact) is how cheap it is to compute collisions; in short, a collision is where a function maps two distinct inputs to the same output, a collision-attack describes the process of attempting to find two inputs that produce the same output. Computing collisions in MD4 is really fast & incredibly cheap. In-fact there was a collision attack published in 2007 that could find a collision in less than two hash operations.

Other Weaknesses

One distinct issue is the ability to perform a relay attack fairly trivially see: Practical guide to NTLM Relaying

I won't go into it here for the sake of post length however the above linked should have more than sufficient detail.

Weaknesses in MSCHAPV2

As for weaknesses in MS-CHAPV2, in step four of the process because the NT hash is not salted as an attacker you can reuse it, this means the NTHash is used as the password, meaning that we can use it to authenticate as the user; to add to that we can also impersonate the AS and authenticate the user. Because there is no salt being used this allows us to use rainbow tables.

Another blatant issue is in step six where you can easily perform a brute-force attack on each key fairly trivially see: Evil Twin Vulnerabilities in Wi-Fi Networks

Further Reading

MD4

DES Challenges

DES

NT & LM Hash

Stop using NTLMV1

LM, NTLM, Net-NTLMv2, oh my!


Why don't PGP and SSH keys see more widespread use as a second factor when authenticating?

Let's check out what PGP and SSH actually offer for this purpose:

PGP:
Client must install PGP software which is not installed by default in the majority of the systems. Client must create a PGP key pair. Then he must send the public key to the server so that the server can use it later for validation. When authenticating with 2FA the server will send a challenge which the client must sign with its private key and send the signed challenge back as response. Of course the client must protect its key against theft, maybe with a password.
SSH:
Client must install the SSH software which is not installed by default in the majority of the systems. Must create key pair and send the public part to the server. When authenticating with 2FA against some web service the client must create a SSH connection to a related server and the server must merge the successful authentication using SSH and the login to the website somehow together, maybe with some additional token the client has to give after using SSH. And oops, there might be a firewall in the way blocking SSH. And of course client must protect key against theft.

Thus essentially both solutions boil down to:

initially install some software
create a static key pair and publish the public part (this might be integrated into the software for convenience but is currently not)
somehow get a challenge from the server and somehow send the signed challenge back. And somehow the server must integrate validation of the challenge into the authentication process. "somehow" because there is no already established process for this which integrates everything with the authentication flow used in web applications.
and of course the client must protect its key

The same procedure can be much easier done with a client site TLS certificate. This still leaves creation of the certificate as a major problem (but this is possible within the browser too today) but at least the validation is integrated into the HTTPS protocol already.

Additionally I cannot see how these solution provide a better user experience or integration experience than existing 2FA solutions. They are not easy to use, require additional software, require new ways to integrate with the server side etc. And they do not provide a better security either. So why care and not take the newer solutions which were designed with usability and server integration in mind?

Apart from that the current cheap 2FA solutions make use of a mobile phone. These provide usually a better security architecture than current PC's. And they are an additional hardware device the user must have access to which makes  the protection offered by 2FA stronger.


Thousands of 404s from various search engines

Your website has been compromised.

Any request that includes a URL component listed by you leads to a 301 permanent redirect to a random porn site serving advertisements.

GET /phxyy/whatever HTTP/1.1
Host: stratigery.com
Accept: */*

HTTP/1.1 301 Moved Permanently
Date: Sat, 22 Aug 2015 02:17:04 GMT
Server: Apache/2.4.16 (Unix) PHP/5.6.12
X-Powered-By: PHP/5.6.12
Location: http://www.somepornsite.massorgy/
Content-Length: 0
Content-Type: text/html; charset=UTF-8

It should be noted that the redirect is served out by your server, which can only mean that your server (not the authoritative name server) is compromised.

What you should do:

Take down your website and investigate the following locations for signs of obfuscated code:

/index.php
/wp-config.php (if using WordPRess)
/configuration.php (if using Joomla)
/wp-content/themes/yourtheme/functions.php (if using WordPress)

If you don't have the above, look for files containing long lines of code. Since you are using linux, you may try the following:

$ grep -rl --exclude-dir={image_folder} ".\{1000\}" /var/www

Also, to look for obfuscated code elsewhere, try this:

$ grep -rE --exclude-dir={image_folder} "eval|GLOBALS|error_reporting|chr\(|\\\\x?[0-9]{2}\\\\" /var/www

Although you have mentioned that you have checked your server configuration files, I would highly recommend you to do so again.

After confirming the cause, the next step is to re-install your server with the latest security updates and date from last known good backup to eliminate any possibility of undiscovered backdoors.


PCI DSS Protectecting Card Data Elements when Transmitting PAN

Encryption at transit
Assuming you're not storing these values (encryption at rest is a separate issue), the relevant PCI requirement is #4 "Encrypt transmission of cardholder data across open, public networks" clause 4.1 which requires you to ensure strong cryptography and security protocols.
Transmitting that data over HTTPS fits that requirement, it is acceptable as long as you ensure proper process (e.g. no possibility to downgrade to http, denying older protocols such as TLS1.1, etc). You do need to ensure that this data is not transmitted over other, insecure channels - for example, in communication with your customer service agents over email or some chat application, as per requirement #4.2.


Before you spend any effort trying to get them to change, consider they might be under a requirement you are unaware of.  For example, if they are using these passwords to access a credit card environment, PCI DSS requires a periodic password change.  This could be something completely out of their control.

If that's not the case, you can try referring them to the latest recommendations of NIST in SP 800-63B. In section 5.1.1.2 Memorized Secret Verifiers (aka passwords), they say this [emphasis mine]:

  Verifiers SHOULD NOT require memorized secrets to be changed
  arbitrarily (e.g., periodically). However, verifiers SHALL force a
  change if there is evidence of compromise of the authenticator.

The entire section on passwords is intended to be read and implemented as a whole, of course, but this recommendation stands on its own.  The only complaint I have on the paper is that their recommended minimum length is only 8 characters, which is clearly not enough to withstand a brute force offline attack on password hashes that might be exposed in a data breach.  To mitigate that, they do require stored password hashes be sufficiently protected against brute force attacks, such as 10,000 rounds of PBKDF2.

10,000 rounds of PBKDF2 is suggested for online password verification because the idea is to make it computationally expensive to verify a single password, while still allowing for real-time processing during the frequent occurrences of user logins.   But note that old password confirmations would happen only during an actual password change activity, which should happen far less frequently than regular logins.  And this opens an opportunity to improve your security.

Consider expending extra processing power during the process of password changing.  Compute both the PBKDF2(password,10000) and store it in your "everyday password" table, and keep an archive of PBKDF2(password,50000) in your "prior password" table.  When they log in again, compare them only against the "everyday password" table.  When they change passwords, perform the lookup against all the entries in the prior password table; this will be much slower than a regular login, but because it's infrequent, it shouldn't disrupt your normal business.  Once it's verified as unique, discard and replace the existing everyday hash with the new everyday hash, and add the new strong hash to the "prior password" table, rolling off their oldest prior password.

If it ends up that you can't talk them out of periodic password changes, try to get them to at least implement the strongest practical storage of "prior passwords".


It is about how you interpret what they are writing. They are not saying you should not hash and should store passwords in plain text. What it is saying is that the value you write into LDAP is not hashed or encrypted. This is like the situation you have with a normal database. You can define a column called password and you can either tell the database to encrypt that column or not. You can then stick data in that column, which may be encrypted/hashed or plain text. If you define the column as being encrypted, then data is encrypted as it is written to the column and will be decrypted when it is read from it. If you are storing hashes of a password, that hash will also be encrypted and will require decrypting before it can be used. In general, database encryption is about protecting data exported in data dumps etc. It is a bit like disk encryption in that once you have access to the database tables, the encryption/decryption is done behind the scenes and you don't see it. However, if someone manages to access a dump of the data or gets access to the table datafile on disk, they won't be able to read the information.

Note the definition of password attributes as being stored in an octet string syntax. This format is defined to support the full range of characters you will encounter in hashed passwords. What the best practice is saying is that LDAP stores the value you give it 'as is' without any further encryption or hashing. It is the duty of the software which manages this data to do whatever hashing you want

The 'L' is LDAP stands for lightweight. An LDAP server typically sees lots of reads with far fewer writes. It is designed to handle lots of queries and tries to ensure good performance by keeping it simple. Adding encryption creates additional unnecessary overhead. If the password attribute was encrypted, then all queries would need to decrypt that information, degrading performance.

LDAP also keeps things simple by not providing a management interface. It is essentially a defined tree of attributes and values whose primary role is to answer queries. To further re-inforce this, you will often find that in high-demand environments, you will have a master LDAP server where all the writes/updates are sent and slave/replicaiton servers where all the queries are sent. When you write to the master, if will forward on the changes to the slaves.

Management of the data is usually performed by some other program. For example, at our site, we have a perl program which receives data from our IAM system. It then takes this data, applies some business rules and writes the results to the LDAP master. The perl program performs the hashes of the passwords (we actualy need to support multiple hash types for each password because not every application understands the same hashing algorithm. This hashing also adds a salt.

When a client queries the LDAP server, it will just get whatever is stored in the attribute. With passwords, the data stored includes details of what type of hash has been used. Of course, for binds to work, the LDAP server must understand at least one of the hashes being used in order to perform the bind.

In our case, the main hash we use is SHA-512. References to MD5, SHA1, Crypt etc are outdated and should not be used. This is another example of the advantage of this approach. We used to use SHA-1 and even Crypt once upon a time. We could update to a newer hashiing algorithm easily without having to worry too much about LDAP and versions etc.


Protect against unauthorized connections to the wifi network?

Since the question has been changed, I decided to change the answer which I provided.

To detect unauthorized connections the web-panel on router may be your good friend. Many routers are listing the devices connected on their web panel. Some routers show DHCP table, others name it as 'connected devices' or something similar. Some routers also keep information about all devices that were ever connected (for example BT Hub 3 type A), however this is not always true. Some routers (like mine) automatically forget devices that are not connected for over a specific period of time. This table will be looking different on different routers.

(for own safety I have modified host names as well as clearly I masked MAC addresses)

On some routers you may be able to use remote telnet or ssh to provide remote shell. This however is usually disabled by default, and some routers do not let the users to access them. If this is the case you may be able to use command arp to list all currently connected devices.

(For own safety I have removed list of MAC addresses from the image)

If the router doesn't allow to list connected devices, then you may be able to use 3rd party software on your computer or phone to find connected devices.
This is example of one of such software I found by using google.
Please however note that I do not have previous experience with this software.

I have decided to leave the old answer as I believe that the tips given in it may be helpful in preventing unauthorized connections.

As an user you can protect your router in few different ways.

First you should always use WPA2 (which is more secure than WPA or WEP). This should be combined with a secure password, at least 10 characters preferably including capitals, numbers and special characters. The longer the password the better. This will stop people from brute-forcing your WiFi password easily. I would personally recommend changing the default WiFi password.

Secondly you should disable WPS (allows to connect to router via 8 digit code, this code can be no longer or shorter). This is because quite a lot of routers do not prevent brute-forcing of the pin codes, and other set the pin to known value. As my personal experience, I have never seen anyone actually use it for their own use, usage of normal password is more often and lots of users will not even know how to connect to WPS enabled router.

Third if your router supports MAC filtering you may enable it. This will not stop hackers getting into your network, however it will stop unskilled users who know the password. As a note here, this may become slightly issue if you want to add new device, as you need to go to router website and add the devices MAC address, in order to be able to connect with this device.

You should also try to keep all software up to date. This is to prevent software bugs for example KRACK (Key Reinstallation Attacks) was a good example. Updating all your clients as well as routers to the newest software and firmware allows to fix such bugs. However please note that flashing routers firmware may cause to brick it, if the power was lost while installation was in progress.

Also you should consider wisely who should have access to your WiFi, for example does your friend really need your WiFi password? This may be a bit controversial but at the end of the day their devices will need to store the passwords, and there are multiple ways to extract known password whatever the device used was computer or phone. At the end of the day, the way they handle their devices may also affect security of your WiFi network.

Another advice is to keep your router away from window or visible space at house. There is a possibility that someone may look at the back of the router to see the password through windows and then use your WiFi, or a guest may assume that you will be alright with him using your WiFi without your knowledge.

While this is not really prevention for unauthorized connection to WiFi, I believe it is worth to note that you should also make sure that you change default administrator password on router's web-panel (usually it is on 192.168.0.1 or 192.168.1.1 however this may vary).


If you have some entropy to work with, then use /dev/urandom. Either the kernel has it, or you can inject it in /dev/urandom (e.g. with "cat file > /dev/urandom").

If you do not have such entropy, then you lose.

Note that being headless is not the major issue, since even without a keyboard and mouse, the machine still has disks and network, and get a lot of entropy-bearing hardware events from these. If the machine got "enough" entropy at any point in its life since the OS was installed, then, by the magic of cryptography, it still has it, and /dev/urandom is how you access it. The one remaining issue is when you begin to clone virtual machines.

/dev/urandom is always preferable over /dev/random.


Why is it allowed to change dates to absurd values in OS?

Because there can be numerous good reasons to force a system date at an old value or in the opposite in the future. And an OS vendor that would implement a feature forbidding to set a date older than the one of the OS release would unplease his customers!

You may have to re-run old programs with old values to build again reports from example if the original report is no longer available but you still have the original values. Some programs were clever enough to accept a month as input and use automatically the year corresponding at the 12 last months. Or do not ask for any date and automatically use previous month - expected to be run on a monthly base from a cron. Ok, the program should be re-written to allow entering a date. But re-writing of old programs comes at a rather high cost (need to find programmers able to understand old dialects, need to find old compilers or port the whole code to a new version of the language), while changing a date is a trivially simple operation. Ok it is just a workaround but it is a simple and sufficient one for use cases like that.

A real use case I have seen was a workaround to keep old applications that used to store the date in only 2 digits. In fact they could only accept dates in the range 1970 (origine of most dates in system format) and 1999. Only 30 years available. The trick was a calendar has a period of 28 years (bissextile * day of first of january). We were glad in to 2000' to be able to declare to the stupid computer hosting the stupid app that the year was actually in the 70'...

Anyway changing the date is an administrative task (in the sense requiring administrator priviledges). So a normal user should not be able to do it. And administrative priviledges include really dangerous operations such as formatting a disk full of data. Or erasing the boot sector from a system disk. Or [write here the most stupid action your imagine on a computer]. And there are indeed correct use cases for them such as re-using an old disk.

That's the reason why a system normally trust his admin, whatever he asks for. There are indeed warnings more or less saying Hey admin, this looks a really weird and dangerous thing! Are you sure you really want it???. But as for almost any stupid action an acceptable use case can be found, the system just obeys.


How to get my GNUPG Elgamal private key exponent?

This indicates your private key is encrypted with a passphrase. pgpdump does not decrypt private keys to display them.

With GnuPG 1 and 2, you can at least export unencrypted subkeys using gpg --export-options export-reset-subkey-passwd --export-secret-subkeys [key-id]. This will also print the secret x part of your key. For GnuPG 2.1, this option was removed.

I'm not aware of a similar option for primary keys without changing GnuPG's source code.


Can we just provide VM snapshopts to LEA

Law enforcement do not care about your uptime. Law enforcement do not care about your losses. They want to preserve chain of custody and integrity of evidence. If your gear is seized as part of a raid, they'll take your whole machine. If you want to prosecute someone for breaking into your box, they'll demand a provably identical image of the drive, obtained via a method that is known to be forensically sound. For this reason, companies like Guidance will send someone to defend their forensic software in court for free, if you require it.

Law enforcement will not accept a VMWare image, because they have to prove to a judge that they have a 100% accurate copy of the data. Trying to defend a non-standard process when they've got defence lawyers staring them in the face is not something they want to try. The notion of the technicality is a common one.

At the end of the day, you need to ensure that you can make a forensic copy of the drive, and maintain chain of custody on the evidence. A defence lawyer will ask you how you know that the copy was accurate, and how you can prove that the copy or original drive was not tampered with. If you can't answer that, they'll tear your case apart.


Yes, It's enough, but you can harden it using XPACK, Xpack is available now in free version of ELK.
Please check the reference regarding XPACK: https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-xpack.html

You can run elasticsearch in local network only, If you want to access it later outside your network you can use NGINX Reverse Proxy

Here's the guide : https://logz.io/blog/securing-elk-nginx/

Additionally, the password in elastic is a default. So you can change password in all built-in users by using this command:

bin/elasticsearch-setup-passwords interactive

Lastly, Enable auditing features. Add the following setting to elasticsearch.yml on all nodes in your cluster:

xpack.security.audit.enabled: true

You can look a walkthrough for security in elastic website.


Are private keys generated by different software packages compatible?

Usually you do not upload private keys on key servers, just public keys... private keys are meant to be, well, private. No point in shouting them far and wide.

OpenPGP is a standard format for messages and keys. The mathematical object which is a RSA public key (technically a list of eight integers for the private key, two integers for the public key) can be encoded in many ways and OpenPGP is one of them. GnuPG follows this format.

OpenSSL is a library (and some command-line tool) which was primarily focused on SSL/TLS and includes implementation of cryptographic algorithms. SSL uses public keys in X.509 certificates, which is another format, quite distinct from OpenPGP. Same kind of mathematical objects (RSA keys...), but different encoding. GnuPG internally uses OpenSSL for the cryptographic algorithms themselves, but applies its own encoding.

PuTTY is a SSH client which uses again keys (RSA, DSA...) with yet another encoding format. Again, the same mathematical objects are represented as distinct sequences of bytes.

Some people are working on bridges between these competing formats. It is still a great source of inconvenience.


Your webserver can disallow access to files and folders.  You could make this configuration in a .htaccess file which contains your password hash.  Storing plaintext passwords should be avoided at all costs.

Make sure that authentication is performed over HTTPS and HTTPS is used for the life of the session. If you don't follow this guideline then you will be in violation of OWASP a9.


1.1.1.1 Cloudflare encrypted DNS.Does it still leak IP addresses?

There are several unrelatd topics here, but:
Yes, the IP never is safe from attackers. Neither is the domain name is your scenario.

First, Cloudflares DNS might support some encrypted transfer, but this won't happen if the client doesn't use it. Making a normal old DNS request is still unencrypted, so a sniffing something can see what domains you're visiting.

Then, even if it was encrypted, the whole point of DNS is to transform a domain name to a numeric IP address. This IP is then used to request the content of the website itself. Anything on the way there (your ISP, some other commercial internet nodes, the websites hoster, etc.) can see the target IP (and yours too).

And the content of the request will also contain the domain again, because there might be several different domains on one IP. This is true for both HTTP and HTTPS, and both times it is not encrypted. There are some plans for HTTPS to make encryption of this part possible, but right now it is plaintext.


There is no known property of the first/last/middle/whatev 60 bits of a SHA-256 output that would make them more/less "randomish" than the last/whatev/middle/first 60 bits. In other words, you could take the first 60 bits, and that will be as fine as you can get.

With such a random generation, you can indeed expect the first collisions to appear after one billion or so (230) IDs have been accumulated. Even if you get your first collision at that point, collisions will still remain a rare event. With 60-bit IDs, when you have, say, 235 of them (that's more than thirty billions), then only one in 225 of new IDs will collide with an existing one (so this would still happen less than once in 30 millions of cases). If you have a database and can tolerate the occasional but quite rare collision, then random generation of the 60-bit ID is the way to go.

(Or, said otherwise, if you get collisions often, then this means that you have already gathered a huge number of IDs, and your central database must be of biblical proportions.)

If you want more uniqueness than that, then you need some sort of central ID generator. For instance, there is a central server that can be interrogated, and returns the next value of a counter. The server always increases the counter value after being interrogated, so it never returns twice the same value. The server won't run out of 60-bit integers before a long time, because, let's face it, 260 is still huge.

Now comes the hard part, which is the one you did not talk about: must the IDs be unpredictable ? This is not an easy question; it depends on what you do with them and, basically, everything in your system. If you need unpredictable IDs, then a central counter will not work, because everybody can obtain an ID value and predict the next one with 100% accuracy. The usual solution, in that case, would be to still have a counter, but to encrypt the successive values with a block cipher whose block size is identical to that of the ID. Here you would need a block cipher with 60-bit blocks -- this can be built out of a block cipher with slightly larger blocks, e.g. 3DES (64-bit blocks). This makes sense, though, only in the context of a central ID generator.

If you must allow ID generation from several "client" machines without having them talk together or with some central system, then you will have to rely on randomness and tolerate the few occasional collisions (that will be quite rare for a long time). If you need unpredictability, then use a cryptographically secure PRNG. Depending on your operating system and programming framework, this may be called /dev/urandom (Linux/Solaris/*BSD systems), CryptGenRandom() (Windows C/C++), java.security.SecureRandom (Java), System.Security.Cryptography.RNGCryptoServiceProvider (.NET)... Is is possible that the inherent UUID generation system of your local programming environment relies on a cryptographically secure PRNG (so hashing an UUID with SHA-256 would then be fine, even for unpredictability), but why take risks ? Just use a strong PRNG directly.


is every site without a CSRF token vulnerable to CSRF attack?

The simple answer is “no”. Cross-Site Request Forgery (CSRF) tokens are a generalized defense against CSRF, but other conditions must be at play to be vulnerable. For example, the attacker needs to be able to predictably make a valid request to the site. There are also other design factors that can be used to mitigate against the threat of CSRF.

Auth/Session cookies tend to make attacks easier because they are submitted with any request to the domain regardless of whether the request came from the same origin site. Cross Origin Resource Sharing (CORS) helps prevent this by blocking cross-origin requests unless the site the request is being made against explicitly allows cross-origin requests. However, GET requests are usually allowed so long as they are not made via JavaScript, so sometimes a CSRF attack can sneak in by requesting content using an image tag.

Related to Auth Cookies... another mitigation against CSRF might be to submit the auth token as a header, rather than a cookie. This requires that your requests have the token added explicitly with each request, thus mitigating the risk of the browser automatically adding the authorization to requests not made by your own code. The token is usually stored in Local Storage for this, which can only be accessed from code that loads from the same domain as the code that saved it.

As mentioned above, to be vulnerable the malicious code needs to be able to predict how it needs to interact with the site to get a useful response. For example, if the site under attack were a bank, the malicious code needs to be able to determine the complete details of a request to transfer money to be able to do so. If the money transfer request assumes a default source account, this is much easier for the attacker to do since they won’t need to guess that information because the server assumed the user’s context by default.

That said, in most cases the attacker may be able to access quite a lot about the user from your site if they have enough time to play around with it from their own account. So assuming the attacker can’t do something because a cross-site request wouldn’t be successful in a single step would be folly. In the prior example, they would just need to make a request to get a list of the user’s accounts before they can make a request to transfer money.


The host machine can impact and alter whatever it wishes in the guest VM. The host can read and write all the memory of the guest, stop and restart it on a per-instruction basis, and, by nature, sees every single data byte which enters or exits the guest. There is nothing which the OS in a guest VM can do to protect itself against an hostile host.

Thus, if the host is vulnerable and subverted (an hostile attacker takes control), then the guests are toast.

In your specific case, be assured that if the "protection software" is not aware of the existence of Windows 8, then it is indeed too old to be much good against virus. I bet your customer knows it, too; by recommending a workaround (the VM with Windows XP), he is showing you how work can still be done without having to openly rebel against a company policy. In big organizations, there are often legacy policies which outlast their usefulness by years but can be removed only by waiting for the responsible people to retire or be fired.


It's a way of an attack, called "Blind SQL Injection". Official Documentation from OWASP: https://owasp.org/www-community/attacks/Blind_SQL_Injection

Blind SQL (Structured Query Language) injection is a type of SQL
Injection attack that asks the database true or false questions and
determines the answer based on the applications response. This attack
is often used when the web application is configured to show generic
error messages, but has not mitigated the code that is vulnerable to
SQL injection.


Where does the responsibility lie for a XSS vulnerability

The fault is almost certainly that of the Workflowy extension.  It is the extension developer's responsibility to ensure their extensions are secure, and avoid introducing mistakes like XSS vulnerabilities into their extensions.

XSS vulnerabilities are common in browser extensions.  It is easy for extension developers to screw up and introduce a XSS vulnerability, and extension developers often aren't focused primarily on security and may not be very aware of security issues, so security vulnerabilities in browser extensions are common.

Actually, Chrome is at the forefront of developing mitigations against these kinds of vulnerabilities.  While the responsibility is ultimately with the extension developer, Chrome recently introduced powerful mitigations that make XSS vulnerabilities in new extensions less likely.  These mitigations rely upon restricting extensions, using a Content Security Policy, in a way that helps prevent XSS vulnerabilities.

For backwards compatibility reasons, the new restrictions only apply to new extensions.  It will take some time for these new defenses to be phased in fully.  That said, this is a great development.  It will really help protect users.  I hope that other browsers follow suit.

For more on this topic, here is a recent research paper on this subject:

An Evaluation of the Google Chrome Extension Security Architecture.  Nicholas Carlini, Adrienne Porter Felt, and David Wagner.  Usenix Security 2012.

Some sample findings from the paper:

An analysis of 100 randomly selected Chrome extensions found that 40% of Chrome extensions had at least one security vulnerability.
The same analysis also found that Chrome's new defenses should eliminate 94% of the most serious vulnerabilities.

See also a blog post summarizing the paper's findings, and another follow-up.


There's no way to tell directly from that actual test, there's no enough information. However, you could tell whether the exploit works or not by telling the target system to do something that it is allowed to do, for instance browse to a web server under your control (presuming that any outbound web connectivity is allowed). If you command it to get a webpage and you get a hit on our site, the exploit works, and then you know that the shell command isn't working for some reason.


How can I check that my cookies are only sent over encrypted https and not http?

The cookies secure flag looks like this:

  secure;

That's it.
This should appear at the end of the Http header:

  Set-Cookie: mycookie=somevalue; path=/securesite/; Expires=12/12/2010; secure; httpOnly;

Of course, to check it, simply plug in any proxy or sniffer (I use the excellent Fiddler) and watch...

*Bonus: I also threw in there the httpOnly attribute, protects against cookie access from Javascript space, e.g. via XSS.


How do I know if my computer is being used for a botnet-based DDoS attack?

There's no easy way to detect whether your machine is part of a botnet.  Instead, the best defense is prevention: avoid getting infected in the first place.

There is lots and lots written on how to avoid security breaches, too much to repeat here.  For a starter, you could read, e.g., a security guide for non-technical users, Windows hardening, Hardening Linux Server, or Secure Linux Desktop.  Happy reading!


You question of

  Does this mean I can copy a certificate from a client(Firefox's built in store, Android's, etc.)

is answered by:

  SSLsplit can also use existing certificates of which the private key is available, instead of generating forged ones.

Since you don't have the private keys for the CA certificates in the built in store you cannot use these.


Encoding is required and is the main part of how URL functions for the application server to receive correct form of data.

If your attack doesn't require user interaction like XSS, you can just craft your attack payload in python; in case it will remain the same and the attack takes place.

If you're missing the basics,  you can read the article below.

https://www.lifewire.com/encoding-urls-3467463

Encoding a URL
The most commonly encoded character in URL string is the <space> character. You see this character whenever you see a plus-sign (+) in a URL. This represents the space character. The plus sign acts as a special character representing that space in a URL. The most common way you'll see this is in a mailto link that includes a subject. If you want the subject to have spaces in it, you can encode them as pluses:

mailto:email?subject=this+is+my+subject
This bit of encoding text would transmit a subject of "this is my subject". The "+" character in the encoding would be replaced with an actual <space> when it is rendered in the browser.

To encode a URL, you simply replace the special characters with their encoding string. This will nearly always begin with a % character.

Encoding a URL
Strictly speaking, you should always encode any special characters found in a URL. One important note, in case you are feeling a bit intimidated by all this talk or encoding, is that you generally won't find any special characters in a URL outside their normal context except with form data.

Most URLs use the simple characters that are always allowed, so no encoding is needed at all.

If you submit data to CGI scripts using the GET method, you should encode the data as it will be sent over the URL. For instance, if you are writing a link to promote an RSS feed, your URL will need to be encoded to add to the script URL you're promoting it on.

What Should Be Encoded?
Any character that is not an alphabetic character, a number, or a special character that is being used outside its normal context is going to need to be encoded in your page. Below is a table of common characters that could be found in a URL and their encoding.

Reserved Characters URL Encoding

Character   Purpose in URL  Encoding
:   Separate protocol (http) from address   %3B
/   Separate domain and directories %2F
#   Separate anchors    %23
?   Separate query string   %3F
&   Separate query elements %24
@   Separate username and password from domain  %40
%   Indicates an encoded character  %25
+   Indicates a space   %2B
<space> Not recommended in URLs %20 or +


Is there any security concern if I kept password hash on client side?

Well, first and foremost, check you are hashing and salting the password correctly. It is a lot more critical if the hash is available more easily to attackers. Also keep in mind that even correct hashing can't protect short passwords from determined attackers.

Second of all, if you are using this hash to the authenticate to the online server, you should be aware, that if someone gains access to this hash, they can authenticate to your server. Because the client app can authenticate just using the hash, the attacker can also authenticate using just the hash. You may want to add some nonce to this, that would change on every online login, in order to prevent reuse after a client logs out.

Finally, be aware that you should hash the hash on server side once more (normal SHA2 will suffice), otherwise if someone obtains the hash from your server database, they would be able to authenticate as well. If they obtain a hash of the hash, they can't get the hash that can be used to authenticate.


Each SAML response includes an issuer field identifying the IdP. Furthermore, either the SAML response or assertion is signed by the IdP's private key so, as long as the signature verifies, you know who sent the SAML response.

If your SP receives a SAML response from Acme it should make the additional check that it includes an @acme.com email address.

In general, the SP can reject the SAML response if it doesn't contain the user identity information it requires or this information is invalid from its perspective.


Signing mails is in my experience the best method to show others they can send you encrypted mail. If they're using OpenPGP anyway, their mail client might even automatically enable encrypted mails as replies to signed ones. Recently I was very surprised receiving (S/MIME) encrypted mail from both a bank and a health care institute, just because I signed the mails I sent them.

You don't need to (and shouldn't do anyway) use clear text (inline) signatures (with all their bulk), although they're a very present hint you're accepting OpenPGP encrypted mail. It might be of interest using this if you especially want to prompt others sending encrypted mail, your capability of doing so, or just make them curious... Instead, there is also PGP/MIME, which will not distract anybody (but I think users of MS Outlook might see some attachment they don't understand), but still offer the advantages to other OpenPGP users described above.

Always signing mail (using PGP/MIME or S/MIME) produces some background noise, but doesn't disturb and nobody has to care about a few additional bits in each mail, and you might get awareness for signing and encryption into the subconscious mind. Worked out for me pretty well, I got quite a bunch of people around me to sign and encrypted mail this way (or do it again, and regularly).
Put your fingerprint into your signature and on your business card. Expect to get asked about it, and be ready to explain what that's all about.
Put your public key on keyservers. Lots of mail clients with support for OpenPGP automatically query them, especially after receiving signed mail.
Talk to others. Request them to send confidential information encrypted. Encrypting mails is rather easy, the sender doesn't even have to create his own key pair. Guiding others is rather easy even on the phone if you tried the most relevant plugins.
Consider also using S/MIME, even if it's "just" a CAcert certificate. Even if the certificate is not trusted, most mail clients support S/MIME out of the box, and replying with encrypted mail is much easier than with OpenPGP: no plugins required, and the certificate is automatically attached to your mail, the replying sender just has to click the "encrypt" button.


The terms you're looking for are Mobile Device Management (MDM) or Enterprise Mobility Management (EMM)

There are many vendors.  Security.SE isn't a vendor recommendation site, but one option is Cisco's Meraki System Manager - they are free for under 100 devices and can handle a mix of iOS, Windows, Android, MacOS.  Disclaimer : I have no relationship with Cisco other than using their services/products.


Which Protection Profiles required for EAL 1 test?

For a simple network device such as router, in 2016 you only need to claim NDcPP (collaborative Network Device Protection Profile) and nothing else.  PP (protection profile) you linked is no longer in use. NDcPP will include all functional (SFR) and assurance (SAR) components that you have to include in your ST (Security Target). NDcPP is evaluated at EAL1, but you don't include explicit claim of EAL assurance with it.
NDcPP requires exact compliance, that is you can't add or remove requirements and conforming is all or nothing deal. The only exception is EP (extended packages) such as firewall and SIP server that are technology-specific. You can find full list of EPs here: https://www.niap-ccevs.org/Profile/PP.cfm by searching for "Extended Package for...".


Value of Physical Security Vulnerabilities to an Attacker

In current, real-world networks, what benefits would physical access to a networked machine provide a potential attacker?

The most obvious example is an 'air gapped' network that is not connected to the internet - there was a real-life example of this in stuxnet where the target facility had no external networking. To physically access the network, the attackers dropped USB drives containing the worm around the facility that facility employees found, picked up, and plugged in, accidentally releasing the worm into their internal network.

You may also frequently hear the term "m&m network" or "m&m security". These terms refer to a network with a hard 'outer shell' and a soft 'chocolate center' - networks that have strong perimeter security but no security features (encryption, authentication, etc) between services or hosts in their network. Physical access to one of these networks can help bypass the hard outer shell.

  How do these benefits compare to the risks associated with breaching physical security at, say, an average data center?

Like other risk questions, this depends on risk/reward. If all you need to do is drop some USB drives near the target network there is low risk. I've been in a few data centers and they all have substantial security - unauthorized physical access is highly unlikely, and employees have been trained against common social engineering tricks and won't disclose information or plug in USB devices. Suffice to say that 99.999% of the time you can be assured that nobody will have unauthorized physical access to the datacenter.

  Finally, are there any network security measures in use today which can effectively prevent remote access by an attacker?

This is too broadly scoped to fully answer, but a good example is the airgapping we discussed before: disconnecting your network from the public internet to prevent anyone remote from even seeing your network. Of course this has the drawback of preventing your network from talking to any other networks or the internet.


what would be a good way for a doctor to send xrays encrypted to another doctor?

Sending healthcare information like that is very tricky, since you have to meet the healthcare security and privacy laws in your country (HIPAA in America). You might be able to use something like PGP to encrypt the emails and this may fine legally (I'm not a lawyer though). Encryption implemented through PGP would have fairly good support in email clients, so it should work for most places you want to share data with. However, this is a very hard-to-use solution. I'd be much better to not have to email PHI like that. You still have to worry about auditing access to the data, as well as proper access control.

What you really need is software that can enabled collaboration between two healthcare providers. This would give your organization a lot more power than what you currently have. This software would then handle the secure communication between the two healthcare practices. It would also let you share this data in a much easier, standards-based way.

As a side note, I started a Healthcare Industry Stack Exchange proposal where this question would be perfect. Those interested in questions like this should consider joining.


precautions before conducting a penetration test

The point of a penetration test is to test a company's actual infrastructure as if the pentester were a real attacker. This way, the penetration tester can find security issues that the company has been unable to find by itself. Pentesters oftentimes find "bugs" in things that aren't software: some test physical security and social engineering as well.

While hacking into virtualized systems that are separate from the organization's actual infrastructure might be useful, it isn't a penetration test in the traditional sense.

Since the penetration tester is being paid by the organization they're hacking into, they're not going to do something that would actually harm the organization. Once they find a foothold into a system, they might exploit it and continue further inside the organization's infrastructure. However, they won't actually steal data or install malware like a real hacker would. The pentester usually has a contract that prevents them from being sued if something bad happens, but they'll still do their very best to avoid causing actual damage.


What should I have prepared for a PCI compliance onsite assessment?

That depends on several things.  Unfortunately, the PDI DSS is a bit vague in some areas, and different auditors interpret things differently.  Expect your first audit to by 80% figuring out what you need to prepare, 20% actually getting it together, and then expect future audits to go more smoothly.  But your QSA will tell you what he/she expects.

In general, though, you should have written polices for how you protect your data (backups, live, etc) and be able to produce logs and evidence that shows that you follow procedures.

For example, to satisfy section 6, developers need to have a documented development process.  We do, and our process includes steps like code reviews (so we provide copies of completed code reviews) procedures for asking admins to publish a specific tagged item from source control to address separation of concerns (so we provide change request tickets that specify which version of source code gets published on what date/time).

The same goes with the rest of the audit.  Have your procedures documented, and provide proof that you follow those procedures.

As for how detailed the policies should be, you should build your paper trail into the policies, so that the auditor knows what to expect for documentation, and so that you force yourself to collect the documentation throughout the year.  It makes things a LOT easier.  Include things in your polices like "All changes are logged in (name a system)" and then actually log your changes in that system.

Odds are, your current practices won't 100% meet the requirements, or you won't be able to provide that documentation.  Generally that seems to be expected on a first audit (or so I gather from our auditors) and the first audit is sort of an eye-opener.  It teaches you where you need to improve your polices (and improve them right now).  You will likely have the opportunity to provide what you have, and start drafting new policies under the guidance of your auditor. In subsequent years, expect less leniency.


How to get any information from 1102,1104,1105,1106 ports?

That depends on the service listening to these ports. Often when ports are in sequence, like your output, there is just one process running multiple instances each bound to its own port.

Without any info about the server, it is hard to tell what protocol is used to communicate over these ports. For all we know it's a custom network protocol, allowing only certain types of data or addresses.

You could feed a stream of /dev/urandom endlessly to see if something comes back. I can ensure you, the successrate is low.


How to understand GitHub's password policy?

GitHub would like me to choose a password that has never been used by anyone on any site at any time in the history of the internet.

That's the general idea, though I would rephrase as

  GitHub would like me to choose a password that has never appeared on any list of cracked passwords for any user on any site in the history of the internet.

Rationale:

Each time a famous site gets its password database hacked, hackers eventually publish the list of username:email:passwords for all users on that site at the time of the attack. The site haveibeenpwned.com catalogs all username:passwords where the password is publicly-available. You should check here every month or two (or sign up for their notification service) to make sure you aren't on the list! This is just the username:email:passwords that are publicly known, I'm sure darkweb hacker groups have many many more than haveibeenpwned knows about.

This leads to a couple different types of attacks which github is probably trying to prevent with this password policy.

Password re-use attacks

Attackers trying to get into your account can look you up on social media and make a list of all the usernames / accounts that belong to you. Then they can look these up in the cracked password databases and get a short list of passwords that you have used in the past. We know that users tend to re-use the same password across different sites.

Github doesn't want to get into the game of trying to guess which accounts on other sites belong to you, so it's easier to say "anyone on any site at any time in the history of the internet".

Dictionary attacks

Attackers doing more general password cracking -- usually after they have stolen a database of hashed passwords -- can't guess every possible password because there are too many, so instead they will use dictionary-based approaches for which passwords to guess. Lists of cracked passwords (sorted most frequently used first) are a pretty good dictionary to use.

Given today's GPU speeds, if your password is one of the, say, billion most used passwords on those lists, then you're probably vulnerable.

Again, it's easiest for github to just ban all passwords on the cracked password lists.

You also ask:

  What are the implications? Does it spell the end of human-memorable passwords?

Yup, probably. Over time the lists of cracked passwords will get longer and longer with fewer human-memorable (aka "weak") passwords available to choose from. This will probably hasten the demise of passwords, cause more R&D focus on making password managers / Yubikeys, etc more user-friendly and force people beyond tin-foil-hat security nerds to start using them. This is probably a good thing. I hope more sites do start doing this!


For updating non-connected computers, you can use offline updating tools that download the updates using another computer (which you can then transfer to the non-networked computer via USB drive for installation). For example, you can use the WSUS Offline Updater for Windows. For your AV vendor though, you would have to check with them on how to get offline updates.


is there any program that can tell me which files have been transferred from my computer thru the web

Depending on what you want exactly, you can use an IDS, like Snort, to record and alert based on certain criteria. Wireshark or tcpdump can also be used with filters to log file transfers.


How are CVSS scores used in security risk management products?

First of all, there are three different metrics to calculate the global CVSS score. These are: Base Metrics, Temporal Metrics and Environmental Metrics.
Temporal Metrics and Environmental Metrics are optional and these are calculated using the Base ones as an input value. To have a better overview of these metrics and their equation, take a look of this picture:

(source: first.org)

Generally, the base and temporal metrics are specified by vulnerability bulletin analysts, security product vendors, or application vendors because they typically have better information about the characteristics of a vulnerability than do users. The environmental metrics, however, are specified by users because they are best able to assess the potential impact of a vulnerability within their own environments.

That means that the user must provide the environmental metrics whereas a vulnerability scanner might provide the others.
As far as I know, Nessus includes just the Base and the Temporal Scores. Thus, Nessus is not able to get the value of the Environmental metrics. The environmental metrics depends on the organization's necessities.
Otherwise, if you want to calculate the CVSS score using the Environmental Metrics, you can not use an automatized vulnerability scanner as Nessus. You would need to assess the system and decide the threat that the organization is capable to bear.
In order to calculate the global CVSS score, you can mix the results of a Nessus scan with the assess of the system.
There is available a CVSS v2 calculator
In addition, it looks as if Qualys works in a similar way. The scanner provides the Base and the Temporal Score, moreover the user provides the Environmental metrics.

The CVSS Environmental Metric group captures the characteristics of a vulnerability that are associated with the user's IT environment.

More information of Qualys and CVSS

I suppose that the global CVSS Score should take the worst situation possible.


Is the unauthorized deletion of data considered a breach of integrity or availability?

However, one of my colleagues disagrees and considers such to be an attack on the Integrity principle, because data was modified by being destroyed without authorization.

Your colleague has a point. Unauthorized data deletion is foremost a breach of integrity since deletion can be considered a special case of modification. This can have an impact on availability, but it doesn't have to. E.g, an attacker who manages to delete all logfiles on a web server probably wouldn't impact the server's uptime. But obviously a breach of integrity often implies impaired availability since a service with corrupted resources will likely not function properly.

I wouldn't always force a vulnerability into one of the three CIA categories, though. The impact of unauthorized data deletion is quite obvious, so I'm not sure categorizing it according to the CIA triad adds any clarification. Also note that there are many alternative models such as the Parkerian hexad that give you a few more options to choose from.


In block cipher algorithms the IV is not secret. Only the key is secret. Most of the time an IV is just a block of random data and is sent along with the enciphered message to the recipient. Actually the IV can be considered as an algorithm parameter.


Simple messaging app with users specifying own keys

The security of your encryption scheme relies basically on 2 factors.

Security of the devices the app runs on. If the devices are compromised and the attacker can spy on the on-screen keyboard then it is game over because the key is compromised
The secure key exchange to the recipient of the message. In order for it to be considered secure, you need to use a completely different channel to agree on the key. Verbal communication (over which medium? Not the same device!), another device (a PC, maybe?), classical mail?


I want to restrict access to Nextcloud using OpenVPN

Given that Nextcloud is designed to be an internet facing - e.g. "cloud" - solution, adding a VPN seems rather overkill unless you are planning to use it for very sensitive or high-value data.

Note that in using a VPN, you are committing yourself to getting the network design right and to ensuring that all the users have secure computers since you are allowing those devices into your secure network.

In my view, you would be better served spending a little time making sure that access to the Nextcloud server is properly configured. Also make sure that the server is constantly patched and that you are receiving security alerts from it so you know if someone/something is attacking.


Out of the box with GnuPG/PGP, there is no way to encrypt a file with the method you suggest.  There is a "group" encryption or ability to encrypt to multiple recipients, but that allows each recipient to individually decrypt the message rather than rely on anyone else's key.

What you can do, and is commonly done, is to split the PGP private key and require multiple individuals to come together and make the key whole in order to decrypt the message.  Also, instead of individuals, you can have the other part of the key be on a hardware security module, smart card, or other such device.

You might want to take a look at SplitGpg which seems to do what you are asking.


If multi factor authentication is enabled, how should that affect self-service password reset?

Assuming the user has a multifactor device and forgets their password, how should that affect the "forgot password" workflow?

If the user is initiating password reset from an unrecognized device/browser then a second factor of authentication should be required to perform a password reset. Best practice is to require the second factor consistently across all scenarios: Normal authentication (after verifying password) or Password reset (after verifying access to email link).

If the device/browser requesting the password reset is recognized, then two-factor authentication could be skipped after clicking an email password reset link.

  What if the user loses the multi-factor device, or the soft token is corrupted, how should that be re-provisioned?

If the device/browser is recognized or if the user already has an authenticated session on the device then the user should be able to de-provision the lost second-factor device and provision a replacement second factor device.

If the device/browser is not recognized and/or the user does not have an authenticated session on that device then a backup two-factor authentication method must be validated before re-provisioning the second factor device.

  What if the user forgets the password, and loses the token... what should the re-provisioning workflow look like then?

Emailing a reset link is sufficient to recover the password from a device/browser that is recognized as trusted*. After the user resets the password the user can go through the re-provisioning of second factor as described above.

If the user's device/browser is not trusted then the user must verify a backup method if the second-factor device is no longer available. This could be a SMS sent to a backup phone number, or a backup string that was provided when the two-factor authentication device was enrolled. Omitting this verification of a backup code negates that two-factor authentication was ever enabled. It must be performed.

See Google's help docs on 2-step verification for more information about how Google handles these scenarios. They've definitely thought this through and have a lot of good information available online.

* Where 'trusted' means that the user previously authenticated using two-factor authentication and indicated that the device/browser should be trusted for subsequent authentications (and to not require two-factor authentication again from this device).


What are the vulnerabilities of VOIP-specific security protocols?

Putting findings in an answer instead of comments seems to be the best approach.

As usual, turns out this has been discussed before. A quick search on CiteSeerX gave 50 papers, however not quite up-to-date:

Angelos D. Keromytis (2009) Voice over IP: Risks, Threats and Vulnerabilities
Prateek Gupta, Vitaly Shmatikov (2006) Security Analysis of Voice-over-IP Protocols

  We present a structured security analysis of the VoIP protocol stack, which consists of signaling (SIP), session description (SDP), key establishment (SDES, MIKEY, and ZRTP) and secure media transport (SRTP) protocols.

  Using a combination of manual and tool-supported formal analysis, we uncover several design flaws and attacks, most of which are caused by subtle inconsistencies between the assumptions that protocols at different layers of the VoIP stack make about each other.

  The most serious attack is a replay attack on SDES, which causes SRTP to repeat the keystream used for media encryption, thus completely breaking transport-layer security. We also demonstrate a man-in-the-middle attack on ZRTP which disables authentication and allows the attacker to impersonate a ZRTP user and establish a shared key with another user. Finally, we show that the key derivation process used in MIKEY cannot be used to prove security of the derived key in the standard cryptographic model for secure key exchange.

G.Aghila, D.Chandirasekaran (2011) An Analysis of VoIP Secure Key Exchange Protocols against Man-in-the-Middle Attack

  We have come to notice that the three key generation protocols ZRTP, SDES and MIKEY are vulnerable to the Man-In-The Middle attack. Our analysis suggests that the key management protocols that operate in the media layer are indeed suitable media keying protocols despite their operational differences.

As pointed out by Philippe Lhardy, audio streams in their compressed form present an attacker with an opportunity to infer: identity of the speakers, language being spoken and a few other details.

Two modes of compression have been analysed in the literature:

VAD (Voice activity detection) - Speaker Recognition in Encrypted Voice Streams
VBR (Variable bit recording) (pointed out by Seth from Crypto SE in this question)

Spot me if you can: Uncovering spoken phrases in encrypted VoIP conversations
Language identification of encrypted VoIP traffic

Would be grateful for any other ideas and suggestions, especially related to videoconferencing.

EDIT: A related question: Can voice chat be spied?

EDIT #2: Cryptocat is an implementation of Off-the-record messaging: Flaws in Crypto Cat

Any discussion of VoIP should include this possible requirement.

Following a suggestion from landroni, here's a link to vulnerabilities found in the ZRTPCPP library: http://blog.azimuthsecurity.com/2013/06/attacking-crypto-phones-weaknesses-in.html


Lock a website login to a certain computer

One relatively easy approach to this would be to create a persistent cookie on the client's side after the first log in. The cookie should hold only the user's username and a generated key. During the next log in the server would verify the key against the same key stored in the database and if it doesn't match or the user doesn't have the cookie at all you can react in a way you want, for example some type of second level authentication etc..

This however brings up the question, what to do if the user for example clears cache or changes the browser? This should be something you take into account. Probably one of the most well known application which uses this system of authentication and verification on new computers is Steam. No cookies, but the principle is basically the same.


How to efficiently locate malware on an endpoint?

from one of the interviews I had, I have no knowledge in system security

I know several people with CISSPs who would struggle to answer the question competently - what was the interview for? Really my question is what level of skill/effort is expected by the person asking the question?

  trivial stuff like checking Firewall Settings or Security Updates

That's a rather strange thing to say. if the interviewees first response was to start looking at the infection vector then the interviewer should be questioning their approach. OTOH, I would consider evaluating the infection vector a useful method of identifying possible candidates for the malware.

You should always start with the obvious/cheap checks:

  A customer suspects that one of his endpoints got infected by malware

My first step would be to establish why the customer suspects that. From then on subsequent steps branch out - there is not a single path which lead you to the answer in every case. You prioritize actions which will maximize the amount of information about the malware for the minimum amount of effort / cost.

Some of the things to look at:

is there a time when the system was in a known good state?

what files have changed since the known good state?

is there anti-malware installed on the system

is it working

if not, when did it stop

is it reporting anything

what processes are running?

how does this compare to a similar system which is not infected

etc.

At some point you may have to intervene with the operation of the system. While this is perhaps beyond the scope of the answer expected by the interviewer, it is essential to preserve the state of the machine before the intervention in order to identify the malware - even if we're not talking about a crime scene, mapping out the cause/effect network often requires backtracking.


Are virus signatures different between antiviruses?

Yes, signatures vary as they are developed by the antivirus vendors independently of one another. One vendor's product may catch malware that another misses, or get a false positive that another would not find.

You may end up with multiple vendors having identical signatures for the same piece of malware because of malware's traits have few, or one signature options, but they are arrived at independently.


Site accepts creation of long password, but not usage

Obviously whoever built this was not very good at what they were doing and/or not really paying much attention to detail. When working with security critical things like authentication, that's not great.

Think of it like this: If you found that your electricity guy had accidentally installed the outlet sockets upside down, that in itself isn't the end of the world. But wouldn't it make you a little bit worried that he messed up something else more critical and your house will burn down?

Also, short limits to password length might be an indicator of a legasy system with no or bad hashing. Even worse, as jrtapsell highlights, the fact that the password is accepted when set but not at logg in could be a sign that it is truncated when inserted into the database and hence stored in plaintext.

So while this is proof of nothing, it should still set off your alarm bells.


Are there any problems with using CAMELLIA, IDEA and SEED based cipher suites on a web server in 2016?

IDEA uses 64-bit blocks. This means that it begins to run into trouble, cryptographically speaking, if you encrypt more than 232 blocks worth of data with the same key (in CBC mode). That's 32 gigabytes, which is quite large, but not unattainable by today's standards. Thus, it should be avoided.

Camellia and SEED are block ciphers that exist mostly because the Japanese and Korean governments suffer from NIH syndrome. As far as we know, they are pretty decent algorithms -- just like the AES. There is no substantial reason to believe that they are stronger; if you are on the paranoid side, consider that if there is some unknown method by which the AES could be spiked, then there is no reason to believe that Camellia and SEED are not equally affected.

A practical reason to prefer AES is that there has been a lot more work on making constant-time implementations of AES. Also, some CPU offer some hardware support, which is even better for protection against side-channel attacks, and offers better performance. A typical Web server will not have any performance issue with any of these algorithms; whether side-channel attacks are applicable in practice or not is anyone's guess.

Still on the practical side of things, if clients don't support Camellia or SEED, then it is quite pointless to enable them on the server -- they won't be used anyway.


The PGP keyserver pool has dozens (129 at the moment) of keyservers in it.  When you make a request to it, you may get a different server than the previous request.  Over time, the keyservers all exchange their new keys & signatures with one another, so it will eventually propagate to all of them.  It's hard to say what "eventually" is, but my experience is a few hours.

If you need an operation to complete quickly, pick a single keyserver by name and use it for those operations.


Is encryption required to store non-PAN data under PCI DSS?

Do we need to encrypt this non-PAN data in our database without the
  PAN?

No.  To quote the DSS, "If PAN is stored with other elements of cardholder data, only the PAN must be rendered unreadable according to PCI DSS Requirement 3.4."  We can assume that when stored with tokens or other non-PAN data, this non-requirement stands, because "[PAN]  is the defining factor for cardholder data."

The first quote is from page 8, which also has a nifty table showing what must be rendered unreadable:


How do I assess and mitigate the security risks of a VNC tool?

Is there a way to mitigate or minimize this security risk?

Sure.

Only use trusted remote-desktop software. Some operating systems come with a default one, though it may not always be the ideal piece of software. This software need not be proprietary, there are open-source options to choose fome.
Use strong authentication, never short or simple passwords.

For a super-secure setup, you can handle this be using a secured connection to the server, with something like an SSH tunnel. Using port-forwarding, the VNC server can be configured to only accept connections on the remote desktop ports from itself and not any external connections.
If that's not an option, definitely use a strong random password and ensure that your communication to the server is encrypted. If you password is sent in plain-text, it can be intercepted. VNC itself it not necessarily encrypted.
Additionally if possible, you can use a firewall to limit access to only the local network. Still use a password though, a compromised local device can still do damage you don't want to spread.


For the SSH part, as long as you will have the server public key stored in the known_hosts of your computer (or way to safely verify the fingerprint), the connection between your client and server can not be intercepted, modified nor compromised in any other way (given you are you using SSH2 protocol with current algorithms and keys of reasonable size).

You can use also SOCKS proxy over SSH, but full-featured VPN is probably a better way of doing that. Once again, VPN provides a way to authenticate the server to the client (certificate?) so once you will be connecting to the server, but I am not so well versed in this area so I will leave it for the others.


The directory name is not the string '0x0d0x0a' (which are eight plainly visible characters) but a string consisting of exactly two characters, the ASCII "CR" (carriage return) and "LF" (line feed), which are encoded as two bytes of value 13 (0x0D in hexadecimal) and 10 (0x0A), respectively.

From the point of view of the operating system, file and directory names are just bunches of bytes, with only two special byte values: 0x00 (which terminates the string) and 0x2F (the '/' which separates directory names in a path)(I am assuming a Unix-like server here, but the situation would be similar on a Windows system). Bytes of value 0x0D and 0x0A have no special meaning at all for the kernel. However, tools with a text-based output may be fooled (e.g. it might display the name as a newline, which would not be clearly visible as such in the output).

With a Linux shell, you can create such a directory with this command:

mkdir `printf '\x0d\x0a'`

To do that from a FTP client, you would have to delve into the way the FTP protocol works so as to know how to encode the corresponding MKD command, but I see no conceptual impossibility.


As a security compliance professional, what should I do if I find that my employer has a PCI AOC but is not compliant?

IMHO, the most ethical think to do would be to resign and report them. The reasoning:

You have an ethical obligation to the users to keep their data safe to the extent the company claims you do.
You have an ethical obligation to your company to keep their products working, secure, compliant and to follow orders.

Because you can't uphold both, you should resign, as that would free you of the second obligation and because the company is putting you into this position.

More practically:

You may want to talk with the other execs, explaining that knowingly being not compliant and misleading customers opens the company up to a lawsuit for damages and also that if it was revealed, they could loose consumer confidence especially considering current situation with privacy and security having the public's attention. The possible danger to the company ought to get you their attention.
You may want to consider gathering evidence and letting the mentioned exec fire you, then file a lawsuit for wrongful termination or the other thingy, hindering your career (not a lawyer, consult real lawyer). The result would be the same as in the ethical example, but you would get some money four your trouble.


I was trying to think of the easiest possible solution for you. What I came up with is just simply writing down all the info you need in a txt doc using Notepad++, then just encrypt the entire contents of the file. When you need to get a number out or add a number just get off your network completely so you are not connected at all, then decrypt the file using whatever password you came up with.

There is a built in plugin module to do this in notepad++. You can find the details here: http://howto.cnet.com/8301-11310_39-57449365-285/how-to-encrypt-selected-text-and-entire-text-files-with-notepad/

Of course this is in NO WAY any kind of long term or perfectly secure solution. But for a quick and dirty way to just store some encrypted data this should do the trick. I am not sure about this meeting PCI though, a QSA might have a hay-day with this one lol


SQLmap POST parameter 'txtLoginID' is not injectable

To be sure of your syntax, you can intercept a regular request of your post by burp for example. You save it in a file and you can inform sqlmap to use this request for testing an injection.
For that the option in sqlmap is -r.

Target:
    At least one of these options has to be provided to set the target(s)

    -d DIRECT           Direct connection to the database
    -u URL, --url=URL   Target URL (e.g. "www.target.com/vuln.php?id=1")
    -l LOGFILE          Parse targets from Burp or WebScarab proxy logs
    -m BULKFILE         Scan multiple targets enlisted in a given textual file
    -r REQUESTFILE      Load HTTP request from a file


If the only port forwarded to the server is the port used by the game, you are fine.

You can protect even Windows 95 with the correct measures. If you block everything but the game server, not use the computer for anything else but host the game (no browsing, no email, no running random programs), it will be reasonably safe.


What is the use of stolen credit card details?

I'm not an expert at using stolen credit cards... but from what I know:

You could resell the numbers on the black market.
You could buy stuff and have it shipped to a rube who reships it to you.
You could "quickswap" on eBay. (Use the credit card to purchase an item that is shipped directly to the auction winner, and you pocket the money from the auction sale.)
Buy prepaid cards / gift certificates.
And probably many others.

It's basically money laundering, so many of the strategies that would apply to other forms of money laundering would apply here.


How difficult is it to mitm ssh connection after trusting fingerprint

As others have pointed out, MITMing a SSH connection is no different from MITMing an SSL connection. All data is eventually sent as packets, and if an attacker can MITM your traffic, they can poison all your traffic.

By trusting a fingerprint that may have been poisoned by an attacker, an attacker can make you connect to their own server and get you to hand over your credentials, send you fake traffic or using the harvested credentials - even execute commands on your server.

Your final question has been answered several times - here, here and here. Tl;dr: It's extremely easy depending on the network that you're on and how you're interfacing with it.


Tracking click-through for organization-wide phishing email test

You could generate a unique link per user like this:

http://server/?userid=[md5hash of username]

Next you can make the index.php at the webserver log all entries of userid.
Or you could check webserver logs to see which userid's have tried to connect.


Smart card compatible with Schlumberger (Gemalto) Cryptoflex 16K and USB reader

Looks like your are working on some solution for the chilean interoperable electronic toll collection system. If so, check the new set of ST standards, they replaced the old key interchange using cryptoflex by a far simpler asymmetric key interchange scheme.You will not find a direct replacement for the 16k cryptoflex for this application.

Carlos Paratori