Combating Networks of Forged OpenPGP Keys on Public Keyservers I recently noticed that someone has created an elaborate forgery of my OpenPGP key. Specifically, they orchestrated a short key (32-bit) fingerprint collision, and also forged additional keys to match those that signed my original identity (also orchestrating short fingerprint collisions):

(http://keys.gnupg.net:11371/pks/lookup?search=fourney&fingerprint=on&op=index)

Worryingly, this includes creating a forgery of the PGP Global Directory Verification Key,

(http://keys.gnupg.net:11371/pks/lookup?search=PGP+Global+Directory+Verification+Key&fingerprint=on&op=index)

together with a huge network of forged keys that sign its identity --  again, exploiting 32-bit fingerprint collisions:

(http://keys.gnupg.net:11371/pks/lookup?op=vindex&fingerprint=on&search=0xE1AA5DD7CA57AD7C)

This was a huge amount of work. Given that all these keys are revoked, I suspect this is the work of a security researcher who is out to prove a point.

However, given that GnuPG and these keys servers rely heavily on short fingerprints, I think this effectively breaks the entire public key server system.

My question is therefore twofold:

What can be done to combat this problem, or reverse the damage?
Can the public key server system still be trusted?

This seems like a key from the Evil 32 key set, which rebuilt the OpenPGP web of trust strong set using short key ID collisions to create awareness on how insecure relying on short key IDs is.

  Can the public key server system still be trusted?

Sure it can, you just never should (and should have) trusted arbitrary keys on the key server network without building a trust path. Building short key ID collision just brought "fake key attacks" to a new level, but these have always been possible.

  What can be done to combat this problem, or reverse the damage?

You cannot really do anything about that key. As all keys from the Evil 32 set have been revoked, at least that key should not be considered at all by others.

But of course, such a key set could be created at any time again! The idea behind the OpenPGP key server network does not provide any trust measures and should not be used for anything but exchanging keys. Trust must be established locally. Always distribute fingerprints or at least long key IDs, and educate your peers about the issue as necessary. Exchange certifications on your real key, for example by joining key signing parties, to enable you and others finding proper trust paths to and from your own key.

  However, given that GnuPG and these keys servers rely heavily on short fingerprints, I think this effectively breaks the entire public key server system.

Neither of those rely on short key IDs at all, unless the user makes it to do so. GnuPG has a debatable default of printing short key IDs in overviews, though (which can be changed by using the keyid-format option (from man gpg):

--keyid-format none|short|0xshort|long|0xlong
   Select  how  to  display key IDs.  "none" does not show the key ID at all but
   shows the fingerprint in a separate line.  "short" is the traditional 8-char‐
   acter key ID.  "long" is the more accurate (but less convenient) 16-character
   key ID.  Add an "0x" to either to include an "0x" at the beginning of the key
   ID, as in 0x99242560.  Note that this option is ignored if the option --with-
   colons is used.


How do I use OpenSSL with the Java Keytool? I believe I understand how OpenSSL works, and I believe I have a good game plan for setting up an SSL server on my private network, but before I go through the process of downloading and configuring all the necessary software, I wanted to post this question as a sanity check.

Please correct me if any of the following are not true:

OpenSSL is a compiled (probably C/C++) library that I can download onto my linux server; it will then give me command-line tools that I can call from external applications or directly at the terminal
The Java keytool can be used to generate CSRs and private keys that will be needed by OpenSSL
To obtain an SSL certificate through OpenSSL, I start by using keytool to generate the CSR, and then, somehow (probably as an argument?), pass that CSR on to OpenSSL through the command-line interface

Again, if any of these are false, please begin by correcting me!

Now then, assuming I am on the right track, I have one major concern with this method:

Although a free option, wouldn't this mean that any web browser attempting to connect to my server over HTTPS would not recognize my CA cert and throw a nasty warning message my end users?

If not, please explain why. If so, then one solution I was hoping to explore was a situation where I buy my primary SSL certificate from a commercial provider (Verisign, Trustwave, GeoTrust, whoever) and then somehow use OpenSSL to "branch off" from that cert for all of my sub-domains.

The goal here is to get several SSL certs on the cheap, but still have them be authentic and thus trusted by my end user's browsers.

Any chance this is a possibility or will I have to go through a commercial vendor?

Your assumption are slightly incorrect, and I'll tell why:
to generate a csr, you can use either openssl or keytool.

if you have a Linux-based sserver like Apache, use openssl to generate the csr/private key, the certificate is then installed referencing the certificate (public key), the private key and the intermediates in the configuration file.
if you have a Java-based server like Tomcat, Glassfish, etc., use keytool to generate the keystore and the csr/private key, then install the certificate in the correct format.

I reckon browsing the knowledgebase of one of the CA authorities you mentioned above will give you all the details that you need.


man in the middle question I've been wondering about this scenario for a while but I cannot fully understand how it works.

Say I am sitting in a cafe on my laptop with wireshark, the cafe has an open WiFi connection. Is it possible for my laptop to become a wireless access point (i will call it something similar to the cafe router) but then redirect all traffic going through my laptop to the actual cafe router as my router is not connected to the internet.

This may help:

Normal route:
users ---> Cafe AP ---> Internet

What I want to do:
users ---> Fake AP ---> Cafe AP ----> Internet

The part I am confused on is how to make my fake AP redirect all traffic to the cafe AP.

Thinking about it, is it possible to connect to the Cafe AP and simply sniff in promiscuous mode to receive packets from all who are connected?

Yes you could do this with ARP Spoofing.

  The part I am confused on is how to make my fake AP redirect all traffic to the cafe AP.

The software you are running should forward on all packets to the real access point after interception.

  Thinking about it, is it possible to connect to the Cafe AP and simply sniff in promiscuous mode to receive packets from all who are connected?

Yes (or in Monitor Mode), although you'll probably need a USB wifi dongle, as most laptop built in  Wifi adapters don't support these modes.


Generating authentication token from PHP sessions I have a traditional PHP site which uses sessions. I've developed a real-time app in nodejs and wish to authenticate users here based on their PHP session. The procedure would go something like this:

Client AJAX's some getAuthToken.php page
Client connects to the websocket server anonymously
Client sends their authentication token
Server checks token, authenticates user

getAuthToken.php should generate an authentication token for the current session's username using some symmetric key (shared by the websocket server) and return it.

What would be the best algorithm to use here? I have little experience with cryptography and not sure where to proceed.

One approach that comes to mind would be to SHA-2 hash the username along with some secret key. We'd then pass the username and this hash to the websocket server which would do the same and compare hashes. Include a timestamp with the hash to ensure a unique token each time.

Is the above approach secure? Is there a better approach? I'm not concerned with anything on the wire, we'll be using SSL for all communication - my only concern is the ability to impersonate other users by generating a bogus token through inspection of your own token. The algorithm must be supported in both PHP and node.

Surely there is some standard way of doing this?

Rather than just hash, you should encrypt some values that can be decrypted by both your PHP and Node.js systems.

The data to include could just be:

Username.
Ticket expiry date.

However, since you are encrypting you could include additional details you would need to be available and these would remain private from the end-user.

These would be encrypted using AES and a 256 bit symmetric key that is known only to your PHP and Node.js applications. For a rolling expiration you should update the expiry date on every request and issue a new ticket. For performance reasons you could update less than this (say once the ticket has reached its half life). This is the encryption method ASP.NET uses for its authentication tickets.

So your token could be

AES-256(256bit secret key, username + "|" + (date-time + 20 mins))

After decryption you can check that the date-time value is in an acceptable range (i.e. the next 20 mins) - if not you should log this as a security event and this will provide reasonable protection against brute forcing. If you're storing this in a cookie as well as sending it via WebSockets you can make the cookie expire at the same time (bear in mind though that not everyone will have their clock set correctly so you might want to add in some extra leeway for the cookie expiration).

If you want further protection, encryption does not provide integrity as @GZBK noted, so you may want to ensure integrity of the decrypted value. This can be achieved with a HMAC of the hashed data. So your token would become:

encrypted_data = AES-256(256bit secret key, username + "|" + (date-time + 20 mins))
ticket = encrypted_data + "|" + HMAC_SHA256(256bit secret key, encrypted_data)

You can use Base64 encoding to represent values within your ticket.


Can I serve a self signed SSL certificate for domain B from domain A, then MITM connections to domain B with it after it's been accepted? I can generate a self signed certificate for any Common Name, such as www.google.com. If I have a server at example.com and serve up a certificate with the common name www.google.com and the user accepts it. Would that allow me to MITM a connection to www.google.com with that certificate without them having to accept it again?

If not, what prevents that from working? Does the browser keep a table of certificate fingerprints to the domain which it came from?

I tested this myself and it didn't work, but I'm looking for further validation since it's possible my testing was flawed.

If the user adds an explicit connection for a certificate while visiting a site this exception is only added for the combination of this specific target site and this specific certificate. In your specific example it means that the certificate will be accepted only for example.com but not for www.google.com since this exception is only added for the target example.com. It does not matter that the certificate contains a subject alternative name for www.google.com too.

As far as I remember the behavior was actually different long ago where the exception was added for a certificate independent of the site. It was fixed to defend against exactly the scenario you've outlined.


How do arbitrary payloads execute on the remote machine? I understand executing something like a reverse TCP bind via shell relies on resources being available on the victim machine... and in the case of running a, shall we say, Ruby script from the command line it will be interpreted down to machine code and executed...

My question is, when you drop machine code directly into the remote machine via exploit via Metasploit or such, what if the code doesn't match the CPU? How is it interpreted and executed? Or does it come down to the 'attacker' knowing what payload to use?

Please forgive the high-level question, I am relatively new to penetration testing.

Assuming you have located a buffer overrun (or equivalent), If the machine code doesn't match the language of the remote machine, then the expected result is that the application with the overrun will crash.

The overrun will operate as 'normal', trying to execute the code in your binary blob of a payload. The victim system will attempt to execute the instructions, but the instructions will not operate as expected for the target system - any given instruction will likely mean something different for the target system than the payload developer intended.  The victim system will, nonetheless, attempt execution.  Some operations may work perfectly fine. Some operations may be illegal instructions, potentially causing an exception or a crash.  Eventually, it is likely that the combination of instructions will either corrupt the running application beyond recovery, or outright perform a valid instruction under an illegal context, and the process will crash.


Tunnel Openvpn traffic through ssh? I know similar question have been asked but none of them are explained thoroughly.
I have setup a VPS and setup openvpn using https://github.com/Nyr/openvpn-install on tcp and port 443(I have access to limited open ports). Now I want to tunnel the openvpn traffic through ssh.I want to do so because the packets are filtered and any vpn related packets are removed on the network. I'm on a linux machine, can anyone explain me how to do so? What changes do I make to client.ovpn?

There's actually at least two ways to achieve this:

Request SSH to forward a local port to your OpenVPN instance, using ssh -L <local_port>:<remote_host>:<remote_port>. This feature is described on OpenSSH manpage

 -L [bind_address:]port:host:hostport
 -L [bind_address:]port:remote_socket
 -L local_socket:host:hostport
 -L local_socket:remote_socket
         Specifies that connections to the given TCP port or Unix socket on the local (client) host are to be forwarded to the given

  host and port, or Unix socket,
               on the remote side.  This works by allocating a socket to listen to either a TCP port on the local side, optionally bound to the
  specified bind_address, or
               to a Unix socket.  Whenever a connection is made to the local port or socket, the connection is forwarded over the secure
  channel, and a connection is made
               to either host port hostport, or the Unix socket remote_socket, from the remote machine.

Request OpenSSH to implement a SOCKS Proxy using ssh -D <local_port> and, then, request OpenVPN to use this proxy (using socks-proxy configuration directive on your openvpn.conf)

Even if technically similar, the first solution may generate warning/errors because OpenVPN will actually connect to localhost instead of the server's real FQDN (which may cause problems with certificate's CommonName attribute).


Does RAND_add(&Time,sizeof(Time),0) at each ssl connect reduce randomness or not? Reviewing openssl 1.0.1g s23_clnt.c code i see that :

int ssl23_connect(SSL *s)
    {
    BUF_MEM *buf=NULL;
    unsigned long Time=(unsigned long)time(NULL);
    void (*cb)(const SSL *ssl,int type,int val)=NULL;
    int ret= -1;
    int new_state,state;

    RAND_add(&Time,sizeof(Time),0);

This RAND_add(&Time,sizeof(Time),0) will not add entropy, but does it on the long run just create a predictable random ?

Reading https://www.openssl.org/docs/crypto/RAND_add.html there is a line "Thus, if the data at buf are unpredictable to an adversary, this increases the uncertainty about the state..." , what if buf is predictable... because time of initial connection is.

Since default random method is md_rand, i think buffer is added even if entropy is 0 and i think adding easily guessable information ( time is in seconds ) will dilute and on the long run make week random

Googling a little gave that https://www.schneier.com/blog/archives/2013/09/conspiracy_theo_1.html#c1694020 that just gives me same impression, but i really doubt such things would not have been kept for ages in openssl ( it was already there with a RAND_Seed(&Time, ... in SSLEAY of 1998 ) if it was so harmful.

So a basic question :

Does RAND_add(X,Y,0) with X guessable lower the random quality or keep it as it is ?

Mixing in easily guessable information never reduces entropy. In fact, that's the whole point of mixing: you can add information of dubious unpredictability, and all the unpredictability from uncorrelated sources adds up. So the mixture still has better entropy than before, or at worst just as much (if the new input is completely predictable).

To put it another way, the entropy of a RNG is the logarithm of the probability for an adversary to guess the sequence of random number (which for a PRNG is equivalent to guessing the (relevant portion of the) internal state). If the adversary can guess some of the input, that lets him establish a correlation between the state before adding that input and the state after. But that doesn't make the state after easier to guess than the state before.

All this assumes that the method for mixing entropy is a good one. This step is very easy to get wrong. As far as I know, ssleay_rand_add does it right.

Schneier's concern is not that there is a partially-predictable input, but that all the inputs are partially-predictable, to the point that the resulting generator state hasn't accumulated enough unpredictability. The problem isn't that unpredictability (entropy) goes down — it doesn't — but that it starts from 0 and may not have risen enough.


How can I generate a unique SALT for multiple apps sharing one user database? Let's say that I have one Database, and several separate web applications that share the database. If hashes are to be unique and generated on the server-side, how can I ensure that I am generating a unique hash across several applications?

Edit: for some reason, it seems that I have completely misread the question. The answer below applies to another question which has little semblance with the actual question.

As for your question, a simple way to ensure uniqueness (with high probability) is to use randomness: from a cryptographically strong PRNG, just produce 16 random bytes. That's 128 bits. Mathematics show that the first reuse happens once you have generated about 20 billions of billions of salt values, i.e. it won't happen soon.

The applications can also use a generation method which tries to achieve uniqueness by using the machine MAC address, the current time, the process ID and whatsnot. GUID are designed to do just that. Each server can simply request a "new GUID" when it needs a salt; a GUID encodes as 16 bytes. Indeed, one GUID generation method is to use a cryptographically strong PRNG, so both methods are actually the same.

Note that for a good salt, the uniqueness is supposed to be worldwide, i.e. to also apply for other applications which are connected to other databases, that you don't know of. Randomness and/or GUID take care of that, too.

Original answer which does not answer the question at all:

In password hashing, the salt is a "unique value": that is, each password gets its own salt value. A new salt is generated for each password. In particular, the salt MUST NOT depend on the password value (so it can not be "computed" from the password), and MUST NOT be used for more than one password (even if the same user just changes his own password, a new salt shall be generated).

Since the salt is necessary to recompute the hash, there is no escaping it: you must store the salt in the database along with the corresponding hash output. When the salt is stored with the hash value, whoever needs to validate a password first reads both the salt and the hash value from the database, then uses the salt and the password to recompute the hash value and see if it matches the one which was just read from the database.

Bcrypt implementations traditionally encode the salt and the hash output for you, as a single string, so you don't have to worry about two values to store: you store one string, you read one string, and the library does all the magic.


How do you stop a hacker when their IP address is 0.0.0.0? Wordfence reports the following visitor:

An unknown location at IP 0.0.0.0 visited
4 hours 45 mins ago   IP: 0.0.0.0
Browser: Baiduspider version 2.0
Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)

An unknown location at IP 0.0.0.0 visited
4 hours 45 mins ago   IP: 0.0.0.0
Browser: Opera version 12.15 running on Win7
Opera/9.80 (Windows NT 6.1; WOW64) Presto/2.12.388 Version/12.15

I suspect that your Wordfence plug-in is blindly trusting the X-Forwarded-For header. This header is used by proxies to indicate the IP address of the computers sending traffic trough them, but can easily be spoofed. It is also very well possible that some of the visits from “0.0.0.0” aren't malicious, but simply users behind a misconfigured proxy.

Edit: Wordfence is indeed doing this, but this is configurable and is meant to accommodate for reverse proxies such as CloudFlare. See the comment by Wordfence founder Mark Maunder below.


Storing e-mails on private servers and getting consent from data subjects (EU GDPR) My initial reading of the GDPR doesn't seem to cover cases of consent with regards to inbound e-mails.
If I run a corporate e-mail server and store all incoming e-mails on it, I'm storing private data of data subjects (natural persons).

Am I in breach of GDPR if I don't get consent from the data subjects to do so?

I mean, that seems insane, but the definitions for data controller/processor are so broad it is hard to tell where the boundaries are.

Any insight would be appreciated.

Some supporting documentation:
The regulation:
http://data.consilium.europa.eu/doc/document/ST-5419-2016-INIT/en/pdf

Easier to digest white paper:
http://cdn2.hubspot.net/hubfs/659257/uk_site/resources/white-paper/white-paper-gdpr-en-uk.pdf

You need to process personally identifiable information (PII) stored in e-mails so that you can run an e-mail server for your company. This means you have a legitimate interest in processing PII and as long as you don't use the the collected personal information for any other reason than e-mail communication, you do not have to obtain an explicit consent.

Since you have a legitimate interest, you are not required to obtain the consent.

You would need the consent, if you, on top of processing the e-mail, would want to use the information in a way that is not required for processing e-mails. E.g. you would send the e-mail addresses to a 3rd party for their marketing purposes -- this is of course a bit extreme, but this is more or less the kind of situation GDPR is trying to prevent.

Of course, even if you have the e-mail server just for sending and receiving e-mails and no consent is needed, there might be some further obligations under GDPR, such as that you are expected to take all the necessary precautions to secure access to the e-mail server, but that is something you need to do anyway.


What might be the reason for an major antivirus software to not detect an malicious DNS entry? I recently installed the trial version of Kaspersky as I had always a good impression of the features of their software. I also bought a 1 PC 1 year license, but didn't unsealed it yet as something very unsatisfying happened to me.

When I was on a LAN gaming party and tried to use the network just a fractal of web services was accessible by domain-name for me. After some research and with help of others, we figured out this was due some suspicious entry as my primary DNS-server IP and that server was probably developed without considering the scenario, that was present on the LAN, as legit DNS had handled it.

After googling the IP which was set as my DNS server, almost any page was alerting about MITM attacks and trojan malware. And even the first post was a report in Kaspersky's tracker from back to 2012.

So here is my question:

How can it be, that a major anti male software like Kaspersky has been informed about this 4 years ago and still isn't able to track this?

From my understanding this should be a easy one to detect.
I guess the most basic thing to do is add this IP-address to some blacklist and just check the DNS entry against the blacklist. Also figuring out how to read the systems DNS entry shouldn't be that much of a deal for devs of such a company, should it?

So, what might be reasons for Kaspersky not being able to track this, except simply lumpyness of the corresponding dev?

Note: I'm legit interested in this. I'm not trying to rant. If this might appear so, one can feel free to replace the product name with a pseudoproductname.

When checking quickly, I saw several instances of the exact opposite issue: Kaspersky blocking any connection to user's router's IP.

The most probable explanation is that Kaspersky actually blocks known malicious IPs (given that you use the right product, ie. at least Kaspersky Internet Security and no the standalone anti-virus), but with two main prerequisites:

The malicious IPs must be known: it must have been confirmed as malicious by Kaspersky teams, added in a blacklist and your software must have updated this blacklist, however chances are that the attacker will change the IPs they use regularly,
The malicious IP must indeed be malicious:

Often this is just a shared or compromised host which is also serving legitimate contents, completely blocking the IP could have unwanted side-effect. To give a concrete example there are poor-quality blacklists on the Internet which are regularly blocking major CDNs like Cloudfare because their IPs have been used to serve some malware. Once such blacklist is applied it becomes impossible to access any website relying on Cloudflare services...
Or the malware is exploiting some legal grey area.

Following your comments, in your case, this seems to be this latter case.

You seem to be affected by the DNS Unlocker software, a company advertising on their website (http://www.dnsunlocker.com, URL voluntary made not clickable) a service allowing to bypass geo-restricted contents but proposing no download to actually install their software (!).

They explicitly explain that they achieve so by replacing the standard DNS server by their own one which will replace the answers for filtered websites. They show a clear Terms and Privacy statements, provide detailed and complete uninstallation instruction (including the fact that the DNS configuration will have to be modified manually), inform that their application is ad-supported and provide a contact form.

They also seem related to GreenTeam (http://www.greentm.co.uk, honest enough to announce in their "About Us" page that they are located in Israel and not the UK...), formerly CloudGuard as per my understanding, which rely on the very same system to filter malicious websites (à la OpenDNS then, but with injected ads and content...).

Should an anti-virus block such kind of "grey area" services? The question is quite difficult, since we are mostly talking here about the balance between freedom and security. That's why for the same software, as long as it is not proven that a service does anything really illegal and harmful, some anti-virus may classify it as malware as other may take a more conservative approach.

Sadly, none of them seem to ask for the user's opinion, assuming that the user doesn't know and prefer not being asked to decide anything.


Can remote LogMeIn Hamachi users access our local LAN? Unknown to me, one of the kids has installed LogMeIn Hamachi on his PC so that he can access and play on his pal's Minecraft server, and vice versa.

However, my lack of fu when it comes to these types of services is leaving me feeling a little uncomfortable about him using this.

Is there anything I should be worried about here? For example, can his friends access our local LAN (which has a number of NAS boxes with unsecured shares) and get up to no good?

Or in other words can inbound VPN traffic from his friend's remote PC leak onto my local LAN. I did scour their docs but couldn't find anything conclusive about how this VPN application behaves.

One of the things I did was disable the Client for Microsoft Networks and File and Printer Sharing for Microsoft Networks on the Hamachi NIC in Windows 7's Network Connections.

If someone knows this particular VPN application and its inherent dangers then your advice would be appreciated.

I don't think so, Hamachi is like its own NIC so as long as there isn't anything on the computer that is bridging your home network NIC to the Hamachi NIC it should be OK. However, I'm not very experienced with networking, especially Windows networking, so I might be wrong.


I have a virus in my USB drive. I haven't inserted it on my PC yet. How should I proceed? I plugged the USB drive on a public computer at my university and all the files became .exe

Is there a way to clean it without risking that it will copy the virus as soon as I insert the thing?

If the malware are just .exe files waiting to be clicked on, then not opening them should be enough (also beware of Autorun). You can further protect yourself by using an OS which won't be able to execute the files anyway (like Mac or Linux). Deleting the malicious files or formatting the drive is enough to clean it.

If the malware also modified the files or some filesystem data to be malicious and exploit a vulnerability, you should decide whether you're likely to be affected - if your system is up to date and it's unlikely someone would use a zero-day on you, then it's safe. Otherwise, it's not and you shouldn't be mounting the filesystem (Windows and Mac mount them by default so be careful). Reformatting the drive is again enough to clean it.

If the malware modified the firmware of the USB drive itself, then it's no longer an USB "drive" and will often pretend to be a keyboard and type in malicious commands. At this point, I suggest you just throw away the drive as it is now comparable to a compromised machine and you can no longer trust it.


Brute force MD5 with a prefix and suffix up to n characters/words I have a couple of things I would like to explore with hashcat. I have a MD5 hashed password, which I know for a fact has a prefix and a suffix. The actual password is located in the middle of the prefix and the suffix, and that password may contain the following characters:

Uppercase characters
Lowercase characters
Underscore (_)

I have already figured out how to do this attack with the prefix and suffix:

hashcat [HASH] -a 3 PREFIX_?l?l?l?l?l_SUFFIX

That will try a 5 character password, which only includes lowercase characters because of ?l. My first question is therefore: How do I generate a charset that includes [A-Za-z] and underscore, then start an attack on a hash starting from 1 character to 10 characters? It basically needs to run through each combination from 1 character to 10 characters.

Alternatively, is it possible to start a dictionary attack instead of using a charset, but separate each word with an underscore? Also up to maybe 10 words. Example:

words.txt

telephone
bottle
door
toilet

The password I need to crack would then go something like PREFIX_telephone_bottle_SUFFIX, PREFIX_bottle_toilet_door_telephone_SUFFIX, separating the words with an underscore.

Hashcat lets you load a list of masks from a file - one mask per line.

[Edited to expand my previous too-brief answer above]:

Hashcat also lets you specify up to 4 custom character sets using the -1, -2, -3, and -4 parameters. Your specific custom character set (upper, lower, underscore) could be specified like so (I'm using "2" to make it obvious that it's not a lower-case L, but it could be 1, 2, 3, or 4):

-2 ?l?u_

You would then invoke hashcat something like this:

$ hashcat -a 3 [other options] -2 ?l?u_ [hashfile] [maskfile]

... with the mask file containing something like the following, with one line for each password length that you're expecting:

PREFIX_?2_SUFFIX
PREFIX_?2?2_SUFFIX
PREFIX_?2?2?2_SUFFIX
PREFIX_?2?2?2?2_SUFFIX
PREFIX_?2?2?2?2?2_SUFFIX
PREFIX_?2?2?2?2?2?2_SUFFIX
PREFIX_?2?2?2?2?2?2?2_SUFFIX
PREFIX_?2?2?2?2?2?2?2?2_SUFFIX
PREFIX_?2?2?2?2?2?2?2?2?2_SUFFIX
PREFIX_?2?2?2?2?2?2?2?2?2?2_SUFFIX

This lets you run the entire attack by only calling hashcat once.

Instead of specifying the custom character set on the command line, you can also specify them positionally in the maskfile itself, separated by commas:

?l?u_,PREFIX_?2_SUFFIX
?l?u_,PREFIX_?2?2_SUFFIX
?l?u_,PREFIX_?2?2?2_SUFFIX
?l?u_,PREFIX_?2?2?2?2_SUFFIX
?l?u_,PREFIX_?2?2?2?2?2_SUFFIX
?l?u_,PREFIX_?2?2?2?2?2?2_SUFFIX

... etc. This is sometimes preferable because it stores the custom character set directly in the mask file, instead of ephemerally on the command line - so that more of your attack strategy is persistently documented. (This can also let you specify different custom character sets on each line for each mask - which isn't necessary for your question, but can be very handy for other kinds of attacks.)


How do I use hashcat to recover password from ata drive lock How would I get the password for encrypted SSD's I bought (legally bought from a business who forgot the password, I plan on wiping them after I unlock them) I am new to using software like hashcat, I tried finding the hardware reset key hut these drives are old so They don't have a code I can use to factory reset it, I have a relatively strong system with a 7th gen i7 and a 6gb 1060 so I should be able to do it.

No need for hashcat. From my answer here:

[...] at the ATA Secure Erase level, you should be able to initiate a
new erase with a new master password, regardless of what the old
password was.

This destroys all existing data, as designed by the ATA Secure Erase specification. But then you can use the drive again when it's done.


Security of external harware when using VMs I'm new to using VMs, so I suspect this question may answer itself with experience, however, this question has been bugging me.

If a computer user has a VM set up, and plugs in a pen drive, what's stopping any potential malware from "hopping" from VM, to drive, to host?

I would expect that a secure VM would either not allow external devices, or isolate them from the host. E.g., a flash drive being used by the VM wouldn't be visible to the host.

However, this system wouldn't be practical for the user because of the various required interface devices. (Think USB keyboard or mouse. I know those can be targeted by a version of the BadUSB exploit.) If the VM isolated the keyboard, then the user would have no means of input while using the host, and no means of telling the system to switch back to the VM.

How is this security conflict resolved?

Think of a hardware based host as a fisk tank. Immagine that the virtual host is a smaller fish tank that sits inside the larger fish tank. You can add fish to your fish tank: either to the larger tank or the smaller tank. Generally the VM (smaller tank) is created in such a way that software running on the VM can't break free of the VM and run on the real hardware. Metaphorically, you don't let fish swim from the smaller tank into the bigger tank.

A VM comes with a set of virtual hardware: CPU, RAM, graphics chip or board, even BIOS and chipset. These pieces of virtual hardware are software programs running on the real hardware and providing service to the VM. Real USB devices are first plugged into real hardware. From there they can either be shared with a VM or dedicated either to the real machine or the virtual machine.

You can of course isolate a VM from any USB devices, but that would not necessarily protect them VM. The VM is vulnerable to software running on the real machine, because the VM depends on the real machine for it's CPU cycles, memory, and storage. If you plug a Bad USB device into your real machine, it could attack the VM by chnaging the contents of the VM memory or storage without accessing the VM through the virtual USB hardware interface.

There is no conflict here, because VMs are only ment to contain software running on the VM from gaining access to the resource of the real machine.


Is this Backup Safe from Ransomware? I'm planning a home backup setup, and I'm not sure if I really understand this quite right.

The idea is I'll set up a Linux server on the network that contains two drives. Drive1 will be network-accessible and used as a backup location for several other machines on the network as well as a general file share. Drive2 will not be network accessible, only the host OS will be able to access it, and will serve as a target location for duplicity to store incremental backups of Drive1.

My understanding is: in case of ransomware on any of the various client machines on the network (that have write access to Drive1), that machine as well as Drive1 will be hosed, but the backups of Drive1 should be safe, since only the server will have write access to Drive2 (assuming the server isn't infected and duplicity is set up to write changes, not erase existing backups).

Is that accurate?

Reasonably accurate. You might also let the Linux server read the files off the PCs, which have no write access to the Linux server (nor even know it's there. They're simply accessed routinely by someone reading all their data).

What you really want, though (because I saw this happen) is an emergency interlock that calculates the size of the new backup, and stops everything if it looks too large. For example if it contains ten times the average daily number of changed documents. Or better still, in that case it freezes the previous backup and starts a new chain, and emails an alert to you. Several other telltales are there: you might for example prepare empty documents ("honey docs") that no one should read. If they abruptly turn out to have changed or disappeared...


How to optimize cracking speed with Reaver When testing network security with Reaver in order to find out WPS, what parameters do you usually use with respect to cracking speed? I've chosen for TP-LINK Archer C20i AC750 Dual Band a delay of 20s, small DH keys and no nacks, but I guess the delay could be much shorter for such a router.

What do you say about default value of 1s and what approach would you - and generally do you prefer?

The WPS PIN vulnerability is an online brute-force attack: you make a guess at the PIN, and the router tells you if it's correct or not.  Because of this, the limiting factor for attack speed is how fast the router is willing to talk to you.

You can speed things up slightly by using small DH values to reduce the amount of computation the router needs to perform, and by reducing how long you wait between guesses, but if the router is rate-limiting you, there's not much you can do.


What specifically is "potentially dangerous" about an ampersand in a URL ASP.NET includes a request validation system that halts page processing if any of the following characters are present in the path portion of the URL < > * % & : \ ?.  Instead of the normal page, the runtime returns an error page which says

  A potentially dangerous Request.Path value was detected from the client

The only information I've been able to find about it being "potentially dangerous" are vague references to XSS.  What's the specific problem the runtime is trying to mitigate?  If I need to accept URL's in my app that I cannot control and might contain some of the unsafe characters, is it safe to disable the runtime validation?

(There are already numerous articles discussing how to disable validation, but none of them mention the implications of doing so).

It's difficult to answer your question about whether it's safe to disable validation without knowing the exact circumstances, but I'd caution against disabling it if you don't do very thorough validation of the path component yourself.

The question mark and ampersand might be dangerous because they are used to pass parameters to an application over an URL. The ampersand is also a problem because html entities can be encoded with it (&auml; produces 'ä'). This isn't really a problem in an URL, but if you get your encoding/decoding slightly wrong and insert a get variable that contains these into your page html, you might allow an attacker to include dangerous html tags such as the script tag, iframes etc. The percent character is a problem because it is used to encode special characters in URLs. And of course the < and > are a problem because these are used for HTML tags.

If your application provides a way to accept the request path (or body content) with these characters from just anyone, someone might think of a way to use them to trick your application into doing something unintended.

For example, if you didn't validate the request path and your application inserted the value of the 'title' variable into your page if it was present, this would be harmless when someone requested an url such as http://www.example.com/profile?user=johndoe&title=John, but someone else might use http://www.example.com/profile?user=johndoe&title=<script>really bad script here<script> (probably encoding the value of the title using percent url encoding) and have his script run in the context of your page.

It would be even worse if you stored the value of the title variable in a database and later showed it to every user who wanted to look at john doe's profile, because that would run the script whenever anyone looked at john doe's profile. The script might then steal these user's cookies or do some other really horrible and evil thing to them. :-) The example is a bit far-fetched, but the basic problem is not.


Can unprotected SSH be an issue if port 22 is open locally but not externally? Let's say I'm running a webserver from home that has port 8080 exposed to the internet. I SSH into that server from another computer on my local network on port 22. If port 22 is not accessible externally, is there a danger to keeping the SSH connection unprotected?

Yes, frankly. If you get a compromise in your network, one of the first things a worm-type malware will do is scan the local network for SSH.

Alternatively, if your webserver is compromised and the nature of the vulnerability means that the attacker can get network access, they might try to connect to the ssh port from the web service and get higher privileges.

But then it all comes down to what you mean by "unprotected". While I might not go crazy with firewall rules (although I might lock down the webserver's ssh to just your normal computer that ssh'es to it, if that's possible), having a very strong password or key-based authentication is advised.


How to detect malicious code sending information to attacker's server in linux Suppose you have some malicious code on your linux laptop, for example a rootkit or trojan or something like that. Now restrict your attention to the case that the malicious code does transfer some information to the hacker over the internet, for example because the hacker wants to steal some files from your computer or your passwords via a keylogger or because he wants to use your machine as a base to hack for example a company or government server.

Being a layman on network security I assume that it should be possible just to redirect (for example via ARP-spoofing or something like that) all traffic of your box (A) over another not compromised box (B) and see by sniffing if there is any suspicious traffic. This seems to be easy if you know that A shouldn't send any traffic at the moment (because you don't browse the web and so on...). However the malicious code could be a bit cleverer and send data only if there is some other traffic outgoing from (A), for example when you are surfing in the web. Then you would need a method to generate controlled traffic outgoing from machine A. Machine B then should know what traffic is when generated, i.e. to expect and should be able to find the additional traffic and detect this way the virus when it reports to the server.

I guess this model is a bit naive, but I want to learn more technical details about this point:

How close is my above description to reality?
What other, more sophisticated methods may the virus use to mask its send of information?
If the described sniffing is a good method to detect such code when the code reports back to server, how would one actually do this in detail (in linux)? And how to make sure to detect even very smart ways to mask the sending of information?

it really depends on how deep the attacker is in your system; if he's controlling your DNS then this will be a little tricky; if an attacker is already on your server, youre doomed anyway. There are a lot of hidden backchannels that are not easy to detect or command-channels using twitter, p2p, dns-queries, etc. pp; search SANS-ISC Reading-Room for "hidden channels" to get an idea of what might be possible

  Redirect ... and see by sniffing if there is any suspicious traffic

Nearly impossible; heuristics dont work.
And what do you do with encrypted traffic?

For controlling http-requests:

Use squid as a transparent proxy and use a whitelist with allowed connection-targets

For general networking-control:

Use strict iptables-setup infront of your server (DENY anything, allow what is needed)
Log any outgoing connection-attempt for later analysis
Use tcpdump to record any traffic (don't forget UDP)


Does re-hashing a part of the password hash increase security? I am not a security expert but I am trying to get my head around the current best practices for adopting a security policy for a website that will contain sensitive information.

In terms of someone trying to access user accounts through the front door/login screen I am happy that I am familiar with enough information to make this a futile exercise.

However I also want to also guard against the possibility that the database could be hacked and a third-party be in possession of all the encrypted passwords.

It is at this point that I can't see any real advantage with using any of the MD5, MD5+Salt, AES encryption method in cases where the database is hacked and all the keys needed to test a password against any stored hash is retained in the database.

Would I not be more secure if I took an encryption method such as MD5 and used that to encrypt the user's password, and then take the encrypted string, and through code, select say the first n characters of the hash and pass that through the MD5 encryption and store that hash in the database?

i.e. take the password "password"

The MD5 generated hash would be 5f4dcc3b5aa765d61d8327deb882cf99

I take for example the first 14 characters 5f4dcc3b5aa765 and run that through the MD5 encryption to get a new Hash 316e881b8519579949391d6f8424decb which I store in the database.

Only the code would know how many characters were being used to re-encrypt the first hash code. Any hacker who is not in possession of both the database data and the source code would not be able to compare hash codes using a dictionary rules set even though they may have correctly identified that MD5 encryption is being used.

All the encryption methods I have researched so far seem to store the encryption keys in the database which doesn't seem to give much protection from a database dump hack.

It is quite possible that I am being naive here and don't understand the first thing about security but any guidance from people would who do would be appreciated.

Only the code would know how many characters were being used to re-encrypt the first hash code.

And this is where the problem is. Right at the start, only one with access to the code knows this. But how long can you keep this a secret?
You may inadvertently publish your code on GitHub, or talk about it with friends and be overheard... as soon as the secret is out, the extra value goes away. And you need to use a different method - which implies having to ask all users to once again enter their password.

It's called Kerckhoff's Principle:

  A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

The only things that should need secrecy, are the things you can change quickly. So you can adequately respond when the secret leaks.

That being said, MD5 is outdated; consider using bcrypt for hashing instead.


How to deal with spam that contains my personal details? I just noticed some spam in my inbox in GMail that is from a very suspicious e-mail address (partially redacted anonymous@webXXXXXXX.ad.aruba.it) containing a link to a similarly suspect URL (http://centrodeesteticaopalo.com/URL_PARMS_REDACTED).  The root website by itself returns an empty page (only newlines and line feeds) and I am not going to follow the actual link because it contains parameters which likely could identify me to the server.

Ordinarily I wouldn't even give such an e-mail the time of day and consider it to maybe be a phishing attempt, but what I find particularly disturbing is that the e-mail contains my real name and street address, along with the text "Your request was approved, you can become acquainted with the agreement here:" and a link to the above redacted link.

I'm assuming that some business I had given my personal information to was breached, but I'm not sure what action I should take, or even if there is anything I can or should do. Is it safe to ignore? Assume I have frozen my report with all three reporting agencies and there is nothing I don't recognize on any of my current reports.

Your name, email address, and street address are not exactly secret information.  It's far more likely the data was either scraped, or purchased from some legitimate (or quasi-legitimate) source than stolen in a data breach.

In any case, regardless of whether it was purchased or stolen, yes, it's safe to ignore, or rather go ahead (since you're using Gmail) and report it as spam.  Then, forget about it.  If they could (and wanted to) use the data for identity theft, then they'd have gone ahead and done that rather than to waste their time sending you spam.


Testing C++ Algorithm On A Server I am making a C++ testing server and want to do that compiled programs would:

not have access to read or write files.
not have access to open or connect through sockets.
not be able to work with ANY non-standard C++ (e.g. system) libraries
have full access to CPU (no or very little performance loses).
have limited RAM memory.
have limited running time.

I hope I have not forgotten anything but what I want to do is to make a normal testing system without possibility to be hacked through the compiled program.

Any tips, links, whatever? Any compiler options?

Here is what current system is going to be:

OS: Ubuntu

Compiler: GCC

Edited:

Do you know whether it's possible to disable ALL system librariesin the compiler? That would help a lot :)

Edited (again):

Here is what I came up with: I make a program that forks it self and the the parent process tracks the testee for timelimits (while you still can use some system command for that as well) and the child process limits it self (resources, seccomp) and runs the untrusted software.

You may be interested in seccomp. This is a feature with which Linux runs a process with only a very limited set of available system calls; the kernel kills the process at any attempt to execute any other call. This is, conceptually, the Right Way to do this kind of isolation: use a (small) whitelist of allowed system calls, instead of a blacklist of disallowed calls. Seccomp can be used by chromium (the opensource side of Google Chrome) so there's good chance that it will remain supported for the time being.

The Wikipedia page has a few links, including seccomp-nurse, which might be the software you are looking for.

For CPU time and memory consumption, the Linux kernel can enforce hard limits on a per-process basis; see setrlimit.


Detection of function hooking in iOS So far as I know, in iOS there are three techniques of function hooking:

preload library using DYLD_INSERT_LIBRARIES
imported symbol table redirection using fishhook
patch the functions when they are already loaded - i.e. already in memory using substrate MSHookFunction

These expose security issues so I wanna be able to detect when such things happen. For point number 1, I can apply function pointer verification to detect. However for 2 and 3, I haven't had any idea. I am very thankful for ideas what can be done to address the issue.

The is a variation of the Ken Tompson Hack.  If the platform is modified to lie,  then what tools can be trusted?  No form of reflection can be trusted, because anything can be modified on a compromised iOS device.

Apple is addressing this issue as best as they can by trying to make it difficult to jailbreak an iOS device.  In practice there is no solution to this problem,  because iOS devices can almost always be jailbroken.


Use of JavaScript by LastPass to encrypt & decrypt the password database a secure approach? LastPass is a top-rated password manager that comes as a browser extension and uses a master password to encrypt and decrypt the password database using the JavaScript. Is this a secure way of doing? Isn't this approach vulnerable to any web based attack? What can be the attack vectors to be considered while doing this crypt operations using the JavaScript?

Lasspass is a browser plugin and is not vulnerable to MITM attacks to its javascript the way that a website is. The plugin resources are not installed the same way that a website requests its javascript files via http requests.

Javascript is not inherently more vulnerable to attacks other than the nature by which the code is requested and loaded. (MITM)

It can however be considerably slower than native code (internet explorer), but it can also be considerably faster than native code implementations (Chrome's V8 engine).

From LastPass's website login, the valid HTTPS certificate authenticate's the resources loaded by the browser. Certificate authenticity can be confirmed by looking to the left of the website address at the top of the window.

Same Origin Policy along with SSL prevents malicious iframes from hijacking any javascript resources that may be loaded in the child frame.


Is SSD encryption useless on data already present? The reason I ask this question, is that presumably when contents on an SSD are encrypted, the unencrypted data is overwritten with its encrypted version. This study tells us that overwritten data can still be recovered.

Such being the case, if an SSD were thought to have been encrypted after having had data stored on it, would it not be possible to recover the data present prior to encryption?

If so, then wouldn't the only way to really be sure your data was safe would be to encrypt the SSD on day zero*?

*(With the advent of quantum computers, encrypted data is arguably no longer safe. Of course, currently only well funded entities have access to these machines, but in seventy or so years time, it may be the case that everybody has access to a quantum computer. If a hard drive (or any encrypted data) were kept for such a time, it could theoretically be decrypted).

Self Encrypting Drives (SED)

Many SSDs offer a "Self Encrypting Drive" feature where the encryption is completely transparent to the operating system.  These require that you enter your drive password via a UEFI module and it will unlock the drive.  These drives are always encrypting your data, even when SED is not enabled.  Enabling SED causes the drive to encrypt the Data Encryption Key (DEK) with your password, thus requiring your password to access the data on the drives.  In such a case, you need not worry about the prospects of data recovery.

OS-Based FDE

In the case of operating-system based FDE (Bitlocker, LUKS, FileVault, Veracrypt, etc.) things are a little different.  There, encrypting the drive does require making a copy of all of the data from the plaintext to the ciphertext.  (Notably, only Bitlocker and FileVault offer in-place encryption.)

From the paper you linked:

  Second, overwriting the entire visible address space of an SSD twice is usually, but not always, sufficient to sanitize the drive.

So not all overwritten data is recoverable.  After encrypting the drive, you can overwrite the slack space a few times to have a high likelihood of overwriting all of the underlying erase blocks.

That being said, encrypting the drive when new is still a best practice -- it avoids all these concerns, and ensures there's no time window where an attacker can get access to unencrypted data.

Side note on quantum computing: There is no evidence that quantum computing would allow breaking encrypted hard drives when used with a key length of 256 bits or longer.  Grover's algorithm is the best known speedup for symmetric encryption, and it has the effect of halving the key length.  (So a 256 bit key offers 128 bits of effectiveness against a quantum computer.)  Additionally, cryptographers do not believe even well-funded adversaries currently have large scale quantum computers, but that is likely to change in the next 10-15 years.


Why is the redirect_uri defined to be an absolute uri in OAuth2? I've been reading the OAuth2 spec and section 3.1.2 states that the redirect uri parameter (the callback used after successful authentication to redirect back to the service) must be an absolute uri. I've struggled unsuccessfully to work out exactly why this is in the spec - is it critical for security? If so, is it protecting against untrusted usages (Facebook auth) or more audited flows where the same org runs both client and IdP?

This answer might help you:
What is the purpose of OAuth 2.0 redirect_uri checking?

Another reason might be that providers can enforce the usage of https for the redirect uri...


Standards for secure key backup of master keys with secret sharing In many cases, there is a single master key that is installed in a HSM or similar device, but which should be backed up. The recommended method for this backup in many cases is to encrypt the master key to multiple smart cards from which there is a "n out of m" style setup required to restore the master key. Some HSM devices support this natively as a key backup method, but do not reveal the exact algorithm to do it.

This is obviously trivial to do manually:

Encrypt master key with a long passphrase
Use some secret sharing algorithm (Shamir's) to split the passphrase
Encrypt each produced part for each smart card

Now, my question is:

Are there any existing encryption standards or industry-accepted practices to do this, or is it just homebrew? I am specifically looking for solutions which are employed with smart cards.

A complete solution in the context of HSM must be HSM-specific because you do not want any piece of secret to ever go through the RAM of a PC, let alone its hard disk. The HSM should include a smart card reader, or establish a secure tunnel (encrypted and authenticated, à la SSL) with a hardware module which includes a smart card reader. The host PC, for a HSM, is used as a network router and an electrical source, nothing more. You use a HSM precisely because you cannot trust a PC for the secret values you are dealing with.

Under these conditions, there is little reason that a standard may have evolved, and indeed none has, except for the usual smart card basics (card size, connector emplacement, encapsulation of commands within APDU). For a HSM to have a secure backup method, it must be something "homebrew", directly integrated in the HSM.

Moreover, any certification for the HSM (e.g. FIPS 140-2 level 3) must cover that backup system as well. Consequently, you cannot slap a system with smart cards on an existing HSM and still claim that "this is certified".

Thales "nShield" HSM include such a native support for smart cards with a quorum. The actual secrets are encrypted files (what Thales calls a "security world") and the "administrator smart cards" collectively contain a master key which is sufficient to decrypt these files.


Regarding the storage of Root CA certificate and any Intermediate root CA certificate on Embedded Device The overall system setup is as explained

SERVER which connects with the client(Embedded device) on SSL/TLS
Embedded Device which acts a CLIENT and communicates with the server

The Server can also be accessed using web browsers (mozilla, chrome etc).

Through the web browser we downloaded/extracted the root CA certificates which were stored in the web browsers (Clients).
It consists of 2 Root CA,

1. Root CA

This is the self signed certificate by CA

2. Intermediate CA Domain validation CA

This certificate is signed by Root CA

This certificate is used to signed the server certificate

We needed Root CA(s) on the embedded device so that it can be used to authentic the server during the SSL/TLS handshake.

So for our embedded device, if we need to put the root CA certificates, as per our knowledge we should be able to use the same certificates
which can be embedded in the firmware.

Question: do we need to store both the certificates (Root and Intermediate CA) on the embedded device or any one of them is sufficient?
If only one, which one should be stored?

Only the Root-CA needs to be known (and trusted) by the client. Everything else can be chained on demand.

Your server can be instructed to send the intermediate certificate along with the server certificate. This process is called "certificate chaining" and often implemented by concatenating both certificates into a single certificate file; older versions of e.g. Apache Webserver required a specific statement ( SSLCertificateChainFile ).

A client receiving this chain of certificates does follow the server's certificate via its issuing CA until it reaches a client-trusted Root CA; if it doesn't reach a client-trusted Root-CA, the certificate will be regarded as "not trusted" and depending on the actual client application, the application will refuse to send data over that (encrypted, but not authenticated) connection.

Please also do keep in mind Root CAs do have an expiration date, so (depending on the estimated lifetime of device and Root CA) you may need to update or exchange Root CA certificates on your embedded client device as well.


What information can my ISP see using squid proxy? My ISP provides a transparent proxy to use and I can see that they are using the squid proxy for caching this.

What I am wondering is what data can they see and what can they see further if they can probe with the proxy?

I know HTTP traffic is visible regardless of proxy but what about HTTPS ; are they able to see it? Since they control the proxy can they MITM and see my cookies, headers, GET POST requests and traffic? What are they able to do?

Effectively they can see everything you do that's not encrypted or sent through a tunnel and in many cases they can see what type of traffic that is too via DNS. I'll list a few examples:

What sites you frequent.

When you're active on-line.

What operating systems you use and in many cases what software you use.

How often you patch your computer.

The firmware of mobile devices can be detected via http user-agent strings.

Who you bank with.

Social media habits.

They can use this info to do political profiling, or profiling for marketing purposes.

In some cases which types of IoT devices you own.

They can geo-locate almost every packet you send and where it's going too.

If you go beyond the Squid proxy you can also include the following:

The DNS lookup for every website you visit and the domain for every message you e-mail. This includes DNS lookups when you go to HTTPS websites.

clear-text SMTP mail (all of the message when sent in the clear).

Types of activities like torrenting files

Connections to the Tor network

Common traffic patterns sent through encrypted tunnels. ( i.e. downloads vs chat )

An additional note regarding HTTPS is some websites have mis-configured settings such that cookies are sent via clear-text HTTP. So in that case they would get copies of those too.

IPv6 connections your devices may make including HTTP or HTTPS over IPv6 if your ISP supports it (Many do).

etc...  Some ISP's record pretty much everything.

Aside from the DNS requests and cookie leaks the rest of your HTTPS traffic should be relatively private.

It's very unlikely that they would MITM your connection but this depends on what country you are in (it does happen in some repressive regimes). That said if you weren't careful about not accepting certificates or installing any software they provided it could happen. Some governments have required citizens to accept a key they can use to decode traffic if this is the case ALL of your traffic is visible. This is rare but I don't know where you are from so I thought I'd mention it.


What should a website operator do about the Heartbleed OpenSSL exploit? CVE-2014-0160

http://heartbleed.com

This is supposed to be a canonical question on dealing with the Heartbeat exploit.

I run an Apache web server with OpenSSL, as well as a few other utilities relying on OpenSSL (as client). What should I do to mitigate the risks?

The bug dissected
Check if your site is vulnerable (Duckduckgo.com is, for instance!)

 I looked at some of the data dumps
 from vulnerable sites,
 and it was ... bad.
 I saw emails, passwords, password hints.
 SSL keys and session cookies.
 Important servers
 brimming with visitor IPs.
 Attack ships on fire off
 the shoulder of Orion,
 c-beams glittering in the dark
 near the Tannhäuser Gate.
 I should probably patch OpenSSL.

Credit: XKCD.

There is more to consider than just new certificates (or rather, new key pairs) for every affected server. It also means:

Patching affected systems to OpenSSL 1.0.1g
Revocation of the old keypairs that were just supersceded
Changing all passwords
Invalidating all session keys and cookies
Evaluating the actual content handled by the vulnerable servers that could have been leaked, and reacting accordingly.
Evaluating any other information that could have been revealed, like memory addresses and security measures

Neel Mehta (the Google Security engineer who first reported the bug) has tweeted:

  Heap allocation patterns make private key exposure unlikely for #heartbleed #dontpanic.

Tomas Rzepka (probably from Swedish security firm Certezza) replied with what they had to do to recover keys:

  We can extract the private key successfully on FreeBSD after
  restarting apache and making the first request with ssltest.py

Private key theft has been also demonstrated by CloudFlare Challenge.

And Twitter user makomk chimed in with:

  I've recovered it from Apache on Gentoo as a bare prime factor in
  binary, but your demo's a lot clearer...It has a lowish success rate,
  more tries on the same connection don't help, reconnecting may,
  restarting probably won't...Someone with decent heap exploitation
  skills could probably improve the reliability. I'm not really trying
  that hard.

I summarized the bullet points above from heartbleed.com (emphasis mine):

  What is leaked primary key material and how to recover?

  These are the crown jewels, the encryption keys themselves. Leaked
  secret keys allows the attacker to decrypt any past and future traffic
  to the protected services and to impersonate the service at will. Any
  protection given by the encryption and the signatures in the X.509
  certificates can be bypassed. Recovery from this leak requires
  patching the vulnerability, revocation of the compromised keys and
  reissuing and redistributing new keys. Even doing all this will still
  leave any traffic intercepted by the attacker in the past still
  vulnerable to decryption. All this has to be done by the owners of the
  services.

  What is leaked secondary key material and how to recover?

  These are for example the user credentials (user names and
  passwords) used in the vulnerable services. Recovery from this leaks
  requires owners of the service first to restore trust to the service
  according to steps described above. After this users can start
  changing their passwords and possible encryption keys according to the
  instructions from the owners of the services that have been
  compromised. All session keys and session cookies should be invalided
  and considered compromised.

  What is leaked protected content and how to recover?

  This is the actual content handled by the vulnerable services. It
  may be personal or financial details, private communication such as
  emails or instant messages, documents or anything seen worth
  protecting by encryption. Only owners of the services will be able to
  estimate the likelihood what has been leaked and they should notify
  their users accordingly. Most important thing is to restore trust to
  the primary and secondary key material as described above. Only this
  enables safe use of the compromised services in the future.

  What is leaked collateral and how to recover?

  Leaked collateral are other details that have been exposed to the
  attacker in the leaked memory content. These may contain technical
  details such as memory addresses and security measures such as
  canaries used to protect against overflow attacks. These have only
  contemporary value and will lose their value to the attacker when
  OpenSSL has been upgraded to a fixed version.


Uploading any HTML files to our server Suppose our site allows uploading any HTML files.

Then a hacker can steal other's cookie using JavaScript.

What if we will serve uploaded HTML files with Content-Disposition: attachment? Will this protect against this kind of attack?

What are other variants of protection? We may serve uploaded files from another domain. Are there other way to protect ourselves against this?

According to the standards, if you use Content-Disposition: attachment, it is expected that the browser will not display the HTML file but instead prompt the user to save it as a file.

If you just want to share HTML files without displaying them, I suppose that's fine, though the conventional thing to do would be to put them in an archive format, such as .tar.gz or .zip.


Auditing user emails (illegal?) I'm the systems administrator for a company that does a lot of outbound emails and a lot of inbound emailing to potential clients.

We've had a email auditing tool running for a couple weeks that catches on to certain aspects of emails (malicious keywords, potential viruses, etc). I've noticed a spike in possible malicious emails.

During my time configuring the auditor our HR representative barged into my office and told me that it is illegal to audit a company email server due the the Snowden act (I have no idea what this is, just quoting what was said to me). My manager lost his mind, and told me I need to shutdown the auditor immediately. I tried to explain the reason behind the audits and what the audit is for, however, they requested it be taken offline. So I have disabled my auditor. The problem I have with this, is that everything is already saved by our mail server (we use GSuite) and is already audited, the only thing I was doing was routing all of them into an inbox so we can access them more efficiently if needed.

My question, is this a true statement, am I illegally auditing my users emails?

I have a decent background in computing and security legalities. While I agree with Steffen Ullrich that this is more of a legal question, here’s what I know. Just a disclosure, I am not a lawyer and I’m not responsible for any legal issues resulting.

Anyway, as long as your company owns their mail server’s in its entirety, and you have been granted root access to the machine, you are not gaining or exceeding your access as defined in the CFAA, and if your HR department is referring to the Freedom Act, this is applying to government surveillance to which your company is not subject to. Companies can make their own private terms of service and privacy policies. As long as it’s noted that the company email is subject to monitoring for malware and unapproved disclosure of sensitive material you should be in the clear.

In short, I’m not personally aware of any laws preventing this as long as your company owns the server entirely and you were granted root access. At that point it’s merely a matter of company policy. If I were you, I would comply with the request to halt auditing, find some case studies online and get a presentation going to give to HR and your manager to explain the benefit to the company from doing this. You may need to convince the company to hire outside legal counsel as HR doesn’t seem to be too knowledge in the subject (or maybe I don’t understand the situation fully).


Risk to Domain members in a Domain that's extended into the DMZ I am an AD administrator trying to look at things from an application server owner's perspective.

Imagine a scenario where an AD domain covers authentication in both the corporate LAN and the DMZ.  The LAN has RWDC's the DMZ has RODC's, standard firewall sandwich.

The RODC's have been hardened; no accounts are cached, a filtered attribute set (FAS) has been applied, there's a delegated RODC admin account, a firewall is in place, have AV, the servers are patched.

For application servers in the DMZ I can only manage them as much as AD allows me to; I restrict the number of users with admin privileges to the servers, I ensure the firewall is in place, the servers are patched, have AV, maybe there's some account Kerberos restriction.

There are other defences in the DMZ; e.g. the network team have their network firewall, but I can't control that and I can't control what the application owners do outside what I have stated above.

How does the security of the servers in the DMZ look, would they be in good shape?
If a server were compromised in the DMZ, what's the blast radius from that; is the domain at threat, are other servers in the DMZ and the LAN at threat?

What would be the most likely escalation path of compromise?

Glossary:

AD: active directory
DMZ: demilitarized zone; location for internet facing servers
LAN: (internal network; separated from DMZ by firewall
RWDC: read/write domain controller
RODC: read only domain controller

I would principaly worry about what is allowed by the firewall(s), and what are the privileges of the accounts used in the DMZ on the internal machines. The real question is IMHO what could happen if an attacker could break the security of an application running on a DMZ server:

does the firewall allow connections from that server to the internal lan?
does any internal server (or client machine holding shared resources) accept connections from one of the users used in the DMZ?

If above risks (DMZ -> internal zone) are already covered, you can then considere DMZ -> DMZ, meaning if one application in the DMZ is compromised, is this account able to do anything on other applications from same server, and what about the other servers.

I know those are just hints, but it is the best I can without more elements on your actual configuration, including the small details as noticed by paj28 in its comment.


Add a file as entropy source for /dev/random What I have: A large file containing lots of secret, true-random bytes (yes, I'm sure they're not merely pseudo-random). I'll call it F.

What I want to do: Tell Linux that it can use this file as an entropy source for /dev/random (each byte should be estimated at a full 8 bits of entropy)

What I already know about and don't want to be lectured about:

/dev/urandom
Existing tools for collecting entropy from other devices in the system

What I'm looking for: A shell command or the name of a tool (and the relevant function) that will either:

Append F to /dev/random
Cause accesses to /dev/random to consume bytes from F as if it were a device, without reusing any

Is this possible? What are the security implications?

First of all, to answer your question directly: This cannot be done. It is purposefully not allowed.

You can, in fact write to /dev/random and it will mix your input into the random pool, potentially improving the quality of the output. But it won't update the entropy_count and unlock /dev/random for reading, because that would be cheating. Otherwise you'd be able to do something like this:

cat /dev/urandom > /dev/random  # Sup dawg, I heard you like random pools...

Except that you can. Sort of.

There's an ioctl called RNDADDENTROPY available on /dev/random that updates the entropy pool and then increments the entropy_count accordingly. The idea is to allow you to read from a hardware RNG in userspace and dump it into the kernel pool without writing your own driver. Nifty. And while anyone is allowed to dump their entropy into  /dev/random (it can't hurt), only root is allowed to use RNDADDENTROPY.

And yes, there is a tool out there that allows you to do this relatively easily; it's called rngd. Its primary purpose is to read from an RNG like /dev/hwrandom or your processor's RDRAND instruction, and constantly re-seed your entropy pool as it gets low. But it takes an arbitrary filename for input, so yes, you can even do this:

rngd -r /dev/urandom

Which, in all honesty, is not entirely unlike doing this:

ln -sf /dev/urandom /dev/random

But as I stated originally, that doesn't mean that you can use this tool to make the kernel use your file as its source of entropy. That bit, at least, is not allowed. You can use it as an additional source of entropy mixed in with all the others, but not the only source of entropy.

If you're convinced your file is of prime-grade randomness, then just use that. You don't have to inject it through the kernel's entropy estimation system. If instead you have a mechanism for generating TRNGs, then by all means dump it in there with all the rest of the entropy sources; rngd makes that pretty simple.

I won't bother telling you about the utter absurdity of religiously avoiding /dev/urandom on real servers, as clearly you've heard that lecture several times and choose not to listen.

But for everyone else, the difference between /dev/random and /dev/urandom only matters immediately at startup on devices without reasonable sources of randomness (like some embedded devices), where the startup conditions are precisely repeatable, and where the random pool is not saved between boots. In all other cases, any theoretical attack  against /dev/urandom would require techniques and technology that literally do not exist, and are not expected to ever exist, ever.

From the wording of your question, you seem to be under the impression that /dev/random outputs the result of a TRNG, while /dev/urandom uses a PRNG. This is not accurate. The only difference in output is that random will "lock up" if it's generating bytes faster than it's observing random events, while urandom will not. Otherwise they both run the exact same code on their respective pools. Neither directly outputs the raw bits from a TRNG. Both use random events to constantly re-seed a PRNG.


Security concerns with a "fiddle" site? I recently came across a cool site for testing .NET code (http://dotnetfiddle.net/).  In the FAQs they mention that they have two restrictions for security purposes:

No access to File System IO
No external internet access

Is this sufficient to prevent malicious users from exploiting the site?  Is there anything that a malicious user could still do even with these restrictions in place?

Is there anything that a malicious user could still do even with these restrictions in place?

It depends on your definition of "malicious". Running a tight loop or otherwise consuming huge amounts of resources is arguably malicious. Serving up a fake PayPal front is malicious, but certainly not prevented by these features.

You pick the level and type of insecurity you're willing to tolerate based on the features you feel you need. And then over time you might adjust based on usage.


Recover SHA1-encoded email addresses Say you have a list of SHA1 hashes which are all encoded with the same salt. All of these are email addresses and you know at least one combination of hash and email address.

Is it possible to use a tool like hashcat to recover the salt and thus decode the entire list?

I have learned that someone has published such a list and my own address is on it. If it's possible to decode that list, I would like to convince them to take it offline. For that I would want to prove to them that even a complete amateur like myself could decode these addresses in a reasonable amount of time, say 72 hours, and with standard hardware like a modern laptop.

Finding salt is relatively easy: put the known email address as the salt for the hashes into hashcat. However, it probably won't handle non ASCII salt (e.g. random binary data).

Once you've got the salt, finding predictable email addresses (e.g. firstname.lastname@gmail.com) is easy enough, but you'd have to brute force both username and domain to find the addresses from a completely unknown space - checking if a given address was present would be easy, but finding all that were present originally is hard. For comparison, even a 12 character random password is hard to break in this way, and most email addresses are longer than that (although they are usually relatively predictable).

That suggests the best way to find out the contents of the list is to find the salt, then hash a list of email addresses to see if there are on the list. Since email addresses are generally not kept private (else it's quite hard to email someone), they are regularly scraped from any databases that get exposed accidentally, and put in big lists on places like paste bin. Unless your email address is only used with trusted contacts, chances are it appears on at least one of these lists already...


Is encryption key length limitations by governments norm? Today my internet service provide gave me a customer agreement form to fill in. I found following line in it:

  Permission limit for Encryption is 40 bit key per length in RSA algorithms, If customer is using higher than specific limit provide the relevent details and permission taken from telecom authority.

I don't have much knowledge of encryption, but use 1024/2048/4096 bit keys during public key pair generation during work.

Is limiting key size fine and norm (I am from India)? Will it impact when I am using some software requiring public key generation like github account key?

UPDATE : I searched more regarding limit and found some talking about 40 bit RSA, other about 40 bit symmetric algorithms limit. This look not logical as RSA is asymmetric. So I searched on original source on DOT website, and found
http://dot.gov.in/sites/default/files/internet_telephony_lce.doc
Where I found following statement.

Individuals / Groups/ Organisations are permitted to use as customer encryption  upto 40 bit key length in the RSA algorithms or its equivalent in other algorithms without having to obtain permission. However, if encryption equipments higher than this limit  are to be deployed, individuals/groups/organisations shall do so with the permission of the Telecom Authority  and deposit the decryption key, split into two parts, with the Telecom Authority.

I thing this covers all (or all asymmetric) algorithms not just RSA, So situation look like more confusing.

Permission limit for Encryption is 40 bit key per length in RSA algorithms

This is totally nonsensical.

First some history: There was a time when key lengths were commonly restricted, particularly but not exclusively by the US government in export control regulations. (This was because encryption was considered a "dual use technology" with both civilian and military applications, and the alleged aim was to reduce the availability of encryption outside of the US that the US could not break. An easy way to do that is to restrict the key length, and the most accessible means for a government to do so is in national and export regulations.)

This key length was, for a long time, capped at 40 bits for symmetrical ciphers. The limit was eventually raised to 56 bits and later the limit was abandoned completely.

However, RSA is not a symmetrical cipher. It is an asymmetric cipher, which means that it uses different keys for encryption and decryption. There's a lot of math behind how this works, which is not necessary to understand, but which you can read about in Wikipedia's articles on public-key cryptography and the RSA cryptosystem specifically if you are curious. Basically, you pick numbers such that given a subset of those numbers the calculations involved in encryption are easy to do, but the calculations involved in decryption are difficult; you then distribute the set of numbers that make encryption easy, but keep the set of numbers that make decryption easy a secret.

Because this requires that keys have certain mathematical properties, keys must be significantly longer to provide a comparable level of security. RSA keys need to be a few thousand bits long to provide security comparable to that of 128-bit symmetric keys, which is generally considered the smallest symmetric key size that can be considered reasonably secure today. Compare Amount of simple operations that is safely out of reach for all humanity? here on Information Security SE. For RSA, absent a more exact specification, the "key size" generally refers to the size of the public modulus, which in RSA is a multiplicative product of two prime numbers. For RSA these days, the absolute minimum is generally considered to be a 1024 bits modulus, with 2048 bits strongly preferred wherever possible.

A 40-bit RSA key would be absolutely trivial to break.

Even a 40-bit symmetric key would be very easy to break with modern consumer hardware and naiive implementations.

Just to give you an idea, I'm browsing Stack Exchange over HTTPS, and they are using a 2048-bit RSA key.

TL;DR:

I don't know about the legal situation in India, but yes, governments have historically limited civilian access to "strong" encryption. What actually is considered "strong" encryption has changed over time. However, the specific limit as you wrote it is utterly nonsensical; there is no reason to use RSA with a 40-bit modulus, because you pay all the complexity in terms of implementation but gain nothing in terms of security because the key is so short. You would be better off not using encryption at all and knowing that you aren't, than using 40-bit RSA, and it is highly unlikely that any software will even allow you to create a 40-bit RSA key.


On the Android platform, is it secure to use a custom URI scheme to receive a OAuth 2.0 authorization response from the Google Identity Platform? Assuming I developed an Android app using the Google Identify Platform as its ID system.
In Google's Identify Platform doc (https://developers.google.com/identity/protocols/OAuth2InstalledApp), it says "Your app must register with the system for the custom URI scheme in order to receive the authorization response".

My question is if a hacker reverse-engineered my APK and figured out my custom URI scheme.  He then used that custom URI scheme and released his own Android app with that URI scheme (https://stackoverflow.com/questions/2958701/launch-custom-android-application-from-android-browser).  Then Google can be sending OAuth 2.0 authorization response (auth code) to the hacker's Android app.

Isn't that a big security problem?

Actually, that is one of the fundamental security problems. If someone knows how your application is supposed to work, then they can mimic it and do evil things like steal tokens.

Given that, there is no direct solution to the problem, but a bunch of related solutions to slightly different problems. These include (but not limited to):

Device restrictions to preventing side-loading of apps
App validation when submitting to store
Store take-down requests

This is the price we (currently) pay for having SSO capabilities within an application. There are other options like requiring custom keys on a per-app-instance basis, but that's impossible to manage, and just makes an attackers job a little bit harder. Conversely, you can push the authentication and token exchange to the device itself within a system-like process, but that just means the evil app needs to do the same thing, which actually might make their job easier.

So what it basically comes down to is whether you're comfortable with the above protections already in place.


How do online polls ensure only one vote per person? For instance, TIME's Person of the Year poll.

I can see that CAPTCHAs would prevent the worst abuses, but if the server just gets a bunch of POST requests, how does it decide that this one came from person A, this one came from person B?

Is it necessary to require that the user have an account on your site in order to accomplish this?

There's nothing you can do online to prevent one person to vote multiple times.

When you do a HTTP request, the website knows:

Your IP address. This can be spoofed easily, through the use of proxies or VPNs.
Some HTTP headers that are sent by your browser. They can also be spoofed.
All information that CSS / JavaScript / Flash / Java applets can collect are client-side, so they can be spoofed with a little bit of effort.

For example, Tor is a browser which helps people to protect their anonymity online, by providing protections enabled by default against most browser-fingerprint vectors.

A captcha won't prevent a user to vote twice. It may prevent a computer to automatically vote, but the user is very likely to be able to pass the captcha twice if it was ever able to do once.

Solutions exist if you ask the user to give some information about its physical identity, but they're not practical for online polls.


Is a crash always exploitable for RCE? Reading papers written by teams looking for vulnerabilities using fuzzing, I notice that many people label a crash as a DoS vulnerability. While in other papers and researches, they go deeper after the crash and try to exploit it to get RCE.

My question is whether all memory related crashes can lead to RCE or there are some prerogatives, and they don't even try.

Many crashes aren't exploitable for anything except denial-of-service (DoS). The most common example would be a NULL pointer read; attempting to dereference a pointer to (or anywhere near) 0 will fail, and unless the exception/signal is caught will cause the program to crash. However, just because the program tries to read from zero when given invalid input doesn't mean that it'll do anything more exciting if given a different invalid input.

Determining the exploitability of a crash is tricky. There's a few heuristics you can use (writes are usually worse than reads, if the instruction pointer is pointing at non-executable code - a NX/DEP violation - that's almost certainly exploitable, if it's a null pointer read then that's pretty unlikely to be exploitable) but they're not perfectly accurate. There are tools that will analyze a crash dump and try to guess for you (for example, Microsoft published a "!exploitable" command for the Windows debugger windbg that will perform this analysis; there are similar tools for Linux debuggers). To know for sure, you need to analyze the program flow that caused the memory corruption and see how much influence you have over it, and whether you can make it do anything actually dangerous.


Can my computer get infected if I hover the mouse to check the thumbnail of an e-mail attachment? So, today an user sent me an e-mail about a suspicious e-mail. When I opened it to check it, I accidentaly hovered the mouse over the "doc.jpg" and it opened the image thumbnail. I never bothered to check the thumbnails, so I never stop to think about it, but would someone be able to execute malicious code in my computer if I checked the thumbnail?

EDIT: As requested, we're using Google Chrome 43.0.2357.134 and Zimbra 8.0(yep, kinda dated, but unfortunately, we can't do anything about it).

Maybe. In theory it might be that the (unknown) mail client you use already extracts information from the attachment when you simply hover over it. And the practice might not be that far away from this theory:
There were several bugs in the past where the preview feature for mails could be used to execute malware, see Can malware be activated by previewing email in Outlook's Preview pane? or BadWinmail: the really bad Outlook flaw. There were also code execution in the past triggered by simply hovering over a file in explorer.


Storing CVC / CVV / CVV2 until payment is processed I need to store the payment info of a transaction.

We have a script that reads which transactions haven't yet been sent to our ERP (the business management software), to then send it. This script runs every several minutes.

According to PCI DSS, I can store info such as credit card number, cardholder name and expiration date, but I can't store the CVV2. How should I store this info until the script sends it?

Technically, according to PCI SSC you can hold onto CVV and other sensitive authentication data until authorization has occurred. In other words the restriction on storing sensitive authentication data applies to post authentication/processing storage. Here is a document from the PCI SSC about data storage requirments. See the "Technical Guidelines for PCI Data Storage" table. Footnote 2 to the table states:

  Sensitive authentication data must not be stored after authorization (even if encrypted).

My advice as a QSA, would be that the pre-auth storage time needs to be reasonable from a business stand point. I would also want it to be as short as technically possible. If your data flow is similar to others in your industry and they are processing payments without storing sensitive data for more then a few seconds at most, then I would expect the same of you.