What does it mean to "burn a zero-day"? I noticed a comment on this answer where another user said

  ...but it requires risking burning a 0day, which people are not always all that willing to do.

I did an Internet Search for the phrase "burning a 0day" (and similar permutations like 0 day, zero day, etc) and not much came back.  It's obvious that "burn" means "use up" in this case.  I understand most of what the user meant, but probably not all of why it was important (aka context).  I'm looking for a canonical answer, with some reasoning about why "burning a zero-day" is an expensive thing.

Mr Robot s01e06 touches on this when Elliot and Darlene start to argue about what went wrong in their attempted hack.

I found some other people on this SE using the same terminology:

Answer: https://security.stackexchange.com/a/184541/71932
Answer: https://security.stackexchange.com/a/184217/71932
Answer: https://security.stackexchange.com/a/162416/71932
Answer: https://security.stackexchange.com/a/175535/71932
Answer: https://security.stackexchange.com/a/182288/71932
Comment on this answer: Do drive-by attacks exist in modern browsers?

I was the one who wrote the comment you quoted.
Quick answer: A 0day is burned when the exploit is used too often or haphazardly, resulting in it being discovered and patched. Virtually every time a 0day is used, it risks being burned. Using a 0day more sparingly and cautiously can increase its shelf life. The idiom intends to compare a 0day to a non-renewable resource like combustible fuel that loses its value when used up.
This likely originates from the idiom burn your bridges:

To destroy one's path, connections, reputation, opportunities, etc., particularly intentionally.

What is a 0day?
A 0day is an exploitable vulnerability that is not publicly known. When a 0day is discovered, it can be turned into a working, "weaponized" exploit. Like all vulnerabilities, if it is discovered in public, it will usually be patched and fixed, making it so the exploit no longer works. Every time you use an exploit, you necessarily transmit valuable information to a system that you do not control (yet). If the system is being extensively monitored, the exploit technique may be discovered and with it, the necessarily knowledge to fix the vulnerability and roll out patches to all affected systems.
What does it mean to "burn" one?
I was the one who wrote the comment you are referencing. To "burn" a 0day is slang for using it either too often or using it in a high-risk situation where it is likely that it will be discovered because of its use. Like combustible fuel, once used up or "burned", a 0day will no longer hold the same value (both in monetary terms* and tactical terms). It stops being a 0day once it is no longer in private hands.
Friends may let you "borrow" a 0day to use yourself, under the condition that you do not burn it. This means they are telling you that you can use it, but they are trusting you to be very careful not to use it in a way that makes it likely that it will be found and fixed, depriving access to it.
Someone might decide to disclose the 0day suddenly in public. Especially when it's not done using coordinated disclosure, it's often called dropping a 0day, which will also burn the 0day. This is a bit uncommon but not unheard of. A few years ago on IRC, a guy joined and informed us of a remote code execution vulnerability in TeamViewer that involved sending malicious WinHelp files (which contain Visual Basic code) or something along those lines. Since the first place he disclosed that was in the middle of a general security-related IRC, he was burning a 0day by dropping it.
* 0days usually have literal monetary value. A 0day can range from a thousand dollars to upwards of a million, depending on a variety of factors such as exclusivity, applicability, reliability, specificity, conditional nature, etc.
How much are 0days worth?
Exploit brokers often buy or sell bugs with promises of exclusivity. For example, you can sell a bug under the condition that it is sold for the highest price to only one person, not to multiple people. That reduces the chance that it will be discovered, but it means you only get paid once. Alternatively, you could sell an exploit to as many people who want to buy it. You would have to sell it for a lower price because it will be burned very quickly, making its shelf life rather short. Obviously, when a 0day is burned, it is no longer nearly as useful since it will only work on outdated systems. The actual value depends on quite a few factors. They are worth more if they:

Work on a variety of systems.

Do not depend on a specific configuration.

Are reliable and work every time.

Are silent and do not leave traces in the logs.

Are sold to only one or a limited number of buyers.

Many contractors that deal in exploits will pay you the complete price in small sums over a period of time. If the 0day is discovered before you are paid in full, they will stop the payments. This behaves as disincentive to selling it to multiple contractors or using it frequently yourself. It essentially forces you to guarantee to them that it will remain a 0day, or you simply will not be paid in full.
Additionally, 0days are bought for more by government contractors than by random exploit brokers. You might be able to sell a complete Chrome exploit chain complete with sandbox bypass and local privilege escalation (LPE) for hundreds of thousands of dollars to Raytheon SI. The same exploit would net only a fraction of that price if you sell it to J. Random Broker on IRC. The reason is simply that corrupt governments want to be non-competitive and have ample money from tax payers to obtain exclusive vulnerabilities so they can drone strike journalists protect their nation.

How do 0days get burned?
There are many activities that can risk burning a 0day. A few examples:

Using an exploit that is unreliable and may create a coredump.

Using an exploit that is conditional and only works for some configurations.

Using an exploit that results in an event being logged.

Using an exploit against a sophisticated and paranoid target.

Simply using an exploit too often, increasing its exposure.

Giving it to or trading it with a friend who is not responsible with it.

I do not condone selling 0days to governments or government contractors.


Can I restrict a Certification Authority to signing certain domains only? Is it possible to create a CA certificate (even unsigned), which is only allowed to sign certificates for specific limited domain(s),  so that it can't be misused for other domains?

Thomas Pornin's answer is good, but a little outdated. Support for Name Constraints is growing.
I've found that OpenSSL 1.0.1k and Windows 7 support the extension.
Test
Using XCA, I created a self-signed CA certificate, and added a critical Name Constraints extension for .lab.example.com, by adding the following line on the "Advanced" tab during certificate creation:
nameConstraints=critical,permitted;DNS:.lab.example.com

Note: the constraint should not have a leading dot. It's technically incorrect, but support for this is expanding: https://github.com/golang/go/commit/e4dafa32620e80e4e39937d8e2033fb2ee6085f8
Then, I used that CA certificate to sign two other certificates for HTTPS servers:

test.lab.example.com - Valid
bad.google.com - Clearly invalid

Next, after setting up DNS entries accordingly, I used this modified simple-https-server.py to run an HTTPS server, once with each of the generated certificates:
./simple-https-server --certfile test.lab.example.com.pem --hostname test.lab.example.com

and
./simple-https-server --certfile bad.google.com.pem --hostname bad.google.com

After installing the CA certificate into the OS trust, I then tried to visit each site with several clients.
Results
OpenSSL 1.0.1k seems to support this. curl gave me the following error when I tried to visit bad.google.com:

curl: (60) The Certifying Authority for this certificate is not permitted to issue a certificate with this name.

Chrome on Windows 7 also does the right thing. Chrome gives a fairly generic net::ERR_CERT_INVALID, but Windows certificate viewer is quite explicit:

The certificate has an invalid name. The name is not included in the permitted list or is explicitly excluded.

References

http://karl.kornel.us/2014/09/cas-name-constraints-and-a-business-opportunity

Update 1
I also tried signing a certificate that did not specify a Subject Alternative Name, instead relying on the old common-name only.
OpenSSL / curl still refused to accept the certificate.
Both Chrome and IE11 on Windows refused to accept the certificate on Windows, even though windows itself (when viewing the server certificate) didn't complain about it. To me, that means that the browsers are doing more than simply asking the OS to verify the certificate, which is a good thing.

Note that name constraints are not properly supported on OSX earlier than 10.13.3 which was released early 2018.

Conclusion
I feel secure in asking others to install my root CA certificate, without putting them at any risk.


What's there to harden for a home Unix-box behind Comcast cable modem? I'm learning that much of the security advice I come across under the "hardening" heading simply does not apply to a single-user home desktop box sitting in a private wireless IPv4 LAN behind a Comcast cable modem.  Furthermore, FWIW, this system is Unix-based, and sudo is used whenever superuser privileges are needed.

My understanding (please correct me if I'm wrong) is that such a machine is basically "invisible to the outside", and thus cannot be specifically targeted, out-of-the-blue, by some random attacker.  (See https://security.stackexchange.com/a/7831/49340.)

Therefore, AFAICT, the only significant vulnerabilities for such a machine would fall into one of four broad categories:

"physical access" (e.g. a break-in);
insecure passwords and/or weak password management;
vectors inadvertently downloaded by the user while browsing the web;
remote (third-party) site vulnerabilities.

The last category above, 4, refers to the exposure to home computer A that may suddenly arise when a third-party site B, holding confidential information about A, suffers a security breach, thereby rendering A more vulnerable than it was before.  There's not much that the owner of A can do to prevent this, other than avoiding giving sensitive information to insecure third-party sites (which is, of course, easier said than done).

Regarding category 1, one thing that the owner of home desktop A could do to reduce this vulnerability would be to encrypt the machine's storage media using a strong password.

As for categories 2, a decent keyring-type program should offer adequate protection.  And for category 3, which is probably the most significant of all four, adopting "safe browsing habits" (including always browsing the web as an non-privileged user) is just about the only thing one can do.

I see very little "machine/OS hardening" in any of the above.  (Or, to put it differently, I don't recall seeing any of the measures described above in the many articles, posts, etc. that I've read in the general category of "hardening".)  The one possible exception is the business of encrypting the machine's storage.

So my question is: how applicable is "hardening" to a home setup like the one described above?  Have I missed some major security areas for which "hardening", as typically understood, would be of significant benefit to such a system?

(EDIT: clarified that the system is Unix-based, and that the browsing is done always by a non-privileged user.)

There is one major category of home hardening that you missed, at least in part. 'Vectors downloaded by the user' is a huge category. It is the most used attack vector today.

A lot of attacks don't require any user interaction to run.  See drive-by downloads for an example.

While you are correct that safe browsing habits are a good way to address this catrgory it simply is not enough. Perfectly normal sites are used to spread malware all the time. I have seen Facebook and yellowpages.com both spread malware.

Hardening (in the form of patches, service isolation, even wiping out changes to the system at reboot) is definitely applicable in a home setting. While you can't eliminate the threat 100 percent, you can reduce it greatly.

Edit: What I am trying to get across is this.

A good policy on safe browing habbits is a great place to start.
A good browsing policy is still ineffective with today's threat landscape.
Antivirus / antimalware isn't enough.
Updating software isn't enough.
Even with all of the above it still may not be enough.


VirusTotal shows that APK contains Exploit and Trojan, how trustworthy those flags? I found that some client apk triggers multiple red flags during VirusTotal scan:

https://www.virustotal.com/#/file/6341be988be00042c698511fd88c97c618e6109afac40fdf5bed52383bcdf18e/detection

Exploit.Linux.agz, TROJ_GE.521F1419, TROJ_GEN.F04JC00IA17

Looks pretty serious. But how do I interpret those results? How serious  and how trustworthy they are?

Koodous (a cloud-based mobile-AV scanner) does not do an analysis of this particular APK -- https://koodous.com/apks/6341be988be00042c698511fd88c97c618e6109afac40fdf5bed52383bcdf18e

but if you look at the subject and issuer attributes for the Android certificate, this malicious app is similar (contains the string rtt) to other ones that have been analyzed -- https://koodous.com/apks/6cea48dd0aa2cf5d5bfcf6c8a162f5a13624aa4429ee494c0f8d6583b204a98f -- (VirusTotal for this second one here -- https://www.virustotal.com/#/file/6cea48dd0aa2cf5d5bfcf6c8a162f5a13624aa4429ee494c0f8d6583b204a98f/details )

This analysis clearly shows that 8 out of 97 Koodous-analyzed APKs with the same cert also contain adware/malware -- https://koodous.com/apks?search=cert:2DAF3283B6EA6F38238102C7B236A22E85A4C2F1

If you look at the Interesting Strings section for the APK you ran through VirusTotal -- https://www.virustotal.com/#/file/6341be988be00042c698511fd88c97c618e6109afac40fdf5bed52383bcdf18e/details -- you will see http://api.share2w.com/stat/adrequest, which is a malicious domain and URL.

As the other answer eludes to (and in the same details section described in the last paragraph), the APK contains one or more Linux executables. In your APK's situation, at least one of the binaries it includes was found on the filesystem as /r/m/su.png which is the su binary used for Linux/Anroid privilege escalation. I have no idea why this made it into the Google Play Store, but the APK is also available in the AppChina app store / app market.

In addition to the su binary, the APK also contains the following suspicious/malicious code:

private void a(File object, InputStream inputStream, String string2) throws IOException, InterruptedException {
    int n2;
    if (!object.getParentFile().exists()) {
        object.getParentFile().mkdirs();
    }
    String string3 = object.getAbsolutePath();
    object = new FileOutputStream((File)object);
    byte[] arrby = new byte[1024];
    while ((n2 = inputStream.read(arrby)) > 0) {
        object.write(arrby, 0, n2);
    }
    object.close();
    inputStream.close();
    Runtime.getRuntime().exec("chmod " + string2 + " " + string3).waitFor();
}

It probably also contains other malicious logic, but these are enough to conclude that the APK is indeed some sort of adware/malware.


Does having in-browser password managers further the risks of successful CSRF attacks? When successful CSRF attacks are executed they have the ability to access credentials and other information between the victim and the site. Are the sites username and password that are stored in the password manager also visible? Or is that out of the scope for this attack?

The term "CSRF" is very broad and, in my opinion, your definition of CSRF is not entirely accurate. A CSRF vulnerability's abilities depend on what endpoint is actually vulnerable to CSRF. Being able to send a request on behalf of a user that changes their profile picture, for example, wouldn't fall under your definition of CSRF above. If you have discovered a CSRF vulnerability on example.com, for instance, this does not necessarily affect your password manager per se. A far more significant attack in the context of password managers, is stored XSS or a subdomain takeover whereby an adversary can trick the victim's password manager into auto-filling a sign-in form, because the password manager trusts the origin.

(Source: https://twitter.com/albinowax/status/1011623832766111744)

It sounds to me like this is probably what you had in mind but were associating this attack vector with CSRF. On the other hand, a CSRF vulnerability in your password manager might be something to be concerned about, but that is a vulnerability in the password manager itself and not the page the user is currently visiting.


Scan for mobile phones? I'd like to measure queuing time, similar to what they're doing in Finland. Instead of detecting bluetooth (which is disabled in most phones) I thought of detecting EDGE/3G.

I'd like to log the following information:

Phone 1 entered the zone at 14:00 and left at 14:30
Phone 2 entered the zone at 19:05 and left at 19:30

etc.

How do I uniquely identify EDGE/3G/etc phones that enter a zone?
Is there a better/easier way to uniquely identify phones entering/exiting a physical location in a manner that allows them to remain anonymous?

By "uniquely identify" I mean I want to be able to differentiate between the same phone entering the zone multiple times versus different phones entering.

By "anonymously" I mean I don't want to record any information that would allow anyone to track down the phone's owner.

Okay, this is very easy if you are the GSM base station as the phone sends unique codes on first contact to that base station. However the legality of setting up your own base station and such may be problematic, depends on country, frequency, power and what radio spectrum licenses you have. As for anonymously doing it, fundamentally, you want to track phones uniquely in your area someone else can track them too, from that data. In fact, phone operators deliberately designed it not to be anonymous so they can track phones for charging the going rates for placing calls and the like.


Can Android 5's own device encryption mechanism be exploited by a malware? My wife's phone can't boot into android and instead displays a message that encryption has failed and all data is lost. She did not start the encryption process by herself. Now my question is: can android 5's own encryption mechanism be hijacked by ransomware? (and not by means of some custom implementation manually encrypting contents of the photo folder for example)

Right now I'm trying to get to the data using TWRP, but I think to no avail as the internal storage folder is empty..

The android she was using was cyanogenmod 12.1 (android 5.1.1) for a galaxy s3 gt-i9300.

Why the encryption process itself failed, I don't know but it could be due to low battery as when finding it in this state it was at 3% or so. Though as I did encrypt my s3 manually and on purpose, encryption would only start with battery being at 100% and the phone being plugged in. Otherwise it would refuse if my memory serves me right.

Okay, the issue was in a corrupted filesystem. Whether this is caused by a software or hardware issue I don't know. So when android booted it interpreted a corrupted ext4 data partition wrongly as being partially encrypted.

What I did to fix was following this comment on reddit here

Quickly summarized:

boot into recovery, start adb from a linux system, pull the partition, fix it locally, push it back:

adb pull /dev/block/mmcblk0p12 data.img
sudo fsck.ext4 -y data.img
adb push data.img /dev/block/mmcblk0p12


Swagger on production APIs What security issues could arise from leaving the Swagger pages on production APIs that expose sensitive data (albeit secured with OAuth)? Are there web crawlers that look to harvest Open API definition files (i.e swagger) for nefarious means?

Publicly documenting your API gives attackers a head-start in identifying possible ways to abuse the API.

If you expect to host a functional Swagger UI page, ensure that your API's Cross-Origin Resource Sharing policy is not overly permissive, and that you have Cross-Site Request Forgery protections in place.

Similarly, take care to defend the Swagger UI page against frame-jacking, e.g., via the X-Frame-Options header.

Aside from those, consider these other business-related risks:

your API document is a reflection of your organization, and so should not contain things like profanity
your API may reveal exactly what sort of sensitive data it handles

social security numbers and other PII would be a big draw for attackers

your API may reveal your organization's business connections, for better or worse

for example, if your API document includes a query parameter named "exclude_data_we_stole_from_the_fbi", you may attract attention from the FBI for stealing their data

the frequency of updates to your API may signal your development or maintenance velocity to your competitors


Is accidental credit card fraud possible? If a credit card transaction appears on your account, that you did not authorize, does it have to be fraud or could it be a glitch?  For example, could the magnetic strip on someone else's card be corrupted somehow and going to the wrong account?

Its is extremely unlikely for this to occur by accident.

If a magnetic stripe becomes corrupted then the checksum on it will let the machine know and not perform the transaction.

So this would require both the data to become corrupted and the internal checksum to be corrupted in such a manner that everything adds up.


Why does the OpenSSH client on Mac OS X silently launch an ssh-agent for the user? I'm confused by the difference in behavior of ssh clients I'm seeing on two different hosts. Just to be clear, this is the scenario:

"macbox" OS X using OpenSSH_5.2p1 ssh client
"sunbox" Solaris 10 OpenSSH_3.9p1 ssh client
"linuxbox" Ubuntu running OpenSSH_5.8p1 sshd server

All three hosts have a user by the same name. I wanted to set up things so that macbox and sunbox could ssh in to linuxbox using just ssh keys, no passwords. On linuxbox, I set up sshd_config to allow this:

HostbasedAuthentication yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

Notice the comment. I took the advice and didn't change the setting about empty passwords. I understood that to mean that linuxbox won't allow host based authentication with public keys which don't have a password set for that key.

Then, on macbox and on sunbox, I did this:

ssh-keygen -v -t dsa

And on both of them, when prompted by ssh-keygen, I supplied a password for the key pair it was generating. Next, I copied the contents of the "id_dsa.pub" (from both macbox and sunbox) to the ~/.ssh/authorized_keys file on linuxbox.

From macbox, using the built-in Terminal.app program, I tried ssh-ing to linuxbox. Suddenly, I was looking at GUI password prompt, launched by Terminal, but not in the terminal, and it wanted the password for the key pair I'd generated. I entered the password which I'd given to the ssh-keygen program when I generated those keys. I did NOT check the box offering to remember the password in my Mac's Keychain.app program. I clicked OK and got in to a shell on linux box.

Next, I typed "exit", then ssh-ed back in to linuxbox a second time, but this time Terminal.app did not ask for a password. I repeated this several times.

Then I went to the sunbox, tried an ssh to linuxbox. Sunbox asked for the public key password via the shell (since I don't use a GUI/X11 environment there). I supplied the password, and got in to the shell on linuxbox. Then I typed "exit", then tried to ssh back in to linuxbox and was again asked for the password. Unlike the ssh client on macbox, sunbox's ssh client asks me for the password every time I ssh to linuxbox.

Is this some kind of undocumented Mac OS X user friendliness thing? Or is it a setting in ssh_config? The macbox has everything commented out in ssh_config. The sunbox ssh_config has a few lines uncommented:

GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
PreferredAuthentications gssapi-with-mic,publickey,password,keyboard-interactive

I've read the manpage on ssh_config, but I don't see how these settings could account for the difference in ssh client behaviors. I even went into the user Keychain.app file on the macbox and searched for a saved password for the keypair, and there is none saved there.

Can anyone explain why I have to type a key password on sunbox every time I ssh to linuxbox, but never (again) had to type a key password after the first time I ssh-ed to linuxbox from macbox?

Answered: It turns out that, yes, this is a feature unique to OS X. See this excellent article about when this feature was introduced to OS X Leopard


Java SecureRandom doesn't block? How? I know from experience that reading from /dev/random blocks when the Linux kernel entropy pool runs out of entropy.  Also, I've seen many articles and blog entries stating that when running on Linux, java.security.SecureRandom uses /dev/random as its entropy source and thus blocks when the kernel entropy pool runs out of entropy.

However, I'm unable to produce an experiment which causes SecureRandom to block.  Conversely, it seems easy to get a simple bash one-liner which reads from /dev/random to block.

Here's the java code I'm using for these experiments:

import java.security.SecureRandom;

public class A {
    public static void main(String[] args) {
        SecureRandom sr = new SecureRandom();
        int out = 0;
        for (int i = 0; i < 1<<20 ; i++) {
            out ^= sr.nextInt();
        }
        System.out.println(out);
    }
}

It generates just over 1,000,000 random 32-bit integers.  That should be 2^(20 + log2(32)) = 2^25 bits or 2^22 (a little over 4 million) bytes of entropy, right?  However, it never blocks.  It always finishes in about 1.2 seconds no matter whether I wiggle the mouse or not.

The bash one-liner I used is:

head -c 100 /dev/random | xxd

This blocks easily.  As long as I keep my hand off of the mouse and keyboard, it'll sit there doing nothing for several minutes.  And I'm only asking for 100 bytes of entropy.

Surely I'm missing something here.  Could someone explain what's going on?

Thanks!

Both OpenJDK and Sun read from /dev/urandom, not /dev/random, at least on the machine where I tested (OpenJDK JRE 6b27 and Sun JRE 6.26 on Debian squeeze amd64). For some reason, they both open /dev/random as well but never read from it. So the blog articles you read either were mistaken or applied to a different version from mine (and, apparently, yours).

You can check whether yours reads from /dev/random or /dev/urandom by tracing it:

strace -o a.strace -f -e file java A

and look for the relevant part of the trace:

21165 open("/dev/random", O_RDONLY)     = 6
…
21165 open("/dev/urandom", O_RDONLY)    = 7
…
21165 read(7, "\322\223\211\262Zs\300\345\3264l\254\354[\6wS\326q@", 20) = 20
…

Don't worry, /dev/urandom is perfectly fine for cryptography.


Is encryption possible for simplex (one-directional) TCP/IP, and if so, how? As explained in the TCP/IP Guide, it is possible to configure TCP/IP to operate in simplex mode and this mode is utilized, among other things, in communication from satellites.

One consideration with TCP/IP is however that, in itself, it "lacks even the most basic mechanisms for security, such as authentication or encryption", as explained in this article.

According to this other question, IPSec can be used to provide encryption for IP, but as can be read at Wikipedia, IPSec is used to establish mutual authentication and exchange of encryption keys.

Neither mutual authentication nor an exchange of keys should be possible in fully simplex mode (or maybe it is but I am missing something?).

Anyway, the question I wanted to ask is: if TCP/IP is actually ever operated in simplex mode, what are the options for encrypting the data?

With one-directional communication the sender must have least some knowledge of the recipient so that the data can be encrypted. This knowledge might be a common pre-shared secret which is used in symmetric communication or it might be the public key like used in PGP and S/MIME. This public key then can be used to encrypt a message which can be decrypted only by private key (which should only be accessible to the recipient). In practice this public key is usually used for performance reasons to encrypt only a short random secret and this random secret is used as symmetric key to encrypt the larger data.

The established standards PGP and S/MIME are actually good examples how to encrypt a message without doing any kind of handshakes inside the communication channel. The sender only needs the public key of the recipient to create such an encrypted message.

Of course if the common pre-shared key or the private key of the sender are compromised all communication done using this key can be decrypted, which includes all old communication. This risk can be mitigated if you use a different key all the time in the hope that not all of the keys gets compromised. But this would mean that you need some kind of back communication from time to time to exchange or negotiate the new keys.


Are there security risks of letting someone use your VPN server? While reading about the setup of a VPN server, I have noticed the setup is very similar to that of a SSH server: there is an exchange of keys/certificates, a key password is setup, and even optionally two-factor authentication, besides firewall rules to avoid unauthorized access, for example.

Also, the OpenVPN for Android FAQ says I should delete the .ovpn files after importing them:

  As OpenVPN is security sensitive a few notes about security are sensible. All data on the sdcard is inherently insecure. (...) The VPN profiles are only accessible by this application. (Do not forget to delete the copies on the sd card afterwards).

While I understand how much all that would be needed for a SSH server, since it gives you a shell to the system, I still fail to understand why a VPN server would need all that. I have read the VPN Wikipedia page, and it mentions that "VPNs may allow employees to securely access a corporate intranet while located outside the office", which is a different use case from just encrypting traffic, as mostly advertised nowadays.

But since I intend to setup a server mostly for encrypting my network traffic, what could be unintended consequences of leting someone authenticate to my VPN server? I believe OpenVPN for Android is used mostly for that purpose too, but it tells me I should keep my .ovpn files safe, in order to avoid that.

They are essentially on your LAN (depending on your local configuration) and can do all kinds of fun things depending on how malicious they are. By just routing their internet through the tunnel and making it look like their victim is the one doing the downloading, someone can use your VPN as an internet connection for piracy, downloading child porn, as a control server for a bot net, or any other type of nefarious deed.


Is it possible to bruteforce a file encrypted with a keyfile? If someone used a keyfile (4092 bit of entropy) to encrypt a file, and bruteforced it with Hashcat... would Hashcat have to guess the blob data in the keyfile to crack the encrypted file?

$ dd if=/dev/urandom of=keyfile.key bs=4092 count=1

$ openssl enc -aes-256-cbc -a -A -in filename.txt -pass file:keyfile.key -out filename.txt.enc

$ cat keyfile.key

@<��B�M�����Yj�TO
               @    d��_G���ݘ`k�M�?�բ�Ƃ��-�b��f(a�Bѩ=> Ξ�U
�uE��s��k���$�N�����/ĢI�HK�N���`�������Js�3�zX>F=�Xy�t˵ǜ�NK�ZA7ݺrˤ��>��0R�n�k�T8gbX�����8��� ��v�
                                                                                �~6�    ,���;�*{U{�+]�%N]������Y��(�JT�@Т��������
�~p@�p��R�rU�_�(��3��9- k�Ɛ��v-}7���\o_��pJ�@�<jc���$S
�rwi�2�6��������R4ȓ�B鶒o�7����}���MВcBU0�t_^9�@�d)
��{Gg|@m~8�g΅��<�
*3ByPHvO�%

                                              ��D�YXR&�7}k���L�u�Bj���44yj��j�w选a��R��@���NO����q  �

First I need to point out that Hashcat would not be the right tool for the job. Hashcat works on hashes, and OpenSSL does not store the hash of the key. Instead, you would need to have at least one block of known plaintext, after which you can attempt to brute force a key that results in that plaintext being encrypted into the ciphertext that you see in the file. There are other tools that can do this.

However, I believe you are misunderstanding how the command you have specified actually works. Unfortunately, OpenSSL does not take keyfiles. When you give it a password in the form of a file, it takes only the first line as the password. This line is processed exactly as if you passed it via pass. That is, it is hashed once with SHA-256 to form a 256-bit value that is used to key AES. Because the file you are using is binary, it is very possible that a newline character (0x0a) is one of the first bytes.

If a newline byte happens to be within the first eight or so bytes, it will be absolutely possible to brute force the resulting encrypted file. The probability that any given byte is a newline is 1/256. The chance that a newline is present in the first eight bytes is only 1/32. This means that there is no guarantee that it will not be possible to brute force a file that you encrypt improperly by passing a binary file as the key.

So, how would you do this correctly? You'd want to hash the keyfile yourself and pass the hash as a key to the OpenSSL command. This can be done easily using common utilities:

pass=$(sha256sum keyfile.key | awk {'print $1'})

You can then pass this key to OpenSSL by using -pass pass:$pass. This will guarantee that the entropy of the key will be no less than the entropy of the keyfile you give it. For a 4092-bit keyfile, hashing it with SHA-256 would result in a 256-bit key. Brute forcing that would require going through up to 2256 cipher operations which, as the other answer mentions, would not be possible to complete before the universe itself ends, assuming of course the 4092-bit keyfile is truly random.


XSS possible inside the value field of input tag when double quote is filtered? Is it possible to get XSS in the value field of Input tag when the application filters out double quote?

<input type="hidden" name="something" id="somenthing" value="my_input_goes_here">

input from request goes inside the value field , so i tried to close it with " and give a payload like " accesskey="X" onclick="alert(1)" but " is filtered out.

So any XSS vector possible in this scenario?

No, per the HTML specification, only the matching quote (in this case, double quotes), can get you out of the attribute value context.

You might be able to get a " past the filter with some filter evasion tricks, but as long as the browser's HTML parser doesn't see a literal double quote, it won't exit the attribute context for you to inject a payload.


Clarification on the -h Flag for Makecert.exe When using Microsoft's Makecert.exe to generate a certificate (and key), there is the option to allegedly "specify the maximum height of the tree below that certificate", using the -h flag (see MSDN).

As an experiment, I created a certificate with "-h 0", assuming this to mean that this certificate in turn could not be used to generate another (adding to the chain). I then went on to attempt creating a subsequent certificate, and to my surprise all went well.

I can't find anything further explaining the usage of the flag on MSDN or anywhere else. Can one of you please enlighten me?

I did some further investigation and realized that this constraint is taken into account at the time of resolving the certificate chain of trust, not at the time of creating a new link. From  RFC 5280:

  The pathLenConstraint field [...]. In this case, it gives the
  maximum number of non-self-issued intermediate certificates that may
  follow this certificate in a valid certification path. [...] A pathLenConstraint
  of zero indicates that no non-self-issued intermediate CA certificates may
  follow in a valid certification path. [...] Where pathLenConstraint does
  not appear, no limit is imposed.

See also TechNet - Understanding Constraints.


Encrypting data before sending to SaaS tool and decrypting on browser view I'd like to send data to a SaaS tool, where the data is stored in the cloud. I'll use Google Analytics as an example, but it applies to any similar service.

Google Analytics does not allow you to store personally identifiable information (PII), and there are many examples of online services where you might want to send user data but don't want the service to be able to view that data.

The best solution I have to this problem is encrypting the data before it's sent to the third party, appending a special token that distinguishes the data from other hashes, and then storing both the original value and hashed value in a database. For example, a username like johndoe could be hashed into s8d7f89sd7f, then appended with hashed- to get hashed-s8d7f89sd7f. You would then store both johndoe and hashed-s8d7f89sd7f in your database.

When you visit the third party's website (say, a Google Analytics report with all the hashed values), you could crawl the DOM looking for values that match your special pattern (e.g. words that begin with hashed-). Then, using a Chrome extension, bookmarklet, or some other local program, you could replace that hashed value to the original value and display it on the page in human-readable form. Unless the website was monitoring the page for changes and phoning them home, they would never have access to the translated values.

The closest solution I've seen to this problem is this Chrome extension, but it stores data in a CSV (not as robust as a database, but that's fixable) and is specific to Google Analytics.

Is there an existing solution to this problem? If not, why? And would the solution proposed above work?

Based on what you have outlined, your solution seems overly complex and I'm not sure why you wouldn't just encrypt the data rather than hashing it. There may be limitations in what you can store in the remote app that may require encoding the encrypted data (similar to what needs to be done when sending encrypted email). This would eliminate the need to maintain a local database mapping hashes to original text. Requiring that sort of mapping would require sharing of the database between all possible clients, which could be a problem - easier to share a secret key than a database in most cases.

However, fundamentally, I think the problem is trying to add security to something which was not designed for it. This is rarely a great path to take. The solution often ends up overly complex and frequently has holes which aren't easy to spot. The real solution is to use a SaaS which includes the level of security you require and avoid any solution which attempts to add security on as an afterthought.


How can I ensure privacy when outsourcing authentication to an IdP (Identity Provider) I need to outsource authentication to an IdP (Identity Provider) but I don't want that IdP to know of the calling site.  The two major issues are the callback URL and the referer header.

Is there any way to "hide" or mask the callback URL, referer header and any other data that may exist?

Some ideas might include

Using javascript to HTTP POST
Using an object such as ActiveX, or add-in
Adapting Mozilla Persona to the idea (unless it already does it)
Callback to a proxy that simply hops and anonymizes the traffic

Is anyone aware of a way to authenticate a site using a 3rd party, hide the source site's identity?

I do not think that it will be a good idea to hide the identity of Service provider(SP) from the Identity Provider (IdP- a trusted third party).

The IdP is providing authentication as a service to SPs that integrate with it.
This comes under federated identity management which is entirely dependent on establishing trust relationships between different domains.
This enables the end users to authenticate themselves with one domain (IdP) and access services which belong to different domains (Single sign-on)
Since the IdP is providing a service to SP It should have a mechanism to identify the SP from which the authentication request is coming from. and to verify the authenticity of the request. (generally implemented by verifying the digital signature of the SP and some kind of prior agreement between the two parties)

Let us say you (SP) do not want to share your identity information with IdP.

After checking for the user's credentials how will the IdP notify the SP that the user is authenticated or not (callback URL is needed)
If there is no strong method to identify the requesting party, some malicious web application may pretend to be you and communicate with the IdP.This may result in compromise of some important information.
Let us consider an extreme case where you are relying on a third party to communicate with the IdP on your behalf. Even then you need to have some mechanism to verify the authenticity of the authentication request.(again you need to share your public key)


End to end cryptographic methods/solutions I want to implement secure communication for my application. The A sends a message/data and B receives it. The message should be encrypted so the internet provider would not be able to read it even if it gets intercepted.

Conditions:

I cannot use https (but should be included for completness)
It's possible to use other protocols then http, but not desirable

I found many sources to this problem, but decided to ask to see all alternatives and maybe create a list of methods/solutions/scenarios to this problem, since many people new to this domain spend a lot of time researching these methods. Thank you!

I'd recommend OpenPGP GNU has a good implementation of that that is GPG or GnuPG that comes with it. Check with gpg --version GNU also has a windows implementation called Gpg4win.

A better place to get these answers that allows for more discussion is IRC. I suggest ##crypto on freenode.

I personally use it with Enigmail(Thunderbird add on) for my email. For more on encryption and digital signatures see this.


Track who leaks your software I'm releasing some software in python which is impossible to fully encrypt. I was thinking of changing the variable names slightly for every copy that I release. Is this a good way to figure out who is leaking my software? Chances are no 2 people who bought this software will compare because the price is in the thousands. Furthermore, there are limited copies so they won't even realize they are being tracked.

What is the downfall to this method and are there any better ways to do this?

You can add an external lib to the product, made in C/C++. Python can import those just fine. Add a couple vital functions on that library, and change the library a little for each client.

An interesting way of doing this is to use internationalization to encrypt most of the strings, and use the external library to decrypt them. Use a custom key to each client, and encrypt the strings file before shipping.


Rolling your own crypto I know this is usually frowned upon, but supposing you were to roll your own encryption cipher (completely on your own or with a small group of friends, with no peer review possible), what could you do to make your custom algorithm as safe as possible (or rather, to keep the danger of using it to a minimum)? Similarly, what would you do for something like a hash function to make the probability of it having some trivial collision or preimage attack as low as possible?

I understand that there would be no way to approach the security of algorithms like AES, and I have no plans to use custom algorithms for anything important, but I thought it would be informative to think of what some best practices would be for rolling your own cryptosystem if you were to do so.

Revised answer

In general, you may want to start by basing your cipher (mostly relevant for asymmetric ciphers) on a known hard problem. You may want to make mathematical proofs verifying your cipher has the desired properties and breaking it indeed requires solving the known hard problem. What kind of problems to choose was explained more on Crypto SE. By creating these mathematical proofs, you will make sure your cipher is not easily breakable directly.

The next step may be to look at side channels. Most notably timing attacks. If your cipher takes different amount of time for different inputs and keys, you may want to at least add code to either make it take the same amount of time always or just add random amount of time by active waiting.

There are many other side-channels and considerations a widely used cipher has to take into account, but this should get you started. Of course, making all these mathematical proofs is very difficult and even then, it does not give you any guarantee the cipher can't be broken. Even if the cipher is secure on its own, in combination with other cryptographic primitives, it may turn out to be easily breakable. That is why rolling your own crypto is such a big taboo. Getting it right is very very difficult and you will not find out you did something wrong until someone breaks it, or if you are unlucky, not even after that.


What is a spinner (empty while loop) doing, and why? I've seen that in the latest iOS jailbreak, they use so called "spinners". What exactly is a spinner doing? And why?

Apparently it's "blocking the thread execution", but why does the exploit need that?

I see a couple of different "spinners" when grepping the code. The one you reference appears to be unused:

static void spinner_empty(mach_port_t* arg)
{
    while (!*arg)
        ; //spin
}

static void spinner_nonempty(uint64_t* arg)
{
    while (*arg)
        ; //spin
}

spinner_empty looks like it waits until the mach_port_t that arg points to casts to true rather than false, and spinner_nonempty waits for the uint64_t arg points to to be 0. I have no idea what purpose these serve, as they appear to be unused right now.

There's also this one:

// in the end I don't use these, but maybe they help?

volatile int keep_spinning = 1;
void* spinner(void* arg)
{
    while (keep_spinning)
        ;
    return NULL;
}

#define N_SPINNERS 100
pthread_t spin_threads[N_SPINNERS];

void start_spinners()
{
    return;
    for (int i = 0; i < N_SPINNERS; i++) {
        pthread_create(&spin_threads[i], NULL, spinner, NULL);
    }
}

void stop_spinners()
{
    return;
    keep_spinning = 0;
    for (int i = 0; i < N_SPINNERS; i++) {
        pthread_join(spin_threads[i], NULL);
    }
}

In this case it looks like they may simply be there to slow down execution, by having a large number of threads constantly spending as much time as possible doing nothing. The comment seems to indicate that they may not be necessary, but the author thinks perhaps slowing down the execution may give the exploit a higher chance of success.


VPN and Unencrypted Protocols I recently started subscribing to a VPN service, and to check that all traffic is in fact encrypted I used Wireshark. According to this page, the lower, right hand side should be gibberish (from this you probably already inferred that I am not especially tech savvy).

I noticed that these protocols are not encrypted: DNS, SSL, SSDP, TCP, TLSv1.2.

Should not those be encrypted as well?

Using ipleak.net, it seems like there is no leak (not even webRTC, which I removed by a browser add-on).

NordVPN, which I am using, does not seem to allow any special configurations to force all traffic through the VPN tunnel. Is there any way I can do this?

In order to setup a tunnel you have to :

1. discover your vpn provider and connect to him ( DNS)
2. Initiate a encryption with your provider ( SSL/TLS)
3. Once a pipe is added, routing entries must be added on your local computer so other services can find out about your tunnel (SSDP).
4. As for TCP, well it's TCP, if all would be encrypted then you wouldn't be able to get to your modem, not even mentioning the
internet.

As you may notice, there is quite a lot of prepwork to do until a tunnel is secured, and it is unencrypted, but once the tunnel is up and the routing rules in place, everything should be safely piped through the tunnel. There's also the possibility that you're listening on the "LAN" side of things and also you're creating additional unencrypted traffic by maintaining connections prior to the tunnel firing up.


Html attachment on Mail I received an attachment on mail with the below script. What does it do?

The code was enclosed in a html script

window.location.assign("data:text/html;base64,

  BASE64 here

It is a base 64 encoding for an HTML five web page with the following content:

Sign in with your email and password.

Receiver's Email Address

Password

Stay signed in
Uncheck on public devices.
This PDF is protected VIEW FILE

Sign in with your receiving Email and Password.

click
You can see the html page if you copy and paste the encoded base 64 into https://www.base64decode.org/ and then copy and paste the decoded result into a file and open it with a browser.

There is a JavaScript URL that returns an error:

<Error>
    NoSuchKey
    <Message>The specified key does not exist.</Message>
    <Key>renga-&</Key>
    <RequestId>DE746594286EECD9</RequestId>
    <HostId>
        SI3jiVV8+qsJR19JyD0fo+qXukQtBkoGl5wEyOlw8Ei2pGsCdm5O1qnTaz6+YQxp73pItZfPegQ=
    </HostId>
</Error>

It may have been a security risk once, but it appears to be benign at this point.  Nonetheless, I would not select or do any other actions other than "inspect" on any HTML elements when viewing the page.

In general, I delete all emails with attachments.  If someone wants to share a document, they can post it online as a PDF or HTML.  If a picture, they can share it on a social network or send it as a Facebook attachment it.

Email is a horrible communication device from a security point of view.  It arose as a messaging device during a time when only research labs, defense systems, and major universities used networking at all.  Transition away from it if you can.


can a backdoor executable be used on an occupied port? Suppose I am doing a penetration test on a network that has a firewall that blocks all ports except 80, 110, and 443. I want to use a metasploit reverse-TCP backdoor executable written in msfpayload to initiate a connection with a remote server that has a listener running.

Since I can't set the backdoor to run on an blocked port because of the firewall, can I set the executable to run on one of the allowed ports assuming that the port is dormant at the time and no traffic is going through it? If not is there any way to get around a blocked port or make this scenario work?

If there's not an application listening on the port that you want to listen on, then you can use those ports. If not, you can make an outgoing connection which should make the firewall less of a problem (especially if you try to connect to a common port like 80 or 443).


Is a company asking for my password over the phone a bad sign? I am a customer of a company that has quite a bit of personal/financial information about me. I had to call their help desk the other day and was asked to type my online password in on the keypad on my phone to confirm it's me.

Does this necessarily mean that they are storing my password in plain text? Shouldn't they be unable to confirm my password over the phone if it was properly hashed?

It does not mean that the passwords are in plaintext. It is possible that they could process your password, when you originally set it, to convert it into the numberpad equivalent and store that, either in plaintext or hashed.

There are a few different ways that this process could be concerning, and worth a question or two about how they process passwords.

My greater concern is how they handle the password you type into your phone. That is most likely stored in their help desk system without any protections. Whatever they do to compare it to your stored password, there must also be a process to protect the password you type in.

My guess is that they calculate the numperpad equivalent of your password and store that number in plaintext in your account notes. It is then compared against what you type in when prompted on the phone.


MPPE-Send and Receive key derivation from MS-CHAPv2 I am trying to get the MS-MPPE-Send-key and MS-MPPE-Recv-key from the MS-CHAPv2 challenge material. I am able to follow the RFCs 2548 3078 and 3079 to the step of getting the GetNewKeyFromSHA() it is 16 bytes long.

I can use the key to encrypt data as the example in 3079. The problem is that I am not sure what should I do to get the session keys used in the RFC 2548 to get MS-MPPE-Send-key and MS-MPPE-Recv-key fields from there.

I have an example of freeradius and the session key is converted from 16 bytes long to 32 bytes long before the construction of the string stated in RFC 2548.

I have tried to encrypt with RC4 the session keys after GetNewKeyFromSHA() but it is not working for me. If someone could explain a bit in detail this intermediate step it would be nice!

Edit 1

I also have tried to make the encryption in 2548 twice but still no results, I am now digging into the freeRADIUS source code but it is not easy to follow after getting the master key from the MS-CHAPv2 material. Any ideas?

Edit 2

Looking into freeradius it seems to be that firstly it derives the keys from the MS-CHAv2 material but then instead of encrypt an send them, it uses the master secret and the random numbers from the TLS handshake to produce the 32 bytes Send and Receive keys. This is as RFC 2716 says, then encrypts them as RFC 2548 and finally it sends them.

So is it possible to use the master key derived from the MS-CHAPv2 material as in the RFC 3079? or the only way to do this is as freeradius does?

Not sure of your question, is it how these values are encrypted? It is described in RFC-2548 section 2.4.2.

The reason I think this is that in your question you state:

  I have an example of freeradius and the session key is converted from
  16 bytes long to 32 bytes long before the construction of the string
  stated in RFC 2548.

so you are wondering how you go from your 16-byte key to the 32-byte value used in the RADIUS attribute?

Basically your 32-byte key is 2 catenated MD5 hashes of your 16-byte key. The value must be a multiple of 16 for this reason. The reason that you have 32, rather than 16 is that you prepend a single-byte value 16 (for key-length) onto the key value which makes the length 17 and thus pushes it into a second 16-byte window. The remaining 15 bytes should be 0-padded.

So anyway you're ciphering your now 17-byte key-value using the RADIUS shared-secret, the 16-byte Request Authenticator from the original RADIUS request, and a random 2-byte salt value.

The random salt value can literally be anything. As you've noted freeradius derives this from a TLS function but that's only suitable where you're tunneling over TLS really. You can just pull something out of the air.

Then you prepend the two byte salt value onto your 32-byte encrypted value, to make a 34-byte value and you're done!

     Construct a plaintext version of the String field by concate-
     nating the Key-Length and Key sub-fields.  If necessary, pad
     the resulting string until its length (in octets) is an even
     multiple of 16.  It is recommended that zero octets (0x00) be
     used for padding.  Call this plaintext P.

     Call the shared secret S, the pseudo-random 128-bit Request
     Authenticator (from the corresponding Access-Request packet) R,
     and the contents of the Salt field A.  Break P into 16 octet
     chunks p(1), p(2)...p(i), where i = len(P)/16.  Call the
     ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
     Intermediate values b(1), b(2)...c(i) are required.  Encryption
     is performed in the following manner ('+' indicates
     concatenation):

  b(1) = MD5(S + R + A)    c(1) = p(1) xor b(1)   C = c(1)
  b(2) = MD5(S + c(1))     c(2) = p(2) xor b(2)   C = C + c(2)
              .                      .
              .                      .
              .                      .
  b(i) = MD5(S + c(i-1))   c(i) = p(i) xor b(i)   C = C + c(i)

  The   resulting   encrypted   String   field    will    contain
  c(1)+c(2)+...+c(i).


Vulnerability scanners for web APIs I've built a few web APIs for my company at intellectstorm.com and I'm tasked to test these products by scanning for vulnerabilities. I can't decide on a good tool as yet; so far I've used the following:

Barracuda Vulnerability Scanner
Nessus
Openvas
Nikto

I can't continue using Nessus or Barracuda because they're not open source.
These tools are powerful, but I think they're used for front-end application testing. I did not see any documentation of finding web APIs and scanning for vulnerabilities for web APIs.

Burpsuite has the capability. You first set up your client to proxy traffic through Burp, then you can start testing the API.

Step by step here: https://support.portswigger.net/customer/portal/articles/2898216-using-burp-to-test-a-rest-api


How to rule out the secondary NIC's from nmap When I do a network scan I get series of live hosts .

host1 - 192.168.1.2,192.168.1.3,192.168.1.4
host2 - 192.168.1.5,192.168.1.6,192.168.1.7
host3 - 192.168.1.8,192.168.1.9,192.168.1.10

But the thing is , Each host has around 3 Nic's assigned to it so it has 3 Ip's for same host . 2 are secondary and 1 is primary. How to rule out the secondary Nic's ?

As far as I saw I couldn't find any options or I don't know whether there is a option like that .. If someone could confirm it , it would be helpful.

If you are doing a network scan it means you are trying to find all the IPs that are 'alive' on that network, so, if if every host has three IPs listening on that subnet inevitably you will get all of them to respond.

I don't think what you want if possible. The only thing I can think of it's that the lowest IP should be the primary on each host. Not guaranteed, but very likely.


Confusion: Why isn't a passhrase encrypted SSH key two factor auth? I'm trying to figure out the best practices for accessing my devbox from a public terminal.

Most sources I've found recommend protecting the box with some kind of two factor authentication, such as adding a "command=" prefix to the authorized_key that forces entering some sort of one-time-password.

My question is, why is this necessary? Say I've got a pass-phrase encrypted ssh key sitting on the thumb drive. I insert the drive, enter my paraphrase and connect: in order to get into my system you've got to have the key file and the pass-phrase.

Say there's a keylogger on the public box. Now an intruder has my passphrase, but my key was never copied to the local system.

Now, of course once my usb drive is connected it's possible for the key to be copied off, but is this really likely? How many keyloggers also slurp SSH keys off usb drives? How many malicious-types are watching their honeypots 24/7 waiting for activity that looks like an ssh connection?

To me it seems like a pass-phrase encrypted key is two factor. Can someone explain how it isn't?

A passphrase-encrypted key provides two-factor authentication, but only if used correctly. It is easy for the user to misuse the key, providing only a single factor, and the server cannot detect incorrect usage. Hence a passphrase-encrypted key cannot be considered two-factor without additional assumptions. From the point of view of the system as a whole, the passphrase-encrypted key provides two factors, but from the point of view of the server, there is only one factor, which is the private key.

The password is what-you-know. However, the password is not visible to the server. The server does not know if you used a weak password or no password at all. In any case, typing a password on a machine which may be running a keylogger is not valid use of a password for authentication.

The key file is what-you-have, but only if you do not copy it willy-nilly. Strictly speaking, it's the USB stick where the key file is stored that is a something-you-have authentication factor. The key file itself stops being an authentication factor once you allow for it to be copied off the stick.

In the scenario that you describe, where you copy the key on a machine that you do not control, is not valid usage. It transforms what you have into what the attacker also has. If the attacker can install a keylogger on that machine, he can also install a program that makes an copy of the content of every removable media that's inserted into it. What you have must be tied to an actual physical object that is not accessible to the attacker. A key stored on your own laptop or smartphone is fine. A smartcard inserted into a smartcard slot is fine (for normal smartcard usage, where the secrets do not leave the card). A USB stick inserted into a public machine does not provide an authentication factor.

And yes, there is off-the-shelf malware that grabs the content of removable media. Depending on where you plug in, it may be more or less common than keyloggers (though I'd expect the two to often go together). The attacker who installs a removable disk imager may be after authentication data, or possibly after other confidential documents. There is a resale market for corporate secrets (confidential documents, contact lists, etc.) which fosters this kind of malware, and grabbing authentication data is an easy side benefit.

With a user who may insert his USB stick into a public machine and type his password there, the passphrase-encrypted key provides zero authentication factor.


Is Google Drive security compromised? Today when I visited drive.google.com, I was auto-directed to http://drive.googe.com/router.php

After clicking on "Exit Now" on that page I was redirected to http://globalreward-zone.sweepclam.eu/home.html

Is this some kind of scam? How to avoid this? I'm running Firefox on Win7.

You mistyped the URL:

http://drive.googe.com
http://drive.google.com
                 ^
                There

I confirmed that the redirect to router.php happens when you mistype the URL, and does not happen when you type it correctly.

Note that typosquatting (which is what this is called) is a serious security problem as you no doubt can see. Had the attacker simply showed a Google login, you would have given him your username, password, and possibly 2-factor token.

This is why you NEVER should manually type in a URL to anything remotely important. Use bookmarks or other similar references. And also use a password minder like lastpass, which will not be as easily fooled -- your password won't auto-fill on the wrong site, so you know that if the password doesn't automatically show up, then you're looking at the wrong URL.


Could an attacker prevent IIS from logging requests I've had an attacker try to gain access to one of my websites through a form using what looks like a blind SQL inject.
It is a huge form, and every possible permutation of values has been tried - in total about 18000 of them.

He hasn't had any success (yay!), but I'm left with a bit of a puzzle: there are no unusual requests logged in the IIS logs.
Nothing out of the ordinary.

I was reading https://serverfault.com/questions/364186/when-does-iis-log-a-request , and I wondered: Could an attacker purposefully prevent his requests from being logged? For instance, by sending the request and then dropping the connection before the response is sent (completely)?

You will not see the payload in the logs If the attacks were sent via a POST, as opposed to a GET.


GnuPG - Symmetric crypt with a null key As the title tells it, is it possible, using GnuPG, to do a symmetric encryption on a file, using a "null" key so when you do a gpg --output doc --decrypt foo, it'll decrypt it without asking for a password/passphrase ?

If not possible, is there a way, still with GnuPG, to make a PGP message that wouldn't need any password to decrypt it ?

Thanks!

There are two ways to create such a message. Either you can sign a message with the signature in the message and with --clearsign not specified, or you can use --store.

Signed but unencrypted

As for the specific message you provided, it is not an encrypted message, it is a signed message, not using a clear text signature. In other words, the signature and message are fused together. See section 1.1.2 of the GnuPG manual, which explains clear text signatures created with the --clearsign option. What you are seeing is a signature for an unencrypted file which is not using this type of signature. As a result, PGP-compatible software is required to read the file, despite it being unencrypted. This allows you to ensure integrity without requiring a decryption key.

You can create a message with a clear text signature easily:

$ md5sum message.txt
ecccffe1886ca709442672e65d66b409  message.txt
$ gpg --armor --sign message.txt

And then to access it again, you "decrypt" it:

$ gpg --decrypt message.txt.asc > message2.txt
$ md5sum message2.txt
$ ecccffe1886ca709442672e65d66b409  message2.txt

Or you can simply verify the signature:

$ gpg --verify message.txt.asc
gpg: Signature made Sat 30 Dec 2017 06:06:52 AM UTC using RSA key ID 8085AFFB
gpg: Good signature from "Test Key"

Store only

There is a way to create a message without a signature either, using --store. This option is effectively equivalent to symmetric encryption with a null cipher. It stores the message encoded with an RFC1991 literal data packet. If your goal is simply to create an unencrypted message, this is probably what you want. It does not guarantee either integrity or confidentiality.

Store the message in PGP format, without encryption:

$ md5sum message.txt
ecccffe1886ca709442672e65d66b409  message.txt
$ gpg --armor --store message.txt

And "decrypt" the message:

$ gpg -d message.txt.asc > message2.txt
$ md5sum message2.txt
ecccffe1886ca709442672e65d66b409  message2.txt


Can I resubmit my GPG key to a keyserver? I submitted my GPG key to the keyserver earlier. Now I got signatures on my key. Can I republish it? gpg --send-keys doesn't seem to alter my key any more, but doesn't spit out any error either.

Yes, of course. Sending should update the copy on the keyservers adding the new signatures (note that it is possible that they already had those signatures which would lead to no changes on their copy).

Additionally, while this would be the traditional action by the keyservers, please note that some keyservers may be read-only (not allowing you to upload keys by hkp), or even discard signatures automatically if they are from unknown keys.


Can SSL certificate (domain verification) process be eliminated? Noob question alert.
I understand SSL certificates help mitigate MITM attacks, but I see the process to be so badly designed.
Basically the client needs to verify that it is talking to the particular domain's ip. This could be implemented this way. There could be a DNS record containing the server's public key. The client could then proceed with the verification and ssl process with the public key.
This will eliminate the following :

No certificate

No certificate authority

Browsers dont need to trust CAs

I dont have to pay and wait for my certificate.

Am I missing anything?

I dont have to pay and wait for my certificate.

You don't need to do this currently. You can get free certificates in no time and fully automated from Let's Encrypt.

Browsers dont need to trust CAs

While browsers don't need to trust public CA directly in your proposal (which is essentially DANE), browsers still need some secure way to retrieve the public key. This can not be done with plain DNS since it provides no protection against spoofing and modifying the keys in transit. These protections are offered by DNSSec though. But DNSSec again involves some kind of trust hierarchy:  the local DNS resolver somehow must be able to verify the DNS servers response - which is again done using trust chains based on locally stored and trusted keys.
Trust relationships cannot just emerge out of thin air. There need to be some initial trust already which can be used as the anchor for building trust chains. This is true for PKI as used in the CA system as it is true for DNSSec as it is true for a web-of-trust model like in PGP. And it is true in "real life" too: one should not trust others just because they say so.


PCI Compliance Check-list I'm currently attempting to wrap my head around PCI compliance - and what I need to do for my business to be compliant. I would like some confirmation on what I've found so far.

I accept payments in a mobile application. We take payment details and pass them to our own REST service (over HTTPS), and then that service instantly passes them on to a third-party payment gateway to handle the payment. We get confirmation, and the app gets that confirmation. At no point do we store the payment details. My business accepts just over 20,000 payments a year.

So, would I be correct in saying that:

An SAQ-D needs to be completed.
Every quarter I need to get some form of network scan from an ASV?

I would also like to know if there are any other steps necessary to be PCI compliant?

Also - if I use the PayPal mobile SDK, what (if any) additional steps would I need to take to become PCI compliant?

The mobile application cannot currently be validated or considered a compliant payment application. Guidance on security and compliance in mobile applications has been issued by the SSC here: https://www.pcisecuritystandards.org/documents/Mobile_Payment_Security_Guidelines_Merchants_v1.pdf

As your environment is receiving and transmitting cardholder data, you are correct in your assertion you should complete SAQ-D. SAQ C would be more relevant if you were processing data in a payment terminal in an IP environment. There are lots of things you need to do to be compliant in addition to the scanning you reference above. The following is not an exhaustive list:

Firewall ruleset reviews at least every 6 months.
Server hardening in line with industry standards (CIS, NIST, SANS)
Anti-virus installed, running scheduled scans, generating logs
Systems patched and up to data Software development lifecycle - secure coding, peer review, separation of dev, test and production environments and separation of duties between those environments
Change control for software modifications and deployments
Access control with documented authorisations for Role Based Access Control
Two factor authentication for remote access
Password policies
Physical security of the in-scope environment (CCTV, badges, visitor controls)
Centralised logging
Consistent NTP configuration with internal peering and external sources
Quarterly internal/external vulnerability scanning
Annual internal/external penetration testing
IDS/IPS File Integrity Monitoring
Lots of policy and procedure documentation

Note that if the payment data was transmitted directly from the mobile application to the third party payment service provider, your systems would never handle cardholder data and PCI would only be relevant to the due diligence performed to validate the third party is PCI compliant and accepts their responsibilities.


Is there any advantage to using encrypted DNS on a VPN server I have a personal OpenVPN server. I am worried that the fact the DNS resolution coming out of the server isn't encrypted, since I am the only one that uses the server at the moment, attribution isn't very hard. As such is there any advantage to enabling one the the Encrypted DNS protocols on the server - would that work and if so, how would I go about doing it?

I would strongly recommend using DNSCrypt and DNSSec directly on your client PC. There is no reason I can see to shift this to your VPN server, and it is probably a lot harder to set up. If you however for some reason have clients using your VPN, that would not be able/not know how to set these up themselves, then this may be worthwhile.


How to decrypt .dmg with BruteForce is there any tool for download which is not that hard to understand to go for a BF attack on a .dmg file?

Theoretically, you could use a tool like Spartan (although I think it's not even around anymore).

Practically, this will bring you absolutely nowhere, unless the .dmg was encrypted with an extremely naive password (like 'admin' or '1234').

Any somewhat decent password will completely rule out the possibility of brute forcing.

(edit) Here's a shell script that will bruteforce passwords following a fixed format:

#!/bin/bash
dmgfile="Your Encrypted File.dmg"

function TryPassword
{
    echo -n "$1 "
    r=$(echo -n "$1" | hdiutil verify -stdinpass "$dmgfile" 2>&1)
    if ! [[ $r =~ "Authentication error" ]]; then
        echo ""
        echo "Found! The password is: $1"
    exit
    fi
}

chars=$(echo {0..9} {A..z})
alphanum=( $(echo $chars | sed -E 's/[^A-Za-z0-9 ]+/ /g') )
letter=( $(echo $chars | sed -E 's/[^A-Za-z ]+/ /g') )
lowercase=( $(echo $chars | sed -E 's/[^a-z ]+/ /g') )
uppercase=( $(echo $chars | sed -E 's/[^A-Z ]+/ /g') )
digit=( $(echo $chars | sed -E 's/[^0-9 ]+/ /g') )

for a in "${letter[@]}"; do
    for b in "${lowercase[@]}"; do
        for c in "${digits[@]}"; do
            TryPassword "$a$b$c"
        done
    done
done

Save this to bruteforce.sh and from the shell, do chmod +x bruteforce.sh once to make it executable, and then ./bruteforce.sh to run it.

This example bruteforces all passwords consisting of one letter (upper or lower case), followed by one lowercase letter, followed by one digit. Edit accordingly to your scheme.

Test first by creating a test .dmg with a password that is attempted first (e.g. Aa0).

Keep in mind that even for simple (short) passwords this will take a VERY long time. Like I said, it's mostly just theoretical.


Can malware have its own GRUB/boot-loader and use it to be active? I use Ubuntu 16.04. After I mounted an ISO which may or may not have had malware in it, my system sometimes ends up showing a blank screen after logging into Ubuntu or reboots a minute or two after I log into Ubuntu or like today, when it reached the Grub screen and rebooted. Then it reached the Grub screen and rebooted again. The third time I reached the Grub screen and the countdown for automatic selection of OS was counting down from 25 seconds. This was unusual because I had set the countdown to 10 seconds. I disconnected my smart-phone from the USB port of the computer, hard-rebooted again, and this time the Grub countdown was at 10 seconds and no problem happened.

I've had my phone connected like this to the computer for two months and I've not observed any odd behaviour, so I'm ruling out that the Android phone could be the cause. However, since the Grub timeout was at 25 seconds, I was wondering if there could be a malware that installs its own GRUB and randomly chooses to boot from it, thereby granting itself root privileges in some way.

Is this possible or am I just being paranoid?

P.S. I should also mention that this problem of the computer restarting used to happen three months ago, which I think is approximately the time I mounted the same ISO file in Ubuntu. I had wiped the hard disk and reinstalled the OS suspecting an infection. But I thought the infection might have come from a pen drive I inserted into a friend's computer. It's only now I suspect that the restarts could be related to that ISO.

Obligatory XKCD:

With that out of the way...

The basics of the boot process
First, you need to know how a bootloader works. When the system first starts up and the BIOS is in charge, it initializes all the devices necessary for boot. It then reads the CMOS to find out the correct device to boot from. It opens the first device, and reads the first 512 byte sector (where the MBR should be installed) into memory. Specifically, it transfers the first sector to physical address 0x7c00. If the last two bytes of the sector are 0x55aa, it considers it a valid bootsector, and executes it. At this point, the BIOS is out of the picture, and the MBR is executing. The MBR is far too small to boot most systems, so instead it boots the second stage of the bootloader. All it has to do is be able to locate and execute some data on the hard drive containing the rest of the bootloader. In this case, the core GRUB modules. At this point, GRUB is fully functional and does all its magic to load your kernel and start the operating system boot process. Now, how can malware hijack this?
Hijacking the process
If malware wants to modify your boot process to randomly make you boot with malicious code in play, it can do one of a few things. In order of increasing levels of sophistication and stealth:

It can modify the second stage bootloader or its configuration directly, so when it is executed, it changes its behavior at random, performing malicious actions during some boots.

It can modify the MBR at the first sector on the bootable drive to, at random, choose to load a different second stage bootloader. The different second stage would inject malicious code.

It could modify your BIOS so it loads a different, malicious MBR for some boots. This is more difficult to pull off, but it is possible. BIOS infections are quite rare.

It could modify the hard drive firmware to return malicious data in the first sector randomly. This would require a very high level of expertise, and is exceedingly rare (virtually unheard of).

The displayed symptoms
But here's the important question... Are the symptoms you are describing indicative of any of the above scenarios? Let's look at the symptoms as you described them, one by one:

Your bootloader counted down from 25 seconds, despite you having set the timeout lower.

Your Ubuntu installation occasionally has a blank screen after you log in, or randomly reboots.

It rebooted itself without you commanding it to do so when it loaded GRUB.

Are these symptoms of a bootkit? No. The first issue is most likely a configuration issue. Every update, your Ubuntu installation updates the GRUB configuration file. The configuration file is very complex and has a large number of conditional statements. It would not be surprising if your settings are occasionally overwritten. The second issue just sounds like a bug in Ubuntu. Perhaps a driver for your hardware is buggy. I had an old Ubuntu system that did something similar. An update fixed it. Your third issue sounds like a bug in GRUB, or perhaps a hardware fault. All you are experiencing is the bugginess of software. As bugs are still annoying, you could try reinstalling GRUB, or resetting the configuration. Perhaps look online to see if there are any known errata for your software. Check your system logs to see if it is reporting an application crashing that may lead to the blank screen. And, of course, make sure you are up to date, so you get all the latest bug fixes for your setup.
Malware wants to be stealthy. It doesn't want its presence to be found out. Malware that is good enough to hijack your boot process will be very stealthy, and won't give away its existence through something as tantalizingly simple as a spontaneous crash. So no, this is not malware.


Is it safe to allow HTTP for SAML 2.0 Issuer URL? I've implemented SAML 2.0 using the ruby-saml gem in my Rails app. In this app, clients can specify their SAML idp for their account. I have a client who insists that requiring HTTPS for the Issuer URL does nothing for security. I figured this URL represents their identity provider. Because of that I figured allowing HTTP identity providers might open my app up to MITM attacks, via their app.

Is it safe to allow HTTP URLs for Issuer URLs for SAML 2.0 implementations? If so, I'd like to hear why.

I believe that technically, HTTP for the issuer URL is OK as the data being
transmitted is less sensitive. However, I would also argue that making it HTTPS
is also fine. In the past, there was a belief that you should only use HTTPS
where you absolutely needed to because of the additional overheads involved and
potential performance hits. With the increase in speeds and processing power,
this argument is no longer as valid (though there are still many sites with an
architecture which relies heavily on caching for performance where HTTPS can
have an adverse overall impact).

I tend to feel that complexity is now one of our main threats. Having an
application which uses HTTP in some contexts and HTTPS in others adds to this
complexity and makes verification more difficult. Much easier to monitor and
varify everything is OK if all you need to do is ensure all connections are
HTTPS rather than also having to check all non-HTTPS connections are OK.


Is disabling Remote Desktop Services sufficient to protect a Windows device from the BlueKeep vulnerability? Microsoft (and the NSA) have been urging Windows users and administrators to install patches to protect systems from the BlueKeep (CVE-2019-0708) vulnerability.

Is disabling Remote Desktop Services sufficient to protect any Windows device (any version) from the BlueKeep vulnerability?

"... Remote Desktop Protocol ... Microsoft advises to disable it until the latest patches have been applied..."

https://en.m.wikipedia.org/wiki/BlueKeep


Is authenticating via the database secure Sorry for this probably noobish question. So far, I've read password comparison/verification is implicitly understood to be made on the application layer and not in the database. For example in PHP, it would be done using the password_verify() function and not via a query like

SELECT * WHERE username = foo AND password_hash = $2y$10$blahblah

What would be a solid case against this? Or is this a perfectly valid approach to password comparison/verification?

Best practice is to used salted hashes for password.  Comparing two salted hashes involves removing the salt from the stored password, appending to the clear-text password and rehashing and comparing equality.  Because of this, it is not something that could easily be part of a SQL WHERE statement.

While I suppose this could be implemented at the DB layer, most implementations will retrieve the user by ID, and then compare the hashes in the app layer.


Handling passwords in wicket I have a form which contains a password field.

In swing the getPassword() method returns a character array. After the password has been processed by my web application the array can be wiped to remove the password from memory. This is not possible when using Strings because Strings are immutable. Using arrays reduces the risk of memory disclosure attacks.

How can I achieve this, i.e. not using Strings for passwords in Wicket?

This page has an example with Strings.

Actually you cannot really "remove the password from memory". Not nowadays.

In older times, memory allocation strategies in Java virtual machines were relatively simple; when a block was allocated, it was allocated once, and remained in memory, until the GC decided that it was no longer reachable and thus could be released. In that mode, allocation is similar to what C programmers call malloc(). For these JVM, the GC was conservative: it did not always reliably detect whether a given piece of data in memory was a pointer or something else (e.g. an integer or some characters), and thus assumed that everything which looked like a pointer had to be treated as such, for garbage collection purposes.

Since Java is a strictly typed language, it allowed the implementations of stricter GC who have strong knowledge of what is a pointer and what is not. This allows these GC to move objects in memory. From your side, in the Java source code, this is completely transparent. But internally, the GC may decide to move an object from one emplacement in RAM to another, automatically fixing all pointers to now point at the new copy of the object. Doing so enables a lot of optimizations which make that kind of GC quite desirable (better cache coherency, very fast allocation...). All JVM from the last decade use such better GC algorithms.

However, a consequence of these newer, enhanced GC is that old copies of objects may linger in RAM. When you "wipe" a char[], you are only writing to the latest in-memory copy of the array; remnants of older copies may still be there and contain your password, completely out of your reach since all of this is done transparently, invisible from the developer.

Therefore, the tradition of storing passwords in char[] and wiping them is just that: a Tradition. It used to be justified, in days from the previous century, when the JVM was using a conservative GC. At that time, wiping worked and was really removing secret data from memory. These days have finished. Programmer-driven wiping no longer works. So it makes no sense to make a difference between char[] and String; just use the String and be done with it.

If you believe in the importance of wiping, then the correct way to do it is to integrate the automatic wiping within the GC, systematically applied to all objects. I don't know if the current JVM from Oracle (or OpenJDK) offers an option for that.


Active Directory GDPR classification GDPR classifies data into Non-personal, Personal and Sensitive personal. Sensitive personal is further broken down to Genetic and biometric, Racial and ethnical, Religion and Philosophical etc.

Coming to implement a new Active Directory I want to present my stakeholders with the different options that they have, with GDPR in mind.

Reading the Microsoft white paper I cannot see mapping of attributes to the GDPR classifications, or a bottom line of how to implement any of the 3 approaches.

I would ideally like to see something along these lines:

to class as non-personal: 1. use employee ID in userPrincipalName and sAMAccountName; 2. only use corporate mobile phone in homePhone/otherPhone etc.; 3. use office address in streetAddress, targetAddress etc.
avoid these to class as sensitive: 1. biometrics (unless stored on the device such as Windows Hello); 2. distribution lists for religion communities (e.g. prayer room, even if multi-faith)

There are of course extension attributes which will have to be considered on case by case basis.

Has anyone been through this process and can share from their work?

Exactly as Geir E. said in the comment, have data minimization in mind. Don't use personal data unless it is explicitly needed for something. The whole AD part can be completely non-personal and there is no reason not to do so.

For user names you can use many alternatives not implying the real name of a person, like employee ID or a derivation of department/team/job scope or anything like that and employee ID.

As employee IDs are more and more often used in practice, doing so will actually simplify the whole employee-management in the end, for most situations.

Employee IDs can be used in AD just are they are widely used in work time counting systems, HR systems, ERP systems and so forth.

You you definitely can classify AD as non-personal, even if you currently use something personal. Renaming AD accounts has minimal implications and does not affect functionality overall except for the part when the user must login with its new ID.

In our company case, since you requested if people have been through this process, we use employee ID for AD, document encryption system login, security system login, ERP. the only name-based thing remaining are the e-mails, which are completely unrelated to AD.


How to combine symmetric and asymmetric encryption to encrypt large files? I understand that it is possible to combine symmetric and asymmetric encryption in a way that makes use of the performance of symmetric encryption, and also getting the benefits of being able to separate the knowledge needed for encryption from that needed for decryption.

Could someone explain this scheme in more detail?

To be concrete, I want to encrypt a few tens of thousands of files at a time, including some that are ~100GB in size.

To get the benefits of both types of encryption algorithms you can create a symmetric key to encrypt the data efficiently  and then encrypt that key asymmetrically.
Only the private key owner can decrypt and have access to the symmetric key.


Can someone hack into my Wifi network through my cell phone? Let's say my cell phone is hacked by somebody and that I have no knowledge that my cell phone has been hacked. My cell phone is connected to a WiFi network A.

Can hackers hack into the WiFi network A through my cell phone in this case?

If an attacker has full access to your cell phone, chances are, they can read the Wi-Fi password in plain text and thus get access to your Wi-Fi network.

The exact specifics depend on the OS, the version, etc...


Mail server sending plenty of mails My mail server was sending plenty of dummy emails using a user mail account, most of them were stuck in my mail queue due to blacklist/ graylist failure at first i tried to change the user's mail password to more complex one, but the issue still exists, and the user confirms he never used his email for sending any mails,

I also tried to use some php script to send email using my account without SMTP authentication, and it failed,

>SMTP -> get_lines(): $data is "554 5.7.1 <mail@mail.com>: Relay access denied

So how can someone use my mail server to do so?!

There are many possible causes for such an issue. here are the most likely:

You have a badly designed form script on one of your web server. It us being abused by spammers to send their messages. Note that the problematic script could be on a different server: check your logs to see where the messages come from.
One (or more) of your users account have been compromised and is being used to relay spam. In this case, you should disable the problematic user, force a password reset and contact the responsible person with the bad news. Usually, you will know it's an account compromise because it is being logged on from unknown IPs when sending spam. You might want to enforce password complexity on all your mail users and, if you do not have it already, setup the system to automatically lock SMTP accounts after a number of failures (5 to 10 are often enough without being too punishing on your users).
Your SMTP server is improperly configured and it allows relay under specific conditions. Check the configuration manual of your mail software to see how you can prevent that. Typically, you will detect this situation my going through the SMTP logs directly. If you're allowing relay from a set list of IPs, it could also be an indication that one of these machines has been compromised.


Will it improve security if I place both SHA1 and SHA256 signatures inside codesigned binary on Windows? My application targets platforms starting with Windows 7 32bit. Many of them aren't up to date (i.e. may be missing many recommended updates from Microsoft).

Given the constraints I must use SHA1 signature inside my userspace and kernel binaries. However, will it make the attacker's life harder if I also embed SHA256?

I'm concerned, because I'm trying to imagine what an attacker may do. As an attacker, my goal would be to substitute binary without breaking making Windows to notice that. I'm not sure how Windows verifies signatures, but the idea is to remove SHA256 signature at all and make my replacement binary to have the same SHA1 signature. Then when Windows will verify app's binaries, it will compare their SHA256 signatures for all but my binary, which only has SHA1 signature.

Note: my public certificate only has a SHA1 signature embedded by the issuer.

Technically, using SHA-256 won't make things really harder for the attacker. Unless you are the attacker.

The concerns about SHA-1 are about collisions. SHA-1 is believed to be somewhat weak in that respect (generating a SHA-1 collision is still very expensive, to the point that it has not been done yet even once, but we have strong theoretical reasons to think that the collision-finding methods that have been designed to attack SHA-1 would succeed in finding a collision in substantially less effort than the 280 expected from a "perfect" hash function).

When you sign a piece of data, you begin by hashing it, and the hash value is then used throughout the rest of the signature generation and verification algorithms. To leverage a collision, one must imagine that there are two distinct versions of the same software, the second one being malicious and doing evil things on the client system, but such that both yield the same value when hashed with SHA-1. If two such files can be created, then a signature (with SHA-1) computed on the first file would also apply to the second one, and vice-versa. This helps the attacker only in a context where the attacker gets to choose the file that is signed in the first place.

In your case, the original file (the normal, honest one) is the one that you produce yourself. If a collision helps the attacker, then you are the attacker.

If you are not the attacker, then what an attacker has to do is to find a second preimage: the attacker sees the honest, non-malicious file (that you signed), and tries to make a modified file that hashes to the same value. This is not at all the same problem. A collision is about finding m and m' such that m ≠ m' but h(m) = h(m'). A second preimage is the same thing except that m is not chosen by the attacker. This is much harder, and (as far as we know) infeasible with SHA-1. There is no known, even theoretical, weakness of SHA-1 that would allow an attacker to do that.

Correspondingly, switching from SHA-1 to SHA-256 would not improve things. If the attacker can make a malicious file with a valid signature from you, then this means that the attacker can actually make you sign code of his choosing (e.g. the attacker compromised your own development computers), and under these conditions, SHA-256 does not block the attacker any more than SHA-1.

However, client systems may have another opinion on the subject. From the point of view of a client, the signature process may go thus:

Somebody submits to the signer (you) some data to sign.
You audit the data to be signed, and sign it if you find it good and appropriate. E.g., for software, you look at the source code and do the compilation yourself.

In this model, the attacker may craft some code that looks good but, when compiled, yields a binary that collides with some malicious code that the attacker also crafted. Under this specific model, collisions are an issue, because the attacker is in position to choose both the honest and the malicious versions of the software.

Most probably, you do not follow this model -- when you sign a piece of software, it is a piece of software that you developed yourself, not something submitted from potential attackers. You know that. But Microsoft is not so sure, and might decide that it would be too risky to use a hash function that might allow collisions to happen.

So you still probably want to switch to SHA-256, not because SHA-1 would be too vulnerable (this is not the case in your situation), but because Microsoft may decide to remove SHA-1 support.

Microsoft policy is explained here, with the particular excerpt:

  Code signed with SHA-1 certificates that are time stamped before 1 January, 2016 will be accepted until 14 January 2020 (when Server 2008 extended support ends), at latest. This date may be moved earlier if Microsoft decides SHA1 is vulnerable to pre-image attack.

Note the final sentence: the problem is really about pre-images, not collisions.

You will also want to buy a code-signing certificate such that the signature on the certificate, and on all CA certificates in the chain, use SHA-256, because it seems that Windows is becoming increasingly allergic to SHA-1. For about the same reasons as above, this anathema on SHA-1 may be qualified as overkill, but Microsoft has no choice: Google is intent on killing SHA-1, and Microsoft must follow; otherwise, they will be mocked and laughed at.


https://www.truecrypt.org forwards to http://www.truecrypt.org Why is the site doing this? Is that a security flaw? In general, I'd be wary about using a http site instead of a https, although regarding truecrypt specifically, I came to trust it. I wonder why not use the higher standard of https.

The reason for this behavior is simply a poorly-run website. Today there's no logical reason to not serve a site over HTTPS, though that hasn't been true forever. Currently the only files I could find that are served over HTTPS are the PGP signatures. Though, critically, the page that links to those signatures is not served over HTTPS, which somewhat defeats the purpose.

It has been mentioned more than once that there is significant incentive for an attacker to MITM the truecrypt website and serve a modified version of their software, along with correspondingly updated PGP signatures and keys. And also the refusal of the truecrypt team to serve their website over SSL makes such an attack trivial for a correctly-positioned attacker.

So far, the truecrypt team hasn't cared.