Testing Session Fixation when cookie is unchanged I was testing a web application where cookies (session ID, session values) are the same for all times. Even after successful authentication takes place it remains unchanged. The session ID travels in the form of a HTTP cookie.

To investigate a session fixation vulnerability, I sent my colleague a link like http://yoursite.com/?SID=1209023, because I thought the web site would automatically assign the victim session ID 1209023 for the victim's future browsing on the site. But it didn't work.

So my application isn't affected in this way but still has the same cookies. Is there any other way to test for the existence of a session fixation vulnerability in my application?

For there to be a session fixation vulnerability, the server most somehow save some input that you (the attacker) can control as a value for the session ID. OWASP has a handy list:

Session token in the URL argument. (This is what you tried. But do note that the parameter could have any name, and you need to figure out what it is. It does not have to be SID.)
Session token in a hidden form field.
Session ID in a cookie. Since you can not set cookies cross domain, you need to some other vulnerability to exploit this, such as XSS or HTML injection (of a META tag).

If the server always sets a session ID on its own, without involving any user input in the process, this might very well not be exploitable.


Is it possible the person sitting across from me at Starbucks was trying to hack my laptop? I was using my laptop at a Starbucks on a table, and a person was using a laptop on the same table across from me, a couple seats to my side. He flicked some plastic thing across the table towards my laptop. What really freaked me out was he then actually flicked it again further to get it right in front of my laptop, behind my screen. The plastic thing was ring-shaped with a metal part on one end, which looked like the 30-pin iPhone charger. I've attached the basic shape.

Does anyone think they might know what the plastic dongle could be and/or have any information that would suggest the person was trying to do something malicious?

No, you are just being paranoid.

You were probably already connected to him over WiFi. There are many attacks he could have run this way without additional devices. Also if he would have wanted to hack you, he would not have thrown his strange hacking device in your face. He would have hidden it below the table.

Side note: I feel like most of the people saying they have been hacked are only paranoid. While most of the people who actually have been hacked do not notice it at all.

Also see VolleyJosh answer about the device.


verification of certificate chain using openssl verify command When attempting to verify google server's certificate chain using openssl, I am getting error.

Extract google's server and intermediate certificates:

  $ echo | openssl s_client -showcerts -connect www.google.com:443 | sed
  -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/server_certs.crt

Extract google's root CA from jdk:

  $ pwd

  /cygdrive/c/Program Files/Java/jdk1.8.0_231/jre/lib/security

  $ keytool -export -keystore cacerts -storepass changeit -alias 'globalsignr2ca [jdk]' -file /cygwin64/tmp/google_root.der

  $ openssl x509 -in /tmp/google_root.der -out /tmp/google_root.pem -inform der

Also extracted google's root certificate from chrome browser to /tmp/google-chrome-root.pem. Doing a diff between chrome's root certificate and jdk extracted root certificate, there is no difference

  $ diff /tmp/google_root.pem /tmp/google-chrome-root.pem

  $
  Based on this, I know, I am using the right root certificate.

Invoke openssl verify

  $ openssl verify -CAfile /tmp/google_root.pem /tmp/server_certs.crt

  C = US, ST = California, L = Mountain View, O = Google LLC, CN = www.google.com

  error 20 at 0 depth lookup: unable to get local issuer certificate
  error /tmp/server_certs.crt: verification failed

I know verification through

  $ openssl s_client -showcerts -servername www.google.com -connect www.google.com:443

is successful

CONNECTED(00000005) depth=2 OU = GlobalSign Root CA - R2, O =
GlobalSign, CN = GlobalSign verify return:1 depth=1 C = US, O = Google
Trust Services, CN = GTS CA 1O1 verify return:1 depth=0 C = US, ST =
California, L = Mountain View, O = Google LLC, CN = www.google.com
verify return:1

and was expecting a similar successful result through the openssl verify command as well.

I am doing this exercise in windows 10 and cygwin.

TL;DR: You need to give openssl verify the intermediate certificate, too.

Your manual verification:

$ openssl verify -CAfile /tmp/google_root.pem /tmp/server_certs.crt

Does not specify the intermediate cert.  When you perform the verification using s_client, it shows that there are three certs - root, intermediate, and server.  I've indented your output to make this more obvious:

CONNECTED(00000005)
  depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign verify return:1
    depth=1 C = US, O = Google Trust Services, CN = GTS CA 1O1 verify return:1
      depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = www.google.com verify return:1

In order for openssl verify to work, you need to download that intermediate cert (CN = GTS CA 101) and pass it in the command line using the -untrusted argument:

  -untrusted file

  A file of untrusted certificates. The file should contain multiple
  certificates in PEM format concatenated together.

Something like this:

$ openssl verify -CAfile /tmp/google_root.pem -untrusted /tmp/google_intermediate.pem /tmp/server_certs.crt


What are the security risks of storing user roles/types in a cookie? Recently I had to use a website which stored things like user role (user or admin) in a cookie.

When I modified the username the displayed username changed in the website.

I immediately asked the developers of said website if it's secure to store the user role in a cookie if you can just modify it. They told me that you could only break the UI of said website and that the back-end always checks the session cookie for important actions.

So let's say I want to build my own website and store things like user-type: admin or user in a cookie.

Is it safe to store the user type in a cookie if it's only used for UI purposes and not back-end purposes?

"Safe" is always a relative term. If the data in the cookie is not used for authentication or authorisation, and it is just a configuration item that is exposed and could be used by anyone without a risk of misuse/abuse, then why not? The letters a d m i n are not special in and of themselves.

At that point, it's just a UI toggle switch, just like dark/light mode.

The real question is about knowing the potential impacts of such a change.

The risks are about some future developer of the site misusing the cookie for sensitive things without understanding the consequence.


Possible leakage of metadata during forensic analysis I'm going to encrypt external hard drive. HDD is wiped three times using the command shred --verbose --random-source=/dev/urandom --iterations=3 /dev/sdc but after it I was accidentally executed command dd if=/dev/sdb of=/dev/sdc bs=4M status=progress and I've stopped it. /dev/sdb is an encrypted hard drive. Should I worry about possible leakage of metadata during forensic analysis?

You should elaborate on what you mean by "leakage of metadata during forensic analysis". Whether or not there is a risk of leaking confidential information, it depends on what you had on /dev/sdb. If you had sensitive, unencrypted data there, then writing it to the beginning of /dev/sdc would result in that data being retrievable unless otherwise overwritten. You should just initiate an erasure once more and limit it to only overwrite however much data you were shown by the results of status=progress.


Backdoor.ASP.Ace.C keeps showing up and being removed by f-secure Backdoor.ASP.Ace.C is being found and removed from:

C:\Users[username]\AppData\Local\Temp[randomstring]

We have recently found some malicious aspx files on our IIS server that we have studied and have stored on our computer. Scanning these files with online virus detecting programs identified the Backdoor.ASP.Ace.C virus on them.

We have several computers and servers with f-secure, but only some of them have detected Backdoor.ASP.Ace.C.

Do anyone know what this virus is doing on our computers and servers?

What is it doing: probably providing access to a malicious user

What you should: wipe the system and restore from backup that was not yet affected  by the virus. If a virus keeps popping up it means it's not being removed succesfully or someone keeps putting it back.

There is no other way to have 100% certainty that your system is not compromized anymore. If you want to extract the file or locate it so you can verify it on your backups. It should be in the Temporary Internet Files directory.


How do I know if my encryption algorithm is strong enough? I am using ruby and have the following encryption algorithm:

 @@secret_key = Digest::SHA256.hexdigest(key)
 encrypted = Encryptor.encrypt("encrypt this", key: @@secret_key)
 encoded = Base64.encode64(encrypted).encode('utf-8')
 StoreInDB(encoded)

The problem I am trying to solve:  If a hacker gets a hold of my database they will not be able to reverse engineer the stored 'encoded' column.

Is this strong enough?  Essentially, encoded column is a user_id.

When the question is:

  How do I know if my encryption algorithm is strong enough?

then the probable short answer is:

It is not strong.
It is strong enough.
It misses the point.

When professional cryptographers design an algorithm, they always assume that what they produced is weak. They will not trust it until it has been seriously looked at by their "fellow" cryptographers (who are actually their competitors, and a rather fierce bunch, though generally good humoured). It would not be wise, for a non cryptographer, to be less cautious than that.

Your algorithm is probably strong enough, where "enough" means "enough not to be the weakest point in your system". It takes really special effort to make a cryptographic algorithm which is so pathetically weak that attackers find it worthwhile to break it upfront (an example is CSS used on DVD, but that's still quite rare).

Your algorithm probably misses the point because most of security is not about cryptography ; cryptographic algorithms fulfill an important role, but with a narrow scope. I spend my days explaining to people that the magic crypto dust they sprinkled all over their systems is not as magic as they assumed (e.g. no, encrypting a SQL database does not prevent an attacker from successfully altering its contents by modifying the files on the disk).

It is possible that your algorithm (about which you give no detail at all) is actually strong, and fulfills a point which is relevant to your situation. Possible, but, as experience shows, not probable.


Is there a online filter to check email attachments? I've just received an email from an old employer. There is very little information in the message sent just:

  See attached file for your review.

  Kind regards, Mick

with an attachment. I would like to validate the email attachment but I am afraid by clicking on it I will inadvertently download something malicious.

I've read about downloading a virtual machine to open it for me but I don't want to download that on the work PC. Is there another way check?

Virus Total and malwr and both good sites to submit suspicious files. Virus total will tell you if the file is flagged by any antivirus. Malwr will give you more detailed analysis (this may/may not be of interest to you).

Note that you're submitting files to an online community, so don't submit anything that is potentially proprietary/secret.


Why aren't sessions exclusive to an IP address? Given the appropriate XSS vulnerability, an attacker can hijack somebody's session with the data that's passed to and from the server.

Why aren't sessions always exclusive to the IP they were started on?  i.e., when would a website/service need to persist an authenticated session across multiple IP addresses? I'm not sure why sessions permit this, thus I don't understand how this is ever a feasible route for an attacker.

First, linking a session to an IP address will not make it secure since the server could see many different users as using the same IP address for various reasons (all types of proxy servers, for instance: client, reverse proxy, CDN, etc.).

Second, the same user could very well use different IP addresses for the same session. For instance, someone could be switching between networks from the same device.

So, since it's not effective and it causes usability and scalability issues, that is not an feature that is usually enabled.


Fake lock screen in full screen browser window Suppose a desktop OS has a lock screen and fades and locks after inactivity. Suppose the default appearance and inactivity duration are well known (eg consider a default installation of some popular version of Linux). Is there something I'm missing that prevents the following attack?

Create a webpage which entices the user to view at full screen for some time without input (eg a video player)
Shortly before the inactivity timer fires, mimic the fading screen and login prompt.
User attempts to log in as usual, providing their credentials to the webpage (additionally the user input resets the real inactivity timer).

The fake lock screen could probably not prevent the user reaching the real lock screen via a keyboard shortcut (eg Ctrl-Alt-L). However if the user believes they are already at the lock screen, there is no reason for them to do this.

Background: My employer recently deployed a custom lockscreen. I and others (who missed the announcement) were suspicious of an unfamiliar password prompt. It was suggested the concern is unfounded because changing the lock screen already requires significant privileges. However I don't see how this rules out the possibility of a user-space program faking a lock screen (admittedly the appearance was significantly different, so if it were an attempted imitation it would be a poor one).

It's pretty common already for malware to inject fake popups asking for a password so this seems like a valid variation of that attack path but isn't really related to the lock screen at all.

See this example in metasploit.


How to decide where to host an online store? How can one know whether it is more secure to host the store on  our own  servers or on those from external vendors?

Answer:
Do a risk assessment.

1.) Summarized Answer
2.) Detailed Answer
3.) Answer that might help you, if you're in the same situation as me

Details:

The CEOs at my company plan to launch an online store
to let our customers buy and download our software-products 24/7.
They want also to leave the hosting to another company that is more experienced in webhosting than we are.

Edit: Some Information about us:

We are not a webhosting company
The only website we have set up was our own (it is also running on our own servers)
We have IT support staff (administrators), but none of them is currently versed in security.
We have some developers that are experienced in web-development

The Problem

However, I am skeptical because this means that the external hosting company:

Can accumulate large parts of our customer database.
Has to care for penetration tests (and regular checks, whether a data-breach occurred, or not)
Has to inform us about breaches (There is a risk that they won't do it, to avoid getting sued)
We have to trust them (which is sometimes impossible¹)

On the other hand, it's not a good idea to host the store on our servers because:

Most of the software devs don't care about security (I am the only one)
CEOs don't want to spend money on penetration tests and audits.
We have to inform our customers about breaches (possible suits).

NOTE 1:
This question is not about convincing the
CEOs to invest more in security.

NOTE 2:
The other company does not necessary has to be an ISP (directly).
It could also be a webshop-developer who takes care about the hosting (and ISP).

The Question is:
How can we know whether it is more secure to host the store on
our own (insecure) servers or on those from external vendors?

¹ For Example: No one outside of the USA can trust US-American hosting companies. (Not really their fault)
The patriot act forces them to hand every data to the NSA. (https://en.wikipedia.org/wiki/Patriot_Act)

Combine this with economic espionage(https://www.theregister.co.uk/2015/06/29/wikileaks_docs_show_nsa_vs_france/)and your business is ruined.
So this is really a serious problem.

This is hardly a security question but I can give you some pointers.

  ... can (and will) accumulate large parts of our customer database.

This is normally handled by contract law. (or to be more specific using a Service Level Agreement (SLA). this document normally holds what level of care the hoster has, what level of support the customer can expect, and how different parts of physical and digital security is handled.

  Has to do penetration tests (and regulare checks, whether a data-breach occured)

Probably not. Security audits should be done by someone outside of the chain. (so an objective outsider or specifically a third party that has signed NDA's (Non-Disclosure Agreement's) and does whitebox and / or blackbox testing dependaing on need and impact.

  Has to inform us about happened breaches (There is a high probability that they won't do it, to avoid getting sued)

If in the contract there is no provision for how to handle (security) threats and the SLA also does not mention it. than yes there is only local applicable law that might require the company to inform you (for example European law has some of this). This is why typically this is written down in both contract and SLA.

  We have to trust them (which is just impossible IMHO)

Trust is the foundation of business and has little to do with the issue, if you can not trust the company you hire to do work for you there is a bigger problem than just your data being leaked!

  On the other hand it's not a good idea to host the store on our servers because:
  Most of the software-devs don't care about security (I am the only one)
  CEOs don't want to spend "unnecessary" money on penetration-tests and audits.
  We have to inform our customers about happened breaches (possible sues).

This is not your problem, basically your boss or CEO is responsible for this, and you are only responsible to notify him/her (or some level between the CEO and yourself in) about the risks involved. Sometimes there are laws that require you to also inform some outside party / law enforcement. But generally thats only for 'criminal neglect', contact lawyer in the field before you do that!  Of course the CEO does not want to waste money on "unnecessary" penetration-tests or audits. You should only do those that are
necessary, and convince by showing and telling why it is necessary. There are real-world examples of risks and requirements to convince any CEO of the necessity of audits and pen-test.

  The Question is:
  Where to host the webshop, if each choice has so serious disadvantages?

Answer: On the bottom of the Marianna trench inside of a 1Km3 cement Block without power or Internet access. Or to be more precise, there is no safe place to host anything. the best place is a location with the least amount of risks and the best value for money. We on stack-exchange can not tell you where that is, nor will we try.


XSS payload without - &"=() Is it possible to construct a XSS payload without the use of these chars - &<>"=()? The server is not doing any output encoding.

Consider both the cases where the user input is being put into 1. attribute value, 2. HTML body.

Generally, no. At least not without preconditions (some of which @tim has lined out), because:

You can only escape from an attribute value by introducing the matching quote. (I assume you're referring to a double-quoted attribute, so a payload without " doesn't get you beyond the attribute value. Obviously, you could escape from a single-quoted attribute because ' isn't blacklisted, or from an unquoted one by using a space.)
In the data state (outside of any tags) you can only achieve XSS by introducing new tags. Everything else is just treated as data. So if < is blacklisted, you're out of luck.


Blocking ports makes the domain almost 100% secure? With one of the most reliable tools like pass the hash or online brute forcing tools like hydra requiring common ports like 445 to be open in the domain, will blocking those common ports secure the domain completely, since even most tools in metasploit require some type of port to be open?

If a port is not needed, keep it closed.

However, for day-to-day operation, you'll need to have a few ports open - 25 (SMTP), 80 (HTTP), and 443 (HTTPS) for example.
Via these, a payload can be delivered - viruses spreading by mail being a famous example, XSS attacks another one.

If you completely disconnect your computer from the internet, you're pretty safe nowadays, as most attacks are made via the net. But complete disconnection is rarely feasible - you wouldn't be able to browse the web, or to offer an online service (like a website).

Even if you can afford to have your computer completely disconnected, a number of attack vectors remain. Gullible users/operators come to mind.


Is there any benefit to keep sending UN/PW to the server over Session ID ( i.e., Stateless vs Stateful) I was reading this question about Session ID Hijacking

and it gave a lot of answers about stealing Session IDs.  I have been thinking about this for awhile, but is there a benefit to using Session IDs over re-logging in with a UN/PW combo, or vise-versa?  It seems to be that the issue with Session IDs is that it could be guessed, as well as it sometimes is shown to the user in the URL line with the Type of Session i.e., JSESSIONID for Java server sessions.

I am curious if re-sending UN/PW information to log in would be "safer" or not?  I would assume that since it's already being sent once, that storing it in an application/cookie, and then reusing it later could be beneficial, but maybe that leaves the PW/UN being open to stealing as well?

My question is, is there a benefit to either approach?  Would one work better or not?  Thanks.

Resending your username and password is a much greater security risk and has no benefits over session ids (or some variation of access tokens) that I can see.

Losing a password has greater impact

Here's why: If your session id is hijacked, your attacker will have access to your session, which is bad enough. But if he gets your username and password, he can impersonate you to the service for as long as he wants (because usually passwords don't expire, unlike sessions), he can reset your password and lock you out of the service etc. Also, since a lot of people reuse passwords on other sites, getting your password might also compromise your accounts on countless other sites. He can't do any of that if he only has the session id. So it's better to expose the short-lived, localized session id to risk than the long-lived username and password.

Ideally, the password would never be transmitted over the network at all (there are schemes which avoid sending the password, and most browsers and web servers are capable of using the simpler ones (google digest authentication, for example), but unfortunately, developing this technology has been neglected in favor of implementing server-side login systems using nice-looking login screens, which require transmission of the password.)

Session hijacking is (should be...) hard

Stealing a session id isn't so easy. Guessing session ids is very difficult (trillions of times more difficult than guessing the average password) if the application generating them is doing it right. Session ids should be created as long random strings using a crypto-strength random number generator; and since most sessions are only valid for a few hours at most, there isn't much time to make a lot of guesses. Passing session ids as GET parameters in the URL is a problem, yes, but this should be done only to degrade gracefully when the user's browser doesn't accept cookies. Most session ids are passed using cookies which live in the header of an http request.

Federated authentication and authorization

Finally, resending the username and password is often simply impossible, since they might not be available. If you use federated authentication an authorization systems such as OpenID/OAuth, you don't have access to the user's credentials; you just get an access or id token (or both), which are a kind of notarized letter to prove that you are who you say you are and should be given access to a certain resource. Again, the access tokens are only valid for a few minutes up to an hour, and only for a specific resource, so even if an access token was stolen, the damage someone could do with it would be limited.

With OAuth, you can request a special kind of token called a renewal token which you can use to get a new access token without the need to have the user log in again when the old access token expires. So this comes close to your question about resending the login credentials, because if the renewal token is stolen, the attacker gets almost indefinite access to the service the token is meant for. But note that even when a renewal token (which is typically kept out of the reach of user agents by a server) is stolen, this doesn't compromise the user's password and all the other sites he uses his account for.

Restful APIs

Unlike websites that allow a user to sign in, APIs are often stateless. So the client must authenticate with every request he makes to the API. This can be done by sending the username and password every time you make a request, but many APIs solve this by having a client first get an access token using his credentials, an then use the access token to access the API. OAuth is a perfect example for this. So again, the password is only sent once per "session" to get an access token.


Do these non-zero durations in btmp indicate someone is logging in? I've set up a public-facing Debian server on a well-known web hosting provider and am trying to determine if hackers are breaking in.  I know very little about securing web servers but I am trying to learn.  I've configured my server to disallow root logins over SSH and I've also disabled password logins via SSH.  All users must use SSH key authentication.  I've also installed Fail2ban.  I have an account but there aren't any other users so no one else should be logging in but me.

When I run the command "sudo last -f /var/log/btmp" to view bad login attempts I see entries like the following:

ubnt   ssh:notty   <ipaddress1>   <date1> 16:55 - 17:22  (00:27)
admin  ssh:notty   <ipaddress2>   <date2> 11:56 - 16:55  (04:58)
user   ssh:notty   <ipaddress3>   <date3> 07:47 - 08:24  (00:36)
pi     ssh:nottyp  <ipaddress4>   <date4> 10:46 - 11:11  (00:24)

Do these entries really indicate that hackers have been able to log in despite my precautions?

What I also don't understand is that if I run the command "sudo lastb -f /var/log/btmp", I'll see the same entries as above except that the "time in" and "time out" entries are all the same.  In other words, instead of this:

# sudo last -f btmp
ubnt   ssh:notty   <ipaddress1>   <date1> 16:55 - 17:22  (00:27)

I see this:

# sudo lastb -f btmp
ubnt   ssh:notty   <ipaddress1>   <date1> 16:55 - 16:55  (00:00)

After reading the man page for last, lastb, the problem may be that I shouldn't be running last against btmp but that I should be running lastb against it instead.  Perhaps just because you can specify a "-f " parameter for each command, that doesn't mean the commands are interchangable.

I should also add that there aren't any accounts in my /etc/passwd file with the usernames shown above.  If people are still logging in without my knowledge, what other things can I do to prevent this?

Thanks.

btmp is failed login attempts. Those user accounts do not have to exist to appear in that log. If you start to see weird entries in wtmp or utmp, then you should start to worry.


Why does Ettercap scan the wrong hosts? Details:

I'm running three virtual machines on VMware Workstation:

Virtual Machine 1: Windows 7. Using static ip: 10.1.1.1
Virtual Machine 2: Windows server 2008. Using static ip 10.1.1.2
Virtual Machine 3: Kali Linux. Using static ip 10.1.1.3

They are connected to eachother via a host-only network on VMNet1.

I want to sniff packets going between the two windows machines using Kali Linux's Ettercap.

But when I scan for hosts on the eth0 interface (10.1.1.3) in Ettercap I get the following ip addresses:

It looks like your eth0 connection on your Kali VM has its network adapter setup incorrectly and is actually using your host machine's network (192.168.128.*).

You need to make sure that your VMs are actually using the host-only network.

On your VMs, run ifconfig and check that eth0 is actually on your 10.1.1.* subnet. If it's not, you'll need to double check the eth0 connection setting within your VMs, and that the VMWare network settings for the VMs are correct.


At what table size does salt reuse make rainbow tables cost effective? While I know that salt should never be reused, I'm interested in whether it is a significant problem if we only have a small number of hashes for which it is reused.

So let's say we have a table with N password hashes for which the same salt is used. The salt is unique but it's reused for all the hashes.

Does the table size have an impact on how much security is lost? For example a table holding only one password would obviously have zero security loss, while a table holding 10 passwords would be less secure, but not significantly so.

Does the amount of security loss depend of the size N, and at what point does a rainbow table become cost effective? At what point does security become seriously compromised? Is it N=10, or N=100, or N=1000?

Edit: Let's also assume that every password is unique in the table. We are not interested in any other kind of security loss except rainbow tables becoming more cost effective.

Edit 2: Let's say we measure computational expense in terms of teraFLOPS per password cracked. Cost-effectiveness really depends on the expected payoff of course, but let's just put an arbitrary value - we consider 1 teraFLOP / password cracked to be cost effective.

It depends

The purpose of the salt is to force a malicious user to use a dictionary attack instead of a rainbow attack.  The reason for switching will depend on the attacker's intention and resources available.

Single user

If a hacker is trying to get the password for a single user, he wouldn't use a rainbow attack anyway.  A dictionary attack is actually faster against one database row (unless the hacker is extremely unlucky).

Just targeting common passwords

If a hacker is only trying to find users who are using very common passwords, he can construct a pretty small rainbow table, one for each of your salt values.  The more salts you have, the more tables he'll have to create.  But there is no magic number.  It will depend on the resources available to the hacker and the size of the password list he is looking for.  Because each rainbow table would be small he may be willing to create hundreds or thousands of them.

Trying to get every single password

If a hacker is trying to crack every single password in your user base, he will need to construct a full rainbow table for each and every salt.  If there are too many salts, he will decide it is easier just to switch to a dictionary attack.  The threshold for this would probably be subjective and indicental... e.g. if the hacker had enough storage space for 100 rainbow tables, then using 101 salts would cause him to switch to a dictionary attack.

On the other hand, if your table has very few users (not few salts) then a dictionary attack may be faster anyway.  When you have millions and millions of users then an attacker would be willing to go a lot further to avoid having to use a dictionary attack.


How to verify signature while downloading log4j? From the log4j download page.

The PGP signatures can be verified using PGP or GPG. First download the KEYS as well as the asc signature file for the relevant distribution. Make sure you get these files from the main distribution directory, rather than from a mirror. Then verify the signatures using
% gpg --import KEYS
% gpg --verify log4j-1.2.17.tar.gz.asc

My questions are:

Which portion of 'KEYS' webpage do I need to download ? Should -----BEGIN PGP PUBLIC KEY BLOCK----- and ----END PGP PUBLIC KEY BLOCK----- be included in the key signed by Christian Grobmeier ?

What does KEYs in gpg --import KEYS mean? Is 'KEYS' a file on the local desktop? If yes which format? txt?

To the second question, the KEYS is the file that is linked on the apache site. You just have to download it as is (and by as is I mean, with all the comments and the --BEGIN --END shenanigans). Just right click the link and save it like this.

To the second question, the gpg --import command will sort out what is a key and what is not, importing all the keys in bulk.


Does a VPN provide any security benefits over sshuttle or a vanilla ssh tunnel? I use sshuttle to tunnel my traffic through one of my remote boxes whenever I'm in a cafe or connected to an insecure network.

Does a VPN provide any additional security benefit over this kind of setup?  What are the pros and cons of a VPN versus an SSH tunnel?

No. It is just different VPN protocol. If NSA can't decrypt SSH, you are fine with sshuttle, if you use strong VPN there should be nothing different.

If you set up weak primes for diffie-hellman key exchange for ssh connections, you are vulnerable, but the same can happen for any choice of weak VPN protocols.

Clarifying more details of your specific application(s) would help to evaluate further, but generally there is no difference in security if used correctly.


Are there any nice info sites dedicated to explaining how and why to (not) store user passwords in the database? I keep finding various websites that are able to email me back my password. I try to email them every time, telling them about this. But it can be tricky to be taken seriously - it's just a random email from a random stranger. Besides, I can't really go into much detail or I'll risk being ignored for TL;DR reasons.

This got me thinking: perhaps there is an info-site out there dedicated to first explaining why this is a problem, and then linking to further info on how to do this right? One that looks authoritative and trustworthy, preferably even authored by someone famous in the IT security field?

The closest I found is this blog by Jeff, but it starts off discussing something else altogether, and so isn't very suitable.

I would like to point you to this post here on security stack exchange.

However, it would be difficult as a normal user to convince a site to change their password policies unless you are paying for their services. I would just avoid using such sites if at all possible.


Online votes where two-part codes are sent together A lot of societies that I am a member of allow online voting for their AGMs (to elect members, approve minutes, etc). To vote in these all members are sent out a two part code - however the two codes are always sent together either in an email or a letter.

The way I see it the two parts of the code should be sent ideally over different channels (e.g. one part via email, one part via letter) or at least at different times (e.g. two emails sent on different days). I realise this would make things a bit more difficult for the voter (losing one of the codes, having to wait for second code before they vote), but what is the point of sending two codes together? Why not just issue a single code to be used?

The codes I receive are often of the format:

Code 1: 12345678
Code 2: abcd

I've received similar two-code mailings for various elections as well.  The same concern hit me, so I looked at them more closely.

One thing that struck me is that the same companies host many thousands of elections.  So there's more going on here than a simple election.

For consistency and branding, the voting sites are customized to the organization, so every year for my Coop, I log in to the same URL, something like https://my.coop.election.example.com/ and cast my ballot.  As far as I can tell, the URL simply determines the CSS displayed so the right logos and colors show up; but underneath the exact same web site serves all their customers and elections.

From this it made sense that the first code identified the specific election ("2018 My Coop Board of Trustees", "2017 My Coop Board of Trustees", etc.), and the other identified me as the voter.  If true, this isn't two-factor authentication, it's simply a pair of identifiers.

As I recall they were named something generic, like "Code 1" and "Code 2" instead of "Election Number" and "Voter ID".  This may be intended to keep things obscure; to keep people from trying to vote in other elections or trying to guess someone else's Voter ID.

Could they do this differently, like combining the two and issuing a giant SHA-1 hashed number for me to enter?  Yes, but the usability of typing in a very long number is difficult, and they are trying to keep both usability and integrity high -- two shorter numbers are easier to type, and probably solves their problems for them.


Is communication with printers protected? If someone can break into my home network then they can record anything going over my WiFi network, which is why https is essential and VPN is useful. Now my printer is connected through WiFi, and several devices use it.

Question: Can I expect that the average printer uses some encryption for the data that it receives, or could someone who can listen in to my WiFi collect anything I print and copy it? I just found out my home printer uses “WEP encryption” which I assume can be cracked.

PS Unless I’m very wrong, VPN will not be able to help you in this situation. It could protect what you send to the printer, but can’t protect what the printer receives.

Most of the commonly used network printing protocols are not protected against sniffing or modification. And even if the printer supports TLS protected IPP it is usually either not setup at all or not setup securely (i.e. with  certificate trusted by the client and with proper certificate validation).

In other words: the average printer setup as used by normal consumers is open to sniffing and modification. It might be different in companies which actually care about network security (i.e. most not). And, if you just interested in securing your own printer connection check if your printer support IPPS (IPP over TLS). See also How can I encrypt my print jobs?.


Potential security issue with md5 filename I've been storing files using a filename of the md5 hash of the file. This allows me to not store duplicates of the same file and avoids any filename clashes. Each file has uses a different salt/iv.

I want to start encrypting the contents of the file app-side (using OpenSSL PKCS5), however, by taking the md5 of the encrypted file, I lose the above benefits of the md5 filename.

Assuming the file storage was compromised, would the combination of the encrypted file and the md5 of the unencrypted file be a potential security issue?

If the possible range of the file's contents were small enough (either because the file is very short, because the attacker knows every part of the file except for a very short piece, or because the attacker knows the file's contents are one of a limited set of things, then the attacker can perform a brute-force search of the possible file contents and check the hash digest of each result to see if it matches the filename.

Note that this vulnerability has nothing to do with the fact that MD5 is cryptographically broken and deprecated; any hash function would be vulnerable to the same issue. If you want to avoid the risk, you need to either avoid encrypting small / predictable files, or you need to not leave each file's plaintext hash digest hanging out in plaintext (the filename) itself.

Another attack that might be possible is if the attacker knows at least some of the files you have stored, and can generate a new file for you to store. Because MD5 is broken, the attacker could potentially craft a malicious file that has the same MD5 as a file you care about, and then when you store the attacker-supplied file you would overwrite your original file because it would have the same name. The use of encryption is irrelevant here (except to the extent that it makes it harder for the attacker to know what files you have stored); this is simply a consequence of doing file de-duplication using an algorithm for which we know how to create collisions and (partial) pre-images. To avoid this risk, don't let a potential attacker know what files you stored, don't store files a potential attacker supplies, and/or move to using a secure hash algorithm such as a member of the SHA2 or SHA3 families.


How do I escalate a security concern of a library when the author doesn't seem to care There's an open source library that is horribly insecure. The author acknowledges it's insecure. The library's headline says "This is an implementation for platform X of Library Y". Library Y is secure therefore the headline that his library is an implementation of a secure library Y strongly suggests his implementation is also secure. Nowhere does his library or it's readme and docs ever mention it is insecure.

I politely brought it up, enumerated the issues, and politely suggested he add a warning to the readme. He said he didn't think anyone would think his library is secure. I pointed out he claims his library is an implementation of Y and Y is known to be designed to be secure. He responded he saw my point and suggested I sent a pull request to update the readme. I did. That was 12 months ago. Others have brought it up but no movement.

Let me also add his library is not actually an implementation of Y. It's similar but would need months of work to actually pass Y's conformance tests and so on top of being insecure it's also effectively lying about being an implementation of Y.

What if anything should I say that might encourage movement? My gut (which I know is wrong) is to basically say he's a jerk for misleading people and putting people at risk and that he should really take the issue more seriously. It's not the most popular library but according to at least one distro point it's been downloaded 160 times this month and there are a few dependent libraries. Assuming that's an average per month then up to 1920 people/projects are at risk.

The author obviously does not consider their project a priority anymore. That's not uncommon. There are too many interesting problems in the world and too little time to solve them all, so projects tend to become abandoned. This includes projects with known security problems. All you can do is make people aware that this piece of software is insecure.

Report the vulnerabilities to the NIST Vulnerability Database.
Does the project have a public bugtracker? Then you should report the security vulnerabilities as bugs. People who evaluate open source software they consider using usually check the bugtracker to get an impression of how well maintained it is. Multiple open bugs regarding critical security flaws will usually be a huge red flag.
Contact dependent projects directly that the library they are using has serious flaws they might not be aware of.

When you feel altruistic, you could fix the problems yourself. Send in a patch or do a pull request when it's on GitHub. When the author completely lost interest, you might want to suggest to take it from them and become the official maintainer. When the author is completely uncooperative, you could start a fork.


Should we be checking password restraints on log in forms? We have many restraints we put on users when they set up their password. These restraints include password length, characters they can or cannot use, the use of numbers and letters, capitalization requirements, etc. These are enforced so a password cannot be created unless all restraints are met.

On a form that requires a user to log in with their password, should we be intercepting the password the user has provided and check it against our original restraints the user was required to follow when creating the password before sending it to LDAP for authentication.

I personally say besides basic data sanitation (to prevent SQL injection attacks, etc.) that there is no reason to check what the user provides as a password to log in after they've already created it. If it doesn't match, authentication will fail. However, other individuals in my department feel that those restraints should be checked again before sending the username/password combination to authenticate.

Which way is better? Why?

Checking again an already registered password is useful IF the rules you want to enforce have changed AND you have the possibility to make the user change his password so that the new one complies with the new rules. Otherwise it is a waste of time, and added complexity (complexity is Bad).


Security while casting my YouTube on a smart TV I was wondering if casting from my YouTube account on my phone onto someone's tv gives access to my YouTube account to the owner of the tv once I stop casting.

No. The TV is not authorised to access your account and your account token is not given to the TV in order to display. The stream from your authenticated account is redirected to the TV.


QiHoo 360's antivirus false positive rate My colleagues recently bought an antivirus,the QiHoo 360 antivirus, for the chinese plant and implemented it on servers and laptops.

The anti-virus showed some of the developments files we've been deploying to the chinese server, .bat and some Microsoft Access's files with .mdb extension as containing the ARP virus.

I managed to get the files through a secure channel and analyzed them with McAfee AV and the Clam AV.

I've found no virus.

My questions are the following:

What are the rates of false positive QiHoo AV generate in comparison to other AV software?
Is there a way to fine tune this AV to reduce the number of false positive?

Thanks

Per your request, I formulated my comment as an answer:

To answer your first question, you can compare test scores over time using this tool: https://fatsecurity.com/tools/test-results-calculator?purposeId=1&groupId=1&startDate=2014-3-1&endDate=2017-3-1&companyId=19

In the table next to the graph, you can pick "False Alerts" instead of "Average Score":

http://imgur.com/zy71fJ8

You can access each test for a thorough review by clicking the data points:

http://imgur.com/yQVyDTx

@MarcusMüller is correct in his comment, Qihoo360 tricked AV testing labs in the past by activating the Bitdefender AV engine in the versions submitted for testing, while it's inactive by default on user versions.

I'm guessing that you could activate the Bitdefender engine in order to reduce the false alerts (although I'm not 100% sure about this), but the better solution would be to simply get Bitdefender or another antivirus which is more reliable than this (or another) Chinese AV.


Zero Knowledge Proof of ownership of an email address Let's say that we want to develop a blogging service where only people with an @example.com email can contribute.
Prior to post submission, the user requests that a large random token be generated by the service and sent to their user@example.com email. This token is stored in the service's database and can then be used to verify that the person posting a certain message + token combination actually has control over an @example.com email address.
This works well as long as the user trusts that the service is not associating their email address with the token that they received. However, consider a scenario where a user would like to post something that cannot be traced back to them (by other users [this is easy], or by the service itself [the hard part]).
Is it possible to prove to the service that I own a certain email address (by knowing the contents of an email sent to the address) without allowing the service to associate that email address with a specific secret?
Currently, assuming a benevolent service, it is easy to allow posters to prove that they are the authors of an anonymous post by storing a "signature" alongside each post for all to see. This would be computed as hash(<posters_email_address>@example.com + <auth_token>) so that at any point, the original author could publicly announce their email and authorization token and the hashes could be checked. With this scheme, each poster is anonymous (if they choose to be) with respect to all other users / viewers of the platform, but critically, there is an unknown possibility that they are not anonymous to the platform (if it chooses to be malicious).
In summary, can we prove to a potentially malicious server that we received some sort of authorization (via access to an email address) in a way that prevents the service from associating that email address with the given token?
Edit: I have done some thinking and it appears as if the person who receives their token via email needs to do something to their token before they send it back to the server in order to make tracing that token back to them impossible. It must be modified in a way where it can't be compared to the original token, but still maintains some property where the server knows that there modified token is derived from some token that it issued.
Clarification: We are not administrators of the @example.com domain. There is nothing special about this domain other than the fact that we explicitly check that clients have an email registered there.

Ideally, you would have example.com provide a protocol to authenticate the users (such as OAuth2, as suggested above). Or simply a "registration password" that is available at some example.com intranet.
Lacking that ability, you would probably want some kind of blind signature. Ideally through a third party. Probably that could use a system similar to the old Mozilla Persona
Adding a trusted intermediary would solve the issue, although you are mostly replacing the platform being malicious with the intermediary being malicious and colliding with the (evil) platform.
An interesting solution would be to (ab)use DKIM signatures. We might assume that all our customers will sign outgoing mail (this will not be the case, but it ubiquitous enough to be a reasonable restriction). On registration, the website provides a token and requests to receive an email at finishregistration@website.com which is DKIM-signed by an example.com key with such token in the subject field.
On validation, it checks that the message indeed passes DKIM for a key by example.com, and then processes the token as usual with url links. For nerdy enough clients, you could allow them to upload the DKIM signed source email, so they can actually verify what they are sending.
The hard part here is that the From: field will contain the email address,¹ so you would need to instruct the users how send an email spoofing an empty sender, accept that people could send you the email with the from: field revealing their identity (maybe they won't care?) or provide a program which can do that on their behalf (so that in order not to give you their email address, they execute an untrusted binary of your choice, to which they provide their email credentials…). Plus, the server itself which shall sign them, may reject/"fixup" a spoofed/empty From:, or include the sender identity somewhere else inside the headers.
¹ and probably the full name, not to mention people that would not removing their email signature full of PII.


What all can a Wi-Fi router be snooping on? Say, I am using someone else's Wi-Fi. I want to know what all information about my internet usage can be found out by someone who has access to the router or by someone who's also connected to the same Wi-Fi (through MITM or something).

There's a lot of possibilities that I don't understand how they might affect what all the router or a malicious user on the same WLAN can find out about my traffic.

In terms of what all could be known about my internet usage:

Does it make a difference if the Wi-Fi is password protected?
What if when I'm using HTTPS vs HTTP?
What if I use a proxy/VPN?
What if I use Tor?

In these situations, what all can the router know about my connections? What all can someone else on the same network know about my connections?

Any data that isn't encrypted will be visible and modifiable. For each of your scenarios:

If the Wi-Fi is password protected, it doesn't affect the router's ability to snoop, but it makes it slightly more difficult (but still entirely practical) for other wireless clients to snoop.
If you're using HTTPS, the site you're visiting will be visible, but the page on the site and any data you're sending to it won't be.
If you're sending all of your traffic through a VPN/proxy/Tor, nothing at all will be visible except your connection to the VPN/proxy/Tor server.


WireShark tried to load a suspicious system.dll When starting Wireshark (v1.12.2, using runas /user:administrator) on an old Windows XP SP3 system, Privacyware Privatefirewall alerted me that Wireshark was trying to load c:\docume~1\admini~1\locals~1\temp\nsq18.tmp\system.dll

Is there any way this is not an exploited system? Is there any legitimate reason why a program would be loading a "system.dll" from such a path?

I've been having an increasing paranoia that this machine has been hacked, but haven't been able to pinpoint anything. I've tried to lock down the machine as well as I can, but it's an old system and I'm no expert. (I have only minimal services running, always run as an unprivileged user, all ports closed from the outside, etc, but I really feel that I am really in over my head)

Download the 32bit Portable Apps version of Wireshark directly from Wireshark.org not from some third party site where their system could have been compromised. Verify the signature with the hash files if you are not sure.

If that DLL is still being called when you execute the portable app, then the DLL was hooked by something within explorer and there is a very high chance that your system has been compromised.

You can always upload any suspicious files to VirusTotal and they will throw it at several different AV vendor products to see what they catch.

You should strongly consider moving systems that are used in production environments off of Windows XP.


Differentiating Between First and Third Party Clients I would like to know how auth services, such as OpenID Connect and OAuth, are able to distinguish between a first party application over a third party one - in particular for clients such as mobile applications, since they obviously can't securely hold some predefined key/identifier.

An example of this would be the Google auth system. When signing in for gmail, there's no prompt regarding scopes; contrast to StackExchange using Google for an account which would show developer info and requested scopes.

I can understand how this could work for an SPA since you could set restrictions around the redirect URL but how would you ensure that the request was coming from a particular mobile app? Is that even possible to truly do securely?

It's possible to make this harder, but it is not possible to entirely prevent it - just tell developers to use your API but assume that it is possible for them to ignore your suggestion.

Google for an example offers a separate API for OAuth, which most websites/apps use, because that's what they are intended to use. However, it is still possible to create an app that logs "directly" into your Google account, if somebody really wanted to.


Does s2k hold any use in symmetric encryption with GnuPG I know that s2k or string 2 key is used to encrypt the private key of an asymmetric pair, but are the s2k-* options meant to be used with the -c or the --symmetric option? Does GnuPG give you no option to change the iteration amount with symmetric encryption?

What is the difference between --cipher-algo and --s2k-cipher-algo, in terms of using symmetric encryption?

OpenPGP uses the string-to-key function for both encrypting the private key with a passphrase and symmetric encryption. The function is used to derive a session key (cipher block) for symmetric encryption.

You can easily analyze what options GnuPG is applying by using the --list-packets command.

Default value of AES128 (algorithm ID 7) for the cipher algorithm:

$ echo foo | gpg2 -c | gpg2 --list-packets
[snip]
:symkey enc packet: version 4, cipher 7, s2k 3, hash 10
    salt 6E6B107661BD9B19, count 102400 (105)
[snip]

Switching to AES256 instead using the --cipher-algo parameter (cipher ID 9):

$ echo foo | gpg2 --cipher-algo AES256 -c | gpg2 --list-packets
[snip]
:symkey enc packet: version 4, cipher 9, s2k 3, hash 10
    salt 44F97F3EE31F2E46, count 102400 (105)
[snip]

And by using --s2k-cipher-algo:

$ echo foo | gpg2 --s2k-cipher-algo AES256 -c | gpg2 --list-packets
[snip]
:symkey enc packet: version 4, cipher 9, s2k 3, hash 10
    salt 2BFDAE2630AB5D5C, count 102400 (105)
[snip]

The same applies to setting the iteration count:

$ echo foo | gpg2 --s2k-count 2048 -c | gpg2 --list-packets
[snip]
:symkey enc packet: version 4, cipher 7, s2k 3, hash 10
    salt 6A08AD73CC36741A, count 2048 (16)
[snip]

With other words: you can use both options, they have the same effect, and you can also use the other --s2k-* options for symmetric encryption.


Why are there duplicated entries in the ARP table in a MitM attack? All I read when it comes of detecting a man in the middle attack is that the ARP cache table will have duplicated entries for the attacker MAC address, but I can't find the reason why.

The way I think it is (because one is the faked one and the other the normal ARP response) leads me to think: supposing I'm the attacker, would it not be as easy as not sending the real ARP response, but only the fake one?

Let's say we have a network with Bob, Alice, and the router. You are an attacker, called Eve.

Now, you wish to carry out a MITM between Bob and the router. There are multiple options now:

Capture traffic flowing from Bob to the router (e.g.traffic flowing
to Facebook)
Capture traffic flowing from the router to Bob (e.g. traffic flowing from Facebook to Bob)
Capture traffic flowing in both directions (Bob to router and router to Bob)=> most common attack.
ARP poison-bomb all hosts in the network

The victim's (Bob's) ARP table will look differently in each of the above scenario's:

Scenario 1

Eve's MAC : router's IP
(optional) Eve's MAC : Eve's IP

Scenario 2

(optional) Eve's MAC : Eve's IP
[On the router, Eve's MAC will now be linked to Bob's IP]

Scenario 3

Eve's MAC : router's IP
(optional) Eve's MAC : Eve's IP
[On the router, Eve's MAC will now be linked to Bob's IP]

Scenario 4

Eve's MAC : router's IP
Eve's MAC : Alice's IP
(optional) Eve's MAC : Eve's IP
[On the router, Eve's MAC will now be linked to Bob's IP]


Is there some kind of a local DoS against processes? Is there an attack that somehow floods a target process (e.g. by repeatedly calling a WinAPI function that involves the process) and thereby crashes or temporarily disables it?

Strictly speaking, what you are asking about is a Fork Bomb.

  ... wherein a process continually replicates itself to deplete
  available system resources, causing resource starvation and slowing or
  crashing the system.

In Windows (because you ask about that OS specifically) you cannot spawn new forks at the OS level, but you can create a cascade of new processes. That technique still falls under the "Fork Bomb" term.


texting password reset link instead of a code An increasingly common process for assisting with password resets is the application texting a code/token to the user’s verified mobile phone.

We have a client which would like to eliminate the need for the user to remember the code and instead send a bitly link via SMS where the code/token is embedded in the bitly link.   This way the user can just touch the link in the SMS message, which will launch their mobile browser and they can proceed with the password reset, possibly with an additional verification with security question or other PII data point.

Is there a reason the above process isn’t being used by the likes of Facebook and Google and instead they continue to just send the code via SMS?  It seems, at least on the surface, to just add an unnecessary step of memorization for the end-user to transfer the code from SMS to mobile browser.

I can think of a couple of flaws with that plan:

It doesn't work for users who are using a different device to perform the password reset for some reason, such as not using a smartphone. For Facebook and Google, it's not uncommon for users to change their passwords using a computer, but to receive a validation code by mobile.
Potentially increases the risk of phishing attacks, by encouraging users to follow shortened URLs claiming to be from a service provider. The use of bitly adds to this, since it's not easy to see the URL which the link actually goes to.

For a mobile application, it's a flawed premise to begin with though, since SMS is not a second factor in this case (an attacker with the phone has access to the SMS message!). Some providers take this into account, and require that password changes are performed through the website, even when they have an application, in an effort to ensure that the existing password is known to the person attempting to change the password (requiring that it is entered for password changes would also work, of course).


Is there an HSTS equivalent for DNSSec? Is there any way to set a DNSSec-always policy similar to how HSTS commands Web Browsers to always use HTTPS?

This would mitigate a DNSSec-strip attack (similar to SSLStrip)

I'm also unclear if this would apply to IPSec, where security is mandatory, however not sure if this requires DNSSec as a pre-requisite

No, there is not a direct HSTS equivalent for DNSSEC. Most clients unfortunately don't support DNSSEC, and therefore couldn't care less about your server's RRSIG record. However, clients that do support DNSSEC will always validate your server's records (Assuming you have a valid DS record for your domain setup with your registrar). So, there is no need for a HSTS equivalent for DNSSEC, as DNSSEC clients won't ever not validate domains.


What is a reasonable timeframe that should be defined and enforced for access token expiry to reduce the risk of unauthorised access? What is a reasonable timeframe that should be defined and enforced for access token expiry to reduce
the risk of unauthorized access?

Totally depends on the service you're providing, if it's something to consult data you might make it 5~15mins and if it's something like authorizations, transactions quick stuff, it might be reduced from 5~2mins
Usually financial institutions require a max lifespan of sessions and such and it goes below 15minutes or something like that.
Some context of what you're trying to secure might give more insight at answering this question


How to detect hosts running in virtual machines with nmap? I have to determine if a given subnet has virtual hosts.

Are there any ideas about what switches to use?

You could use the Metasploit Framework HTTP Virtual Host Brute Force Scanner module.

Nmap is best launched from inside Metasploit. See the Metasploit Unleashed (free training available from Offensive-Security) section on Port Scanning for more information.

If the target IP address is available from the global Internet, then I suggest you also check out MyIPNeighbors and SHODAN, which are incredibly resourceful for this sort of reconnaissance activity.

Identification of caching servers, CDN infrastructure, reverse web proxies, load-balancers, internal IP prefixes, archived content, and associated hosts may also help during the investigation of virtual hosted infrastructure. Be sure to check out tools such as the Host/IP Pattern Extraction Tool (host-extract.rb), Halberd, The Web Archive, HTTP Archive, and W3AF.

To circle back to your original question, it is possible to scan for vhosts using an NSE (Nmap Scripting Engine) script called http-vhosts. However, it's good to know the intricacies of the entire target architecture before settling on a final decision about what has been / has not been discovered.

Typically, I find it easier to first find a path disclosure vulnerability that leads to a file read inclusion vulnerability -- and then to download the web server configuration in order to go through it manually. Or email/phone/text/DM/FaceBook-message the web server administrator who has access and then ask him or her for a copy of the web server configs.

If you are on local LAN (force with --send-eth), you can map the MAC Address' OUI 12-bit extension identifier map to the org assigned by the IEEE Registry Authority. Nessus and some other tools do this by default. My favorite is NetworkMiner of the traffic, as it also provides a sample of packet analysis and gives a good view of what happened for proactive troubleshooting.


Could one fit a root application in sim card In the third Mr.Robot episode a character inserted a Micro-SD card in a smartphone in order to root it and gain information, so I thought maybe someone could fit a root-kit on a Sim-card. Would that be possible to achieve in terms of the space available on a Sim-Card?

Some SIM cards have a capacity for 128KB (or more) of storage, easily large enough for a small exploit, perhaps a rootkit plus remote execution vulnerability. Conceptually, phones have a sandbox that protect them from the SIM's data, but there are known vulnerabilities that can be exploited. Technically, these cards aren't supposed to contain executable code (they should contain only data), but there's nothing prohibiting this rule. After all, they are basically small processors with permanent storage (Software-on-a-Chip, or SoC).

One such article that I found suggests that the sandbox can be defeated, and also that no carriers have bothered to patch this exploit, simply because "nobody's using it." Admittedly, this article is already two years old, but for most vendors, that's almost as good as yesterday in terms of carriers, who rarely spend time patching even critical exploits, much less exploits that supposedly aren't used in the wild.

A well-versed hacker, such as Mr. Robot is supposed to be, could easily write code that could exploit a phone, even if it hadn't been previously rooted. Of course, if the phone were already jailbroken, perhaps to enable a custom OS or unlock features such as tethering or changing carriers, the exploit might be even easier. Mind you, I'm not aware of an explicit exploit that exists in the wild, only example/proof-of-concepts, but it appears that the author of Mr. Robot has bothered to do their homework within the realm of possible. Please keep in mind that Mr. Robot, like almost all television shows, are science fiction, usually based on fact, but not historical evidence.

It's also well-known that a hacker that has physical access to almost any system basically has full control of the system. For example, a hacker can easily crack all Windows passwords using Linux-on-a-disc, and a hacker with sufficient knowledge and resources could hack any phone, even one with full encryption enabled (but this is a very specialized, and very costly technique).


Good resources for learning cryptography and OpenSSL? I'm a programmer and I'm working on a Single Sign-on project using SAML. I want to do all I can to make this as secure as possible. Since making a secure Single Sign-on/SAML solution requires signing xml messages over https and creating various keys/certs etc etc I think I better know about this stuff! I don't want to learn how to be a cryptographer, just know how to properly select the right cryptography method for this project and future projects.

I tend to like to find a few GOOD books and then watch some lectures/talks about a subject so I can really dive into what I'm learning so I can actually grasp all the new vernacular.

So far I bought "Network Security with OpenSSL" and I'm reading it but I have to admit some of the stuff is going over my head.

If your an openssl, public/private key making guru, what helped you get to that level?!? :D

Thanks!
Jason

You probably don't want to be working at the level of selecting from among several encryption algorithms, digital signature primitives, etc.  That's too low-level, and it requires too much crypto knowledge to get everything right.

Instead, you want to be selecting from full protocols that other have vetted: e.g., TLS, OpenPGP, OpenID, OAuth, etc.  There the authors of the protocols have already done the work of figuring out how to piece together the encryption/signing algorithms into a full protocol, and those protocols have been carefully vetted by knowledgeable cryptographers.  Therefore, if you can possibly use some existing vetted scheme like this, you will be much better off (and much less likely to have subtle flaws in your crypto).

If I had to recommend one book for the practicing programmer, I would recommend Cryptography Engineering: Design Principles and Practical Applications by Ferguson, SChneier, and Kohno.  It is fantastic.  But it also describes design of cryptographic schemes at a rather lower level than you probably want to be working, if at all possible.


Why do digital certificates provide authentication? Let's say Alice wants to communicate with some server S. Eve manages that the traffic from both parties will pass her in order to impersonate server S. Now, digital certificates are supposed to provide authentication. In this scenario it should ensure the identity of the server, so that Eve is not able to impersonate S. But what prevents E to send the identical certificate from server S?

As i've understood, the digital certificate that was issued by a CA or a intermediate-CA to S has only static fields, meaning there are no fields that will change upon request. All fields are static until the certificate expires or it is revoked. A certain subset of these fields is hashed and a signature algorithm is applied to the hash using the private key of the issueing authority.
The client can verify the signature by hashing the subset of fields and comparing the calculated hash with the "decrypted" signature (using the public key of the issuing authority) value that resides in the certificate.

So, if Eve just passes the certificate from S to A, A will verify that the certificate is valid and thus believe that it is communicating with S instead of E.

What am I missing here?

You seem to understand that Alice checks that the certificate was issued for the server and that it was signed by an issuer (certificate authority) which is trusted by Alice.

But what you are missing is that Alice also asks the server for a proof that the server actually owns the certificate - a proof which only the server but not Eve can do. This proof is essentially done by Alice giving a challenge to the server and the server signing the challenge with the private key matching the public key inside the certificate.  This signature then can be verified by Alice using the public key inside the certificate.

Since Eve has no access to the servers private key Eve cannot properly sign the challenge and thus Alice will detect that she does not talk to the expected server.


Does my account lockout policy makes sense? I have a web-based application where users can log on with username and password.

I just implemented a new account lockout feature and was wondering whether it makes sense or I totally screwed it up.

The first 3 invalid login attempts just show my standard:

Incorrect user name or password

but I store each failed attempt. For any further attempt, I lockout the account for more and more seconds and I show this to the user:

The logon failed because your account is blocked due to a previous unsuccessful attempt.
Please wait a 18 seconds and try again.

If the failed logon count is greater 10, I lockout the account for 120 seconds, that is the max wait time.

If the proper user finally remembers the correct password, she has to wait 2 minutes, that's
not too bad.

But a hacker can only try a new password every 2 minutes, which soon becomes tiresome.

After a successful logon my failure-count is reset to zero.

All the numbers here are configurable.

Problems:

After a few attempts, I disclose that a username is valid, by
displaying a different message, but I could turn that off as well and
always just display the standard message.
If the real user tries to log on while someone else is trying to
break into her account, she wont be able to log in, so this is a
denial of service. But two minutes after the attacker gives up,
she can log in without having to call the help-desk.

I agree with you on the flaws, but it appears to be along the right lines.

  After a few attempts, I disclose that a username is valid, by displaying a different message, but I could turn that off as well and always just display the standard message.

Yes, you should execute the same behaviour for invalid usernames too. Your site should simulate the lockout policy for these users. This will help protect against Username Enumeration.

  If the real user tries to log on while someone else is trying to break into her account, she wont be able to log in, so this is a denial of service. But two minutes after the attacker gives up, she can log in without having to call the help-desk.

You're correct in this is a DOS attack against the user. Maybe you should simply rate limit attempts after X failed attempts. An artificial delay of 5 seconds would stop brute force but it would allow a legitimate user to log on. The attempts should be measured by username and IP address (separately) and the throttle should be across threads to prevent an attacker submitting requests in parallel. Again, the same logic should apply to invalid usernames too.


Is server startup time sensitive information? Let's say we have a web server. Server startup time is the time the server process was started.

Say, the startup time was being leaked via its response headers due to the carelessness of a programmer by not getting current time while the generation of the response. The programmer is using the time variable he initialized before entering the "listening" loop, which remains the same throughout the process's lifetime, which is the time the process was started.

As we know that date field must be the date and time the response was generated which it is not in the current situation.

Could this information be useful to an attacker? How?

Yes, this could have value as a source of info.

If the attacker is looking to see if a DoS is working, then the server uptime can provide data about success. Alternatively, knowing that a server has been up for a very long time can indicate that resources might be starved, or it is unpatched.

It could also be used to get a sense about the infrastructure's response to load. If you are in a DevOps scenario, where you generate new servers, one could start to map out the unique servers and make some estimates about how many servers you might spawn (if a small pool) or at what load you start to spawn new servers.

Uptime could also be used to uniquely identify one server in your cluster.

The real question is: how much value is this to an attacker? That will depend on your specific environment.

I might push back on the term "sensitive info", because I do not think it is. I would rather use your other expression "useful information" because it might not have intrinsic value by itself, but can help provide secondary information that an attacker could certainly take advantage of while pursuing other goals.


macOS and .ssh/id_rsa security My super crucial private key is stored at ~/.ssh/id_rsa
with a chmod of "-rw-------"

I run a lot of applications on my Mac.
For example:

Bash scripts
.app binaries (For example, Sketch.app)
Ruby gems and Python packages

It seems to me that anything I run has access to my private key
and, in theory, can siphon it off with an HTTP POST to a hacker's server.

Isn't this a security issue?  How do folks mitigate it?

Yes, malicious software running as your user can do anything that you can do as a user.  There is no privilege separation between different applications running as the same user.  This has also been noticed by xkcd.

To protect your SSH key specifically, you can add a passphrase, as mentioned by galoget, but that will only help marginally -- a malicious program could also scrape memory when the key is in use or log your keystrokes for your passphrase.  (Though there are some mitigations for those attacks.)

A better option is to use a hardware token of some sort -- I use a Yubikey 4 with an OpenPGP key for SSH authorization.  Though my key might be abused when unlocked, the key material itself cannot be stolen, and it is only unlocked for a short period of time.  (You could set this timeout to near 0 and require user interaction for each use of the key.)

Another option is to store your key under another user account and use su to switch to that account before SSHing.

In any case, if you have malicious software running as your user on your computer, you're going to have a bad time.


Is there any security threat due to advertisements? I was working on my localhost in my computer but I was connected to internet. Recently I downloaded a few music files and since then advertisements are getting popping into my browser through which I downloaded the songs. Advertisements are being shown even if I open a webpage in the localhost. Is there any security threat due to these kind of ads?

You've probably downloaded and installed a piece of adware like the Social Search Toolbar or something similar. Such adware are known to force install certain browser addons/extensions/plugins that inject advertisement boxes and/or popups into the webpages you visit.

The good news is that the vast majority of those adware aren't really sophisticated and can be easily removed. Go to your browser's addon's page and try to find anything suspicious then copy the name and try to find removal instructions on Google. For example, there are tens of results on how to remove the Social Search Toolbar.


Did I install malware/virus? I bought a laser plotter, and the seller provided me with software to control it. It's called EleksCam. The provided package from the seller (from aliexpress) consisted of assembly instructions and other stuff (see files from seller.png).

What worries me, is that I have downloaded the software EleksCam from the official site, and comparing the contents of the folder from the seller and the official site, they have two different sets of files (see compare packages.png). It's supposed to be the same software, same version. Yet, the seller insists that I install his package, running the bin application. Which I stupidly did. It didn't work, so I went to the official package, realising the difference in the contents (no bin file there).

Could someone tell me what to do next? How do I get rid of the potential malware? Here's a link to the compressed folder of the seller's package. The bin file is in there.

Help?

EDIT - POSSIBLY CRUCIAL DETAIL: when running the driver file, I was prompted to allow it to make changes on the hdd (as per usual), but when I clicked yes, and got back to usual screen, the console saying something like "you can use CTRL+G" so I did, and it seems it's a xBox related windows function for screen recording. Same thing happens when running the original app's driver installation.

Do basic malware analysis.

Compare the sizes of the executable, one from the seller and one from the official site.
Submit the binary to VirusTotal, from there there are a lot of anti-virus vendors which has a library of hashes that are deemed malicious. (Sometimes it can be an unknown malware)
Download process explorer to check for potential running processes.
Check for abnormal outbound connections (netstat).

And I believe this is a benign application. Upon checking on the file system you have, there's nothing suspicious about it.


How to perform taint analysis on Java source code? I want to perform taint analysis on java programs. I want to do this  by finding functions calls, variable being modified, variable being accessed. So my question is how do I do this? I think Java parsers can be used here. But I will have to implement my own logic to find variable being accessed and modified. So I want to know if there is any high level library already present for this?

You need a Java parser. Most exactly, a static Java code analyzer.

There is a lot from them, for example SonarQube.

It has already a lot of builtin rules, but also you can implement your own ones.

Its core follows the most common lexycal analyzer flow:

it constructs a tree structure from the syntactical elements
then walks this tree, and
you can attach hooks (the instance of your lexycal analyzer classes will be called upon) entering or leaving the nodes of this tree.


"I hacked my way into this interview": Is this a good idea for getting a job? There's been some joking on the internet where a candidate would "hack their way into getting a job interview" and disclose that as a proof of skill in a job related to Infosec.

If I somehow find a "hack", such as keywords in an ATS, bypassing application checkpoints, secretly putting my name in the "interview list", or anything similar, would it be a good idea to disclose that along with a report on that hack as a reason to hire me for a job in Infosec?

From some quick research (such as 23946), I'm guessing not.

Gaining access to a computer system without the consent of the owner is a violation of law in most countries (if not all of them). If it is your future employer, then I would guess it shows that you can not be trusted with confidentiality, on top of it being illegal.

Please don't do it.

If you want to show off your skill, then offer to take a test or get permission first. Make sure that whoever gave you permission actually has the rights to do so.


OpenSSL ECC key - Additional byte in DER encoding for one curve In the below, I use OpenSSL to create a private key for the secp224k1 curve. Note the length of the private key in the DER - 0x1d. That's 29 bytes, or 232 bits, not 224. It appears that a leading zero byte has been prepended.

$ openssl version
OpenSSL 1.1.1a  20 Nov 2018

$ openssl ecparam -name secp224k1 -genkey -noout -outform DER -out ~/secp224k1.der

$ certutil -asn ~/secp224k1.der
0000: 30 69                                     ; SEQUENCE (69 Bytes)
0002:    02 01                                  ; INTEGER (1 Bytes)
0004:    |  01
0005:    04 1d                                  ; OCTET_STRING (1d Bytes)
0007:    |  00 9b 69 d2 25 22 85 cc  58 c5 57 29 7e 59 02 6f  ; ..i.%"..X.W)~Y.o
0017:    |  ee 90 b1 f7 7e 78 c3 10  5c 20 52 22 78           ; ....~x..\ R"x
0024:    a0 07                                  ; OPTIONAL[0] (7 Bytes)
0026:    |  06 05                               ; OBJECT_ID (5 Bytes)
0028:    |     2b 81 04 00 20
         |        ; 1.3.132.0.32 secP224k1
002d:    a1 3c                                  ; OPTIONAL[1] (3c Bytes)
002f:       03 3a 00 04 47 21 06 a1  dc ea 7d 12 e9 0f 00 29  ; .:..G!....}....)
003f:       ca 5d db 67 3f 51 e3 b3  a7 5a b6 8c d3 23 f6 93  ; .].g?Q...Z...#..
004f:       7f 8a a2 fe ce cb d9 22  f1 92 95 69 4f 25 08 3a  ; ......."...iO%.:
005f:       0d 28 1a 27 a8 99 0e 5f  0b e0 17 b5              ; .(.'..._....

Now, since this is OCTET_STRING, not INTEGER, the number having MSB 1 should not have led automatically to the prepended zero byte. Indeed, for secp224r1, it does not:

0005:    04 1c                                  ; OCTET_STRING (1c Bytes)
0007:    |  e5 5f 38 18 d8 7b ca 84  85 f3 c0 1a c7 83 21 bf  ; ._8..{........!.
0017:    |  b9 f9 ed 9c 83 2b b5 b0  ce 15 6c 0b              ; .....+....l.

This behaviour does not occur for either of the secp256r1 and secp256k1 curves. Does any one know why it would have happened for this one?

Thanks.

Although for secp224k1 the size of the underlying field, and thus point coordinates including a public key, is (slightly) smaller than 2224, the order of the curve group, and thus the size of a private key, is slightly larger than 2224 and nominally requires 29 octets to represent -- even though the probability of d chosen uniformly at random per spec actually needing 29 octets is so small it probably won't happen during the Earth's lifetime. Quoting SEC2 from http://www.secg.org (since it's free and X9.62 isn't) minus formatting I can't reproduce without MathJax:

  2.3.1 Recommended Parameters secp224k1
  The elliptic curve domain parameters over Fp associated with a Koblitz curve secp224k1 are
  specified by the sextuple T = (p, a, b, G, n, h) where the finite field Fp is defined by:
  p = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFE56D
  = 2224 − 232 − 212 − 211 − 29 − 27 − 24 − 2 − 1
  The curve E: y2 = x3 + ax + b over Fp is defined by:
  a = 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  b = 00000000 00000000 00000000 00000000 00000000 00000000 00000005
  The base point G in compressed form is:
  G = 03 A1455B33 4DF099DF 30FC28A1 69A467E9 E47075A9 0F7E650E
  B6B7A45C
  and in uncompressed form is:
  G = 04 A1455B33 4DF099DF 30FC28A1 69A467E9 E47075A9 0F7E650E
  B6B7A45C 7E089FED 7FBA3442 82CAFBD6 F7E319F7 C0B0BD59 E2CA4BDB
  556D61A5
  Finally the order n of G and the cofactor are:
  n = 01 00000000 00000000 00000000 0001DCE8 D2EC6184 CAF0A971
  769FB1F7
  h = 01

See https://github.com/openssl/openssl/commit/30cd4ff294252c4b6a4b69cbef6a5b4117705d22#diff-a51596fb2f3b3650972f0f650cdcf115 -- although this was initially implemented wrongly, using the field size ('degree'), and subsequently fixed to use group order (not directly in ec_asn1.c but by calling to EC_KEY_priv2{buf,oct} in ec_key.c) AFAICS only in 1.1.0 up.


How was the Apple Hacker caught? How can meta data be used to identify users through chained VPNs? Online privacy is a big issue for many people nowadays.
Using VPNs is the usual suggestion as a means to stay anonymous. More often than not, somebody comes up with the point "just chain multiple VPNs together and you should be safe".
However, my intuition says that one can't hide meta-data and that there's a lot of useful information in them which can be used to break online privacy.

Now I'd like to know whether this tactic of chaining VPNs is actually effective or more explictely, especially with meta-data in mind:

Can meta-data be used to identify users and associate them with activities while they are actively trying to defend their privacy with chained VPNs and and if so, how?

Very good question. Metadata is insanely powerful, and most people just don't realize how powerful it can be. Fortunately, it's not that hard to discover if you do a little digging into how technology and the internet works.

I'm of the opinion that it's not very easy to hide online. In most cases, if you're a small fry, nobody's going to pay attention to you much beyond the first investigation into your activities if nothing shady comes up.

National Security Letters and Subpoenas

Thanks to National Security Letters, the NSA, FBI, DEA, CIA, and other alphabet agencies can work together to request lots of data from American companies. If you wish to operate on U.S. soil, you are subject to U.S. laws and regulations.

Due to the Stored Communications Act, while companies aren't required to store information on users, they are required to handover any kind of information that they've stored.

In some repressive countries, the police just need to show up and force you to do anything they want, and you'll have no choice if you want to live. Worse still, the government may own those internet service providers.

What is a Device ID?

When I talk about "Device IDs" in this post, I refer to anything that can uniquely identify your machine: Operating System keys, hardware Device ID enumeration, browser fingerprints, accounts that you're logged into, et al. Assume it's a piece of information that uniquely identifies you.

Device ID Correlation

Many VPN users think that they can chain multiple VPNs on a single machine, and that they're "safe." They are usually reconnecting to multiple services under different IP addresses, but their Device ID remains the same.

Even if they were to shut down their service accounts (Skype, Steam, Battle.net, et al), they're generally still leaking information to Microsoft, Apple, et al. You're requesting updates periodically from Microsoft. You're also often sending packets to Microsoft servers every now and then.

And if you shut down your service accounts prior to performing illicit actions, it points to a clear pattern of trying to hide yourself, and will help give you away. In many cases, you're damned if you do, damned if you don't.

Even if you use Linux, you're usually requesting information from update servers periodically. For example, Ubuntu frequently phones home to get information. Ubuntu will use whatever IP address you happen to be using at the time.

Most major service providers record every single IP address that you've ever used to connect to those servers. Either you, or someone else using your account. When you use Windows or OSX, the information about your computer is sent to their servers. All IP addresses associated with that device ID will help investigators find you.

Note that most of the IP addresses in these images are local IP addresses so I don't end up posting someone's address and causing them annoyance.

These investigative methods are used by good guys, and bad guys. In some countries, having the wrong beliefs, being the wrong race, or opposing the wrong people will usually result in your death.

Real World Example of Successful Device ID Correlation

It appears that with the recent Apple Hack, the attacker attempted to hide his identity behind proxies, but connected to an Apple server via SSH, which somehow revealed his actual Mac serial number during the connection process:

  "Two Apple laptops were seized, and the serial numbers matched the serial numbers of the devices which accessed the internal systems,"

IP Address Correlation

Another method, which usually always assists Device ID analysis, is the IP Address Correlation. I called it an attack in the picture, but it's really an investigative method. And a damn good one at that.

It isn't just your IP addresses used. It's the time range that such IP addresses are used.

This can be used to detect those who are clever enough to hide behind multiple proxies without leaking any additional information, other than the IP address itself.

Quantum Insertion

This is likely just a classic Man-in-the-Middle (MITM) attack on non-HTTPS websites, or HTTPS websites with improper configuration, which was given a fancy name. Nothing more.

This may only reserved for high-value targets, or abused with reckless abandon; using this attack against security researchers is actually a painfully stupid thing to do. It's best if the target is completely unaware. With the Snowden leaks, any researcher worth their salt will be reading about these kind of attacks because "bad guys" will be doing it too.

Quantum Insertion is just a MITM attack which could allow a threat actor to intercept a request to retrieve a file from a website, or even a fake website, and then replace it with another one entirely. For example, if you're downloading known hacking tools, a man in the middle attack, if successful, will redirect your download and replace it with an infected variant of the same file.

In other cases, a threat actor could insert infected Flash or Javascript files into the page and exploit a vulnerability.

With a successful MITM attack, an actor can gain access to the machine you're on, and easily find out who you really are by unraveling your VPN chain from the source. At the very least, they can get the first entry point of your IP address in the proxy chain.

They could also steal your password through unencrypted or intercepted connections. Password re-use can help reveal your identity as well (see page 57 in the document, or 59 if using "go to page").

Examples of things Vulnerable to Quantum Insertion / MITM attacks

Typical targets would tend to be high-traffic downloads or websites that are unencrypted. This could include websites that only provide insecure methods for downloading the files.

For example, Nvidia drivers default to non-https downloads with no verifiable hashes or signatures available on their HTTPS site, and many Linux distributions also serve ISOs over unencrypted connections - some of which even fail to provide verifiable hashes. What's more, Nvidia drivers frequently phone home with device IDs.

Popular security products such as Burp Suite require Jython to run modules. Jython has no https certificate on their website, does not provide hashes for the latest version of their software, and they only provide SHA1 and MD5 hashes for older versions. Given that Jython has no actual https certificate, these hashes could easily be modified to give you a false sense of security. Older versions of software are frequently outdated and may lead to compromise of your system, or further compromise through privilege escalation.

XKeyscore and PRISM

XKeyscore and Prism have all of the abilities I've mentioned here, and much more. Say what you want about the NSA and their generally ineffective dragnet surveillance: they are damn good at figuring things out after the fact. This helps prevent people from getting away with committing crimes in the long run. It also helps bring the bad guys to justice... do what you want with that information.

Is it just the government that can track you this way?

Unfortunately, no. Repressive regimes, corporations, advertisers, and the like, are able to create and maintain such databases in order to track users around the web.

Many companies also share your data with third parties. It's even there in the EULA. Read the EULA next time, and it will reveal connections to many of the things I've mentioned here. Remember, if it's free, then you are the product. And in many cases, even if it isn't free (Windows, et al), you are still the product.

And in repressive regimes, if companies such as Apple and Microsoft wish to do business, they are required to adhere to the laws of that country. This is one of the many ways that repressive regimes can track down individuals behind Yahoo, Hotmail, Google, and other accounts. And if those companies refuse to provide information, then they'll face fines, expulsion, or worse.


PKI solution vendor selection What would you look for in a (X.509-) PKI solution, and why would you look for that, given the following constraints:

Available programming/sw-engineering know how is limited (ie, "OpenSSL with a handful of Perl scripts" is not a feasible approach)
Processes are reasonably well understood (eg certificate lifecycle)
Some (root/intermediate) certificates will have high monetary value and must be protected accordingly (HSM?)
Handle "a couple of tenthousand" identities across multiple organisations with delegated admin rights
Hardware-based solution (smartcard or otherwise) is likely to emerge as a requirement soon.
On-premises, self-hosted solution

I have identified some candidates from the "usual suspects", but I have some doubts (the market seems to have matured very little over the past years?). I will therefore not name the candidates but ask for unbiased inputs.

Full disclosure: I work for Voltage Security.  I think it's better to state that up-front, rather than give you some sales spiel and then "accidentally" point you to our web site.  While this is not a company-sponsored response in any way, I freely admit that my views are not unbiased. I will try to minimize the leakage into this response, but please read with the appropriate degree of skepticism.
The fundamental issue with asymmetric encryption schemes is not the encryption, but the key management.  So what distinguishes PKI systems is not the security of the encryption, which is identical, but the ease of user provisioning, deletion, and general system management.
So, the questions I would ask of a vendor of asymmetric encryption are:

What is the process for bringing a new recipient of encrypted data in to the system?
How are the private keys stored, protected and backed up?
How are credentials managed?
How are name changes handled?(e.g. someone gets married and changes their name & system logon: what, if any, are the impacts?)
How can encrypted data be scanned by data loss prevention devices to ensure insiders are not using the encryption facility as a way to smuggle data out of the company?

EDIT
(this is the stuff I left out originally, because it felt too sales-y)
Reasons for asking the questions above:

Most PKI systems require the recipient to create a public / private key pair before any data can be sent to them.  This inhibits ad-hoc use of the system, in which people can encrypt for any recipient.
If a private key is lost, the data encrypted with the corresponding public key is lost.  End of story.  Any serious PKI system will have some mechanism for retrieving lost private keys.  If this is a database of keys, then you need to think about how this is protected, and ensure that it is backed up frequently.  Also consider replication if the solution has to exist in multiple data centers for high availability.
This is a easy one: users have to provide some sort of authentication credentials to get access to the private keys.  Ask how this can be integrated into existing authentication methods.
Imagine that Mary Jones gets married (or divorced) and becomes Mary Smith.  Using the credentials for "Mary Smith", she needs to be able to access data that had been previously encrypted for "Mary Jones".  The PKI system should handle this case gracefully.  The alternative is finding all the data encrypted for "Mary Jones", decrypting it and then re-encrypting it for "Mary Smith".  Yuck.
Fundamentally, the DLP device needs to be able to access the plaintext of any encrypted data.  Ask how this can be achieved.