Why haven't (most of) the Zodiac Killer's letters been decrypted?

The Zodiac killer ciphers are an interesting case. As there were four ciphers sent to the local papers, I will address each in turn. They do share some common traits however.

They are each their own cipher, so the 'solution' used for cipher 408 cannot be applied to the other messages.
Each message has a unique character count.
The Zodiac Killer sent these ciphers to newspapers with accompanying plain text messages threatening to commit additional murders (including killing school children) were the ciphers not printed in the papers.

 13

The message containing this cipher was sent to the authorities postmarked April 20, 1970.

This cipher was prefaced with the plain text "my name is". While the cipher contains 13 symbols, 8 of those symbols are unique. Attempts have been made to find a solution to this cipher using modern computing techniques, however the message is just too short and the possibilities are just to many to determine what 'solutions' are valid candidate solutions.

 32

The message containing this cipher was sent to authorities postmarked June 26, 1970.

This cipher accompanied a plain text message claiming that when decoded this cipher would lead to the location of a bomb he had buried and set to go off at a later date. The cipher was never decoded and the alleged bomb never found.

The cipher had 32 symbols, 29 of which were unique - leaving pretty much nothing to analyze, essentially making it a one time pad cipher.

 408

The messages containing this cipher were sent to the Vallejo Times Herald, the San Francisco Chronicle, and The San Francisco Examiner postmarked August 1, 1969. Each letter included one-third of the 408 symbol cipher.

On August 8, 1969, high school teach Donald Harden and his wife Bettye of Salinas, California, solved it, however the solution did not work for the last 18 symbols of the message. The cipher was a homophonic substitution cipher, but not a simple one. Rather than using 1 symbol = 1 letter substitution, The Zodiac Killer assigned multiple symbols to each letter. It is theorized that the last 18 letters of the cipher are filler symbols added to ensure that the three papers received equal portions of cipher text. There have been attempts to find a meaning for this last potion of the cipher "EBEORIETEMETHHPITI" via anagram, however there are 740 billion ways to anagram 18 letters and nothing meaningful has come of these attempts.

It's notable however that the rotation of symbols for each letter was consistent across the cipher until the last 18 letter, lending credence to the filler explanation. It's also interesting to note that The Zodiac Killer appears to have been a bad speller, or perhaps they struggled to follow their own code keys as there are spelling errors throughout the text. It's interesting however that these errors always seem to be made where the incorrect symbol resemble the intended symbol. (e.g. 'MOAT' instead of 'MOST' where the symbol for 'A' is a filled in triangle and the symbol for 'S' is a triangle with a dot in it.

 340

The message containing this cipher was sent to authorities postmarked November 8, 1969.

There are a number notable differences between the 340 cipher and the 408 cipher which make 340 more difficult to 'solve'. The first difference is that it is 68 characters shorter, giving a substantially shorter message to analyze. 7 symbols which appeared in 408 were removed from 340 and 16 entirely new symbols were added in. These changes in addition to the shorter message have posed a real problem for analysis efforts.

Methods of analysis:

Symbol repetition by row and column - 340 has many rows but no columns without repeating symbols, which supports that the text is meant to be read horizontally. There is also a pattern, where the first three rows contain no repeated symbols, and then exactly at the half way point, another three rows which contain no repeating symbols. This has spawned a theory that the original cipher was created twice as wide, then cut in half vertically to put one side above/below the other as a means of obstruction.
Repeating Bigram analysis - when comparing 408 to 340, it is notable that 408 has 62 bigrams where as 340 only has 25. This is interesting because if you look at bigrams in randomly scrambled cipher text, you will normally get around 20 in this sized text. This would not support a horizontal text pattern. Additionally, if you cut the text in half - the first half has significantly more bigrams than the second half. This would indicate that something in the cipher is disrupting the naturally occurring bigrams.
Repeating Trigram analysis - when comparing 408 to 340, it is notable that 408 has 11 trigrams where as 340 only has 2. Whatever is disturbing the bigram count does not appear to be disturbing the trigram count. This favors the theory of a horizontal reading direction.
Bigram distance analysis - This type of analysis looks at the possibility of symbol transposition. This analysis as been inconclusive and no conclusions have been able to be drawn.
Homophonic substitution analysis - Strongest example (symbols L/M) repeat 7 times.
odd/even analysis - Very wide spread of bigram counts. Less than 1% of randomized trials show this even of a bigram spread.

Notable Oddities

Two pivot pairs appear in the cipher text. The chances of this happening naturally Once in this size of text is 1 in 50,000. This may or may not be significant.
Two strange 'box corner' patterns appear in the text between the 'O' and 'C' symbols.
"ZODAIK" seems to appear in the cipher at the bottom left of the last line of text, if you replace a solid triangle symbol with a 'D'

 My Conclusion

To answer your questions specifically;

  Why haven't his remaining three letters been cracked yet?

13 is too short. 32 is essentially a one time pad. 340 is short, complicated and nigh-on nonsensical.

  Is this a technical problem, or is it just not being worked on?

It's a technical problem. without patterns, no amount of pattern analysis is going to make a difference.

  Are the letters available to the public for someone to try their hand with?

Yes. There are multiple forums dedicated to this task.

The 340 cipher is still being actively pursued by a dedicated community. There are several forums (http://zodiackillersite.com, http://zodiackillerfacts.com, http://zodiackiller.com) focused on finding a solution. The shortness of the cipher and the number of symbols pose a real challenge to investigators. It would be interesting to see if an AI like Watson or Deep Blue would be able to make any headway on this, however at this point, to some degree its academic. No solution to this cipher will be able to bring any peace to those affected by the murders.

If you are truly interested in this topic, I would HIGHLY recommend you listen to the video I've listed in my sources and visit the forums. The people who are working on this will be able to go into FAR more depth than I'm able to.

  Sources:

Wikipedia

Zodiac Killer Ciphers

Youtube - David Oranchak


openssl speed tells me blowfish is much quicker than md5, what am I missing?

First, I think you're misinterpreting your results. If for example we look at 1024-size blocks, MD5 is doing 1,547,154 in 3 seconds while Blowfish is only doing 355,336, and so is taking more than four times as long per operation as MD5.

Second, bcrypt iterates Blowfish key setup a configurable number of times, typically 4,096. Try running your test again, but comparing one iteration of MD5 with 4,096 iterations of Blowfish, and see which is faster. So yes, it's the COST parameter in bcrypt setup.


Centralized local hosted web based password manager

What you're looking for sounds like Privileged Access Management - a central database that stores administrative and other non-user credentials and allows authorized users to "check them out" for use.  Such systems often will programmatically change the credentials on the target system so as to prevent re-use outside the window for which access was granted.

The most prominent example of this sort of software is CyberArk.  You install it on your network, tell it how to authenticate your users, then you start stuffing credentials into it and, if possible, telling it how to "manage" credentials.  It can be configured to change them regularly (e.g. every 60 days), after use, or however you like.

Competitors to CyberArk include Dell Privileged Password Manager and BeyondTrust PowerBroker.  And here's a wider list of products that "compete" with CyberArk, ranging from local single-user to cloud multi-user, you might find a match for your needs somewhere on this list.

It is possible that OpenIAM Access Manager, which is Open Source, would provide the functionality you're looking for - but OpenIAM addresses a much wider swath of the Identity Management field, so I'm not sure if it would be suitable for what seems like a more limited need on your part.


It's a hardware implementation that hasn't been tested formally, and it's proprietary. The potential worry is that Intel could have backdoored the implementation at the NSA's demand.

The current way of mixing the rdrand output into the Linux kernel PRNG is that it's xor'ed into the pool, which mathematically means that there's no possible way for a weak output from the rdrand implementation to weaken the overall pool - it will either strengthen it or do nothing to the security.

However, the real risk is that the xor instruction is backdoored in a way that detects for the use of rdrand in a special scenario, then produces a different output when xor is called, causing only the purposefully weakened rdrand output to be placed into the pool.

Feasible? Yes. Plausible? Given recent revelations, maybe. If it is backdoored, is Linus complicit in it? Your guess is as good as mine.

Also, there's a great paper [PDF] on hiding hardware backdoors at transistor level in CPUs.

Edit, Feb 2019. User Luc commented below that things have changed since this answer was originally written:

  As of Linux 4.19, the kernel trusts RDRAND to seed its CSPRNG fully, unless one passes the random.trust_cpu=0 flag on boot (or sets it compile time). This should not be an issue if this is not your first boot, but newly installed systems or newly created VMs might have a predictable startup seed file (or no seed file at all), so for those systems this is relevant to gather good entropy.


Someone is trying to brute-force(?) my private mail server... very... slowly... and with changing IPs

What's the point of this kind of "attack"? The rate is much too slow to do any efficient brute-forcing, and I really doubt that someone would specifically target my tiny personal server.

You may be seeing connections very rarely, but how do you know the bots doing the brute forcing aren't constantly saturating their uplinks, and your site is just one of many being attacked? There is no advantage for an attacker to spend a short time going after one site at a time (and triggering fail2ban), compared to attacking a huge number of servers at once, where each server only sees infrequent connections. Both can have the same total rate of outgoing authentication attempts per second, but attacking one site at a time is simply a less efficient use of the attacker's bandwidth.

Is there anything I can do against it except banning that provider's complete IP range (or ignoring the messages, since my passwords are strong)?

No, not really. Chances are, these are coming from a botnet or a cluster of low-cost VPSes. It is not possible to determine what other IP ranges may be being used just by seeing a few of these. If they are not on the same subnet, they cannot be predicted. You can safely ignore these connections. It is nothing more than the background noise of the internet. Just make sure you aren't low-hanging fruit.


Change NTLM hash in memory on the lock screen?

If you have the NT hash, you can just use it in a pass-the-hash attack to gain access to the system. I'm not aware of a way to execute this from a login screen.

If you've got physical access, you can always just boot to a live CD and reset the password that way.


How do I use google drive local folder with auto sync while protecting myself from ransomware?

Let's address the approaches you highlighted first

Approach 1:

As you stated, this doesn't resolve, nor prevent your files from getting encrypted if you're hit. It only creates more problems in the sense that you will end up with considerably less backups and be open to potentially more data loss.

Approach 2

You do not need to use Backupify, they were just suggesting their product. You can very well create your own file server (hosted or on-premise) and set up the same level of retention they offer. Beware of security however as they will undoubtedly surpass you in this area.
As you rightly noted this also doesn't resolve the problem as you will need to restore a backup from before your files got encrypted and this is always guesswork (unless you can forensically or otherwise determine the date the attack started).

Now this is what it all boils down to: Where services like Backupify offer value is in the length of retention. In your case, Let's assume you have used up 700GB of your 1TB drive (cos it can't be all used up right?). It wouldn't usually take months for most variants of ransomware to encrypt that amount of data but it could take up to 4 months for one of the slowest variants tested - see https://blog.barkly.com/how-fast-does-ransomware-encrypt-files.

Also bear in mind what hardware you are using, you might have 16gb of RAM and a quad core processor coupled with an SSD? Well that could almost halve the time to total encryption.

What can we do then?

The answer is really simple, plan for the worst and hope for the best. Knowing that there will always be data loss when ransomware hits is the first thing you need to accept.

From here, you will need to take further steps to prevent an attack in the first place (AVs, etc).

Next you will need to have a remediation strategy which is almost always going to be a restore from backups or to go bitcoin shopping.

Here you'll need to determine the longest window of retention you can afford. A smart approach will be to look at tests like the one above showing the time to full encryption and matching the slowest variant - so in your case, retain backups for about 4 months.

But there is a quicker and cheaper way

This only really works with incremental and (arguably) differential backups.

What happens when you wake up and review your backup logs to see that files you did not change have been backed up? Loads of them? - You immediately stop any further backups and roll back as quickly as you can!

Here you can afford a retention rate as low as a month provided you are diligent in monitoring your logs (and can remember stuff you've changed).

So there is my idea - monitor your backups daily and you will be able to tell when you have been hit and should be able to minimise data loss.

(Now this will be easy for you to implement / carry out a lone user but very difficult to replicate in a work environment... for that, we are still stuck at the "educating-the-users" stage).


How to tell if someone else's site is vulnerable to Shellshock without hacking them?

With Heartbleed, a definitive scan is possible: ask for a heartbeat response that's one byte too large, and see if you get it; a negative result means that the server is not vulnerable.  This tests the OpenSSL library directly, and performs exactly the same operations that an attacker would perform.

This isn't possible with "shellshock": the bash shell is never exposed directly to the Internet.  Any scanning is indirect, calling a CGI program and seeing if the attack payload gets run, so a scan that returns a negative result could be because the server has been patched (not vulnerable), or because it uses a different system shell (maybe not vulnerable), or because none of the CGI programs calls bash (not vulnerable right now), or because the scan didn't try the right CGI program (vulnerable, but you don't know it).


Is Intel SA00086 / CVE-2017-5712 remotely exploitable?

In the context of Linux, if one obtains root via a privilege escalation exploit, they may deploy a rootkit via AMT or make other system modifications that one won't be able to evidence/remove by trivial OS fixes.

The scenario is:

An attacker gains remote code execution within the context of your web server (e.g. www-data or a user Apache runs at, or pick your favorite web server). At this point you should be able to identify these events in your logs and figure out how did they access the system, and potentially recover/patch/remove backdoors.
Via a privilege escalation vulnerability, they gain root/UID=0 privilege. Still, logs may be available, and you may be able to patch/recover.
They exploit the AMT/IMT vulnerability and gain AMT execution. At this point you lose any regular visibility to as what have they done at AMT level, and they may use this access to install a backdoor or rootkit that may be really difficult to discover/detect or eradicate.

The temporal score for you may not be the same as a unauthenticated RCE, depending on the context of the system, so I'd say it is a medium criticality vulnerability.

Case #3 applies also to authenticated attackers that may want to gain persistent access or mask their activities in a way that would not be visible to you via a SIEM/remote syslog or other means.

I hope this helps clear the issue.


WPA2 enterprise credentials involved in encryption?

Basically, it is 802.1x.  Key derivation is complicated.  There is a high-level explanation here: http://www.tldp.org/HOWTO/8021X-HOWTO/intro.html

To answer your question simply, the key (actually there are several keys) is agreed upon by the AP and client based on another key issued by the authenticating RADIUS server.  All of these keys are (ephemeral) session keys, with the exception of the group transient key, which is shared between clients (for multicast and broadcast) but periodically changed.

Simply knowing credentials will not cause you to arrive at the same set of keys as another user of the same credentials, or even the same set of keys you had the last time you authenticated.  Any credentials at all will get you the group transient key, but unicast traffic remains secure.

As with all such things, there is an attack.  To render that traffic insecure, an attacker could set up a rogue AP which acts as a gateway, allowing the target to authenticate to it and in turn authenticating with its credentials to the network.  This is an active MitM, though, not a passive disclosure like you were worried about.


Is it worth deleting certificate exceptions if they no longer need to be?

The only reason you would need to have them remove it is if there's a possibility somebody will steal the certificate's private key. If this were to happen, AND a hacker were able to hijack a connection to one of your internal applications (with the same domain name that the self-signed cert had), then they would be able to see private information.

Now if a hacker were able to get the old private key, they would probably be able to get the new one as well (if you're storing them in the same place). So it probably doesn't make a difference whether your users delete the exceptions.

If you want to be extra safe, though, you could.


Confidentiality is about a data, whereas privacy is about a person/group of people/organization.

Every data belongs to a person. Every person is identified by his data. So these 2 notions extend each others. Interpreting one of them as being a sub-characteristic of an other is correct at your will.


Reverse Shell Exploit for SquirrelMail 1.4.22

You may find that many of these XSS attacks (https://www.cvedetails.com/vulnerability-list/vendor_id-803/product_id-1366/year-2018/opxss-1/Squirrelmail-Squirrelmail.html) on Squirrelmail will allow you to perform a session hijack, bypassing the need to create an account, at which point a known vulnerability in 1.4.22 will allow remote code execution: https://www.cvedetails.com/cve/CVE-2017-7692/

If this is a test environment, the XSS attacks would still require a 'victim' to open the mailicious email. If that won't happen, you'll need another approach.


The six keys are derived from the master secret, the client random and the server random. You can get the master secret and the client random from the SSLKEYLOGFILE. I suppose you can sniff the server random with Wireshark from the server key exchange message.

If you have those, you can call some library function or script on them to get the six keys.

The way this works is that a HMAC is computed over the random numbers and the master secret and the result is cut in parts to get the six secrets:

  To generate the key material, compute

  key_block = PRF(SecurityParameters.master_secret,
                  "key expansion",
                  SecurityParameters.server_random +
                  SecurityParameters.client_random);

  until enough output has been generated.  Then, the key_block is
  partitioned as follows:

  client_write_MAC_key[SecurityParameters.mac_key_length]
  server_write_MAC_key[SecurityParameters.mac_key_length]
  client_write_key[SecurityParameters.enc_key_length]
  server_write_key[SecurityParameters.enc_key_length]
  client_write_IV[SecurityParameters.fixed_iv_length]
  server_write_IV[SecurityParameters.fixed_iv_length]

More info:

Decoding TLS with PHP
The First Few Milliseconds of an HTTPS Connection
Fun with the TLS handshake


To be honest, this question is generally a duplicate of questions such as this and be generally answered by looking at this hardening tag.

Just to add to the great points made by DKNUCKLES.

Regarding IDS/IPS, I personally wouldn't use a HIPS/HIDS on an email server. Email servers generally work pretty hard (due to AV, content-filtering and other checks on emails flowing in and out of an organisation) and having managed email servers, HIPS/HIDS wouldn't be for me.

I would use NIDS (most likely Snort, I'm not familiar with Suricata) and have it configured like a true Network Security Monitoring solution so I've visibility of what's going on in the network.

Additionally, I'd not only have the email server hardened as per the best practices in the links above but also have it segregated in a DMZ with outbound restrictions (i.e. connections to the Internet and back internally so that it can only talk to specific devices that it needs to (this is generally following defence-in-depth principles and layered security). Some papers from the SAN Reading Room on it - 1, 2, 3. You don't want the email server being used as a pivot point to attack more valuable elements of your infrastructure so its ability to do stuff needs to be restricted.

From a protocol perspective for downloading emails to the client, ensure that IMAP over SSL is used rather than POP, which is a clear-text protocol.

Ensure your sysadmin accesses the email server (for administration purposes) in a secure and controlled fashion.

On a a possibly unrelated note, configuring your mail server to always take certain actions (such as encrypt or block) when you see email going to a certain recipient or from a certain internal person or based on certain content can save unintended data leakage and other security issues.


Unable to obtain TCP/HTTP traffic from WPA2 packets even with full handshake and decryption

As it turns out, the issue was that my WLAN is setup as 802.11b/g/n, and the target devices I had been testing this on were all 802.11b/g/n compatible, so they were using 802.11n by default to directly communicate with the AP. As I realize now, the Alfa AWUS036H is only 802.11 b/g compatible, so it was was not able to intercept the 802.11n traffic! Once I switched my router to only use b/g, then I was able to capture the TCP traffic as expected.

Lesson learned: get a WiFi card that is actually compatible with modern wireless standards -_-


When does a company need to hire a dedicated security specialist?

Now.

The fact that you are realizing that issues are being found so late in the SDLC is a sign you need to hire security people. But here's the difficult part. There are many different disciplines in Information Security, and you may need to hire more than one person to cover the different disciplines. For example, the following are each different skillsets. There may be some overlap, but you'll be hard-pressed to find someone who is skilled at everything that has the depth necessary to get the job done correctly.

Software Architecture
Network Architecture
Code Review
Penetration testing
Vulnerability assessments
Risk management
Developer education

There also should be questions about where you want a security program to mature to. If you hire penetration testers that just find vulnerability after vulnerability, you'll end up with developers who keep writing bad code, because their mistakes aren't caught during the development process. Or during the design process. It's really hard for me to tell someone "yeah, I found this serious design flaw. You'll need to rip out a bunch of code to fix it." That's financially expensive. Human-time expensive. And developers don't really get education out of it.

It should be noted that even within each of these disciplines, there's different skills. For example, software architecture can be someone who is embedded in a team, but from the security team, helping design software. Or it can be someone who takes documentation near the end of the design process, reviews it, helps the team understand design flaws. Both approaches have their pros and cons. Or you may find people who are good at risk management when it comes to physical security, but not information security. Or people who are good at vulnerability assessments, but not good at penetration testing.

Take stock of what the company needs now, and start developing a security program around that.


Does password protected git public key protect my repository?

The passphrase is used to encrypt the private key, which prevents it from being used to digitally sign commits. This protects your private key from being abused by an attacker if it becomes compromised (e.g. you accidentally commit your private key to a public repo) unless they can crack your password.


What protocols are authenticated by Active Directory?

It depends which generation of IDaaS you are referring to but in general Active Directory (and other IAM solutions) tend to have better support for on-prem authentication protocols than IDaaS, which is a cloud bridge, does.

I find your question intriguing because I have never tried to compare them previously (they are after all apples and oranges).

I have made a start with a few of the common authentication protocols:

Kerberos = AD
LDAP = AD and IDaaS
NTLM= AD
OIDC = IDaaS
SAML = AD and IDaaS

I am sure others may wish to add to or update this list. If that is the case please comment and I will update the answer.


When a SSL/TLS client and server talk to each other, the client needs to know the server's public key. In some dedicated applications the client already knows it (hardcoded in the client); but the normal method is for the server to send the key as an X.509 certificate. However, it is conceivable to use another kind of vessel for the server's key, for instance OpenPGP. There is even a RFC for that; GnuTLS is an SSL/TLS library that purportedly supports that usage.


How should developers handle Form POST variables that conflict with route variables?

Don't trust the URL... since POSTed data may hide what is really going on.

The URL should be treated as a client-side value and should not be trusted anyway. Anyone can easily alter the URL and could easily create a POST to any UserID.

Anyone who can guess the route variable names in ASP.NET MVC, can put unexpected data into a controller

This can happen anyway by parameter tampering. There are some useful pointers in this guide: http://msdn.microsoft.com/en-us/magazine/hh580736.aspx
Specifically

What Is It? Parameter tampering is an attack in which parameters are altered in order to change the application’s expected functionality. The parameters may be on a form, query string, cookies, database and so on. I’ll discuss attacks involving Web-based parameters.
How Is It Exploited? An attacker alters parameters to trick the application into performing an action it wasn’t intending. Suppose you save a user’s record by reading her user ID from the query string. Is this safe? No. An attacker can tamper with a URL in your application

In MVC this can happen via Model Binding:

Model binding is a great feature of Model-View-Controller (MVC) that helps with parameter checks as the properties on the Order object will automatically be populated and converted to their defined types based on the form information. ... Just be careful to limit what properties you allow to be populated and, again, don’t trust the page data for important items. ...
Note that I use the [Bind(Exclude)] attribute here to limit what MVC is binding into my Model in order to control what I do or don’t trust. This ensures the UserId won’t come from the form data and thus can’t be tampered with.

So you should also be careful that form parameters that don't exist in your view cannot be tampered and added by a malicious user. You would do this by adding the Exclude attribute:
public ActionResult Edit([Bind(Exclude="UserId")] Order order)

Is this behavior consistent across other MVC frameworks (Rails etc)?

Not sure, but I don't see it as a flaw as permission checks should be made on POSTs as well as your GETs. You application should not assume that a URL that has been POSTed to has permission to do this just because that of the false assertion that the URL with the form on must have been loaded first.

What are some ways to guard against this type of unexpected results? Should every POST be cross checked with URL parameters?

You code should just decide to take either the route variable or the POST variable (if it's provided to you from MVC as a method variable named UserID then why not use that, it doesn't matter if it was from POST data or the URL as long as you are consistent), and then make all logic decisions based on that. This includes the initial authorisation and also the processing and business logic - they should all use the same origin of the value to make sure actions are only carried out when authorised.


Can I add a new user to an unencrypted Windows installation from a Windows installation disk?

Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore. (https://technet.microsoft.com/en-us/library/hh278941.aspx)

This is definitely a realistic threat. The question is whether you need to worry about it. If you can't guarantee that someone will not have unfettered access to your PC then you should be concerned and mitigate. This is likely the normal scenario.

If the PC is in a secure location where people don't have access to it, then it might not be necessary to worry about it.


Can I secure a server on which I'm deliberately allowing code execution?

Since you are already running in a virtual environment, the simplest way would be to give each user a separate, small, environment to work with. If your operations team are any good, they will be using standard templates and/or scripting to create and tear down virtual environments in any case so this should be simple.

If you were using a Linux server, the easiest approach would be virtualisation via Docker.


When given a SSL-Private-Key, how would one generate a valid SSL-Cert from this?

Web sites hand out the public certificate, that's the way TLS authentication (identity) works (excepting aNULL ciphers). If, for example, you were able to use Heartbleed to steal a site's key, the required certificate would already have been given out by the server during the handshake (for every correctly set up TLS connection).

No creation of a certificate is required. Were it required or desired, then a CSR can be generated from the key material. Then that CSR could be signed by a commercial CA, your last line of defence is the weakest verification policy of the most lenient CA. Not very comforting ;-)

Clients which implement certificate pinning should not, in theory, fall for such a bogus certificate.

You could also sign it with your own private CA, the resulting certificate would be valid in a technical sense, just not accepted by clients (which verify CA chains, and won't recognise your private one).


It's an IP address in octal format, followed by an arbitrary path, which happens to be formed of elements that look like query parameters.

You can generate octal representations of IP addresses using various online tools: 0xD83AD60E should link to Google at 216.58.214.14. They're not inherently malicious, but the fact that you received it from a spammer suggests that there is a reason they wanted you to follow it, and the page it loads may well attempt to install malware. Since you did follow it, you may already be infected, in fact.

Links don't (generally) infect computers, but the pages they link to may well do. Never follow links sent by spammers - at the very least, you verify that your email address works. At worst, you end up infected with cryptoware and lose your data.


A larger output length makes it stronger, up to a certain point which is already reached, by a large margin, when you have a 128-bit output. Enlarging it any further does not change security.

Details: barring any structural weakness, the security of a hash function depends on its resistance to generic attacks (aka "luck": attacker tries random inputs until a match is found), and that resistance depends on the hash output size. For a hash function with an output of n bits, it takes effort 2n for the attacker to find a preimage (i.e. some password, not necessarily the "real" one, which matches the output). Efforts beyond about 280 are too far away into the technologically infeasible to be envisioned by an attacker. At 128 bits, you already have a 248 margin, i.e. a factor of almost 300 thousands of billions over that which was already overly expensive. It would be like boasting about reimbursing the US national debt while not having more than 0.01$ in cash.

Larger output size also help against collisions; there again, the generic luck-based attacks have cost 2n/2 (and there you see why SHA-1 has a 160-bit output: to make the collision cost of 280 unreachable). However, collisions are not an issue for password hashing. The ability to compute collisions does not give any advantage to the attacker. It so happens that collisions are also infeasible with usual hash functions, but if they were feasible it would not be that much a problem.

The real weakness in password hashing is not the hashing; it is the password. Or, more accurately, the human mind behind the password. Successful attacks on hashed password are attacks which try potential passwords, not attacks which work on the hash function structural weaknesses, if any. Mitigations include slow hashing and salting, which is what PBKDF2 does.

You can store only 80 bits or so of PBKDF2 output (and the salt); things will still be safe. (For purely aesthetic reasons, make it 128 bits: these computer people, they just love powers of two.)


Why don't ISPs filter on source address to prevent spoofing?

One of the main issues is with fast switching at the core routing level. A long time ago when I was a Cisco Engineer, the cisco core routers could fast switch very effectively and provide minimal latency, but if you wanted to source filter then this would turn off fast switching and add hugely to the latency - No ISP is going to be willing to have multiple seconds of latency when they like small numbers in the millisecond region.

One of the other issues can be around encapsulation. For example, if you are using an MPLS routed networks then you were unable to see inside of the packet to conduct source filtering.


How to check for cross-domain referrer leakage?

Your browser will add the HTTP Referer header (which, in a sense, indicates the "originating" URL) to most resource requests originating from a web page (exceptions include loading HTTP content from an HTTPS website, and refreshes).

Thus, the simplest way to automate testing is to crawl/spider/monkey your web application and log all requests to other websites. Then collect all the HTTP Referers and see if there is any sensitive information being disclosed.

What you should be looking for is any sensitive data in the GET parameter of these referers (e.g. session IDs, account numbers etc.). This is a bad practice anywhere, and not just because it allows cross-domain referrer leakage, since this means that users browser histories and shared URLs are tied directly to their session/account. I've heard about this being reported generally for things like password reset (on edx and on Mozilla), where the URL allowed social media plugins to initiate "reset password", effectively giving their owners the ability to take over accounts.

Simply avoid having sensitive data in GET fields, perform all actions using POST, and use a good one-time-token for generating links to critical actions.


Help me understand the relationship between GPG public keys, sub-keys and expiration dates

The Primary Key

The OpenPGP primary key holds your trust. If your key gets certified, those certifications will be issued on tuples of primary key and user ID. Outgoing certifications (on other keys) are also exclusively issued by your primary key. User IDs and subkeys are all coupled to a primary key. All in all, your primary key is the entity the glues everything together.

What capabilities your primary key has depends on the algorithm chosen and what capabilities are actually enabled (you can change this when running GnuPG in the --expert mode). All primary keys must have the certification capability C, but can have signature capability S (which must always be supported, as certifications are also signatures) and finally encryption capability E (which is not supported by all algorithms that fit a primary key, for example DSA can only be used for certifications/signatures, not for encryption).

Subkeys

  What I don't understand at this point is what happens in case my sub-key expired, but the public key is still present and valid. Will gpg fall back to use the public key to encrypt and validate data?

Which subkey is chosen is implementation dependent, usually they will choose the newest non-revoked key capable of what you want to perform. If you add another subkey, this will be chosen. If you remove all subkeys, the primary key will be used -- given it has the necessary capability bits set. If the primary key does not support the required capability, the key cannot be used at all!

In GnuPG, you can enforce a specific subkey: by specifying the key ID followed by !. For example, if you want to enforce usage of subkey DEADBEEFDEADBEEF as a recipient, use the option --recipient DEADBEEFDEAEDBEEF!.

Subkeys can be arbitrarily revoked and regenerated without losing reputation in the web of trust.

  I'm also not really sure about the exact role of the public key in case of the existence of sub-keys. My guess is that it's only used to validate the sub-keys before they are used to actually encrypt/validate, is that correct?

This is not necessary, but considered best practice. Lots of people even keep the primary (secret) key offline.

Expiration Dates

  Does it still make sense to use an expiration date for the public key in case all sub-keys have an expiration date set?

Expiration dates are a reasonable thing to use on subkeys, as they require the sending party to update your key after a given time. They can be changed arbitrarily, though. This is also the reason why expiration dates on primary keys are not a reasonable thing to use; if the attacker gets hold of your primary key, he can simply change or even completely remove it, even if your key already expired! See "Does OpenPGP key expiration add to security?" for a more in-depth discussion.

Instead, have a pre-generated revocation certificate at hand (and in your backup).

  However, what I want to do is to set an expiration date on the public key as well, while keeping the secret key non-expiring. How can I do this?

I think you're confusing public  and primary here. The expiration date is always set on a public, special "configuration" signature on your primary public key, but issued by your primary secret key (so it can be verified through the public primary key). If you really want to specify an expiration date on your primary key, you can still change it at any time anyway, the old expiration date is simply overwritten.

But as discussed above, an expiration date on primary keys is providing false security, anyway.


Is Steganography a safe method to store secret data?

NO, it isn't safe at all and steganography is not encryption!

Encryption means that the method is known, but that's not a problem, the data can't be decrypted without a key. Bad luck for interceptors when a strong method and a strong key have been used. The message is useless for them.

Steganography means hiding data in other data and it relies on the method used to hide the data being unknown to interceptors! It isn't encryption at all, but it can be combined with encryption. Simple/public domain steganography techniques can be detected quite easily, if the interceptor expects a hidden message.

Pure steganography (just the hiding process) is security by obscurity, which is a bad practice. However, sometimes the combination of steganography and cryptography can be desirable, for example when you don't want anyone to know that a secret message has been sent at all. Interceptors won't be able to prove it, when they can't break the encryption.


To briefly answer your question, in order for a Federated Identity Management to work a trust must exist between SPs and IdPs.

Federated Identity Management separates account management from the service itself. Identity Providers (IdPs) act as the source of identity and account information for a user. That information can then be re-used across all services so that a user only has to remember one account name and password and SPs no longer need to spend time on account management. As I said, the SPs and IdPs have to trust each other for this approach to work. Typically this trust is made explicit by signing policies and contracts that describe the requirements and responsibilities of the IdPs and SPs. An Identity Federation is a collection of IdPs and SPs that have agreed to work together and trust each other.

Next to the trust, policies and contracts there needs to be agreement on how to communicate (identity information) between IdPs and SPs. Almost all Federated Identity Management Systems currently use the SAML2.0 protocol (Security Assertion Markup Language v2.0) to achieve this. An overview of a SAML login flow is shown below.

Note: You should stop using the term Federation as it implies something completely unrelated and can be miss-leading.


You could use an encrypted token consisting on a prime number and an expiration date. For encrypting the token just use a symmetric algorithm such as AES.
You would need to keep track of

The difference between the number of tokens generated and the number of tokens validated, d
The last prime number generated, p
The product of all primes generated, t

To generate a token

Increase d
Calculate the next prime p and return that (this can be done efficiently).

To validate a token

Check that the token has not expired
Check that t is not divisible by the prime number

If the token validates

Multiply t by that prime number
Decrease d

This way, you automatically invalidate the token so it cannot be used anymore (next time you try to validate that prime, t will be divisible by it so it will return false).
Every time the number of tokens validated equals the number of tokens generated (d=0), you can also reinitialize all the variables (p=1,t=1) so that the size of t does not grow indefinitely.


Why use PBKDF2 over multiple iterations of a another cryptographic hash function?

Don't roll your own crypto. Generally, if you are directly calling (as opposed to specifying the name of) some crypto primitive (SHA-512, AES, etc), then you are violating this rule. If you think crypto implementation bugs are not hard to avoid, I suggest you give Matasano's crypto challenges a try.
Fewer lines of your code. This means fewer chances of you messing something up. It also means cleaner, more maintainable code.
Configurable iteration counts. Sure you could change the iteration variable in your code, but what about all the hashes you already have lying around? A library implementing PBKDF2 will have a built-in way to store and retrieve the iteration count for each hash.
Avoid RNG bugs. Your code makes a call to random(), but most languages' built-in PRNGs are not crypto-safe. Get a library that does salt generation for you, and you avoid the extra hassle and possible bugs.
Portability. Need to upgrade or change your backend? You can probably just copy (database export/import) your users' records and old hashes into the new framework. Otherwise you have to rewrite your custom hashing algorithm for the new framework, running into implementation differences:

Is the output of sha512 raw bytes or hex?
What character encoding did you use for passwords?
Is salt a string or a number, and how does it get converted into bytes for the input to sha512?


If you are trying to learn, then asking for others to answer the question for you seems counter-productive.

Check out cheatsheets and other material to work through it all.


HTTP Status Codes - security considerations

I think RFC 2616 is quite clear:

  10.4.4 403 Forbidden

  The server understood the request, but is refusing to fulfill it.
  Authorization will not help and the request SHOULD NOT be repeated.
  If the request method was not HEAD and the server wishes to make
  public why the request has not been fulfilled, it SHOULD describe the
  reason for the refusal in the entity.  If the server does not wish to
  make this information available to the client, the status code 404
  (Not Found) can be used instead.

So really it's up to you if you would like to add additional information (the "reason for the refusal") if the request was made by an administrator.

But really, isn't your administrator unauthorized to view the requested resource? I think that's the case, and if I'm right, the response should definitely be 401 Unauthorized.

From 10.4.2. 401 Unauthorized:

  [...] If request already included Authorization credentials, then the 401
  response indicates that authorization has been refused for those
  credentials. [...]


Why are passwords sent unhashed by most modern websites?

Your question boils down to

  why do passwords get sent in clear text over an encrypted channel and are not hashed on the client before submission?

The answer is: if the client is compromised to compromise the TLS session, it does not matter - the password is typed in and can be keylogged.

Additionally, hashing on the client side just makes the hash value effectively your new password being send - again - in clear text over the encrypted connection.


Is encrypting a salt value with a password/plaintext a viable alternative to straight up hashing?

I don't see what problem you're solving. Imagine what will happen if your database gets compromised. The attacker will have this encrypted string, salt, and (likely) the encryption key.

What keeps them from decrypting any user's salt or password, and having the password?

It's pretty hard to invent something that will be more secure than algorithms developed by professionals and have been "battle-tested" for many years (namely, bcrypt).


What if the attacker tamper the IV used in the block cipher CBC mode?

AES-CBC only insures confidentiality, not integrity or authenticity.

If you look at the image down below, you can see how the Cipher Block Chaining Mode works for AES:

Source: Wikimedia Commons

For now, let's ignore all the other blocks of data, padding, etc., and just focus on the first block of data. The ciphertext is decrypted with the key, and then XOR'd with the IV.

Since the attacker can freely modify the IV, the changes to the IV are directly, bit-for-bit, reflected in the decrypted text. This property is called Malleability. In fact, all the blocks are malleable, since you can modify any block of choice and it'll be XOR'd into the result of the next block. Yes, you will "lose" one block, but depending on how the data is structured, that may be okay.

Isn't this really dangerous?

Yes, which is why AES-CBC must be used in combination with a primitive that guarantees integrity and authenticity. That means, if either the IV or the Ciphertext are modified, the decryption will fail.

Or, you can use Authenticated Encryption, such as AES-GCM, which will do all of this for you.


How to check/test security issues of freeware?

Almost the same thing as what can be done for paid softwares: examine the reputation of the vendor/software, and evaluate the risk in adding it to white list against the cost of forbidding it.

For example, Postfix, OpenBSD, Spring framework or LibreOffice are all freewares with an excellent reputation, even better that many commercial tools. The risk of using them is very low. But if your white list already contains concurrent softwares (equivalent features) adding them to the white list with no real reason will only add more work in maintaining the list of valid versions - said differently it would not be different than what you should do for IDEA, Windows or Microsoft Outlook.

On the other hand, you can find freewares with little reputation, simple because few people use them. The first question to ask is whether they are correctly maintained. If serious bugs have been pending for a long time it is a hint that you should avoid it... But it is the same for niche commercial softwares.

The last point that can be done is an audit of the code. I gave it last despite it being IMHO what can give the most information on the quality and security of the software. But it is very expensive in time or money, the reason why I would be reluctant to use it. But if you want touse a little known freeware for a mission critical operation, you should considere that.

For your last question, I would not trust tools nor any single website for assessing the security of a software. Of course if an anti-malware chokes on it you should keep away, but finding no viruses is not a sufficient condition. For websites, I try to find converging hints to establish a reputation. And I also try to use the reputation of the site or the author. For example when a high rep user from Information Security says something, I trust that much more that what I can find on my ISP forums :-) . But we are close to fuzzy logic at that point.


Is phone-based authentication more secure than passwords?

Password is something that a user would know, but not necessarily expose. The phone is something that you keep close to you, but it is regularly exposed, sometimes left unsupervised, periodically non-operational.

Knowledge can be hijacked\captured when you type it and send your credentials over the network.

Phone can be snapped from you in public transport or on the street, etc... It can drain it's battery deny you logon ability. Network coverage can vanish and leave you helpless.

Changing a password is usually a trivial task, what about the phone?
I go abroad and I might be using a diffrent phone there, not an everyday problem, but that just adds a little bit more complexity.

I can see how phone is a less reliable option with more external risks and dependency. I also assume your users would be people with different kinds of phones, carriers and habits, potentially introducing even more scenarios where the phone would hinder their ability to be authenticated by your service.


Security by obscurity is bad. While developing it act as if the login form was displayed to every user of your website.
Remember to create the "Remember me" function in a way that does not store e.g. the password in a cookie. One choice would be having a random and unique login hash stored for the user. You then save the user id and this hash in a cookie. This prevents the password from being saved in a cookie and you can provide a "log out everywhere"-style button that simply changes the hash in the database and thus invalidates all "remember me" cookies.
While also somewhat of security-by-obscurity you could simply return a 404 error in this case. No need for people to know that something exists even though they do not have access to it.
Brute force attacks might be carried out by botnets so an IP filter alone is indeed not much help. So restricting the number of login attempts by account is the only valid choice. However, you can do this in a very user-friendly way by allowing 1-3 attempts without any captcha etc. and then require a captcha on every additional attempt. Of course locking the whole account for some time would be even better but then people could DoS your legit users.
That captcha will not interfer with "remember me" - the restrictions would only apply to the Username+Password login but not to the cookie login. That's not an issue since you can simply use 40+ character hashes for this purpose and you can safely assume that those won't be cracked using brute-force.

Since you just have a few users you might want to consider using SSL client certificates for authentication in case those users are not likely to login from random machines. They'd install the client certificate/key in their browser and then simply select it when logging in - no need for a username/password anymore. And SSL is secure enough so you don't have to worry about brute-force attacks for now. However if your users are stupid enough they might export the key without encryption and store that unencrypted file on their PC. But then again, this kind of user would also have a passwords.txt file on their desktop...


Do I put my subordinate (intermediate) or root CA certificate in my truststore?

Generally speaking, you should be putting the root cert in stuff. The model generally works like this:

Clients

Have the root cert "pinned" (ie embedded in trust store).

Whevever they validate a cert, it needs to trace back to some cert in their trust store, the number of intermediate certs between the end-cert and the pinned cert should be irrelevant, so there's no reason not to pin a root cert - at least from the client's perspective.

Certificate Authorities

What to do in the case of the CA key being compromised is a big concern for people who run CAs. To make the cleanup easier in the case of something bad, people usually use an "offline root":

Have your root CA sign some subordinate CAs, then unplug the root CA (if the CA is a dedicated physical server), or hide the root private key on a well-protected backup disk and make sure there are no copies floating around. This makes it very hard for hackers to steal the private key.
Do your day-to-day cert issuance, CRL publishing / OCSP, etc off the intermediates. They are connected to the internet and therefore at higher risk of compromise.
In the case of compromise of an intermediate CA, you can fire up your root CA, revoke that intermediate, bring up a brand new intermediate and re-issue all of the legitimate certs that got incidentally revoked.
Servers that were using certs signed by that intermediate will have to install the newly-issued cert since their old ones are now revoked.
Clients will be completely unaffected since they have pinned the root cert, so swapping around the intermediates has absolutely no effect.

As a though-experiment, compare the above to what you would have to do if your root CA key gets compromised. Since it can take months to years for a root to get embedded in the public browsers, vpn clients, other servers, etc it probably means the CA will go out of business.

Advantages of pinning a root, vs pinning an intermediate:

The example above illustrates that pinning the root makes it MUCH easier to cleanup from a compromise because you can simply revoke the compromised intermediate, re-issue some certs and move on with your life.
There are fewer certs in your trust store. If everybody had to pin every intermediate, everybody's trust stores would be much larger to the point where it could impact the performance of cert validation since searching the trust store would take longer.
Load-balancing: by pinning the root you're free to re-arrange the topology of your intermediates, or even put them behind a load-balancer for handling cert requests and the clients won't care.


The second test is easily defeated because the user knows the original image.  A bot could easily compare the selected words against the original image and determine which is the best match.  In fact, they could submit an image which is intentionally easy for a computer to detect, such as installing a digital watermark or other stenographic content into the image.

The first test is interesting but has some oddities to it:

You presume everyone can read eachother's handwriting.  Good luck reading mine!
You presume it is safe to send user generated content from one person to another (there are some images that many users would like to not see)

In all, the first part reminds me a lot of the CAPTCHA which had users writing phrases from books out of Google Books archives, which doubled as a service for digitizing otherwise hard-to-transcribe books.

In all, the only fail-safe way to determine if someone is a human is face to face contact, and even that is drawn into question as computers get more powerful.


Callback Detectors: Connection to High Confidence C&C Server IP Detected

The IPS sensor seems to believe that 173.224.123.242 is a C&C server (this information is taken from McAfee itself, which analyzes the server to determine if it is malicious or not).

A C&C would be a server that has been compromised and manages a botnet, for example. This is not a good sign.

If this signature is showing up always for the same internal host, disconnect it from the network immediately and determine if it has been compromised or not (run an up to date AV, check the processes that are active, etc.). If the external IP belongs to your company, this may indicate a false-positive. Then, make sure the server is really OK and create a filter to ignore this alert in the future.

Hope it helps! :)


Wireshark DNS sniffing : too much junk -> Are there hostname "blacklists" for wireshark?

The list of advertising tools, web tracking, etc. is infinite and changes daily so you could try to use a list like others have provided but it's not a scaleable or reasonable solution. Instead perhaps use the statistics features in wireshark or export and do some analysis to see abnormalities like the nosiest dns entry or the quiet ones or the largest packets or the hosts with changing ip addresses , etc


We use an anomaly based detection engine. There is definitely a high false positive rate and the learning phase can take up a lot of time. In my experience, an IDS that is OS and application aware is still a better option. While we have found some interesting things, it is not useful unless you have the staff to maintain it and sift through all of the false positives. I would say they are coming along but are not for everyone.


How can I identify precisely the exact number of bytes the ClientHello and ServerHello in a TLS traffic needs?

The size of the ClientHello varies. Parts of it depend on a specific client TLS implementation or configuration, especially the number of ciphers offered by the client and the extensions. Then there are use case specific differences: for example the client might add ALPN extension to signal support for HTTP/2 in case of a web client. The size of the server_name extension depends on the size of target hostname. And then there might be additionally a session id or session ticket if the client tries to resume an existing session. Only if all these variations are known you can compute the size of the ClientHello simply be filling in the necessary parts in the ClientHello structure.

The ServerHello itself is similar variable size and depends mainly on the kind of extensions added. But, after the ServerHello  you get additional variable parts until the ServerHelloDone message, like the certificates (which can differ in both number and size), key exchange specific parts and an optional variable-sized CertificateRequest. Similar, only if all of this is known you can compute site size of it.

If you instead just want to get some statistics about this you might do a packet capture of your favorite use case, extract the relevant parts and measure their size (or look at the length fields as RoraZ suggested). Note that any conclusions you draw from this only apply to the use case and context you've measured. It can be wildly different if other clients or other servers are used or even if the same clients or servers are used but the hostname and certificates differ.

If you've already captured traffic then getting the size of each record is simple since all records follow the same structure described in RFC 5246 section 6.2 Record Layer: first is the ContentType (one byte - 0x16 for records in the TLS handshake), then the protocol version (two bytes) and then you have the length of the remaining data (uint16, i.e. two bytes).


OpenVPN relies on SSL/TLS for establishing the session secret values, with certificates on both client and server (this is documented here). To do a successful Man-in-the-Middle attack, the attacker must impersonate both the client and the server: the attacker must pose as a fake client, when talking to the server, and as a fake server, when talking to the client.

If the attacker stole the client private key, then he can impersonate the client, but this does not give him the power to impersonate the server.

Moreover, since the client-side key in SSL/TLS is used only for a signature, but is not used to actually impact the generation of the secret key used thereafter to encrypt the data, knowing the client private key does not give to the attacker the power to decrypt exchanges between the client and the server (the same would not necessarily be true if the attacker had stolen the server's private key, not the client's -- depending on whether the SSL/TLS layer negotiates a "DHE" or a "plain RSA" cipher suite).

Summary: to the best of our current knowledge (and assuming that OpenVPN's protocol, beyond SSL, is not weak in some way), an attacker who stole the private key (.p12 file with password) of a client can only impersonate that client, but not run a full MitM, or impersonate the server, or eavesdrop on exchanges between the client and the server.


How to modify the hex code in the exploit to meet my requirements?


Real-world applications of Differential Privacy?

Here is an article from Scientific American at the end of 2012 mentioning one real-world example-- 'OnTheMap' and references research into others:

http://www.scientificamerican.com/article/privacy-by-the-numbers-a-new-approach-to-safeguarding-data/

"One real-world application already uses differential privacy: a Census Bureau project called OnTheMap, which gives researchers access to agency data. Also, differential privacy researchers have fielded preliminary inquiries from Facebook and the federally funded iDASH center at the University of California, San Diego, whose mandate in large part is to find ways for researchers to share biomedical data without compromising privacy."


What are the heuristic detection techniques most often used in modern AVs?

According to Malwarebytes:

  ...if an application is programmed to remove important system files, the anti-malware software may flag it as malware (since applications should not be doing that). But, heuristic analysis can sometimes result in “false positives,” or programs flagged as malware that are actually legitimate.
  https://blog.malwarebytes.com/101/2015/12/how-does-anti-malware-work/

Most modern heuristic detection is a flag-and-score system. Basically each program scanned will get a score based on how shady it is, these scores are obtained by counting the amount of 'flags' a program gets. Flags are activities monitored and reported by the anti-virus when it attaches itself to a process. These are usually renegade activities such as modifying or deleting system files in the background, escalating privileges without user input, or downloading data from a remote server without displaying UI. After a scan is complete, these flag scores can be averaged to find how far away from normal some program's activity could be. After a certain threshold in the bell-curve, it is considered too mysterious to be normal and detected as a virus or PUP.

There are different approach between products, all with trade-offs, but all end in the same result:

System emulation, flag shady activity. (some malware can detect virtualization)
Scan binary, flag byte-marks associated with shady activity. (can give off false positives to similar less-shady logic)
Attach to running agent, flag shady activity in real-time. (debug-traps can halt detection)
Decomiple/reverse-engineer, flag shady code. (Code obfuscators can throw off results)


Is it possible to invoke OS commands from a NASL script in OpenVAS?

There is the NASL function pread which allows you to run external commands from within a NASL script. An example to run cat and get its output could be:

args = make_list( "cat", # The cmd which is called, needs to be in cmd as well
                  "/etc/passwd" );
ret = pread( cmd:"cat",  # The command to run
             argv:args,  # The arguments list of above
             cd:FALSE ); # This specifies if a `cd` to the directory of the `cmd`should be done

A "full" example with various code path (e.g. checking if the command exists before running it) can be found in e.g. nikto.nasl (http://plugins.openvas.org/nasl.php?oid=14260)


How is the QSS tag used as payload in an XSS attack?

This appears to be a tag inserted by Qualys WAS (Web Application Scanning) engine.

<qss> tags are inserted as input in order to test whether these are encoded correctly as output.

This approach is safer on a live system that testing using <script> tags, which may have unintended consequences as a result of the scan becase the <qss> tags will be ignored by any browser.


Does reverse proxy between two web servers impact security of both?

Yes, there are possible issues. For instance, consider the Same-Origin Policy: this is one of the foundations of how Web sites are contained and don't attack each other. For instance, Javascript from a site can talk (send "POST" requests) only to the originating site. This prevents some evil Javascript from some site from siphoning your bank account by sending hidden request to your bank Web site. However, when server A reverse-proxies B, then everything seems to come from A, from the browser point of view. If B is hacked into, then it may send hostile Javascript which will run in the client browser as if it came from A, thus being able to send arbitrary commands to the rest of the site on A.

However, yes, some issues associated with WordPress are mitigated by the separation; namely, that if the machine B is hijacked, then A is not hijacked right away. As explained above, you are still in deep trouble, but not as deep as you would be if both machines had been the same. "Mitigation" might not be the right term; let's call it "partial damage reduction".

If you want a separation which is effective in the security model as implemented by browsers, then you should separate servers under two distinct domains. For instance, there is security.stackexchange.com and security.blogoverflow.com: that's what you should aim at. Reverse-proxying a vulnerable site is really looking for trouble.


Is there a secure way to share sessions in the same server with different sub domains?

An application should rely upon the platform's session handler. Rolling your own session handler is dangerous.

A cookie can be scoped to the parent domain and used by every sub-domain. In PHP this can be done with session_set_cookie_params() to change the scope the domain to *.example.com.  Then use session_start() normally.

XSS on any subdomain may compromise the session id.  Make sure to enable the Secure and HTTPOnly cookie flags.  This will ensure that HTTPS will be used with the session id for all requests, and limit the impact of XSS.

Additionally,  generating a session id using the following method is insecure:

$id = md5($userip . $salt .  $userbrowseragent  . $sessionname);

Never attempt to roll your own random number generator. A session id must be a cryptographic nonce generated with a cryptographically secure pseudo-random number generator (CSPRNG).  The hash function md5 must never be used in a security context,  it has been broken since 2005.  Even if a secure hash function were used, the attacker will knows the $userip, $userbrowseragent and the $sessionname,  which means they could bruteforce the $salt value offline.


Is my private SSH key compromised if someone hacks my Wi-Fi?

Getting your private key would require that someone has the ability to read data off of your computer. If they're on your wifi it makes it significantly more likely that they can get this information but it still requires that there is some sort of vulnerability that allows them to get at the data on your harddisk (assuming you don't just start sending your private key over the network for any reason).

Common problems might be having a share on your computer you might've forgotten about or unpatched software + bad firewall configuration that would allow them to perform some sort of read operation via a previously known vulnerability (think: old IIS and directory traversal).

Another attack vector to look at is if they are on your network, they have the ability to influence the traffic going to your machine. DNS Spoofing a website on your local network and then tricking you into downloading some sort of malicious application would be another route they could take.

Tl;dr: Just because they're on your network does not explicitly mean they can read the private key but it opens up a lot of different attack vectors that may not have been possible before making it more likely that they could get to your private key.


Why CAs instead of global fingerprint database?

This is in fact two questions: why use CAs instead of a global fingerprint database, and why use CAs instead of doing what SSH does. There's no global fingerprint database for SSH, it's in fact the very opposite.

In the SSH model, there's no built-in way to obtain the fingerprint of a server other than by connecting to it. The usual model for security is that when you connect to a server for the first time from a given client, you are prompted to manually verify the fingerprint, and when you connect again, the client verifies that the fingerprint hasn't changed. A common case where this model just works is when the client is on a laptop and you perform the first connection from inside the same trusted network that contains the server. Other than that, you are supposed to verify the fingerprint out of band, but most users just type “yes”. This system doesn't really scale; it's workable when you only connect to a handful of new hosts per year, but not for something like the web where you might connect to several new HTTPS sites every day.

If there was a global fingerprint database, then it would for all intents and purpose be a universal CA. The definition of a CA is that you trust it when it tells you that a certain public key K belongs to a certain entity E. In the SSL protocol, a CA tells you this by providing a certificate that contains a cryptographic assertion that K is the public key of E. A fingerprint database, where you look up E and get K or vice versa, is a different implementation of a trust relationship assertion. So with a global fingerprint database, we'd have an even bigger “too big to fail” database.

An approach that avoids the “too big to fail” problem is the web of trust as used by PGP. The principle is that you know that K is the key of E because someone you know tells you so. This approach is reasonably well-suited to applications such as email, because many emails are sent between people who have a prior existing relationship, or who have common friends. It isn't applicable in a case like “I want to connect to this merchant's website”, where you'd never heard of this merchant before seeing a link to it on a price comparison site, but you want to know that the website belongs to a corporate entity that has been doing business for several years, and not to some drive-by scammer who'll take your money and be gone next week.

Having a single CA would raise concerns other than the risk to the integrity of the trust relationship database. When an entity registers a key, the CA is supposed to verify that the registrant has a valid claim to its purported identity (that the user registering a key for "Joe Bloggs" is really called Joe Bloggs, that the registrant for "Yoyodine, Inc." is indeed an authorized officer of Yoyodine, …), so the registrant cannot have privacy with respect to the CA. A choice of CA means that registrants have a choice of who they submit their private identity to. A state-run CA would be in a good place there because it knows the registrant's identity already — but which state? People may well want to declare identities that are not known to the state they live in. Another concern with a single CA is that it would have a monopoly on registration; having many CAs means that an entity is unlikely to be barred from participating.

A way to reduce the impact of a failure of a CA would be to routinely have keys certified by multiple CAs. This is something people often do in PGP-style web of trusts: I want to verify Alice's key, so I ask Bob, who tells me that the key is correct. But while I'm sure that it's Bob telling me this because I've verified his key, I don't completely trust Bob to have verified Alice's identity. So I also ask Carol, and Dan, and so on. With many converging presumptions, I get a better assurance that Alice is who she claims to be. In the same way, having a website's key certified by multiple CAs, and not revoked by any, would reduce the concerns that one of these CAs may have been compromised or may have been lax in verifying the registrant's identity. However, this would require updates to a lot of software that verifies SSL certificates and increase the cost of key registration.


Password sharing with spouse or mate (bulk-change shared passwords (via cloud service))?

Services such as LastPass have an auto change password feature.

However, this has to be done per site.

The solution of bulk updating everything is to a problem that should not exist in the first place. i.e. Passwords should not be shared between applications. Each service should have a unique, strong password of its own. Otherwise if one service gets compromised and the password is found, the rest go with it.

The idea of using a password manager is to have a strong but memorable password for the master password, and for each site it protects they have a totally random, unmemorable, strong password (e.g. 20 completely random characters). If you wanted to share account details with a trusted partner, then some password managers have functionality to allow this. The account owner would just have to unshare these accounts in the event of breakup before changing the password.


If he connects from his computer to the VPN, the company can't see what is happening within the VPN connection unless they have monitoring software on his computer (which for some types of VPN clients, may include simply having their own trusted certificate to allow MITM attacks).  Only his computer has access to the details of the encryption for the VPN tunnel.  The company would possibly be able to tell that an encrypted connection was being used though.


Short and simple answer: You can't.  HTTP headers are sent by the user agent on behalf of the user, and cannot be hidden from the user.
So in a case like this, it's probably better to "proxy" the call to the 3rd party through your own API and rely on the authentication you use for your own users.


Why does VirusTotal have two different reports for the same hash depending on FILE vs URL submission?

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

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


Could I XSS a page that filters &,", characters and has Content-Type set to UTF-8?

The OWASP XSS Experimental Minimal Encoding Rules suggest that all that needs to be encoded are <, & and >, as long as the charset is specified.

Assuming the second page outputs within an HTML context, then there doesn't seem to be an XSS attack vector in this case.

Setting charset and then encoding your POST will simply mean that the server will interpret it as such, converting any text into its own internal representation (assuming no flaws exist in the technology stack the site is using and everything is doing its job properly). So when it is output, the characters will be encoded again meaning your attack fails.


Can a hacker, that knows my IP address, remotely access accounts I have left logged in on my computer?

No, they would have to have access to your browser cookies in order to abuse them to log into a site you left logged in. Merely knowing your public IP address would not allow them to log into any website. If you are asking this question though, I would not be so sure that there are "immense barriers" between them and your personal computer. A good hacker can do a lot more than you may think.

In theory, a vulnerability in your router could be exploited which typically requires knowing your IP address, but there are dozens of ways to get your IP address anyway. Not to mention, the IPv4 space is small enough that a decent server can scan every single possible IP address in under a day (only 232, or 4,294,967,296 in total, including a large number of reserved or invalid ones). It is more likely that an attacker would exploit a vulnerability in, say, your browser than your router through your IP address. That is not to say that vulnerabilities in routers are uncommon, but the risk of an infection or compromise through some vulnerable or out of date program is far greater.

IP addresses are not very dangerous when a malicious user knows them. This is somewhat of a myth caused by script kiddies (especially of the video gaming variety) who ominously proclaim that they have your IP address and you better watch out, often with the implication that knowledge of an IP address amounts to full access to a network. The worst common scenario is that a malicious user mounts a denial of service attack on your router, causing your network connection to slow down or break. This can be irritating, but is not particularly dangerous.

There are two real situations where your IP address is sensitive information:

If you are dealing with a bitter player for an online video game who you just beat (because that headshot totally didn't hit him) or a spiteful troll on IRC, they may mount a DoS attack against your network in vengeance. In this case, you may want to call your ISP. They may be able to change your IP address or protect you from the attack in order to restore your connection to the network. Even if that does not work, these types of attacks quickly subside. You should probably just avoid associating with the type of person who falls into this category.
If your adversary is a law enforcement agency or any other legally-privileged entity whose goal it is to tie your IP address to your real-life identity, you should be using an anonymity network such as Tor (for web browsing) or a VPN (for P2P). This is the case when your adversary is able to subpoena your ISP to obtain your subscription details. In the past, it was easy to social engineer ISPs to get this information (folks on IRC used to do this to get someone's real address), but nowadays it tends to take a legally-binding court order, in which case your ISP will barf up all the personal information it has on you without giving it a second thought.

If neither of those cases applies to you, you have nothing to worry about.


By default the ZAP spiders do submit forms, although you can turn this off for the traditional spider. Likewise the active scanner will by default attack both GET and POST requests, but again this is configurable.
Why it didnt in this case is another matter, and would require more investigations. The ZAP User Group might be a better forum to help investigate this: https://groups.google.com/group/zaproxy-users


Cross-certification between worlds like X.509 and PGP?

The trust systems of OpenPGP (web of trust) and X.509 (hierarchical) are not compatible, nor are the signatures (the "math behind" both of them in respect to the keys indeed would be, as long as the algorithms are defined for both, for example with RSA).

While you could easily map the hierarchical X.509 trust system to the more powerful (and complex) OpenPGP web of trust, the other way round is not possible for a general solution. What would be possible indeed is generating trusted X.509 certificates for all validated OpenPGP keys.

This would require proprietary software (in the sense that there is no standard defining how to do this) on each client computer that wants to validate, I'm not aware of any solution for this.

What is available is the Monkeysphere Firefox Add-On for validating against OpenPGP certificates in HTTPs, which tries to bring OpenPGP to the web -- but is propietary (with the same definition as above) anyway, and I've never seen it being used in the wild.


You can instruct nmap to use a proxy, in this case you will want to use Burp as your proxy. More information here: https://nmap.org/book/ncat-man-proxy-options.html

edit:
this should work for you seamlesly:

--proxy 127.0.0.1:8080

Assuming 127.0.0.1 is the IP of your burp proxy and its port is 8080


Oauth2 PKCE - What security does "S256" provide over "plain"?

I can't read, apparently. The justification is described in the RFC itself:

A number of pre-conditions need to hold for this attack to work:

[...]

  4. Either one of the following condition is met:

      4a. The attacker (via the installed application) is able to
          observe only the responses from the authorization endpoint.
          When "code_challenge_method" value is "plain", only this
          attack is mitigated.

      4b. A more sophisticated attack scenario allows the attacker to
          observe requests (in addition to responses) to the
          authorization endpoint.  The attacker is, however, not able to
          act as a man in the middle.  This was caused by leaking http
          log information in the OS.  To mitigate this,
          "code_challenge_method" value must be set either to "S256" or
          a value defined by a cryptographically secure
          "code_challenge_method" extension.

plain is enough for the threat model described in my question, but S256 is indeed necessary for a more advanced threat model.

Now I am wondering: if the attacker can observe all responses, what is stopping the attacker from observing the final access token response?

Why does this threat model restrict request/response observation vulnerabilities only to the authorization endpoint?


Will this work? Revealing identity (facebook) of person who clicks specially crafted link

Contrary to the other answers, actually YES it is possible. However it is not actually so simple, and not exactly as you put it.

Instead of directing your victim to a profile, you can send him to your Facebook app. Of course, this app needs to be registered as a valid facebook app, and etc.
In the URL to your app, you can submit certain parameters - say, for example, the user's current session id on your own website.
Note that this URL is directed to Facebook, and thus your FB cookie will be sent, since it is FB's servers; they then forward the request to your app.
Your facebook app should be hosted on your own server, and this should be have some form of communication with your victimizing website, allowing a lookup between the Facebook identity and the session id.
Thus, you just used Facebook as an unintentional identity provider.
Using certain additional techniques, such as CSRF, you can send the user directly and automatically, simply by being on your site.
Note, however, that this is actually not as simple as it once was, and here is where social engineering would come into play: Facebook now requires explicit user approval before allowing an app access to your details.
On the other hand (and I admit I may be out of date on this - it is hard to keep up with Facebook's consistency) - there are some details that an app can recieve before even asking you to install it. (I'm not going in to all those technical details here, I think it's irrelevant at this point, and would probably be off topic. )

You can find more in depth details, including all the technical details, on this blog post from a few years ago; as I said, some of it may be out of date.
(Disclosure: I did assist in some of that research).


SSH works for root but not for other users?

Can you please explain how this is possible?

There are two valid configurations that will permit root to login using a password:

PermitRootLogin yes
PermitRootLogin without-password and ChallengeResponseAuthentication yes AND certain PAM configurations

I seem to remember the Ubuntu default is PermitRootLogin no but I believe that Linode, being a service that provides remote servers which only have a root account initially, have tweaked the default in their build to that their users can log right in without using lish or other remote console options (which can be a little kludgy to use).  I actually run a Ubuntu 16 Linode, but my sshd_config was modified right after installation, and that's one setting I always tweak, so I can't tell you how it shipped :)

To quote the sshd_config man page:

PermitRootLogin
    Specifies whether root can log in using ssh(1).  The argument
    must be ``yes'', ``prohibit-password'', ``without-password'',
    ``forced-commands-only'', or ``no''.  The default is ``no''.
    Note that if ChallengeResponseAuthentication is ``yes'', the root
    user may be allowed in with its password even if PermitRootLogin
    is set to ``without-password''.

    If this option is set to ``prohibit-password'' or
    ``without-password'', password and keyboard-interactive
    authentication are disabled for root.

To quote the sshd_config on my Ubuntu 16 system:

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

You may want to read How To Tune your SSH Daemon Configuration on a Linux VPS which, while it doesn't go into this particular issue, is a nice readable survey of what you can do to your sshd_config.


How to Minimize Apache Loadable Modules (serving MediaWiki)

Unless MediaWiki's documentation details which modules are required then there is no way to know other than by trial and error... as @Tom Leek suggested, disable them one by one.  This can be a little tedious and time consuming but will achieve your goal.  Some of the modules should be obvious though.  For example, if the system is not a proxy you don't need mod_proxy.  If you don't do any URL rewriting then you don't need mod_rewrite.

Hopefully the list of Apache modules with descriptions will help narrow the field more quickly.


Privacy & tracking concerns regarding Service Workers

No!
Service Workers also run in origin context, just as normal JavaScript. So, for a Service Worker registered for a domain cannot really interact with Service Worker registered for another domain. Furthermore, they do not have access to the DOM, unlike JavaScript.

And, as long as you visit a site, it doesn’t need SW to track your activities within that site (compared to your Threat Model). So, it really provides no advantages over tracking.

And about open question, it does no harm simply registering a SW as it has tremendous impact over performance and such. They do restrict it to HTTPS to avoid SW registered over MITM attacks, and as already mentioned in the comment, SW are disabled in Incognito mode.


Typical mistakes when implementing digital signatures?

Ok here is a good one that is not commonly mentioned as a digital signature security risk.

There is a technique  called blind signature. Which usually used for anonymous authentication like in anonymous P2P network, electronic voting, digital cash, etc.

Now, if the system use the same private key for regular digital signature and for blind digital signature there is a huge risk that an attacker can foul the system and cover data encrypted by the server public key.
See Blind Signature for more details.

Of course, the solution is to use different private keys, one for regular digital signature and one for blind signature


Security hole when bridging OpenVPN tap interface with the same ethernet interface used to connect to the internet

Your rpi interface is not directly connected to the Internet, and thus the warning does not apply.

You are behind a modem/NAT, as you say your are forwarding the OpenVPN port. So the other ports are firewalled e.g. inaccessible.

The problem here would be if you had your rpi like my lamobo R1, which is the router for the Internet, and the machine doing NAT.


How do I use C# to encrypt/decrypt data where the private key is on a smartcard, hardware security module, TPM chip etc

In the Windows world, cryptography with special hardware goes through the "Cryptographic Service Providers" (CSP). A CSP is a module registered in the OS, which offers access to such a kind of hardware.

From C#, you can look at RSACryptoServiceProvider, which can be created with some parameters which designate a specific CSP.

The non-Windows world tends to use PKCS#11 for that. Google finds some software packages which can apparently use a PKCS#11 DLL (i.e. the driver for the crypto hardware) from C#; e.g. pkcs11.net and NCryptoki (the former seems to be open source, not the latter).


Re-pairing Bluetooth devices in public places

The sub-section of the answer you are referring to indicates that refreshing the security pin frequently is a good idea. By no means is bluetooth a secure technology.

You can read the rest of that answer or this article for some more info on how bluetooth is vulnerable. If you want specific attacks, just google "CVE bluetooth" and read through.

In answer to you asking:

  can I generally feel safe repairing my phone with a headset or a keyboard in public?

Maybe... Just because the threat is out there does not mean someone is actually trying to attack you. Bottom line, it all depends on the level of security you need. If you are working on a confidential doc (why would you be doing that in public anyway) or are banking, I wouldnt use inherently insecure tech to do this, but if you are just playing words with friends, go ahead -who cares.


Is there any Security issue if we not used SSL between AWS Cloudfront and AWS ALB?

I would say the short answer is: a compromise is possible.

It would seem that defense-in-depth applies here. Not using SSL assumes that the environment is completely trustworthy and secure, and always will be. Such an assumption has lead to many incidents.

Put another way - there is no risk assuming that all of the following is always true:

you do - and always will - fully control and trust the VPC that hosts it;
that you do - and always will- fully control and trust all the instances involved (and new ones that may be introduced);
that you do - and always will - fully control and trust all the traffic that will ever traverse the VPC;
that you will never have an incorrectly - or maliciously - configured perimeter control;
that there will never be a vulnerability in any of the components that could lead to man-in-the-middle or other types of compromise;
that the environment will never be exposed to any malicious actor (individual or software);
that there is little-to-no potential loss if the systems or information involved are compromised, damaged, or lost.

Since it would be unlikely that one could say with certainty that all of the above will always be true, it is usually wise to use encrypted communications at all times. Given that the functionality is readily available, and the overhead impact is negligible, it would seem best to simply use it.


Are PGP/GnuPG trust information transferred to key servers?

This mechanism only works if people know which key I have signed. Can I assume that such signing information is stored on key servers?

Yes, certifications are stored on key servers.

  Does this mean that I have to resend my key to a key server after having signed someone's key?

You have to upload a key, but not yours, instead upload the certified key (or ship it to the owner, who can decide whether to upload it or not).

You have to differentiate between different kinds of trust.

Certifications (Signatory Trust)

OpenPGP expects trust in identity to be public, thus certifications being shared. "I believe that Alice is really who she claims to be" is a statement based on facts that can be shared without further implications (maybe apart from network analysis and clustering being possible).

Owner Trust

On the other, you have to decide whom to trust. Certifications issued are only valid, if a key itself is valid (so you can build a trust path to the other user) and you put trust in the certifications of all the users in-between (or partial trust on different paths). "There's Trust and Then There's Trust and Then There's Trust (a nice article on trust in OpenPGP) called this "trust to vouch".

Sharing this kind of trust might have heavy implications. You don't trust in the capabilities to correctly certify others of your boss, wife/husband? They might get this very wrong. It also reveals social connections at a much deeper level, as you have to know the other person to some extend, while you can safely certify a completely stranger's identity by verifying his identity card/passport.


Php two-way encryption to mysql database

What you do here depends on your threat model and what attack scenario you're trying to defend against. I'm going to assume you're trying to protect against a situation where an attacker can read the database contents (e.g. via a SQL injection vulnerability) but not the contents of the filesystem. I'm also going to assume you care about confidentiality and not integrity or authenticity.

It's worth noting that you will need to lock down your database user's permissions to prevent a SQL injection from gaining filesystem access via commands such as LOAD DATA INFILE, otherwise database access inherently also means filesystem access in most cases.

The general way to secure database contents against such a scenario is to have a symmetric key stored externally to the database, e.g. in a config variable or stored in its own file. Then, for each item of data that you want to encrypt, you generate an IV and encrypt the data with AES in CBC mode, then store the IV and encrypted data as columns in the database. You can then decrypt the value by finding the row you want to decrypt, reading out the IV and encrypted email address, then doing an AES-CBC decrypt using the key you loaded from the key file.

This does, however, mean that you can't search the users table by email address. Scott Arciszewski wrote a great blog post recently about building searchable encrypted databases which may help you if this is a requirement.