What steps do Gmail, Yahoo! Mail, and Hotmail take to prevent eavesdropping on email? I would like to ask what happens when an email is sent from gmail, yahoo or hotmail public web email services?

I don't understand email protocols in details, but as far as I know email traffic is unencrypted and the messages are passed along many mail servers (in plain text) before reaching their destination server. However, this was questioned recently by other people, and their view was that if one of the big providers is used, the email messages are encrypted and there is no need to worry about security.

Do you know if they are right about this and are emails moderately secure?
Thank you!

An SMTP session between two mail servers may be encrypted, but only if both ends support it and if both ends choose to use it.  So if you're sending mail from Gmail to example.net, then Google could only encrypt if example.net was ready and willing.  For this reason, you cannot trust email to be even moderately secure at the transport layer. (The only safe end-to-end method is to encrypt your email using S/MIME or PGP, but the people you're exchanging email with need to be on board too... just like the mail servers).

As to whether the big three are performing opportunistic STARTTLS, I haven't seen any evidence of it, but I spend less time reading my mail server logs than I used to.  And if they are, they're still only half of every SMTP connection they make, and cannot guarantee the use of encryption.

Update:

I just banner tested MX hosts for gmail.com, yahoo.com, and hotmail.com.  Only gmail advertises STARTTLS, which is to say, only gmail would be willing to encrypt the SMTP session if the other party wanted to.

I tested gmail outbound by sending mail to a server I own and watching the wire; Google does indeed take advantage of STARTTLS if it is offered and encrypts the SMTP transaction when a gmail user is sending mail.  Props to Google.

So as far as "sending" email encryption goes: Google 1, Yahoo 0, Microsoft 0.

As per the comments below, if you want to test these yourself, it's very simple:

Determine the MX hosts (Mail eXchangers) for the domain
Telnet to port 25 on one of them
Type in "ehlo yourhostname.domain.com"
If you don't see "250-STARTTLS" as one of the responses, they don't support opportunistic encryption.

Like this:

$ host -t mx yahoo.com
yahoo.com mail is handled by 1 mta5.am0.yahoodns.net.
yahoo.com mail is handled by 1 mta7.am0.yahoodns.net.
yahoo.com mail is handled by 1 mta6.am0.yahoodns.net.
$ telnet mta5.am0.yahoodns.net 25
Trying 66.196.118.35...
Connected to mta5.am0.yahoodns.net.
Escape character is '^]'.
220 mta1315.mail.bf1.yahoo.com ESMTP YSmtpProxy service ready
ehlo myhost.linode.com
250-mta1315.mail.bf1.yahoo.com
250-8BITMIME
250-SIZE 41943040
250 PIPELINING
quit
221 mta1315.mail.bf1.yahoo.com
Connection closed by foreign host.
$

As a side note, Yahoo will close the connection if you don't ehlo right away.  I had to cut & paste my ehlo because typing it in took too long.

MORE UPDATE:

As of January 2014, Yahoo is now encrypting - I just tested (as above) and verified.  However, both The Register and Computerworld are reporting that the intracacies of SSL setup (such as Perfect Forward Secrecy) leave a lot to be desired as implemented by Yahoo.

EVEN MORER UPDATE:

Google is now including SMTP encryption data in their Transparency Report Safer Email section.  They're sharing their data about who else is willing to encrypt, and you can look at the top numbers as well as query individual domains.

Addendum:

@SlashNetwork points out that it is possible to configure a mail server to require that TLS be negotiated before exchanging mail.  This is true, but to quote the Postfix documentation:

  You can ENFORCE the use of TLS, so that the Postfix SMTP server
  announces STARTTLS and accepts no mail without TLS encryption, by
  setting "smtpd_tls_security_level = encrypt". According to RFC 2487
  this MUST NOT be applied in case of a publicly-referenced Postfix SMTP
  server. This option is off by default and should only seldom be used.

Now, the world is full of implementations that violate the RFCs, but this sort of thing - e.g., something that may break routine required functionality like accepting bounces and mail for the postmaster - is probably more likely to have negative consequences.

A better solution which mail gateways often allow is the imposition of TLS requirements on a per-domain policy basis.  For example, it is usually possible to say "Require TLS with a valid Certificate signed by Entrust when talking to example.com".  This is usually implemented between organizations that are part of the same parent company but have different infrastructure (think: acquisitions) or organizations with a business relationship (think: ACME, Inc., and their outsourced support call center company).  This has the advantage of ensuring that specific subsets of mail that you care about get encrypted, but doesn't break the open  (accept from anyone by default) architecture of SMTP email.

Addendum++

Google has announced the gmail will percolate information about the security if the mail path out to the reader.  So these behind-the-scenes encryption steps will be brought to the notice of the user a little bit more.

(Probably still doesn't care about the certificate provenance; just an indicator of encryption of bits).


Password reset - Cryptographically signed user ID and timestamp or randomly generated value? What are the pros and cons of the different ways of handling reset links?
I see two ways of handling them:

Generate a random string, for example with uuid4. Store it in the database with the user and send it in a link to the user. When the form is filled in and submitted the random string will be the payload and matched to the user. The string is then removed from the database so it can only be used once. It should also have an expiry date.

Pros:

Simple and safe

Cons:

Have to store it in the database
A malicious user can cause database writes by repeatedly using the "forgot password" feature. This would have to be mitigated by a maximum possible tokens per day feature and that still only limits it for one account. If the token is overwritten then storage space will not matter but it could still cost money in form of database writes.

Generating a signed token. From the username or id and a timestamp a signed token is generated with a secret key. This is the link sent to the user. When the user submits the token is decrypted back and the user and timestamp retrieved and validated. The issue here is that it can be reused so you have to store the old password in the link as well (it would be a salted hash). I don't like the idea of being able to reuse it, what if it is used on a public computer? Then the user has to clear the browser history, bad!

Pros

Nothing needs to be stored in the database.

Cons

Riskier? Is it a bad idea to send the old, encrypted (salted hash) password in the link? If "last time modified" is already stored then that could be sent instead without writing to the database upon the reset request.

I'd go option 1 all the way - you want to ensure that a given token is only used once and it is not possible to do that without a database entry.


Replacement for One Time Passwords (OTP) OTP may known as new generation of password security techniques, but I want to know does it still safe enough after several years of appearance or it will deprecate soon? & what would be the possible replacement for that?

One-Time Passwords (not to be confused with "One-Time Pad", a theoretically perfect but practically heavyweight technique for encryption) are a sound concept which cannot, as itself, deprecate. It just means: a given password (i.e. a secret value shared between prover and verifier, used for authentication) can be used just once with the verifier; in other words, if the verifier (e.g. a server you want to log on) accepts a password but will reject any further attempt with the same password, then it is a one-time password.

One-Time Password schemes are systems which use the One-Time Password concept and establish rules and mechanisms for the two parties (prover and verifier) to actually share one-time passwords. Any given scheme can be weak or strong, broken, deprecated... but the concept is unharmed.

RSA SecurID tokens can be viewed as an incarnation of the concept of one-time passwords -- a variant with a clock, actually -- and they are very much alive.

HOTP is a free and open standard for generation of one-time passwords (with an internal counter), which can be implemented by extremely cheap hardware tokens.

(Traditional one-time password authentication schemes for Unix servers use software generation of lists of passwords, which users are supposed to print and keep in their wallet, striking out used passwords. This never got popular -- I guess it is too low-tech; users are not amazed enough to forget the inconvenience of fiddling with a tangible object).


How do boot-sector viruses propagate? I'm doing research on various malware and I came across boot-sector viruses. Kaspersky states that "they are not designed to infect removable media."

My question is, how do they spread then?

Again quoting Kaspersky, "Boot sector computer viruses are most commonly spread using physical media." Are not removable media (USB sticks for example) the same as physical media? External hard disks etc?

Well actually Removable media is a subset of physical media. Its the old "a cube is always a beam, but a beam is not always a cube." thing.

Boot sector viruses have been know to be spread through:

Hard Disks
Floppy Discs
CD/DVD/Blu-ray Discs
Tape's
Cartridge's
BIOS and Secondary BIOS infections
PCI equipment (I only know of lab-experiments like this, but they do prove its possible)
Firewire devices.
USB devices.
Networks
Downloads(quite rare there actually)

For most cases the way the work is the look for the Primary MBR (Master Boot Record) and modify its content with there own payload so the Virus is loaded on each boot. It usually have some companion app that it will retrieve as soon as possible to do the reinfection on different devices and redistribute the virus to other devices. so while on themselves they often do not pose a risk for removable media. They are hard to get  rid of. they are more a thing of the past though, since secure boot and the UEFI environment its harder to implement scheme's like this undetected.


Are PHAR archives secure? I want to send the new releases of my application in encrypted, signed archives to the server. Are PHAR archives a good solution to do that? Is PHAR secure enough?

No, PHAR archives provide no security features in themselves. But you can sign updates using GPG like literally every other project does.

Some package management systems (rpm, deb, etc) allow for signature verification built-in. You can use one of those and get security for free, or you can implement it yourself.


What does EIP stand for? There are a ton of questions on here that make reference to the eip:

How can I partially overwrite the EIP in order to bypass ASLR?
Unable to overwrite EIP register
Do I always have to overwrite EIP to get to write on the stack in a buffer overflow?
Etc.

What is the EIP? How is it used, both as an exploit target and in benign code?

EIP is a register in x86 architectures (32bit). It holds the "Extended Instruction Pointer" for the stack. In other words, it tells the computer where to go next to execute the next command and controls the flow of a program.

Research Assembly language to get a better understanding of how registers work. Skull Security has a good primer.


Can IMEI be tracked through IP address if cellular never activated on device? Just want to know if an iPad can be tracked via IMEI over IP address if the device is NOT activated on a cellular network. The device is only used on a WiFi network and has never/will never be connected to cellular network.

The IMEI is transmitted only on the GTP open context packet on GRPS (requests, update, etc...), that is in general what is used on 3G/4G and different versions, but basically is there. So if you device don't sent that packets, general is when you use the radio interface, I don't think the IMEI is transmitted in other cases over WiFi devices or even Ethernet.


How should I start security testing of python standalone application? I'm looking for an answer specific to Windows/Linux standalone applications, for instance Dropbox has Windows Application written purely (I think so) in python, What steps should I follow? What are the various threats I should consider?

I am very interested in penetration testing standalone applications, I have good enough experience with Web Application Security Testing and I do Python programming a lot.

Any good reads, links and write up are welcome.

This is a two-part answer:

You must overcome any obfuscation or get to some sort of decompiled state. See this question on StackExchangeRE for more details on Python obfuscation.
Once you have the code (or if you have the source in the first place), you will want to utilize a mixture of secure code review, runtime analysis, and security-focused static analysis to uncover potential findings for triage.

If you are looking for security-focused static analysis tools, sadly many of the commercial ones are just not there yet for the Python language. Pylint and Flake8 also are primarily style or correctness checkers with zero security checks. My top recommendation for Python SAST is the Bandit project from the OpenStack Security team. There are only a few basic checks but you can add more. Bandit is only a slight (but important) improvement over older tools' techniques, such as seen in graudit and RATS.

If you are interested in runtime analysis, most security testers leverage Burp Suite Professional for HTTP/TLS traffic and Canape as a pluggable, local-logging proxy for other protocols. In order to understand file handlers or network protocols that utilize encryption or compression routines during runtime analysis, many security testers turn to software tracing (because it's faster than debugging) or hooking techniques, such as found in the Frida framework. A popular set of flaws targeting serialization (pickling in Python) are becoming more widely known, so it may be worth checking out the OWASP Python Security Project page or list for more information.

For a more-detailed look at Dropbox specifically, see this other answer over at StackExchangeRE, in addition to this Security Analysis of Dropbox code.


Mac OS X vulnerabilities and not having the need for an antivirus? I have just read news about Mac OS X vulnerabilities and wondered why would people say that you don't need an antivirus if you are using a Mac?

There are vulnerabilities in other operating systems but at least someone can be a bit safer by having an antivirus which is recommended to Windows users for example.

Some of these vulnerabilities included "execute code". Wouldn't this lead to virus/malware etc.?

I think you're hearing information that was generally thought by not so tech savvy people that a Mac doesn't require AV, or is less susceptible to attacks. That's a very bad assumption, and the idea was brought about by individuals who gave Windows a bad stigma, and were pro-Apple.

Some individuals learn that Mac is based on Unix/Linux. They learn, or rather think, that Linux is more secure than Windows, or they hear that Windows is insecure. While this can be somewhat true and I would be more willing to say Linux is a little more secure than Windows, it still doesn't make the system immune. The reasoning behind this logic was at the time a lot of vulnerabilities were posted that were related to Windows Operating Systems because of the fact that a lot of businesses used Windows. So a lot of early on attacks were targeting Windows OS's because they were the go to in the corporate world, and even in today's world most businesses will have a majority of their systems running Windows.

Mac is no less vulnerable to attacks then Windows or any Linux distro. It's important for any individual using technology to have a basic understanding of potential security threats and vulnerabilities. Without going into too much detail, it's true that Windows is much different than a Unix/Linux based OS, they both have their strengths and weaknesses and both are susceptible to attack.

Macs can and will get malware just like the rest of the operating system world, and Macs can and will get attacked just like the rest of the Operating System world.

When it comes to security arrogance is a downfall.


What risks do I take using an application that always requires admin access and AV exception listing? My knowledge level about OSs and security is extremely low. Is anyone willing to tell me whether it's risky for me to use an application that requires me to run it with admin permissions and to put it on my AV exception list in order to properly save files?

For background, this is a machine embroidery design package called Embird, out of Czech Republic. When my files weren't saving, support told me to run as admin and put all its EXE and DLL files in my AV exception list.

Other similar applications I have used do not require admin permissions to save files.

When I asked why admin permissions are required,  I triggered a kind of fight-or-flight, abusive, kiss-off response but no actual answer (ending in "use your antivirus software to do embroidery").

I've sunk 2 years and more than $1000 in this software and I don't want to switch,  with all the time costs of training on a new interface as well as the financial cost of acquiring a new application, if it's not necessary.

Thanks.

It sounds like poorly designed software.

It likely needs admin permissions because it is designed to save in unexpected places. The risk here is that the software has admin permissions to do anything. If an update to this program adds nasty surprises, then it has access to everything. This is not unusual, though. There are a lot of programs that require admin permissions.

Whitelisting the EXE and DLLs in your AV is just weird. I would try to give it admin permissions to see if that solves your problem before whitelisting the program. The problem here is that if a virus gets in and infects those files, then your AV has been told to ignore them. You are unprotected even if you gave the program admin permissions. Frankly, if whitelisting in AV solved the problem, I'd be leaning towards trying different AVs than whitelisting.

With admin access and AV whitelisting, the program can do anything without any controls to limit its damage. BUT you can design your system to be ok with this, too. If your computer only runs this program, is not connected to the Internet, and you backup your design files on a separate disk (which you do not leave plugged in all the time), then if something goes wrong, your risks are contained. Not ideal, but a much lower risk.


Security checks on file transfer What are the security checks that I can make on a PDF file being transferred between server and the client?

"Security" is a bit too broad here.

If you're looking for integrity checks -- that is, "has the file been altered in transit?" -- then what you need is a checksum. Just about any cryptographic hash will do (except MD5 and older, maybe avoid SHA-1 as well for new projects), so SHA-256 for example is a fine choice.

Of course, if you want the recipient to be able to crypographically verify the checksum, then what you're after is a digital signature. Roughly: you checksum the file, you then you encrypt the checksum with your private key, which means anyone in possession of your public key can decrypt the checksum, compare the checksum against the file, and verify that it's the one you signed.

Don't implement this yourself directly; use GnuPG or PGP. They've worked out the details that I glossed over.

If by "security" you mean "secrecy" -- if instead you want to guarantee that the file is only readable by the person you intend to send it to, then you encrypt the file using the person's public key (using the standard combination of asymmetric and symmetric ciphers), which means that only the intended recipient can decrypt it.

Again; use GPG or PGP. They do it right.

If you want to have both, then do both. The combination is also supported.


Find security weaknesses in this website (exam question) I am currently studying for a computer security exam and I am stuck on the following question from a past exam paper

1c  <form action=”message.php” method=”get”>
2c
Message: <input type=”text” name=”message” />

3c
Username: <input type=”text” name=”user” />

4c
Password: <input type=”text” name=”pass” />

5c
<input type=”submit” />

1s  <?php
2s  $user = $ ̇REQUEST[”user”];
3s  $pass = $ ̇REQUEST[”pass”];
4s  $message = $ ̇REQUEST[”message”];
5s  $result = mysqli_multi_query($con,”UPDATE messages SET
6s     message=”.$message.” WHERE user=”.$user.””);
7s  $row = mysqli_fetch_array($result);
8s  if (!empty($row)) {
9s     echo ”Your message: ”.$message.” has been added”;
10s   }
11s  ?>

I know I should look for things like SQL injection, XSS, Cross-site request forgery, etc ...

My attempt:

$user could be used for SQL injection as it is not sanitized
password is not verified anywhere (?)
echo $message also looks like vulnerable part (input not sanitized again) but not sure what would be the exploit (some sort of XSS?)

I would really appreciate if someone could highlight the vulnerable parts of the code or even explain why they are vulnerable.

Vulnerabilities 1 & 2:

5s  $result = mysqli_multi_query($con,”UPDATE messages SET
6s     message=”.$message.” WHERE user=”.$user.””);

These are SQL injection vulnerabilities. The program invokes a SQL query built using input coming from an untrusted source. As you pointed out $USER is vulnerable but $message is also.

Vulnerability 3:

8s  if (!empty($row)) {
9s     echo ”Your message: ”.$message.” has been added”;
10s   }

This is an XSS vulnerability. Although it is hard to classify specifically the type given the little amount of source code, because the data is being stored in a DB (thus making it persistent); however the example code does not show other areas it is output, so we can only state that it is reflected at this point.

Potential Vulnerability 4:

3s  $pass = $ ̇REQUEST[”pass”];

Computer programs depend largely on context, so while it appears that the author of this program wanted to authenticate, this may not be the case. If the author did want to authenticate, then $pass is not checked anywhere. Regardless of if this is a vulnerability, this is unused code. It is bad practice to leave unused code in a production program.

Potential Vulnerability 5:
1c  <form action=”message.php” method=”get”>

This is potentially a CSRF vulnerability. Once again this is dependent on the programmers intent to have validation. If they did then the form post must contain a user-specific secret in order to prevent an attacker from making unauthorized requests.

Potential Vulnerabilities 6 & 7:

5s  $result = mysqli_multi_query($con,”UPDATE messages SET
6s     message=”.$message.” WHERE user=”.$user.””);

$message and $USER are potentially stored XSS vulnerabilities, although the sample code does not show these variables getting retrieved, it would be fairly safe to assume these may be displayed in another part of the program.

Potential Vulnerability 8:
4c
Password: <input type=”text” name=”pass” />

This is potentially a shoulder surf vulnerability. This input should be obfuscated. Once again this depends on the programmers intent to actually validate, and the actual meaning of the pass input field. We can assume that this is a password, but unless we get confirmation from the programmer, it is just that, an assumption.

Potential Vulnerability 9:

1c  <form action=”message.php” method=”get”>
2c
Message: <input type=”text” name=”message” />

3c
Username: <input type=”text” name=”user” />

4c
Password: <input type=”text” name=”pass” />

5c
<input type=”submit” />

This is potentially a shoulder surf vulnerability. This will result in a GET request displaying the password on the URL, which could result in a shoulder surf attack. Once again this is dependent on the programmer' intent.


How likely is an attack for a known OTA ring 0 vulnerability in mobile devices? Following on from this question about a WiFi OTA vulnerability: assume a popular computing platform has a known vulnerability that would allow creation of a worm with access to ring 0 (kernel). Then, how likely is it / how long would it take before a malicious worm was created that targeted:

The general population
A special subset of users, such as workers at a particular organisation such as a hospital
Specific people of interest, such as politicians or celebrities

I'm interested in both anecdotal accounts and formal studies. I found this paper, but it seems to be behind a paywall. As an aside, what terms would you use to search for this information?

Edit To make this easier to answer, let's be specific: how likely is it that the recent WiFi vulnerability (which is still* unpatched on many phones) will actually be exploited?

As an example of why I think this threat is real: an exploit might gather the location of all users with an unpatched phone. That has to be worth something to somebody (and so might make it worthwhile to implement).

* as of 14 Apr 2017

The answer must vary dramatically based on many factors which are specific to the individual exploit.  For instance, consider how easy it is to actually cause the exploit.  The harder it is to write a worm which leverages that exploit, the longer it will take.  As a trivial lower bound, consider if you published openly that your root password was "password" and was accessible by SSH.  How long would it take for someone to take advantage of that?  Compare that with Heartbleed, which in theory can cause unspecified damage by revealing random blocks of memory to the attacker (including revealing passwords that could arguably lead to ring 0 compromise in particular circumstances).  It was considered to be a big deal because it was a substantial bug in openSSL, by in practice it was deemed less risky than other exploits because it required more effort on the part of the attacker to hit pay dirt.


x509: must the signature algorithm and public key algorithm match? I'm having trouble getting Firefox to send an encrypted message using a certificate, and I've found that the only difference between this one and others that work fine are that this one has a DSA public key while the others have an RSA key. The signature algorithm still says "sha512WithRSAEncryption". I'm wondering if that is causing a problem since the public key algorithm is not RSA.

The signature in the certificate is computed by the CA, and must match the public key of the CA. There is no problem with having a certificate which contains a DSA key while being signed by a CA which uses a RSA key.

There is a big problem, though, with trying to encrypt some data with a DSA key. DSA is only for digital signatures.


Can google detect tor browser Usually while we browse Google through our IP we will be redirected to respective countries. I normally use tor browser for anonymity. Today while I browsed google I got redirected to encrypted.google.com.

Does this mean google can detect tor browser?
If yes, how do they detect our browser identity and IP?

Note: if we browse using proxy sites we are not redirected towards their encrypted website.

Any web site can determine which of their visitors are using Tor, because a comprehensive list of Tor node IP addresses is a public part of the Tor network's operation. What actions a website takes based on that information is out of your control, so you can only expect the worst, whatever that may be.


“Don't break Debian” and bug fixes Don't break Debian page is quite clear that always installing the latest versions of third-party software from from places other than official Debian repositories is not a good idea. Although the article tells a lot of things, it comes in essence to the following points:

Third-party sites may not be trusted as much as Debian repositories.
Newer versions of a software product may contain new bugs.
Newer versions haven't been tested thoroughly with a specific version of Debian.
There may be issues between newer versions of a software and other software products installed on Debian machine.

I'm not sure how should I apply the advice in the following situation. I'm deploying a cluster of virtual machine which will be used to host several instances of RabbitMQ. The official Debian repositories for Debian Stretch come with version 3.6.6, which, it appears, was released more than two years ago, with a lot of versions being released since then.

My use of RabbitMQ is very basic, which means that I won't probably benefit from all the new features which were released. What scares me, however, is that most of the new releases claim to have fixed bugs, which, I suppose, includes security issues.

Therefore, should I ignore the recommendation of Debian documentation and install the software product such as RabbitMQ from the source recommended in the documentation of RabbitMQ, or should I stick with the old version provided through official Debian repositories?

Or there is absolutely no way to answer this question, without checking the entire list of changes and manually evaluating the risks?

Note: although I illustrated my question with RabbitMQ, it applies to most server-side software I have to install, such as PostgreSQL.

What you might not have thought of or read about is that Debian backports security fixes from newer versions of software to current versions. For instance, one of the Spectre-associated CVEs on Debian's security tracker shows all supported Debian versions, including oldstable. Although these really old Debian versions won’t be receiving brand-new kernels, they will be getting security fixes backported to the stable kernels.

In the case of RabbitMQ, you can see from the package tracker that security fixes have been made for the old versions in Debian Stable.

Additionally, if you do need a newer version of this program than the one in Stable, you can install it from the “stable-bpo” branch or follow the directions in this Server Fault question to get it from Testing or Unstable. This is usually the safer alternative to installing the package from the project website directly.


File upload not checking on mime type So, I have an upload functionality where extension of the filetype is checked correctly (and not currently bypassable). But the mime type is not checked. Does this leave me with some residual risk or possible "attacks". Where I mean attacks in a very broad sense where it is possible to upload a file that should not have been able to be uploaded.

I am especially interested in the risk for my users that can download files of other users. So one user uploads and the other downloads it with their browser and opens it on their not über secure machine.

The mime type isn't built in to the file in any way. One could even say that files don't have mime types. Sure, whoever created the file may have intended it to be of a certain type, but on disk it is still just a strings of ones and zeros.

The place where you encounter mime types in the context of file upload is in the HTTP headers, both when the file is uploaded to you and when the file is then downloaded from you by your users. Note that an attacker could try to send any file with any mime type, correct or incorrect.

Unless your server software doesn't explicitly store the mime type the client provided that information will be gone the second the HTTP request is processed. So when the file is downloaded, your server may very well give it a different mime type (Apache, for instance, derive one from the file extension).

So, what does this mean for you?

During upload, whitelisting on mime types isn't as important as whitelisting on file extensions. The file extension will be preserved on the server, and can affect how the file is treated (e.g. PHP files might be executed). I would still do it though, as an extra layer of security even though the mime type can be easily faked.

During download, you need to make sure that your server only puts "safe" whitelisted mime types in the Content-Type header. For instance, you don't want to serve anything as application/javascript since that would open up for XSS. But again, file extensions is just as important. E.g. don't serve anything with an exe extentions even if you don't allow the application/vnd.microsoft.portable-executable mime type (unless you want people do be able to up- and download executables, off course).

File upload is complicated, and I have tried to focus on issues related to mime type here. Please don't read this as a complete guide - there are many more things to consider, depending on your context.


Internal SSL Certificates? As a developer I really like the idea of using OpenSSL to get perfectly good, free, SSL certs. Unfortunately, from all the research/analysis I've done so far, it doesn't look like there is any way to use OpenSSL in such a way that my web users' browsers will trust the certs it generates for me.

It looks like, in order to avoid my users getting nasty warning messages from their browsers (complaining that my OpenSSL-generated certs aren't trusted/verified), I'm going to have to use a major vendor like Trustwave, VeriSign, etc.

I'm wondering if there is such a concept of "public" vs. "private" SSL certs? By that, I mean, I would buy a "public" SSL cert from one of these vendors, and would use that for all communication between my users' browsers and my public-facing HTTP servers. But once a server-side message is consumed, it would communicate with the rest of the back-end using different, "private" (OpenSSL-generated) certificates.

The idea behind this is to keep data moving through my backend using secure transports, but not have to pay for a bazillion different SSL certs.

Is this unheard of or completely unnecessary? Or is this standard practice?

Why would I need that data to be secure between 2 of my own backend servers? I don't know. Probably doesn't need to be, but probably couldn't hurt. Thoughts?

Yes, for your backend you can just generate self-signed certificates with OpenSSL as you have already done. The difference is that you then need to instruct your frontend servers to trust those certificates (how depends on the platform used).

Alternatively you can set up your own private CA (certificate authority, e.g. Verisign) and have your frontend servers trust its root certificate, then use it to generate certificates for your backend servers. This makes it easier if you need to use many certificates, other than that there's no difference.

That is exactly how "public" certificates work, except that the root certs of well known CA's are bundled with e.g. browsers. They are trusted because they perform checks of e.g. your identity, and that's what they charge for, not for the technical aspects of creating a certificate.

Of course, there is the question of whether the frontend-backend communication needs to be secured. Does anybody have the possibility to listen on the line? That depends on your hosting setup.


Why does the RFC 5280 dictate the CAs not to issue certificates with negative serial numbers? I have tried to issue a certificate beginning with 8 to F but I have found it is impossible, mostly due to the RFC:

  The serial number MUST be a positive integer assigned by the CA to
  each certificate. It MUST be unique for each certificate issued by a
  given CA (i.e., the issuer name and serial number identify a unique
  certificate). CAs MUST force the serialNumber to be a non-negative
  integer.

So I would like to know if there is any actual reason not to do that beyond the "buggy ASN.1  implementation"?

Short answer: because RFC 3280, its predecessor, says so.

Longer answer: because historically ASN.1 encoders/decoders have had problems with properly encoding and decoding integers.

X.509 uses DER encoded ASN.1, which amongst other things, means that the data must be encoded in its minimal (shortest) form. As integers are stored in a variable length twos-complement form, in order to properly encode a non-negative integer which happens to have its leading bit (MSB) set, it must be padded with a leading zero, which in other circumstance is disallowed.
The wording of X.690(http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf )
is such that the leading 9 bits of an integer must be inspected in order to verify the minimal form, thus allowing such positive integers to have leading 0 byte.

To quote Peter Gutmann

  There's a second but: Historically many encoders have gotten the signedness of
  integers wrong, which means that (a) if you get a negative number (at least in
  the area of crypto, which I'm most familiar with) it's always an encoding
  error and never a deliberate use of a negative value, and (b) because of the
  widespread use of incorrect encoders, many decoders treat all integer values
  as unsigned.  So while you can use negative values in theory, it's not a good
  idea in practice.

The correct determination of serial numbers is critical when it comes to revocation checks. Ambiguity is an enemy.

It seems to me that this is exactly the problem your encoder is having...


Is keepass random password generator fully secure and trustworthy? Am I safe using keepass for generating passwords? For example my accounts, am I safe using a keepass generated password? Could my future keepass master-keys be safely generated in keepass? What method is used? Keepass 2.30 for Windows and Linux.

Thanks,
Irrationally Paranoid Keepass User.

tl;dr: Yes, it's reasonably safe.

When an attacker knows you use KeePass, then they might also assume that you use the standard settings for the password generator. That tells them the length and the character set [a-zA-Z0-9]. This makes it slightly easier to crack than if the length would not be known and if they would expect that you also use special characters. But even with that knowledge, the generated passwords are still far, far too strong to brute-force.

But how exactly are the passwords generated? If it would be a predictable pseudorandom number generator, that might be an attack point.

Looking at the sourcecode of KeePass 2.30, the password generator seems to be implemented in KeePassLib\Cryptography\PasswordGenerator\PwGenerator.cs. It uses the class CryptoRandomStream from KeePassLib\Cryptography\CryptoRandomStream.cs with the stream cipher Salsa20 used as a random number generator.

The password generator works like this:

A random number is genrated (PwGenerator.cs line 65). It uses the standard RNGCryptoServiceProvider from the .NET framework (CryptoRandom.cs).
The generated random number is combined with some additional entropy if available. I haven't bothered to find out where this entropy comes from (usually unpredictable user behavior like mouse movement or keypresses are used for this), but apparently it isn't assumed that entropy is always available.
A SHA256 hash is generated from the random value with entropy (CryptoRandomStream.cs line 114-118).
That hash is used as encryption key for a Salsa20 stream cypher (CryptoRandomStream.cs line 119).
The stream cipher is used as a random number generator by repeatedly feeding its output as its input (Salsa20Cipher.cs line 176-196).

To predict a password, one would need to crack Microsoft's cryptographic random number generator and predict the entropy (if used).

Alternatively, if someone would crack the Salsa20 cipher, one could predict a password from the previous password. According to Wikipedia "As of 2015, there are no published attacks on Salsa20".

Best regards, Irrationally Diligent Software Developer.


Would an unnecessarily long password degrade performance of a WPA2 wireless network? My friend wants to keep his home network super-secure, due to some trouble that he's had with unwelcome Wi-Fi intruders. So, naturally, he devised an ultra-long WPA2 passphrase (on the order of 100+ characters) to thwart any would-be intruders.

Now, to my knowledge, even a simple 10-character alphanumeric passphrase would be quite secure for everyday use. Nonetheless, he insists on overkill. My question is, can this gigantic passphrase be detrimental to the performance of the network, or somehow cause slowdown at all? And, why or why not?

This question arose because I was having trouble connecting an older laptop, running Xubuntu, to his WPA2 network, whereas the laptop connects and functions fine with other WPA2 networks.

No.  It doesn't matter how long your passwords are because that value is never transmitted during the WPA-PSK Key Exchange.  Instead a CMAC is calculated based on the secret key, the client and server id, as well as client and server provided large random values.

Regardless of how large your password is the resulting CMAC for WPA2-PSK will always be 128 bits:

MAC_P = CMAC-AES-128(AK, ID_P||ID_S||RAND_S||RAND_P)


Why use HTTPS Everywhere instead of going to the HTTPS site directly? My understanding is that HTTPS Everywhere redirects websites to an https:// version if they support it.

My question is, if websites do have an https:// supported version why aren't they using them in the first place?

Suppose you're using a very old browser that cannot connect to the server using TLS, because the server does not support the old TLS versions and/or deprecated TLS cipher suites that the browser supports. For example, IE6 in WinXP supports at best SSLv3 + 3DES, and IE8 on WinXP supports at best TLS 1.0 + 3DES. SSLv3 is insecure because the CBC padding is non-deterministic and not covered by the MAC [1], and 3DES is not very secure (insecure?) because its block size is 64 bits [2]. Many servers don't support any TLS version and ciphersuite that would let Internet Explorer on Windows XP (with all the patches applied) to connect, for example to at least download a newer browser.

If you're on such a browser, and the website implemented a mandatory redirect from http to https URLs, you would be SOL.

Another reason is that some sites are under the mistaken, anachronistic, impression that encryption is computationally expensive and their server's performance would be severely degraded by spending CPU cycles on crypto, and so they use TLS "when necessary" (login page, checkout page) and don't use TLS "when not necessary" (browsing the product catalog), to "improve site performance".

Some sites were built and deployed some time ago and have not been updated in a few years. At the time, people were less aware of the total surveillance situation and the issue of authenticity and data integrity. Basically they thought that if confidentiality is not important, TLS is not needed, and thus bad people can inject bad javascript into sites and viruses into executables as they are being downloaded, with impunity.

1 - https://www.openssl.org/~bodo/ssl-poodle.pdf

2 - https://sweet32.info/


Audiobooks to learn about Infosec? I recently got homeland on a humble bundle and I've been getting really interested in Information Security so i want to keep learning and the best way i find is to listen to Audio books or podcast while drawing\walking\sleeping.

I've listened to Homeland and SnowCrash, i know the Cryptonomicon has an Audiobook but the one i found has a voice I don't really like.

I'd love to hear about more Infosec Audiobooks/Podcasts. I think Risky Business is great and allways on the pulse of what's current. I personally like their sense of humor although it's not for everyone.

Ghost in the Wires is pretty entertaining.

I had a look through Audible a few weeks back for educational infosec books but couldn't find much. I guess that anything with block of code or diagrams doesn't work so well as audio.


How can a website like mobilepay.it know your telephone number? Recently I had to disable some paid services on a mobile phone (those kind of annoying services that automatically enable when you visit some particular websites and cost lots of money). To do so I visited the website

http://selfcare.mobilepay.it

I was expecting some kind of authentication like

put your mobile number here - receive an SMS - enter the SMS code you just received here

Instead I was presented with a page where I was already authenticated and my mobile number was displayed, there I could manage my payments etc.

How can websites like mobilepay.it know my mobile number?

I checked the website https://www.mulliner.org/pc.cgi to see if my mobile number was shared via HTTP headers but I couldn't see anything suspicious.

Note: Sometimes visiting the mobilepay selfcare webpage from a computer connected to the internet via a portable router with a sim inside (and a mobile number) shows you the administration page for that number, visiting the selfcare from a mobile phone connected in the same way of the computer before (so with a portable router) shows you a page where you have to put your mobile number.

I believe the MSISDN (phone number) is passed over by the Mobile operator directly to the mobilepay.it server. When you are connected to a 4G or 3G network your mobile network operator knows this information and it can pass over to any application server if it has an agreement. I am also interested to know what protocol they use, anyway for sure mobilepay.it has agreements will all service providers in Italy.
When you browse using a PC on a Wifi, or your mobile phone on a wifi they don't detect your number.
If you use a wifi but your connection is a 3G/4G, e.g. tethering on a mobile phone or 4G router, they may detect the 3G router SIM MSISDN, but it depends on the device and hotspot configuration, I guess.


Web Application Firewall using web app source code analysis I read this page: Category:OWASP Best Practices: Use of Web Application Firewalls, and I found that WAF cannot generally detect logical attacks.

We know each web application has a number of input parameters. I think these input parameters and their associated valid values can be possibly extracted by code analysis tool.

Now, my question is that can we use code analysis tools and pass their results to the WAF to detect some logical attacks such as an example which has been described in this page: Logical and Technical Vulnerabilities?

Besides, I would like to know what are the advantages of using code analysis with WAF?

I googled and I couldn't find any WAF which uses code analysis for generating its rules or increasing its performance and decreasing false positives.

If you can actually determine the valid input values from static analysis, you can use that to guide proper input validation in your application.  However, with that lack of input validation, most static analysis tools would not be able to determine the appropriate answers.  Web Application Firewalls are used to defend against the unknown vulnerabilities and common patterns (e.g., XSS and SQLi mostly).


MS-SQL Password Storage What would be your recommendation for replacement of an MD5 hash approach to password storage within an MS-SQL database be?

Way back in 1978, Robert Morris and Ken Thompson published the Unix "crypt" password scheme with two innovations that are crucial for password hashing: salts and iteration counts.  Without a salt, hashes are very vulnerable to hash tables and rainbow tables.  Even with a salt, iterations are also needed to prevent very quick brute-forcing of most any password with 8 or fewer characters, to say nothing of simple variations of dictionary words.  How long does it take to actually generate rainbow tables?

So please use a real hash designed for passwords - i.e. one that is slow and salted.  Some good candidates are:

bcrypt
PBKDF2: Rfc2898DeriveBytes Class (System.Security.Cryptography)

You can tune them to not take up too much server time, but people don't authenticate very often, so don't be stingy.

See also: Password hashing - IT Security


How can I find if my password has been posted online? I have just received this email from AbeBooks.com:

  Hello AbeBooks Customer,

  This is an important message from AbeBooks.com.

  As part of our routine security monitoring, we have learned that a
  list of email addresses and passwords were posted online this week.

  While the list was not AbeBooks-related, we know that many people
  reuse their passwords on several websites. We believe your email
  address and password set was on the list posted online.

  Therefore we have taken the precaution of disabling your password on
  your account. We apologize for any inconvenience this has caused but
  felt that it was necessary to help protect you and your AbeBooks
  account.

I don't care so much about my AbeBooks.com account as I barely use it. But, I am very worried to know that my email and password are published online.  Although I tried to Google for my email and haven't found anything.

What should I do now? Should I change the passwords in all my 50+ accounts?

Probably the most comprehensive database of searchable compromised accounts is haveibeenpwned.com.

If you've reused the password in multiple places then yes you should assume that password has been compromised. I also recommend enabling two-factor authentication wherever possible as this will reduce the risk of one account being compromised leading to other accounts being compromised.


Is it safe to allow untrusted field names in JSON? When forming a JSON data structure, are there any security risks with allowing the field names to be chosen by an attacker?  You can assume they'll be quoted properly.  I'd like to know if allowing the attribute names to be attacker-chosen poses any additional risks over allowing the attribute values to be attacker-chosen.

Example: I might have a JSON value such as the following:

{
  "name": "me",
  "interests": "sewing",
  "comment": "hello world!"
}

Assume that both the attribute names (name, interests, comment) and attribute values (me, sewing, hello world!) can be freely chosen by the attacker.  Also assume that they are properly quoted (e.g., they are always surrounded by double quotes; we escape backslashes and quote signs, to prevent breaking out of the quotes).

Is there anything I need to worry about that's specific to attacker-chosen attribute names?

Do I need to worry about an attacker choosing an attribute name like toString or valueOf or length or 0?  Or names that start with an underscore?

There's no inherent security risk.

Of course, you remain at the mercy of the security of the library with which you are parsing the JSON, and you remain at the mercy of the security of the application which will make use of the parsed JSON.


Does digested passwords send over a non encrypted channel offers additional security over plain text passwords? I am learning about WS-Security and trying to compare different options offered by UsernameToken as described in this document.

AFAIK, a digested password is a hash of the plain text password along with a nonce and a date. This prevent replay attacks and the need to send the plaintext password :

Password_Digest = Base64 ( SHA-1 ( nonce + created + password ) )

According to the document what will be send is something like this :

<wsse:Security>
    <wsse:UsernameToken>
        <wsse:Username>NNK</wsse:Username>
        <wsse:Password Type="#PasswordDigest">weYI3nXd8LjMNVksCKFV8t3rgHh3Rw==</wsse:Password>
        <wsse:Nonce>WScqanjCEAC4mQoBE07sAQ==</wsse:Nonce>
        <wsu:Created>2003-07-16T01:24:32Z</wsu:Created>
    </wsse:UsernameToken>
</wsse:Security>

What I don't understand is this part (page 6) :

  Passwords of type PasswordDigest are defined as being the Base64
  [XML-Schema] encoded, SHA-1 hash value, of the UTF8 encoded
  password (or equivalent). However, unless this digested password
  is sent on a secured channel or the token is encrypted, the digest
  offers no real additional security over use of wsse:PasswordText.

AFAIK If some attacker is able to catch the password digest the only thing he can do to find the password is to brute force it (to try all possibilities until it match the hash). To me it seems much secure than sending the plain text password. I must be missing something.

Brute-forcing a single round of SHA1 is extremely fast. An individual high-end graphics card can compute billions of such hashes per second; by parallelizing it even further (using multiple cards, cloud services, or custom hardware) the rate can be driven to even greater orders of magnitude. While the nonce and timestamp prevent building a rainbow table, modern hash cracking is so fast that it scarcely matters anymore. The slowest part, by far, of creating a rainbow table or any other persistent hash lookup table is simply the time to write it to storage.

Digest auth can hide your password, but doesn't protect the data itself. Without encryption, an attacker can read all data passing in both directions. Without integrity checks, an attacker can tamper with the messages, even to the extent of completely replacing your requests or the server's responses. Additionally, if you haven't authenticated the server in some way (typically, this is done during a TLS handshake by the server providing a trusted certificate and proving it has the corresponding private key, but it could also be done using a password of some sort) then you don't even know if you're communicating with the server you think you are; an attacker might have spoofed your DNS or ARP, or compromised some node along your path, etc.

This scheme means the server must store the passwords in plain text or under reversible encryption, because it cannot apply further hashing to the password part alone (in order to match the hashing used before storing in the database). Client-side hashing like this can protect the password itself from a network attacker, but only be exposing every password in the system if the server / its auth database gets compromised.

If sites A and B both use this protocol, and the attacker wants to get into your account on A but A uses a secure channel (such as HTTPS) and B does not, then the attacker can attempt the following:

Obtain a man-in-the-middle position between you and B.
Attempt to access A (via its secure channel), receiving an auth challenge with a nonce in it.
Spoofing your communication with B to present the nonce that the attacker got from A.
Your client hashes your password using this nonce (which is actually for A, not B), and the attacker intercepts your UsernameToken.
Attacker replays your token to A, along with the request that the attacker wants to make in your name. Because the token was constructed using the nonce for A, A accepts it. Because the token contains no information about what service its intended for use with, neither the server nor the victim realize that the they crafted a token for a different site (although the victim might think something's up when B rejects the token... but the attacker can suppress any awkward response messages.)

This type of attack - passing the hash intended for one server to a different one, and thus accessing the other server using the victim's account - is a very common way to compromise any system that relies on client-side hashing (even with a server-supplied salt/nonce) when the same password is used in multiple places.


Windows Authentication and Session Ids After a penetration test made upon an intranet application I'm developing, in ASP.NET MVC, one of the concerns raised was that the application supports concurrent user sessions and it is recommended that the application is reconfigured to support only one session at a time for any given user account.

Windows Authentication is being used. This means the user doesn't have to log in to the application, obviously. The application simply checks the Windows Identity IsAuthenticated property before proceeding with any action. The Session can't be timed out either. There is no configuration available, as far as I'm aware, that can limit the user to a single session id.

Is this recommendation correct? If so, can I limit the user to a single session id given I'm using Windows Authentication?

For standard applications I usually raise this as a "low" priority finding, mainly as if an attacker has compromised an account, it can be a useful restriction to have a user only able to maintain a single session and log out old sessions when a new one is started, that way the attacker gets kicked out the next time the user logs in.

In this scenario the attacker would need to be signed into the domain account of the user in order to have access to their session, so really the control should be placed at the domain level (e.g. stop users having multiple concurrent domain logins) if that's desirable/possible in the context of your organisation

So I'd say that the recommendation doesn't really apply to the application that you're developing, as the application doesn't really have control over that aspect of authentication.


Including GPG Transition statement as a signing policy Assume that I am transitioning from key A to key B by signing key B with key A and then revoking key A.
What do you guys think of including a link to my online transition statement in my signature of B with A as a "signing policy"?

Transition statement explanation: What's the purpose of a PGP transition statement?

If you are signing a link to your transition statement, then the location where people go to look for it is fixed, but there's nothing preventing you or an attacker from changing the text of the transition statement at some point in the future. You really need to sign the transition statement text with the old key, not just the location of the statement.

Assuming you're doing that already and embedding the link is just to help people find it, then sure, why not.


How to find default S2K parameters in GPG How can I find the default string-to-key parameters in GPG?  I am using it in Tails.

According to the Tails source, no custom S2K counts are specified for GnuPG. This means you will be using the default for the current version. The changelog for Tails shows that 3.7.1 is using both 2.1 and 1.4. For 2.1, the count seems to be variable and depends on your hardware's performance, with a minimum of 65536. Version 1.4 on the other hand hardcodes the default at 65536.

The S2K version will always be 3 as is the case for all modern GnuPG setups. As for the default digest algorithm, for both 2.1 and 1.4, SHA-1 is the default. Note that there is an open bug that may make it such that the various S2K options in 2.x do not do what you think they will do.


HeartBleed - how do I invalidate all session cookies? As part of the Heartbleed event, I have upgraded OpenSSL, reissued and replaced certificates and revoked the old ones and changed passwords however, I am also seeing advice to invalidate all session cookies (https://security.stackexchange.com/a/55089/18057) but I cannot find out how to do this.

Does this just apply to PHP sessions, for example, or is it more than this? What do I need to do to ensure all session keys and cookies are invalidated?

Thanks

The easiest way to invalidate all in memory sessions is simply to restart your application server(s), which will clear the in memory session cache and make everyone's session cookies invalid.

Also, if you are using a login framework that supports persistent logins (you are if you have a 'remember me' checkbox on your login form), then you can and should delete all the persistent logins from your database too.

One note is that if you have shared session state between your application servers in a centralized cache (a not uncommon setup in a load balanced configuration where sticky sessions are not supported), then that cache will need to be flushed.


Why does the first call to DecryptUpdate in AES-CBC return 16 fewer bytes? While decrypting a file by CBC mode of AES algorithm, the output length is 16 bytes lesser than that of the input length. For example if you pass a buffer of 512 bytes it decrypts 496 bytes. It happens only in CBC mode for the first call of EVP_DecryptUpdate(). Why is it so?

while((bytes = fread (buffer, 1, 32, fp)) != 0)
{
    EVP_DecryptUpdate(e, buffer_out, &c_len, buffer, bytes);
    ret = fwrite(buffer_out, 1, c_len, fpout);
    printf("c_len %d bytes %d ret %d\n", c_len, bytes, ret);
}

AES operates over blocks of 16 bytes.  The EVP_DecryptUpdate() will operate on blocks of 16.  As long as you are using EVP_DecryptUpdate() it assumes that you will give it more data to decrypt, and retains the last block of data within the crypt context.  This is because in CBC mode it needs the next cipher block to be the IV for the next block of decryption because it can't predict when it will need it to calculate  the padding.

Wiki Image

The "decrypted length" will be exactly one block (16 bytes) less than what you give it for the first iteration because it retains the 2nd block of data.  Once you decrypt the 2nd iteration it outputs block 2 and block 3 (32 bytes), and retains block 4.  Extrapolating this out to the end of your encrypted file you'll realize that you would be 1 block short.  Once you call EVP_DecryptFinal the final block is decrypted (padding taken care of if necessary), and output to the buffer given for the full 32 blocks (512 bytes in your example).

Example Code

char *decrypt (char *key,
               char *iv,
               char *encryptedData,
               int encryptedLength)
{
    // Initialisation
    EVP_CIPHER_CTX *cryptCtx = EVP_CIPHER_CTX_new();
    EVP_CIPHER_CTX_init(cryptCtx);
    int decryptedLength = 0;
    int allocateSize = encryptedLength * sizeof(char);
    int lastDecryptLength = 0;
    char *decryptedData = (char *) malloc (allocateSize);
    memset(decryptedData, 0x00, allocateSize);
    int decryptResult = EVP_DecryptInit_ex(cryptCtx,
        EVP_bf_cbc(), NULL, key, iv);

    // EVP_DecryptInit_ex returns 1 if it succeeded.
    if (decryptResult == 1)
    {
        decryptResult = EVP_DecryptUpdate(cryptCtx, decryptedData,
            &decryptedLength, encryptedData, encryptedLength);

        // Note that EVP_DecryptUpdate will alter the value of the third parameter
        // to be equal to the amount of data that was written. This is not always the
        // entire length of the decrypted data! To finish the decryption process, use
        // EVP_DecryptFinal_ex. This will decrypt any remaining data.

        // Cleanup
        if (decryptResult == 1)
        {
            // Stick the final data at the end of the last
            // decrypted data.
            EVP_DecryptFinal_ex(cryptCtx,
                decryptedData + decryptedLength,
                &lastDecryptLength);
            decryptedLength = decryptedLength + lastDecryptLength;
            decryptedData[decryptedLength – 1] = ”;
            printf ("Decrypted size: %d\n", decryptedLength);
            printf ("Decrypted data: \n%s\n\n", decryptedData);
        }
        else
        {
            printf ("EVP_DeccryptUpdate failure.\n");
        }
    }
    else
    {
        printf ("EVP_DecryptInit_ex failure.\n");
    }
    EVP_CIPHER_CTX_free(cryptCtx);
    EVP_cleanup();
    return decryptedData;
}


What is worse for password strength, a poor password policy or no password policy at all? Recently I saw the following screenshot on Twitter, describing a obviously terrible password policy:

I wonder what is worse for the password strength. Having no password policy at all or a poor password policy (like described in the screenshot)?

The question is: worse for what?

With the policy you posted, the possible passwords are less than 64⁸ (~2.8*10¹⁴). In practice, very much passwords will probably be [a-z]*6[0-9][special char] (e.g. aabaab1!) and similar passwords.

All possible passwords with the same characters and length less than 8 are just 64⁷+64⁶+64⁵+... which is ~4.5*10¹². Thats a lot less than the passwords with length 8, so it doesn't increase security much to allow them. (allowing longer passwords would obviously increase security a lot)

Without any policy, many people will also use bad passwords, sure. But an attacker can't be sure about that. Also some people will use better passwords.

Without any policy, an attacker can never be sure how hard it is to crack a password. If you give me a DB of password hashes, I might try to crack it. But if there are no results, after some time I might stop. With the policy in place I can be sure that after 64^8 tries I have all passwords.

I would say, a bad password policy is worse. But it depends on the attack scenario.

With a dump of password hashes, with no password policy it is very likely easier to crack any password but harder to crack most passwords.
With a bad policy like the one given, it is easier to crack all the passwords but slightly harder to crack the first one, most likely.

If your concern is how hard it is to crack your own password, without any policy you can use a secure 20 char random password if you want. With the policy in place, you are forced to use a insecure password. (in practice, it's more relevant how the passwords are stored and so on, but that's out of scope here). So as a user of the website/service, a bad password policy is a lot worse.

If you look at it from an organizational standpoint, a bad password policy is way worse than none.

No password policy means, probably nobody thought about it (not very good that they don't think about security, but ok...)

But a bad password policy means: Somebody thought about it and came up with that crap. This means they probably have no clue about security.

In the end, if you can implement a bad password policy, you can also implement a good one so there is no excuse for a bad password policy ever. Just changing the policy to "A password has to be at least 8 characters" would increase security a lot and isn't hard to do.


Security of LXC compared to OpenVZ For years, I'm now using OpenVZ on my server, but support discontinued for Debian and Ubuntu, current releases seem to focus on LXC now, which is not a bad idea from the point of comfort.

But what about security? I remember I read once that LXC doesn't provide the same level of process and container separation than OpenVZ does. Unfortunately, I cant find the document anymore, but I agree there might be some security issues at least in the default configuration of LXC. For example, with a completely customized rootfs I managed once (in an older version of LXC) to change the host's terminal from an LXC container using chvt 1 and pressing Ctrl+C ended in a restart of my X11 environment when I tried to reproduce it today. I know, all container solutions use the same kernel and a kernel hack can lead to a container breakout, that's not what I ask. But it shouldn't be that easy to influence the host or other containers from a container.

How much security can I expect from OpenVZ and LXC?

My server exposes some guest ports to the internet, so I really care about this aspect, but I have to make a decision because the currently used tools need to be upgraded. Using KVM or similar is not an option since my server has a low-performance CPU.

PS: I'm speaking about the real OpenVZ implementation with vzctl 4.7.2-1. Some newer implementations of vzctl use LXC techniques.

(Disclaimer: I am not an authority on OpenVZ. This answer is more opinionated than my answers usually are, so feel free to criticise!)

OpenVZ might be "more" secure in that it does not integrate with the entire kernel, so that its attack surface is a bit lower. Though, essentially OpenVZ is what served as inspiration for namespaces and hence ultimately, LXC and Docker. I don't believe it's going to be continued for long now that those more complete solutions are, well, complete.

As pointed out by WhiteWinterWolf one of the big differences is that LXC finally gets to use the user namespace, opening the ability of unprivileged users to run containers and ensuring that contained code that breaks out of the container retains unprivileged users' privileges. Also, namespace-based containers may eventually be fully SELinux-labelled. Docker containers normally already are, and Dan Walsh is working on a way to make SELinux automatically enforce an extra layer of isolation between containers by using randomly generated categories for contained processes.

So in summary, containers are better because:
- They can partially thwart some container breakouts (limiting them to an unprivileged UID), making privilege escalations inside the container irrelevant.
- They are more supported and more actively developed, and in particular they'll greatly benefit from SELinux support.

And they are worse because:
- Their TCB is very large, across the entire kernel and bugs will occur every now and then leading to exploits and breakouts.
- The user namespace feels to me to be kind of an edge case. You usually achieve privilege escalation via a bug in the SCI (which you would be able to reproduce after your breakout) or confused deputy attacks on a privileged service (which are likely to keep existing outside your container in the first place). So you would still need to tightly limit that container-running UID to running containers.

In summary, keep practising defence in depth, and keep thinking about how you let contained processes interact with the outside world and how you run containers. Differences exist but as you can see are rather minimal.


What is the need of security token to prevent CSRF attack? I have a REST API which is running in one domain and I have a client in another domain. To prevent CSRF I have configured REST API to accept request originated from client application only. I have added proper encoding as per owasp XSS prevention cheat sheet to prevent any XSS attack on my application. Can I say that my REST API is safe from CSRF attack? Do I even need a synchronizer token to make my API safe?

As per my understanding of CSRF or XSS attack can lead to CSRF attack, as i am preventing both of them, is my application is vulnerable to CSRF?

To prevent CSRF the most effective method is to provide a CSRF token along with every request.  This is a token that is generated on the server side and associated with a particular session.  Then whenever that session submits a request, your server side code will check to confirm the correct CSRF token was submitted.  If it was not, a CSRF attack has taken place and the request will be rejected.

Often times these tokens are stored in hidden fields, but if you are using a REST API then I suspect you are making a lot of AJAX calls and this probably isn't the best method.  I would suggest creating a global javascript variable that is initialized with the CSRF token one time and then accessed whenever submitting a request.  If you are using something like jQuery it is fairly easy to include another request parameter in all AJAX calls, so this might be an option as well.  The latter is typically what I do, and it makes for much cleaner code.

Here is a link to OWASP's CSRF prevention cheat sheet.  I would recommend giving it a read.


Tamper Protected VS. Tamper Proof for write-protected memories I read in the answer here by Marcus that ROM is Tamper-proof.

What is the difference between tamper-proof, tamper protected and tamper-resistant?

Now, there are some re-writable memory (eg. eNVM) that can be configured to have some of its pages as write-protected (set as ROM option) (Read-Only VS. Write Protected). In that case, can we consider that the configured ROMs are Tamper-protected? or they are only tamper-proof?

About tampering

Dan Kaminsky from "The Motherfucking Professionals" held a great talk at Blackhat 2011 regarding tamper-evident, tamper-resistant and tamper-proof devices. One of the key points he made was that there is no such things as a tamper-proof device! Anything can be tampered with, and it's up to whomever it may concern to see how far one would go to check for tampering.

He explains the meaning of those three words:

Tamper-Evident: A tamper-evident device does not stop you from accessing something, but it makes it evident that you did. A good example for tamper-evident devices are those G-force stickers used on packages. They don't stop someone from handling a package roughly, but it will be evident (by the broken glass) that it was handled roughly.
Tamper-Resistant: I assume that this is the closest to "tamper-protected" in your original question. A tamper-resistant device will actively attempt to prevent you from tampering with something. So it's a bit of a middle-ground between a lock and a seal.
Tamper-Proof: A device that claims to be tamper-proof is a device that is impossible to tamper with. It's effectively as real as a lock that claims to be pick-proof. As I already mentioned in the comments, nothing is tamper-proof.

From this list, you can see that tamper-protected is a stronger claim than tamper-evident, and tamper-resistant is a stronger claim than tamper-resistant.

About Memory

Neither ROM nor other write-protected memory is tamper-resistant or even tamper-evident, at least not by default. While these devices are designed to not be writable, they are not designed to be unique. That means, I can take one ROM chip out of a device, and insert a different ROM chip (of the same model) with my own data, and I have tampered with the device. If my soldering was on point, it will not be evident at all that this has happened. As such, any regular ROM fails at being tamper-evident at all.

Are there ways to make it tamper-evident?

Yes, there are. You could, for example, put a cryptographic signature over the contents of the ROM and a unique serial number. That means that without the knowledge of the private key being used, I will not be able to modify the content of the ROM without the signature check failing (which would make it evident that I tampered with the ROM).

This could be circumvented by replacing the public key that does the verification with my own public key, that I used to sign the tampered ROM contents with. But then it again remains evident that the ROM was modified. It depends on who does the checking, and how thoroughly they do.

You could also attempt some physical tamper-resistance. A simple example would be a solid epoxy blob over the chip. Yes, it will not stop a dedicated attacker, but it makes it harder to tamper with the thing, so it fits our definition for tamper-resistance (and you will now realize that we never specified how well something has to resist).

All in all, any tamper-resistant or tamper-evident device or measure can be defeated by a skilled and dedicated attacker.


Would it be possible for an ISP to guess specific requests on an HTTPS site using package size? In light of the recent senate decision in the US to allow ISPs to sell users' browsing history, I've been reading of recommendations on how users can retain their privacy. One of the common recommendations is to restrict your browsing to HTTPS sites, so that at least on-site content remains private even if domain activity is no longer private.

Though thinking about this, ISPs could surely make some basic deductions quite easily - e.g. high download rate on youtube.com suggests watching video, high upload rate on said site suggests uploading video, etc.

Taking this approach further, I wonder if ISPs could guess specific page content by using HTTPS request size? E.g. that "tech security / possible bias against Republicans" article from Ars Technica I linked is a 16.77 / 16.78 kB transferred response size for just the base HTML page. Whereas another article that fits the "weather nerd" category is usually coming in at 13.34 kB.

Now of course this is going to depend on the dynamic vs static/caching nature of the page, and particularly if there is substantial user-specific tailoring to each HTML load.

Though does this concept stand? Am I correct in thinking that encrypted request size via HTTPS is going to be almost exactly proportional to underlying request size?

Thinking about possible solutions, sites could obfuscate articles by filling in with junk HTML (e.g. a big comment section) to minimise uniqueness. Likewise images could be compressed to identical sizes, making a simple mapping approach for any ISP / packet-sniffer ineffective and requiring more substantial pattern recognition. Though of course this is somewhat moot, as what domains have been visited and when is already more than enough to build an online profile.

Effectively you are asking about fingerprinting web browser behavior when visiting specific pages on a website. Yes, this is definitely something which can be done but the accuracy will vary from site to site depending on how much the web pages themselves vary and typically people doing this type of analysis are also gathering a little more data than just HTTPS request size (although in some cases HTTPS request information is all you would need).

Keep in mind the ISP's are actually getting a LOT more data including DNS requests, timing information for page loads, additional browser assets that may be loaded (javascript, 3rd party CSS, web fonts, etc..) and requests for files hosted on a Content Distribution Network CDN or a secondary image server, or remote ad server requests and some things like Google Analytics at the same time.

Add all of this additional data and fingerprinting what the browser is doing at any given time becomes much easier even with HTTPS enabled on the main site being visited.

Think of the following three requests to a website.

1.) The main page containing 15 images across 2 hosts and 2 CDN's as well as a banner ad. This page also loads a Javascript library from a remote site as well as some web fonts from yet another website.

2.) A secondary page containing 3 images that are hosted on 1 host and one large image hosted on a CDN, some HTML content from 1 host and 2 new javascript library connections.

3.) A third page containing very specific information of interest hosting a much longer HTML page, a few very large photos all from only 1 host (not accessing a CDN) and maybe this website took a few milliseconds longer to load since the web server no longer had it cached in ram.

These are overly simplistic examples but what you can start to see is that each web page in these examples has a unique fingerprint when loaded by a browser. Many websites have very homogenous pages which won't lend them self to such easy fingerprinting but this is primarily for example purposes.

In any case, since these unique fingerprints can be created and even proactively analyzed by large search engines or bots (or simply collected in mass by the ISP's). It does make it very easy in some cases to predict what a user is doing and in many cases exactly which page on a website is being viewed.

As far as request sizes being the same you also have three additional variables to keep in mind:

1.) Compression algorithms negotiated between browser and server for data being sent.

2.) Packet size variation due to additional factors like type of network.

3.) Dynamic pages with things like news feeds will change in size.

Even with a couple of variables like these, it would still be possible to reasonably approximate which page a person is loading. It won't be an exact one-to-one size to page comparison but for certain browsers under certain conditions the data size will frequently be the same and the range of behaviors will likely be very closely grouped together.

Finally, a bigger concern is the aggregation of many different types of data and compiling that information about customers so that customer profiling can happen with only a few clicks and comparisons with other data sets. ISP's will get an amazing amount of data about end users from every device in their houses that communicates out.


How to avoid log4j output external modification I had a request to find a solution for making a log file secure from editing from the user (not root user) running the JBoss instance of an application (Linux environment)

First idea I had is to use the 'chattr +a' from root user to allow only the appending of new raw in the log file.

But the Log4j file is configured to rotate the file each day and for this reason I suppose that I should repeat the 'chattr' command for each file created everyday. I also not sure that the past day file in its "append only" state can be zipped from rotation.

Any suggestion or alternative way to proceed is welcomed.

You could use the SyslogAppender

This sends all logs to syslogd (which can be on a separate server). You could configure the log files to be non-accessible by the application user, while syslog takes care of rotation.


sha512 as no-login-necessary token My site has a news subscription system. When an item is updated, a notification email goes out to everyone subscribed to that item.

You can un/subscribe via a form on each item's page.

I wanted to include a direct unsubscribe link in the notification emails. Then I figured people might be logged-out, or viewing the email on a different machine from their login (we don't allow users to be simultaneously logged-in on different machines), so I wanted to create a one-click unsubscribe function that does not require someone to be logged-in.

Naturally, this meant a (hopefully) unique token.

My test solution is this:

when a user subscribes to an item, a token is generated via sha512 on a concatenated string of various things (username, datetime, itemid, etc.)
the unsubscribe link includes the item ID, item type, and token as GET parameters
if and only if all three things are matched on one row in the user_subscriptions database, the row is removed thereby ending the subscription

This works, and I suspect it is adequate for this non-security sensitive task of subscribing and unsubscribing to news posts.

What leads me to Security.SE is the larger question of how secure is such a token system for other actions?

sha512 yields a 128 character hash, plus you'd have to nail the ID and Type of the action you wish to perform...

One security problem with your approach is that everything that you are hashing may potentially be guessable.  As a result, tokens may be guessable.

A simple fix is to generate the token randomly: use a random 128-bit string from a cryptographically random source (e.g., /dev/urandom or CryptGenRandom) to form a single-use token.  Store the token in the database along with information about the desired action, and when you receive a request, if it contains a token found in the database, take the action suggested by that database entry and delete the token.  If you take this approach, don't include anything like item ID, item type, etc., in the URL.  Instead, store that in the database.

Alternatively, you could include some unguessable secret (e.g., a 128-bit cryptographic key) as part of the input to the hash function.  When you receive the request, you'll need to recompute the hash function (using the parameters in the request) and make sure the provided token is correct.  Make sure that all of the parameters in the URL are included as part of the input to the hash function (otherwise someone could change that parameter without invalidating the token).

As @AaronS notes, if someone forwards the email, then the recipient of the forwarded email learns the token.  Thus, this scheme is not perfect.  For some uses (e.g., unsubscribing), it may be good enough.  For others (e.g., managing access to an online banking account), it is not a good choice.


Storing multiple hashes to prevent collisions, security risk? This is all just for curiosity's sake, so discussion on which hashing algorithm is harder/better/faster/stronger is irrelevant. But my question/thought is this..

With regards to password storage, and to prevent hash collisions, I was thinking that one possibility would be to create one hash that is basically salted and hashed, and then create any number of alternate hashes where the password is modified in some unique way (Rot-13, Reversed, etc.), then salted with a different salt and hashed. Then store and compare all the hashes when logging in.

Would this situation be easier to crack, given that the attacker has more information to get at the actual password?  Or is it more difficult given that the attacker now has to crack multiple hashes to get at the password?

UPDATE: let's assume the hashing algorithm used is something ridiculous (and fast) like MD5, and that the attacker has gained access to the database through whatever means.

Also, some of the modified hashes may have been run through a hashing algorithm as part of it's "modification".

This is not a good idea.

The first reason is that collisions are not an issue. For password hashing, you don't rely on resistance to collisions, but on resistance to preimages. There is no need for a password hashing function to admit easy-to-build collisions, but if it does, this is not a problem either. For instance, collisions can be built with PBKDF2. And we don't mind.

The second reason is that the attacker intent on finding a password which matches a given hash has no need to compute several hashes. The attacker tries a long list of potential passwords, but that list is way smaller than the hash function output range. The consequence is that when the attacker finds a matching password, it is the password -- and this is so even when the attacker works over a single hash function. Therefore, though you spend the CPU to compute several hashes, the attacker is perfectly content to work with only one. In other words, the several hashes waste your CPU. This is important because you normally want to use a slow hash (with a configurable number of iterations) so that attacks are made slower. By doing the job several times, you force yourself to lower the iteration count, thereby automatically giving an advantage to the attacker.

The third reason is a generalization of the previous one: the attacker only needs to work on one hash value. If you provide several, then this can only help the attacker: he will choose the one which makes things easiest for him.

Summary: your "several hashes" idea does not solve an actual problem, but it may help the attacker. So don't do it. As @Iserni explains, use bcrypt. For a more detailed treatment on how password hashing should be done, read this.


When to use the different types of Encryption / hash algorithm? I'm studying for CISSP and know they will ask what type of encryption to use in different situations. Does such a list exist or is there a general rule of thumb to use?

I think in general you'll need to understand the difference between symmetric and asymmetric encryption.  Symmetric algorithms are faster and stronger per bit of key length than asymmetric algorithms.  But symmetric algorithms require a pre-shared key and asymmetric algorithms do not.  So, in situations where strength and speed is required, and securely pre-sharing a key is possible, you would use symmetric ciphers like AES.

In practice, cryptographic hashes, symmetric and asymmetric encryption are combined to provide a more complete solution.  For example, asymmetric encryption can be used to exchange the keys for symmetric encryption.  This is how Secure Sockets Layer (SSL) works.


Why would Bill Burr of NIST say N3v$r M1^d? Wall Street Journal wrote that Bill regrets his password recommendations NIST SP 800-63 Appendix A.

Apprendix A is titled "Estimating Password Entropy and Strength". It is about how we might assess password strength - not about rules to control password creation.

Bill discusses hyperthetical password rules and posits how a user might comply with these rules and how their behavour is likely to affect password strength or entrophy calculation.

For example, elimination of dictionary words (for short passwords) and requiring uppercase, lowercase, digits, and symbols means an attacker needs to check fewer combinations.

Same for checking against a database of common passwords.

Bill believes that dictionary and composition rules generally improve “practical entropy” of passwords.

But Bill warns that enforcing uppercase, digits, and symbols is likely to result in a change at begining or end of a password and hence discounts entrophy value of using these characters within a password.

Discussion concerning frequency of changing passwords is limited to assessing likelihood of an attacker being successful in an in-band attack.

Articles like this one from theverge based on WSJ article, claims that Bill recommended passwords be changed every 90 days - It does not suggest this.

Am I reading wrong document or reading document wrong?

Did NIST ever recommend uppercase, digits, symbols and 90-day or regular enforced changing of passwords?

Data

The Wall Street Journal article says:

  The problem is the advice ended up largely incorrect, Mr. Burr says.
  Change your password every 90 days? Most people make minor changes
  that are easy to guess, he laments.

In that context the "90 days" appears to be his current summary of what was put in place as the result of his recommendations 15 years ago.  I do not read that as quoting NIST 800-63 v1.0 as saying "90 days" anywhere.  And when we look at the Verge article, which appears to be based on the WSJ article, they've changed that to:

  Even worse, Burr suggested people should change passwords regularly,
  at least every 90 days.

I don't get that from the original quote, and I think that it's a mis-representation of the original quote.

So let's look at the "original", or at least, the oldest version I can find: NIST SP 800-63 Version 1, September 2004.  (A list of many versions is available from NIST.)

Appendix A does not contain any reference to 90 days.  It does contain a reference to 90 years:

  Such a lock out would suffice to limit automated attacks to 3 trials a
  minute and it would take about 90 years to carryout 2^25.5 trials. If
  the system required that password authentication attempts be locked
  for one minute after three unsuccessful trials and that passwords be
  changed every ten years, then the targeted password guessing attack
  requirements of level 2 would be comfortably satisfied.

And he demonstrates how the entropy of a password and the lockout conditions can be used to calculate how susceptible a password is to online brute forcing:

  For example, consider a system that required passwords to be changed
  every two years and limited trials by locking an account for 24 hours
  after 6 successive failed authentication attempts. An attacker could
  get 2 ´ 365 ´ 6 = 4,380 attempts during the life of the password and
  this would easily meet the targeted attack requirements of level 2.

If you search for keywords like 'change', 'rotate', 'hour', 'day', 'month' you will not find any specific advice which says passwords should be changed every 90 days.

That's the data we have. Now:

Opinion

Appendix A of SP 800-63 v1 explained the idea of entropy as a measurable aspect of passwords, described ways that more entropy could be employed in password strings of given lengths, and drew a connection between acceptable password timeframes based on average guessing with online constraints.

In practice, a lot of people looked at that and said "Okay, so we'll set password complexity requirements, and require rotation, and we'll be A-Okay!"

In hindsight, this was regrettable, for the following reasons:

It discussed online brute force attacks, where delays can greatly slow down an attacks.  The combination of Moore's law and offline brute force attacks shredded those assumptions like a tiger with a box of goat-flavored Kleenex.
It had the overall effect of emphasizing short, complex passwords, just because it focused on exploring their mathematics.  But the fact of the matter is, the Appendix itself knew this wasn't preferred!  It said "...many people may prefer to memorize a relatively long “pass-phrases” of words, rather than a shorter,
more arbitrary password."  Fast forward today, and where are we?  "Passphrases are better than passwords."  It's not Burr's fault people ignored that.

In summary, NIST SP 800-63 v1 may have been as damaging as Burr thinks it was - but it wasn't his fault.  People drew short-sighted conclusions based on a report that stated up front how little data it had to work with in making recommendations.  It was better than nothing at the time and it has been our failure - choosing to rely on it, rather than trying to resolve the lack of empirical data that the report called out.

On that note, I'll leave you with this part of the Appendix intro:

  Unfortunately, we do not have much data on the passwords users choose
  under particular rules, and much of what we do know is found
  empirically by “cracking” passwords, that is by system administrators
  applying massive dictionary attacks to the files of hashed passwords
  (in most systems no plaintext copy of the password is kept) on their
  systems. NIST would like to obtain more data on the passwords users
  actually choose, but, where they have the data, system administrators
  are understandably reluctant to reveal password data to others.
  Empirical and anecdotal data suggest that many users choose very
  easily guessed passwords, where the system will allow them to do so.


Risks of allowing users to upload PDF and XML files to be stored/retrieved from a DB (ASPNET MVC 5) I'm modifying an ASPNET MVC 5 web site and a requirement is to allow users to upload an XML and PDF file.

The XML file will be used to layout text on the PDF based on variables coming from within the system.

I have a schema for the XML that can be uploaded - so I can validate against a malformed XML - and that the XML matches the schema.

Where I'm unsure is in worries about DOS and malicious code in the XML. Is checking against the schema enough or can malicious code pass the schema check?

Also, the PDF is just stamped with text content using iText - would I need to worry about something nefarious in the PDF?

Both files are stored as byte[] in a database and never on a file system directly.

Part of the site prepares the PDF with the XML content and displays to the user and another part prepares the PDF to attach to an email. (Just trying to give some context in its  use)

There seems to be so many places this could open security vulnerabilities and the client is using a 3rd party IT security vendor for this as well. I have to allow the functionality as I can't get around it.

Good moves to check XML for the correct schema, make sure you disable DTD as well and never allow a user input to modify XML schema, for that could result in a deserialization vulnerability.
https://docs.microsoft.com/en-us/visualstudio/code-quality/ca3075-insecure-dtd-processing?view=vs-2019

A potential vector could be, that the PDF content itself contains malicious stuff, but it is something you really can't avoid, because it is in the users control.


Zeus v3 - can I detect its existence "manually"? A firewall in my company was triggered by a DNS query from one of our laptops. Specifically, the exact reason was MALWARE-CNC Win.Trojan.Zeus v3 DGA DNS query detected.

Now, I could just follow this blindly and nuke the laptop in question from orbit, but this is disruptive and time-consuming. Ideally, I'd like to get confirmation that the problem is, in fact, this particular laptop and that it has been infected. The problem is, all attempts to actually confirm this have failed. All machines in the company are running up-to-date Windows Defender, and that hasn't reported anything and I've also scanned the laptop with a Kaspersky Recovery Disk, which also found nothing.

Is the Zeus bot basically undetectable beyond the DNS queries or does it leave a trace (like registry entries or other specific files that could be clear signals of an infection)?

EDIT:
Not sure if this is helpful, but this is the whole logged entry:

2019:04:02-13:25:00 firewall snort[5508]: id="2101" severity="warn" sys="SecureNet" sub="ips" name="Intrusion protection alert" action="drop" reason="MALWARE-CNC Win.Trojan.Zeus v3 DGA DNS query detected" group="241" srcip="10.150.4.104" dstip="10.150.1.34" proto="17" srcport="54103" dstport="53" sid="26267" class="A Network Trojan was Detected" priority="1" generator="1" msgid="0"
2019:04:02-13:25:09 firewall snort[5508]: id="2101" severity="warn" sys="SecureNet" sub="ips" name="Intrusion protection alert" action="drop" reason="MALWARE-CNC Win.Trojan.Zeus v3 DGA DNS query detected" group="241" srcip="10.150.4.104" dstip="10.150.1.34" proto="17" srcport="58112" dstport="53" sid="26267" class="A Network Trojan was Detected" priority="1" generator="1" msgid="0"

We're using Sophos UTM which has a prepared Snort rule set. I believe the ruleset can be viewed here: https://lists.astaro.com/ASGV9-IPS-rules.html

I experienced this exact problem and my Sophos firewall also indicated the same warning two times in close succession. After that, there has been no further warning.
Two additional observations here that really confuse me:
1). The laptop in question is a macbook running macOS 10.14.3, and
2). The laptop was not running at the time reported in the logs.

The firewall is Linux-based and my only Windows machine is on a separate subnet.
All our other devices are wireless running ios 12.2

I can only explain that as a false positive.

One small correction: My laptop was closed but apparently was still pinging the network, according to the logs.

CRIT-861: MALWARE-CNC Win.Trojan.Zeus v3 DGA DNS query detected


Routing Protocol Encryption As far as I know 'newer' versions of routing protocols support authentication between routers.

What about encryption and integrity checks? Some implementations like this one from Cisco use MD5, which I dont feel secure using. How do you protect against MITM tampering with your routing tables?

Is there any easier way to protect from using IPSEC between your routers?

OSPFv3 uses IPSec if you don't know much about IPSec I wrote a paragraph about it in another answer which should give you some more information.
In Ciscos implementation of OSPFv3 they use MD5 correct, however, it's not to keep the data safe, it's merely used as an authentication check. You can read more about OSPFv3 in Configuring IPSec. IPSec is pretty secure I don't think you have any reason to feel that it's not, for confidentiality of data you can use AES-CBC 128/192 but more is in the link I provided.
I believe Cisco's implementation has thrown you off a bit as you've seen MD5 and instantly assumed "bad" however that's not the case, they're not encrypting the data with it else that would be bad.

Regarding people "tampering with the routing tables" I find this section to be a little unclear. If you're worried about local credentials on newer Cisco devices/versions for local credentials, you can use Type-8 passwords, you can read more about this here

Just to add to this Forest's comment on it being used as an HMAC is correct.