Securing iOS applications communication from client side Many of you have heard about instagram flaw that facebook has not fixed yet,

The flaw allows the attacker to hijack the session by sniffing the session cookie on Instagram iOS app since it does not encrypt the communication,

I have been looking for a way to protect my account - say that I am famous and hackers target me :p - What would help me protect it from my side. I am not the developer, and I don't work on Facebook, so I cannot fix the flaw.

Someone would just say, do not use the iOS app and just use the browser, but that would not fix the problem as I am looking for the best solution.

Is there a way to secure the iOS apps communications? Do I need to register to a proxy server and set it on iOS, or rent a VPN? what would be the advantages and disadvantages of my solution and is there any better way?

This belong to a more general question which could read "what can I do, as a user, to protect myself against services that have know unpatched security flaw".

The answers aren't very nice, unfortunately.

First - and perhaps the best way to handle the issue - do not use the vulnerable service and applications. This is the best possible way because not only does it protect you against your data (identity, etc.) being stolen, it also put pressure on the provider to fix their service.

Second, try to mitigate the problem: use 2FA if it is available, don't reuse password, use the service only minimally and assume every data you place it on is going to be compromised: properly planning ahead your recovery is often half the battle.

Third, try to lower the risk of interception by using a VPN to a network connected as close as possible to the target service. Unless you can connect directly to the target network, this does not remove the vulnerability but it does force any attacker to get in the route between the end of your VPN tunnel and the target service in order to exploit it.


MX records being linked to spamming? I have seen a rule in an environment that detects DNS MX query types going from an internal source to an external, none SMTP server.
The justification states that this could be indicative of malware being used for spamming. I would like to better understand how
this works, does anyone have an explanation of how this would work.

The basic idea is probably that internal clients just use the mail server of their specific mail provider which is configured in the mail user agent. Whereas spam tries to deliver directly to the MTA (mail transfer agents) of the target domain. The configured mail server does not need MX lookups (just normal A|AAAA lookups) while the delivery to target domains MTA needs  MX lookups. And spamming lots of different domains thus causes lots of different MX lookups.


EAP-TLS fragmentation implementation I am trying to build an EAP-TLS client. The handshake I have to deal with involves receipt of fragmented messages from the RADIUS server. As a part of the client reply, I have to construct a certificate verify message, which involves hashing all messages involved in the handshake using a private key, to ensure mutual authentication. So, do I treat the fragmented messages as separate messages (because each fragment has an Ethernet header appended to it) or as a single message? Thanks !

In TLS, the handshake messages are encoded into records. Each record has its own header. A given handshake message may be spread over several records, and a record may contain several handshake messages.

The hash computations for CertificateVerify and Finished messages is over the handshake messages only: you input the successive handshake messages into the hash function, in due order; each handshake message begins with a four-byte header (one byte for the message type, three bytes for the handshake message length), and these headers go to the hash function as well. The record headers do not enter the hash function.

In other words, fragmentation into records is ignored in the hash computations. The resulting hash value does not depend on how the handshake messages where conveyed, in particular any kind of fragmentation. EAP/TLS defines that the EAP messages contain TLS records. Neither the Ethernet headers, the EAP packet headers, or even the TLS record headers, enter the hash function. Only the handshake message themselves are hashed.

(This allows for a cleanly layered implementation: the SSL/TLS library produces handshake messages which are sent one after the other on a conceptual endless stream of bytes; the stream is hashed; the library does not have to care about how the stream is split into records encapsulated into EAP messages fragmented into individual Ethernet frames.)


Sniffing an outbound HTTPS packet - only intercepted by certain software, can't decrypt I'm trying to sniff an SSL-encrypted outbound packet. It's sent by the game Mass Effect 3 to an EA web service.

When I sniff packets with Nirsoft SocketSniff, I can see the packet (positively identified by the moment it appears in SocketSniff):

Socket      Index  Type  Local Address  Local Port  Remote Address  Remote Port  Send Calls  Receive Calls  Sent Received  Closed
0x00000CBC  24     TCP   192.168.0.111  49191       94.236.58.180   443          5           492            661  1,753     Yes

I can then click on this row to view hex dumps of all communications (in both directions) on the relevant socket. There are 5 sent packets, and 12 received packets, one of which is a partially legible certificate from Electronic Arts inbound to my PC.

I can also see the communication in more detail in Wireshark, which shows this:

When I click on the Application Data row, I can see hex-dumped ciphertext. However, I want to view the plaintext, so I need to use an HTTPS proxy.

I first tried Charles, which I configured and successfully used to decrypt some HTTPS data to and from a website, as well as some different HTTPS traffic from Mass Effect 3. However, the packet described above does not show up in Charles. I also tried Fiddler 4, which I similarly used to successfully decrypt HTTPS traffic, but the packet does not show up in Fiddler either.

So out of the 4 pieces of software that I used, 2 of them can pick up the packet, but not decrypt it, and 2 of them can decrypt HTTPS traffic, but can't pick up this particular packet.

Any ideas for what I might be doing wrong, or what I can try next? I can provide more information if needed.

Using an HTTPS Proxy relies on the fact that you can MitM the connection by using a self-signed certificate. Effectively you can create a certificate for "*.ea.com" issued by your own CA and tell the HTTPS proxy to send it to your game, in case it tries to establish an outbound connection.

This is the normal process:

Game wants to contact ea.com
Performs a TLS handshake with ea.com
Receives a certificate saying "this public key belongs to ea.com"
Game determines whether the certificate is authentic and trusted
If no, terminate connection, otherwise send encrypted data which can only be decrypted by the owner of the private key

As soon as the game encrypts the data, you cannot decrypt it, even if you use Wireshark. Using a proxy which breaks HTTPS does this:

Game wants to contact ea.com
Tries to perform TLS handshake with ea.com
HTTPS proxy establishes the connection to ea.com itself instead
HTTPS proxy gives the self-signed certificate (which YOU have the private key for) to the game

All traffic is now decrypted and re-encrypted in the HTTPS proxy using the self-signed certificate

Game determines whether the certificate is authentic and trusted
If no, terminate connection, otherwise send encrypted data which can only be decrypted by the owner of the private key (which is YOU in this case)

Step 5 is problematic. An HTTPS proxy only works if the game relies on the OS to determine the authenticity of a certificate. In this case, you can locally install your self-signed cert and the OS happily tells the game "yup, everything is fine". If the game does some sort of HSTS- and certificate pinning technique to avoid fake-certificates and insist on an original on (or even stores the only accepted (root)certificate locally in its code), you cannot trick it in accepting a self-signed certificate (without messing with the game's code itself).

I assume this is the reason for your HTTPS proxy failing to replace the original certificate with a fake one. Your proxy does either not pick it up, as it cannot reveal the plain text or pick it up without being able to decrypt it.


Ouath2 how does it work (Android client) I have read a lot about Oauth2 but still cannot understand, how does it work. I will explain how do I understand this protocol.

There are some main characters in Oauth protocol interaction.
User, application, resource provider and authorization server.
How do I understand main flow.
I am creating mobile client, so I will use it as an example.

Firstly user installs app, than first time user run this app to access secured resources user have to enter password and login not directly credentials for resource server, but for authorization server. For example, I have online store app , user allowed to login via facebook account, so when user need to access resources from my site first step will authorize with facebook account. You enter login and password and if credentials are correct facebook server gives you or your app access token.

After you got the access token, you store it on device in secure place or in local database (for android it is SQLite).
When you successfully signed in, Oauth server redirects you to the resource provider server (my online store) wit token, resource server saves this token into the database along with user id/login name. So now your resource server knows that user with such id can access secured resources with this token.

On the client side (android app) you now have this token, it has expire date.
When you need to access secure resources you pass this token in your POST/PUT or any request over HTTPS protocol, because if another person get this token, it can be used to access private, and make changes.

For example you need to place an order, from mobile client you make REST request with attached token, resource server checks this token and if it is the same as in the database you are allowed to access/change secured resources.

Am I right, or I don't understand Oauth protocol correctly ?

Now my questions

If I have native client, and I don't have ability for user to login with social network accounts and other Oauth2 servers in the network, only allow to login as on the web page ? With password and login. In this case Oauth2 is not applicable in this case ? If yes, next question.
What should I use instead ? I need to send credentials only once to my resource server, it will check them, generate token if everything is ok, put token into database, and return success response to the app. For instance using POST method over https connection to send password and login for the first time. Now resource server issues me the same token as in Oauth flow ?
How can I secure issued token ? Make user reenter login and password after some time ?

Please help me to get this. I would be grateful for any help.

To your questions:

  [...] I don't have ability for user to login with social network accounts
  and other Oauth2 servers in the network [...].

You will need your own OAuth authorisation server, that will manage your resource server.
The OAuth server from Google, Facebook, Twitter, etc., will not help because, as far as I know, can only grant access to their own resources such as email, photos, posts, etc.

An example would be:

You need a picture for your service.
You want the one an other site is using.
You get authorised by the owner of the picture (typical the user).
With the token you now can access the picture.

I think you understand the protocol flow, but probably mix up Authentication(verify ones identity) and Authorisation(grant access to resources).

OAuth v2.0 is an authorisation protocol, it will manage the access to resources. To make it possible for other services (this could be your app) to access your resource server data.


HTTPS for private networks I am trying to create a client-server architecture application in a private local area network. I plan to use HTTPS as the protocol between the client and server. Is it possible for me to use HTTPS in a private network without internet connection?

Yes.
Is there any reason you think this wouldn't work?


Bypassing VPN detecting websites and services? Currently one of the websites I'm visiting blocks all VPN traffic from services like privateinternetaccess, torguard, and other vpn providers. How can one prevent VPN detection without exposing their IP address?

The service I'm trying to use is banned in my country, which is why I need to use a VPN, but it seems that this service now has banned all VPNs too. What are some solutions and how can they even detect that I'm coming from a VPN?

Lets handle this question as two different:

  How can they even detect that I'm coming from a VPN?

It's not that hard to look if someone is coming from a VPN provider. Most of them are using static IP addresses. There are lists of their exit gateways. They block this IP and no one can come through. Even if they don't use such type of an address they just need to make an automatic DNS reverse lookup and see that this have to be a VPN provider.

If this also don't work, you can look into the round trip time of a tcp ack. If it lasts too long you are able to take this as an indicator.

  What are some solutions?

That's a bit tricky. If you are into VPN's I would suggest to rent a Server in a country where the Website is allowed. After that you should set an OpenVPN Server up. Maybe this Tutorial helps you. Connect to your own server and surf on this site.


Improve RDP security: router with VPN or IP whitelist on firewall I am considering to improve the security setting on our workstation shared within the university lab.  We are sharing the workstation among lab members with RDP and got compromised recently. I highly suspect it's from brute force. So I have the chance to setup a new RDP security strategy.

We use a router for internet connectivity and the workstation is wired to the router. RDP is reachable from outside through port forwarding.
Given that I will change the port from 3389 to some other port and all sorts of setting to improve the security. I still cannot decide on one of the following options:

Setup RDP only to be accessible from the local network, i.e. use 192.168.X.X as my address of RDP host. Together with a router setup with VPN, the machine can still be accessed from home. I am a bit concerned if the VPN gets hacked, the university resources will be open to others.
I enabled the firewall and restrict the IPs that can access the port in question. I am concerned if it is not secure enough.

Which option is better?

First of all,

There are always risks when opening up ressources to the internet. A VPN seems to be a reasonable approach to minimize such risks.

Now, have you thought about segreation of networks to reduce the impact of a compromised VPN access?

Also, your two options are not mutually exclusive - why not use a VPN to allow for connectivity and at the same time use IP Whitelisting to restrict access to the VPN?

Additionally, identifying the actual vector of compromise is key - just guessing is not quite a good idea.

PS: changing the default port is making everyones lives harder for almost no benefit in security - it's called "security by obscurity" and supposed to not be neccessary if everything else is in order.


Is it possible to hack a database inside of local network by external attacker? Can an attacker from global network hack a database located on office machine inside of local office network? For example after hacking a router, a gateway or the very machine? Or maybe there is another way for him? Is it possible to make local network with database absolutely secure? Maybe to turn the database on just when it's needed and turn off the connection to global network at such time?

If there was a standard, easily answerable way to make a local network "absolutely secure", most of the community here would not have jobs. It's not nearly that simple. Network security is incredibly complex. And the environment, the people using it, and the people attacking it are constantly changing, adapting, and evolving.

Can an attacker from global network hack a ... machine inside of local office network?

Of course. This happens all the time.

maybe there is another way...?

The answer to that is "how many paths could there be?" The more direct route is to infect the machine's administrator's PC with malware and use that to access the machine. That's just one "hop" to the target. But one could use whatever means necessary to create one's own "network" to reach the target. And this happens all the time, too.

turn the database on just when it's needed

This is a form of "air gapping" and this, in a crude way, implements a security principle that things should only be accessible when they are needed. But the costs and inconvenience tend to be very high for this approach, and it is still vulnerable once it turns on.
If you are looking for an approach to start designing security for this machine, there are multiple frameworks that you can use as a guide. At a high level, and broadly applicable, the NIST CSF provides practical, actionable factors to consider. But nothing will make it "absolutely secure". You only increase the chances for the machine to remain in a secure state.


When is it acceptable to use self-sign cert in production? Self signed cert is always looked down as a test-only certificate. But as per understating, using it for production is perfectly fine if used for the right reason. I am trying to provide some guidelines to my customers about that to use what. E.g.:

Authentication: Not ok to use self-signed as the Brower will not trust the "self" issuer. So, for service-to-service or service-to-client authentication is not ok to use self-signed. Unless there is a pre thumbprint/CN whitelisting process before verifying. Lot of people do these, e.g. Azure where I upload the management cert public key, which is used to authenticate their API.
Signing: No ok, as there is no trust with the issuer. Unless there is a pre thumbprint whitelisting process before verifying. Unless there is a pre thumbprint/CN whitelisting process before verifying.
Encryption: Perfectly OK to use self-signed as there no chain trust required. In case of an attack, the MIM cert will simply not decrypt, no other impact.

I would like some thoughts/recommendations/guidelines from the community to ensure my recommendations are in the right direction.

Thanks.

Encryption: Perfectly OK to use self-signed as there no chain trust
  required. In case of an attack, the MIM cert will simply not decrypt,
  no other impact.

That is not correct. Trust needs to be established for encryption using a public keys, but it is on the other end. The encryptor needs to trust the encryption certificate, since otherwise he would be encrypting his sensitive data for some stranger to decrypt and read.

I think that your categorisation is the wrong take on the matter. The important question that you need to answer, if you want to use a self signed certificate (or even a non-publically trusted PKI) is: How will I be able to make my communication partners trust my certificate?

This could be done via a company policy (for company internal TLS certificates), via direct communication (for securing messages with a very small group of people) or it cold even be unneccesary since you control both ends of the communication (e.g. an app you wrote which communicates with a server you run).

There are more scenarios than the ones that I have listed, but not that many. If you ever have to rely on some unknown user having to actively do something, than you really should not use self signed certificates.


Preventing LSASS from storing clear-text passwords in Kerberos environment It is a well known security risk that LSASS stores clear-text passwords if a user has performed a keyboard-interactive logon on a machine - be it local login to his/her workstation or using RDP to a remote workstation.

There is also a classic fix to this - disable wdigest and tspkg. So far so good, but if Kerberos is supported, then it apparently needs the clear text password to renew the Ticket Granting Ticket (TGT) and so you're left between a rock and a hard place - don't support Kerberos and enjoy all the risks associated with hash passing or support Kerberos and accept the risk of cleat-text passwords. The linked post gives the following advice which I think is unacceptable:

  Therefore, the most effective protection is to avoid interactive
  logons to any untrusted hosts.

A big enterprise has 1000s of servers, how do you known which one is compromised and login should be avoided?

My question: are there any practical measures other than rolling out a 2FA (onto those issues later) that would permit a secure keyboard-interactive logon?

P.S. About 2FA. The most common methods are passcode + OTP and X.509 PKI on a smart-card. They aren't flawless either:

if you have hijacked the lsass process, then you could arguably use
the otp+passcode to log on to other servers while the passcode is
valid. Using auotmation, this could mean you've logged on to tens of
servers or more during the 60 second window
As per this TechNet article the user sends the PIN to the server and makes the smart-card available to the RDP server. Same process as in the first item can be used to hack many servers while the admin is clicking away at the compromised server.

°º¤ø,¸¸,ø¤º°`°º¤ø,¸,ø¤°º¤ø,¸¸,ø¤º°`°º¤ø,¸°º¤ø,¸¸,ø¤º°`°º¤ø,¸,ø¤°º¤ø,¸¸,ø¤º°`°º¤ø,¸

2018 Update: Starting from Windows Server 2012 R2 and Windows 8.1, the LSASS can be ran as a protected process by enabling the RunAsPPL setting and inhibiting credential dumping. Starting with Windows 10 and Server 2016, the Windows Credential Guard is enabled by default and achieves similar outcomes.

°º¤ø,¸¸,ø¤º°`°º¤ø,¸,ø¤°º¤ø,¸¸,ø¤º°`°º¤ø,¸°º¤ø,¸¸,ø¤º°`°º¤ø,¸,ø¤°º¤ø,¸¸,ø¤º°`°º¤ø,¸

To answer your question: I believe that the safest way would be to use psexec to get a remote cmd shell.  This method should not result in a plaintext password stored.  Or do you mean interactive, AND with a GUI?

Unfortunately your best solution really is to avoid interactive login whenever possible.

Luckily there are some safe ways to remotely manage machines:

winrm (including Invoke-Command powershell)
psexec (only if you do NOT use the "-u" option)
Remote Assistance

These are pretty safe. You generate a token on the machine but that is part of the Windows architecture and not a bug/flaw.

You should avoid using the following whenever possible, as it is possible to dump plaintext passwords using mimikatz:

RDP
psexec with the "-u" option

With Windows 8.1 (and Windows 2012R2?), the plaintext wdigest password is disabled by default. However, as demonstrated in this article, you can simply re-enable plaintext password storage in the registry.  And, there's always kerberos attacks.


BundleID of an iOS Application installed on iOS 10.2.1 I'm fairly new to iOS Security and was trying to obtain the BundleID of the applications installed on my jailbroken iOS Device (10.2.1).

I tried using both Appster and BundleIDs but both failed to list down the applications installed on my iOS Device. I'm guessing that its probably because these applications are not compatible with my iOS Version.

  Just wanted to know of any other way to find the BundleID of applications not installed from the iOS AppStore when I don't have the IPA file available.

Figured it out.

Just navigate to
/var/mobile/applications for iOS versions less than 8.
/var/mobile/Containers/Bundle/Application for iOS versions less than 9.3.x and /var/containers/Bundle/Application for all versions greater than 9.3.x.
Find your application UUID (Universal Unique Identifier) and 'cd' into the folder.
Grep for the text softwareVersionBundleId in the file iTunesMetadata.plist.

Reference:
https://pspdfkit.com/guides/ios/current/faq/finding-the-app-bundle-id/


Does stretching a hash increase a denial-of-service (DoS) risk and does brute-force protection mitigates that? Disclaimer: I noticed several questions on this site but none really answer this two questions directly. Therefor I do not consider this duplicate.

Personally I really like the article called Some words on Password use, salting and stretching from Michael Anders explaining why stretching is important.

  For the legitimate user it doesn't make a difference whether the program needs a microsecond to verify the password or a tenth of a second. He will not notice the difference. For the attacker it may be the difference between 1 day for an exhaustive search or the 100 thousand fold time of 300 years.

I wonder if extensive stretching increases the risk of a denial-of-service (DoS) caused by resource exhaustion. It's likely easier to use more server resources when doing multiple login-attempts (not for the purpose of logging in, brute-forcing but for the purpose of causing a DoS).

Secondly, would a simple brute-force protection that prevents the password from reaching the password check function (including hashing and stretching) after an X amount of failed login attempts, possibly prevent this kind of DoS (by resource exhaustion)?

1) In a sense, yes, since checking the password against a stretched hash will take more CPU time. But you should have some rate-limiting in any case to prevent brute-force guessing passwords, and while doing that, you can take into account the DoS potential. Also, login attempts will not be the only way to (try and) DoS something, you might get excessive load from other requests too, or just receive excessive amounts of network traffic, preventing legitimate requests from reaching you.

I think making it harder to crack the passwords in case of a leaked password database is worth the cost, but of course it is a trade-off. You have to take into account the expected amount of (valid) logins, and that the system can handle them. With millions of users, the stretching might start to take its toll.

2) Yes, if you rate-limit connection attempts and start denying them outright at some point, it would be useless work to run the hash fully for a login that is going to be denied. Though, returning a failure immediately will reveal via timing the fact that the password wasn't even checked.


File upload attack vectors when file is not saved to disk I'm curious to know if there are any significant threats presented by files which are uploaded and read but are never saved to disk?  I've read countless articles about file uploads regarding storage and retrieval of the file itself but I haven't found any information on simply keeping the file in memory.  My specific situation is as follows:

I have an HTTP endpoint which will accept CSV files from users.  For a file to be accepted, it must be in a predetermined format and encoding.  The file bytes will be read and converted to a CSV OOP model, which will then verify valid characters and persist the values (not the CSV file) to a database via parameterized queries (I realize that this is a form of persistence to disk but in this scenario, the data would be sanitized/verified by this point).  Any invalid character (markup, code, invalid whitespace, etc) in the byte stream will cancel the entire process and return an error.  Any invalid/unknown CSV field will cause the same cancellation/error.

It seems that most of the risks with file uploads are associated with the file's permissions on disk, surreptitious contents intended for execution, and the like.  All of which involve the file being persisted as-is (or approximately so) and then handled by the OS/runtime in some exploitable way.

If a file is only read into memory from the network and then garbage collected, what vectors might an attacker exploit?

UPDATE 2109-03-07: This question states (erroneously on my part) that the parsing would occur before checking characters against whitelist.  In the actual scenario, characters are checked before parsing.  Leaving the original scenario as-is to maintain the context addressed by Euphrasius.

A dangerous code present in a file can be ran no matter where the file resides. But if the file is non-exe/script one (like a text) then there must be something else infiltrated to be able to execute the content.

Advanced attacks can store the file pretty much anywhere, run code from there and then remove the initial file. Doing that in-memory leaves a lot less traces compared to saving it to a drive.

If the file is in any type of executable format, then things are easier since nothing else is required to activate the content.

If you do protect yourself against CSV injections (note; make sure not to have Equals to (“=”), Plus (“+”), Minus (“-“), At (“@”) at any cell beginning) you should be fine from that side but that would not prevent someone from putting code in a .CSV that actually looks harmless but if correctly assembled makes up a script ran later. So you should also make sure there's no possibility for something to be in already and able to interpret / run further data. If there is no way for anyone to access anything except doing that CSV upload, then this should not be a vulnerability.


My OpenPGP private keys are set up with sub-keys. What happens if I revoke a sub-key and re-issue a new one? I have set up my OpenPGP keys with sub-keys, following the general instructions laid out in "Creating the perfect GPG keypair." The general gist is that you create a "master keypair" which is not stored on your laptop, but instead on a secure air-gapped device. In my case, it's an encrypted USB key. I also have a paperkey version, and printed revocation keys for the master key, in case the digital version is lost or corrupted. My laptop only has subkeys, not the master signing key. As a result, when you run gpg -K (to display secret keys), you get:

/Users/myusername/.gnupg/secring.gpg
-------------------------------
sec#  4096R/0x123412341234FFFF 2014-04-18
uid                            My Name <me@example.com>
ssb   4096R/0x123412341234AAAA 2014-04-18
ssb   4096R/0x123412341234BBBB 2014-09-24
ssb   4096R/0x123412341234CCCC 2014-09-30

The sec# indicates that the master signing key is not stored on the computer. If I load up my encrypted USB key and then run gpg gpg --home=/path/to/secure/gpg/keys/.gnupg -K, it would show:

/path/to/secure/gpg/keys/.gnupg/secring.gpg
-------------------------------
sec  4096R/0x123412341234FFFF 2014-04-18
uid                            My Name <me@example.com>
ssb   4096R/0x123412341234AAAA 2014-04-18
ssb   4096R/0x123412341234BBBB 2014-09-24
ssb   4096R/0x123412341234CCCC 2014-09-30

As you see, it shows sec, not sec#.

Under this setup, if your laptop is compromised, you can revoke the subkeys safely without losing any connection with the web of trust - because you are connected to the web of trust through your master signing key.

Let's say that my laptop is compromised, which this model supposedly protects against. The best practice, I think, would be to:

Go get my secure USB key, and load up GnuPG from the secure keyring
Using the master keypair, I would revoke my sub-keys [because they are now compromised]
Now, I would issue new sub-keys for signing and encrypting, and push all of these changes to public keyservers.

My question is: Is this the right thing to do? What happens here exactly, when you do this? I presume that it generates a new private key/public key pair, and invalidates the old one. That way, if an adversary has my old private keys - they can in theory access old communications encrypted to my old public key. But they could not sign anything as me, because that private key will have been revoked. Further, when someone looks me up through a keyserver, both the old and new public keys will be visible, but the old public key will be shown as revoked and the new one will have a newer date, so a GnuPG user trying to send me an encrypted message or encrypted file will automatically encrypt it to the new (non-revoked) public key. And the adversary will be unable to read this message.

Am I right in this at all? Can someone please clarify?

My question is: Is this the right thing to do? What happens here exactly, when you do this? I presume that it generates a new private key/public key pair, and invalidates the old one. That way, if an adversary has my old private keys - they can in theory access old communications encrypted to my old public key. But they could not sign anything as me, because that private key will have been revoked. Further, when someone looks me up through a keyserver, both the old and new public keys will be visible, but the old public key will be shown as revoked and the new one will have a newer date, so a GPG user trying to send me an encrypted message or encrypted file will automatically encrypt it to the new (non-revoked) public key. And the adversary will be unable to read this message.

You pretty much got everything right; that's exactly what subkeys are primarily used for (there are some other neat use cases apart from exchanging subkeys without losing reputation in the web of trust).

I'd add that there might be a given latency: the key needs some time (usually minutes, less than an hour) to spread through-out the key server network. If the situation is critical, and you know somebody is listening your communication, consider uploading to different servers in the SKS server pool to speed up reconciliation/spreading of the key.

Furthermore, your communication partners will very likely only occasionally fetch updates of your key. Consider sending an information about changed subkeys due to compromised old ones; and also explain why your master key is still save.


What is implication of ICMP timestamp responses? I have tried to understand CVE-1999-0524.
It is recommended to configure the firewall to prevent ICMP timestamp responses: https://access.redhat.com/security/cve/cve-1999-0524
What if I will not do it?
What is implication of ICMP timestamp responses?

When ICMP timestamps are allowed an attacker can probe the network to find live hosts and potentially suggest trust between hosts (for example by constantly submitting traffic it would seem as the attacking node is in fact a regular in the network and trick pattern based IDS)


How to test a physical machine? In two weeks time, I will have to test a couple of computers that a client would like to provide to its employees. The main concern is making sure that the employees won't be able to use those computers for anything that isn't actually allowed.

I won't have any information on these computers until I get there, but I can think of some measures that are probably likely to be implemented:

No CD/DVD drive
Disabled USB ports
No Internet access (not sure if the machines will or won't have a network card)

Now, the first thing that popped into my mind was trying to use a live CD and see if I will be able to bypass some of the measures, but since I never did a test like this one...

What other things could I test on those machines?

The main thing to understand is that your client is trying to solve an impossible problem.  Trying to prevent someone with physical access to the machine from accessing it is like trying to make water not wet.  It ain't gonna work.

If you want to do the best that you can, you can take the steps you mention, and I also suggest you research "kiosk mode".  But fundamentally, it will still be relatively easy for employees to use the computers for activities your client doesn't like.  It will be as easy as inserting a Linux LiveCD, or a gazillion other methods.  You're never going to close them all (not and leave the employees with a useful computer), and realistically speaking, you're not even going to be able to make it terribly difficult to defeat the security measures.

So I would argue that there are two important takeaways: (1) keep your expectations low; there is only so much that technical methods can provide, so don't waste too much time or energy trying to invent a foolproof defense, (2) this is primarily a matter for policy and social methods, rather than technical methods -- for instance, your client might want to adopt and promulgate a clear company policy regarding acceptable use of company computers, and be explicit about the penalty for violations.


What's the correct way to handle a failure with Client Certificate Authentication I'm adding Client Certificate Authentication to my application - what is the correct way to handle an invalid certificate, untrusted certificate or an un-mapped user ID?

If authentication fails usually it's good practice to drop the connection/session, then log that as a security incident.

If the certificate is expired, consider contacting the responsible party via email or SMS and informing them.

If you notice a trend of invalid certificates then you may want to look into that as a potential attack (DoS or brute force).

Invalid certificates may be a configuration issue with a user, if you can ID the responsible user try to contact them. Most people don't really understand certs and can easily mess up the config.


Is there a criteria for allowing or disallowing the execution of bash scripts as root with sudo? What criteria could I take in order to to allow or disallow the execution of bash scripts with sudo as root?

I know I should analyze the script but I have not enough time and I trust my developers.

My criteria today is to request the script user owner, group owner and permissions just to be sure the owner and group are root and permissions don't allow the user to modify the script.

For example, is there any tool in order to extract the commands executed within a bash script? I think with this list of command I would be able to evaluate if all command requiere root privileges or not.

A few options:

Read through the script once, make it r-x, change ownership, and add
the script to the sudoers entry for the developers
Require that the
developers use sudo in the script, rather than on executing the
script, and whitelist commands in the sudoers file
Trust your developers and accept the risk

As far as extracting commands, there's only one right way to do that: read the script. You could turn on auditing or read the command history or something, but if it's truly malicious, those can't be relied upon.


What additional privacy impact does using the COVIDsafe app have for people in Australia who are using their phones normally? I've been trying to encourage some people I know to install and use the COVIDsafe app. Some people have raised privacy concerns as a reason to not install the app (there's other concerns, such as it reportedly interfering with diabetes apps). To the best of my knowledge, these people are using smartphones with SIM cards and lots of apps installed.

I understand that privacy breaches may involve either the developer of the app, malicious third parties, the Australian government, Amazon, and the US government, however I assume that the main concern is around the Australian government.

To what extent does using the COVIDsafe app give the Australian government data that it doesn't already have from existing sources of information?

"To what extent does using the COVIDsafe app give the Australian government data that it doesn't already have from existing sources of information?"

Just to start off I'm not an Australian but I would assume that the Australian Government has your name/age/HPNumber/addresses(postcode).

Based on the privacy policy of the covidsafe app, they would seek consent for the aforementioned list of data which the government, or any government should have on their citizens/population. The privacy policy states that they do not extract any location data.

The app merely focuses on contact data. Time/Date, Bluetooth signal strength to detect other users of the app & most importantly an encrypted user ID is generated & re-distributed every 2 hours. It adds another layer of obscurity over pinpointing a user. The contact data would be handled & operated by the Digital Transformation Agency Australia.

Hope this helps! The policy has pretty much everything, take a gander!


Why does Android mix phone state with phone identity? The "Phone State" permission on Android is widely requested by many apps. The explanation often given by the developer is that the app needs it in order to determine when you're on the phone, to stop doing stuff or making noise or the like.

However, it also provides an application with your IMEI, phone number, and remote number (number of inbound or outbound calls). This allows a lot of personal information collection, all under the guise of "my weather app needs to know when you're on the phone so it doesn't interfere with calls".

Why is knowing someone is on a call even a special permission? Certainly phone calls are still common enough to warrant providing a permission-free API that all apps can use to not bother a user in-call.

Why would Android hide such a powerful permission that allows detailed personal identification and cross-user tracking behind something that seems so innocuous? It only serves to get users in the habit of allowing permissions and accepting excuses from app developers.

One specific piece of data you can access with the "Phone State" permission is the IMEI/IMSI of your phone/sim card. This number is used to identify your device for target-ads (so the ad provider could tell whether you've already seen an ad). Since showing ads is a common business model in mobile apps, the "Phone State" permission being requested is as well very common.
I think it's a logical decision (from an economic point of view) of Google to group this ability with other, somehow similar abilities so users won't be scared of permissions that could obviously harm their privacy.
It's definitely possible to give the ability to detect whether the user is on call without a special permission, but that would go against Android's policy of requiring explicit permissions for everything that gets beyond the local concerns of an app.


Is there a secure way to have a publicly facing terminal server? TL;DR We are looking at opening port 3389 for a terminal server all the advice I’ve seen is that its suicidal but without good explanations as to why. Is it really that bad?

We are looking at setting up a terminal server for staff to access remotely. They are going to be using a bunch of devices including iPads, Android Divices, Windows (XP to 8), OSX, Linux, pretty much anything with an RDP client.

I want this to be stupid simple and work on everything. My plan is to setup remote.example.com (obviously with our real domain name) to point to our server then secure it by:

Firewall everything except port 3389.
Set there encryption level to highest (with a certificate) and not allow “Negotiate”
Lock accounts with more than 7 failed attempts and look at maybe some script to block based on IP addresses with failed logins (https://security.stackexchange.com/a/17354/22241)
Other obvious things such OS updates and anti-virus.

However when I talk about setting up a public facing RDP the responses are generally along lines of:

“Don’t open port 3389 put a VPN in front of it” – but as far as I can see the two main arguments for this are encryption (Doesn’t RDP already do this?) and better authentication because people will brute force RDP. We allready have a PPTP VPN setup but it just uses the same account username/password combo to authenticate as our Terminal server would so I don't see a terminal server adding to our attack surface. The only argument that I think holds any weight is setting up a VPN (such as Cisco) that supports two factor authentication, that sounds good but will massively reduce the number of devices that are supported.

"Don't do it, use an RD Gateway"
As far as I can see reading http://technet.microsoft.com/en-us/library/cc731150.aspx the advantages of a RD Gateway are:

Manage multiple servers from a single entry point with fine grained control over who can connect to what and so on.  - Sounds good but we only have one terminal server.

Uses port 443/HTTPS so people behind poorly configured outbound firewalls can connect – sounds great but RDP already offers encryption and changing the port doesn’t add security. Also for all the extra ease of not needing to deal with outbound firewalls comes the lack of support from most RDP clients (last I checked the OSX clients couldn’t connect to RD Gateway)

"Don't use RDP, use (Hamachi/Team Viewer/Jump Desktop/VNC … seriously/some other RDP tool) it's safer"
To me any of these suggestions go from putting all your eggs in one basket (Microsoft) to putting all your eggs in another basket (Hamachi) but without tangible security benefit.

Am I just being dismissive? Is setting up a public facing RDP server a bad idea?

RDP is a complex protocol which requires complex implementations, and thus likely to contain bugs. The initial versions of the protocol did not include much encryption. Ulterior versions are better, and can use either a homemade encryption system (which may or may not use a certificate to embed the server public key), or SSL/TLS (which necessarily uses a server certificate). Note that, in the latter case, the TLS records are encapsulated into RDP-specific packets, so you cannot content yourself by saying "this is just SSL".

There is no conceptual reason which would make RDP inherently insecure; but the whole tower of inner protocols and the general lack of decent documentation is a problem. It is already hard to know what features will be supported by a given client. Microsoft's implementation had its lot of remote exploits, e.g. this one and that one.

Microsoft's own response is that if you want security, you need Remote Desktop Gateway, which adds yet another layer, but on the outside: a standard SSL/TLS, with user authentication, and RDP in it (so you end up with a SSL-RDP-SSL-RDP sandwich). The idea is that a public-facing SSL server is a known situation with code which has been thoroughly debugged, through years of exposition (in IIS, for HTTPS Web servers). RD Gateway won't prevent RDP holes, but exploits will be limited to people who can get through the outer SSL, i.e. people who can open a session on the server itself and already have a lot of power. Of course, RD Gateway is not free, so it is Microsoft's best interest to sell licenses for it.

Note that client support for RD Gateway is not a given, when the client software is not Microsoft's implementation.

To sum up, there is only one authoritative source for RDP (Microsoft) and they themselves have about given up the idea of claiming that their product is sufficiently bug free to be public-facing. This does not bode well. Some of the alarmist discourse on the subject might be prompted by the urge of selling RD Gateway licenses, but it makes sense that making Microsoft's RDP implementation secure is hard, because of the complexity and long history of the code.


Is it possible for page to get your installed extensions through javascript? When you visit a page, could that page tell what extensions you are running
if javascript is enabled?
If so then could we stop them or at least make it extremely difficult to increase our privacy?

If the site can control the extension, yes. Look at chrome.runtime.onMessageExternal.addListener.

If the site can't control the extension, no. Chrome protects the extensions.

But there are ways.

If the extension has web_accessible_resources, the javascript of the website can XHR or whatever to the resource (e.g. chrome-extension://oiplkfaidhjklglajdpfehoagkmlcakh/images/camera.png for Pig Toolbox) and check the reply.
If the extension modifies DOM, the site can detect it using Javascript.

If it is not an extension but an app, the site can just use chrome.app.isInstalled

If the extension wants to check other extension, it can use chrome.runtime.onMessageExternal


Spytechphone - iPhone When port scanning my iPhone I get an RST, ACK from 'Spytechphone' over port 8192, does anyone know what this port does?  I can't find any useful information.

[1] http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=spytechphone

Port 8192 is one of many ports that is used for TCP/UDP. After a little bit of searching it appears that this is a port that, like #INV3NT3D said in his comment, is used by SpyTech Phone Service, among a few others.

I think a better question you need to be asking is:

"This seems like unusual traffic on my phone. Who is SpyTech Phone Service and why are they accessing my phone?"

Hope this helps.


How do I verify the supported ciphersuites of a TLS server that only accepts POST requests? I'm currently trying to get a bidirectional TLS 1.2 connection working between 2 local Karaf-based XMLRPC servers that by design only accept POST requests. The environment is Windows 10 and both XMLRPC servers are running in the same JDK: 1.8.172. I'm currently at the point that the client can send a ClientHello to the server, but the answer from the server is a Handshake-failure, with an examination by Wireshark of the response stating it's a Handshake-Failure(40). I understand this means that the server and client do not have any ciphersuites in common. I find this hard to believe considering they both run in the exact same JVM with the same java -Dhttps.protocols property (TLSv1,TLSv1.1,TLSv1.2 on both ends).

The client sends the following TLS ciphersuites in the ClientHello:

  [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
  TLS_RSA_WITH_AES_256_CBC_SHA256,
  TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,
  TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,
  TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,
  TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
  TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,
  TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
  TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
  TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
  TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
  TLS_RSA_WITH_AES_128_CBC_SHA256,
  TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,
  TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,
  TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
  TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
  TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA,
  TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
  TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
  TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
  TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
  TLS_RSA_WITH_AES_256_GCM_SHA384,
  TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
  TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,
  TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
  TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,
  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
  TLS_RSA_WITH_AES_128_GCM_SHA256,
  TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
  TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,
  TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
  TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,
  TLS_EMPTY_RENEGOTIATION_INFO_SCSV]

I'm now trying to figure out the TLS suites supported by the server. the problem is that I've tried using Nmap for this, but Nmap uses GET requests, which are rejected immediately by XMLRPC (this is hardcoded: it has a hardcoded check that the Method is POST, and immediately throws a custom BadRequestException if this isn't the case).

How can I check the supported TLS suites of a local server that only accepts POST requests?

It is  totally irrelevant if GET or POST is used. The TLS handshake is done before any HTTP request is even send. So if the handshake fails it means that neither GET nor POST is possible. If the server will only accept POST and a GET was send the server will reply with an HTTP level error. It cannot cause a TLS handshake error since the TLS handshake was already finished and cannot fail anymore.

  ... with an examination by Wireshark of the response stating it's a Handshake-Failure(40). I understand this means that the server and client do not have any ciphersuites in common.

Actually, no shared ciphers is only one of several possible reasons of a handshake error. Depending on which state this happens it might for example also a lack of a requested client certificate or the wrong client certificate. And no shared ciphers might for example be caused by a failure to load the certificates in the server which means that it cannot use any ciphers which require certificate based authentication.


Can someone tell if you delete deleted files? I am aware that to delete something completely we will have to use a program that over-writes the deleted file such that it is unrecoverable.

Is there anyway to tell that this has happened? Or is the resultant state so random that no one can tell that it has just been "cleaned" ?

Ok so we have a 100GB C:\drive and all of the data is "cleaned". After "cleaning", if someone try to do a reversal and couldn't, he will suspect that it is "cleaned" before. So what I do is to copy "random files" and delete them such that if he do a reversal, he would get the "random files". Now the question is, if I simply have 50GB of "random files", will the remaning 50 GB show evidences of "cleaning" ? Do I need to fill all 100GB will "random files" (and delete them) to erase ALL traces of "cleaning" ?

You are correct, in order for a file to be deleted the actual disk blocks it previously inhabited must be overwritten.  This is generally done with random data; for example, the Windows tool 'cipher' overwrites unused (e.g., formerly used) disk space with 0s, then 1s, and then random data.

If a forensic investigator were to look at your computer's disk, and you had wiped deleted files in this manner, he would notice that the "slack space" on the disk was filled with random data, and that there were few or no deleted files.  Let's say you deleted "readme.txt" and didn't wipe it; he'd find the contents of that former file, and say "Okay, here's a deleted text file."  Therefore, if he can't find deleted files of any sort then  he must conclude either a) you've never deleted a file or b) you've wiped your slack space to overwrite deleted files.  Obviously b) is more likely than a).

To put it a different way: if the resultant state of the wipe is random, then that very randomness is what tells the investigator that the disk has been "cleaned".

Some tools, such as PGP shred, will overwrite the single file you specify rather than cleaning up all slack space on the disk.  If sensitive files are shredded, and normal files are deleted as usual, then it would be harder for an investigator to prove that file wiping had occurred.


What's a good time period before refreshing CSRF token of the user session? I am using a form token to prevent CSRF attacks. Those tokens are stored and tied to a user's session. Now I want to refresh the token only every N minutes or hours so that the user's don't experience any usability issues like the browser Back button not working properly.

My question is, what would be a good time period before refreshing the user session token?

My recommendation: Never.

You should only have one CSRF token per session. If the session times out, then the CSRF token expires at this point.

As there is no way for an attacker to read the CSRF token (at least there's no more of a risk of an attacker reading a CSRF token as the Session ID cookie), there is no need to generate a new one unless you have a new session to go with it.


Is radio burst transmission really "jam resistant"? Quoted from here:

  Certain military communication systems are based on the jam-resistant
  burst transmission of binary telegrams which consist of orthogonal
  spread-spectrum waveforms (BOK). To regain the message content at the
  receiver the a priori not known arrival times of the telegrams have to
  be detected by means of a synchronization circuit. In this paper a
  novel power-level adaptive synchronization circuit for producing the
  telegram alarms is proposed. This circuit shows CFAR-performance in
  the case of noise jammers but does not show the degradation typical
  for other synchronization systems (e.g. systems employing a hard
  bandpass limiter at the receiver front end) if other types of jamming
  signals are received. The performance of the synchronization circuit
  is theoretically analyzed for noise jam mers and CW-sine jammers. Some
  considerations concerning the influence of pulsed jammers are also
  included. Measurements finally confirm the theoretical results.

Isn't anything transmitted through the ether potentially jammable? I mean, what stops someone from transmitting orthogonal spread-spectrum waveforms with a higher powered radio frequency constantly to overwhelm any other lower frequency radio transmission? Shouldn't any type of data transmittion, including very short bursts be incapacitated at that point?

Yes. This is why it was not described as "jam-proof". However, it just so happens that transmitting powerful RF waves across the entire RF spectrum is a) very, very power intensive (like "you can't do this outside of a fixed installation near a dedicated power plant"-type power intensive), b) ruins your own systems as well, and c) makes you an excellent target for anti-radiation missiles. The whole point of jam-resistant stuff is to make it so that the enemy, who has finite amounts of power, doesn't know when and where to transmit to jam the signal. It's simply not practical to transmit high power across a broad spectrum for long periods of time.


Why do I sometimes need to "bypass" SSL intercept? I use the BlueCoat ProxyClient filter in a small office network (< 50 computers).  We have it set for category based filtering and it works perfectly on almost all sites.  However, sometimes, we have a site that

Even if it's in an allowed category
Even if we add it explicitly to a whitelist
Even though we can navigate to it in a browser,
It still does not function properly unless we add it to the "SSL intercept bypass" list.

What does this "bypass" actually do and why is it necessary?

Example

We installed Visual Studio 2015 Community on one of our computers
When we tried to update our license using our MS account, we got the message "Failed to update license".
Using Fiddler we found that VS was trying to access https://app.vssps.visualstudio.com.  That's flagged as Technology/Internet by BlueCoat which is on our allowed category list.
We added it to our explicit whitelist and it still didn't help.
We enabled the HTTPS decrypt setting in Fiddler and found that it was sending a lot of requests to https://app.vssps.visualstudio.com/_api with an Authenticate header that looked valid, but the response was coming back as 401 Not Authenticated.
We finally added app.vssps.visualstudio.com to the SSL bypass list and it suddenly started working.

My guess is that your Proxy is stripping off the Authenticate header from the request. I did a quick Google search on the issue and found this forum page. From the same page:

  It is by design if the proxy sees an Authorization header and the
  proxy have authentication enabled or used in the policy, the proxy
  will consumed the Authorization header, thus the Authorization header
  will not be forwarded to the upstream device.

  In this case, the Authorization header was generated from the client
  and NOT due to the proxy's authentication challenge, this is why it
  failed. So in order to 'tell' the proxy not to suppress the
  Authorization header, we would need to disable authentication for this
  URL and forward the Authorization header to the upstream as what the
  CPL suggested will be doing"

I believe the issue you are having is kind of similar. The solution proposed on the forum:

  Solution at present would be to have "security
  force-credential-forwarding" enabled or use the CPL to bypass Auth for
  the domain. Since the command will affect the "Proxy-Authorization"
  headers too.

Hope this helps.


How many IP addresses can a user have? If you don't have a botnet and you needed to use an application with a new IP address on each page load, how would you achieve that? How many different IP addresses can a person have? What does it depend on?

As many as you would like. It's basically a question of paying for them. With IPv4 it's expensive, but still trivial. I can probably access a few hundred for a few dollars through a VPN provider.
With IPv6? As many as you would like - for free. I currently have a /48 (2^80 addresses) at my personal disposal...


Should I use a cryptograpically secure random number generator when I generate IDs? It is common to generate random identifiers to expose through an API instead of using a simple auto incrementing primary key. The reasons are many:

Prevents easy enumeration.
Does not give away order objects were created.
Does not give away total number of objects or growth rates.

When generating these ID's, are there any substantial benefits to use a cryptographically secure pseudorandom number generator (as in crypto.randomBytes() in Node.js) over using something more simple (as in Math.random())?

Math.random() is usually seeded from the current time of day. Therefore there is a chance that collisions will happen for objects that are generated around the same time each day.

From a security perspective, this means that these "random" values will be predictable by an attacker.

Even if seeded with something else, a non cryptographically secure pseudo random number generator can reveal its state should enough values be captured. This is why it is better from a security perspective to only use values generated by a cryptographically secure pseudo random number generator (e.g. crypto.randomBytes() that you refer to).

CSPRNGs have certain properties that make them suitable for use in security:

  Every CSPRNG should satisfy the next-bit test. That is, given the
  first k bits of a random sequence, there is no polynomial-time
  algorithm that can predict the (k+1)th bit with probability of success
  better than 50%. Andrew Yao proved in 1982 that a generator passing
  the next-bit test will pass all other polynomial-time statistical
  tests for randomness.
  Every CSPRNG should withstand "state
  compromise extensions". In the event that part or all of its state has
  been revealed (or guessed correctly), it should be impossible to
  reconstruct the stream of random numbers prior to the revelation.
  Additionally, if there is an entropy input while running, it should be
  infeasible to use knowledge of the input's state to predict future
  conditions of the CSPRNG state.

Using such a generator will satisfy your security requirements:

Prevents easy enumeration.
Does not give away order objects were
created.
Does not give away total number of objects or growth rates.

However, you shouldn't let the fact that these are now unpredictable from protecting the first case with proper access controls (authentication and authorisation). URLs should not be considered secret and there are many ways they can leak  (shoulder surfing with hidden camera, HTTP referrer header leakage, proxy and browser logs). Also, once a URL is known and you're relying on an unpredictable secret to protect it, the user accessing it will always have access and this cannot be revoked. Remember - they can easily bookmark it.

Using unpredictable values would definitely help your other requirements should they be deemed necessary for your application. I would recommend using a 128 bit random value which is more than enough entropy to prevent predictability and collisions.


Writing to .fini_array I'm learning about format string exploits, and am attempting to use one on an example program to overwrite the .fini_array section in virtual memory with a stack address containing shellcode (and hence redirect execution to the shellcode once main exits). Unfortunately, trying to write to this address raises a segmentation fault, and I have written the following program to try to understand what's going on. (Disclaimer, I am running x64 linux with ASLR disabled while I am learning.)

//fini_test.c
#include <stdio.h>
#define OFFSET 0x555555554000

int main(int argc, char **argv) {
    unsigned long int addr;
    char **ptr;
    static int canary=0xdeadbeef;

    if(argc<2) {
        printf("Usage: %s <position to write to in object file>\n", argv[0]);
        exit(0); }

    addr=stroul(argv[1], ptr, 16)+OFFSET;

    printf("[*] about to print\n");
    printf("writing to %p\n%n", (void *) addr, (int *) addr);
    printf("[*] print complete\n");
    printf("canary @ %p\t%d\t0x%08x\n\n", &canary, canary, canary);
    exit(0);
}

So, the program simply takes a position in the object file as a command line argument, and then writes some bytes to the corresponding position in the virtual memory space of the process. With GDB I found that the right offset between the location in the object file and the location in the virtual memory space was 0x555555554000.

I then compiled and used objdump to find the desired sections in the object file.

$gcc fini_test.c -o fini_test
$objdump -h ./fini_test
Sections:
Idx Name          Size      VMA               LMA               File off  Algn
...
 19 .fini_array   00000008  0000000000200da8  0000000000200da8  00000da8  2**3
                  CONTENTS, ALLOC, LOAD, DATA
...
 22 .data         00000014  0000000000201000  0000000000201000  00001000  2**3
                  CONTENTS, ALLOC, LOAD, DATA
...

So, the position of the .data section in ./fini_test is 0x201000 and the position of the .fini_array section is 0x200da8. I also noted that, like the .data section, the .fini_array section does not have a READONLY flag, so I assumed that I should be able to write to it with the appropriate command line argument. However, this is how execution behaved:

$./dtors_test 0x2010000
[*] about to print
writing to 0x555555755000
[*] print complete
canary @ 0x555555755010 -559038737  0xdeadbeef

$./dtors_test 0x201010
[*] about to print
writing to 0x555555755010
[*] print complete
canary @ 0x555555755010 26  0x0000001a

$./dtors_test 0x200da8
[*] about to print
writing to 0x555555754da8
Segmentation fault (core dumped)

First, to verify that my code and choice of OFFSET were right, I tried to overwrite the value of canary. As a first approximation I just inputted the position of the .data section, which was unsuccessful because – as inspecting the outputted address of canary shows – the value of canary is stored beneath the two pointers addr and ptr. Hence I inputted the position of the .data section plus 0x10 to account for this, and indeed successfully overwrote the value of canary with the expected value of 26 (precisely the number of bytes in the string "writing to 0x555555755010\n".)

So everything to that point is working as expected. However, I then try to write to the start of the .fini_array section* and a segmentation fault is raised. This surprises me because this section is not marked as READONLY in the object file; can anyone help me understand what's going on? Thank you in advance

*I know that destructor addresses are not stored at exactly the start of the .fini_array section, and so even if I could write to that address it would not yield the desired results. But for now, before I cross that bridge, I'm just trying to understand why I can't write to an address that seemingly does not have a READONLY flag enabled. As a broader question, general references to understanding how .fini_array works in ELF files would be greatly appreciated!

you can use -Wl,-z,norelro to disable RELRO.


Suspicious phone browser activity On a droid Razr M, I used chrome to log in to Gmail instead of the app.  It asked to log in as me on a toast at the bottom of the browser, taking my credentials from somewhere on the phone I assume. When logging out of the mobile Gmail site, a white screen with some text about redirecting appeared briefly, followed by Korean characters.  The URL on exiting is

http://www.google.co.kr/accounts/Logout2?service=mail&ilo=1&ils=s.KR%2Cyoutube&ilc=1&continue=https%3A%2F%2Fmail.google.com%2Fmail%2Fmu%2F%3Flogin%3D1&zx=

I've censored the end of this URL where some numbers appear.  Why a Korean domain? Anyway, my question is: Is my mobile browser being hijacked or would it appear that my account has otherwise been compromised in any way?

A whois of the www.google.co.kr domain seems to indicate that it is legitimately Google.  Why it was redirecting through there is a bit of a mystery.  I do know that there is a feature on a lot of phones that will us the Google account of the phone.  It is possible that the vendor that wrote the software was Korean and simply used the Google server from their home country to do the redirect.  I'd certainly keep an eye on it, but I don't see how this particular thing could be an attack from what you've described.


Use combination of digital certificates and symmetric key cryptography Assuming that:
 - A have CertA and secret key KsA
 - B have CertB and secret key KsB
A need to transfer data M to B with the requirement of confidentiality and authenticity, BUT Data encryption must be done by symmetric encryption.
How do A and B do that to achieve all the requirements?

This is how all HTTPS and TLS communications work.

2x Async certs/keys are used to create a shared secret which is used as a symmetric key for the lions share of the communication.

In step 6/7 of this diagram, is where the Symmetric key is created and both sides ChangeCipherSpec to make use of this newly established shared key.


Challenge authentication without roundtrip Is it possible to have a secure challenge/response authentication protocol, authenticated immediately?

Too slow: a client request -> server challenge -> client response -> server response

Fast enough: client request -> server response

Short answer:
No. By sending a response to the request, you are not challenging the client, making it a different kind of authentication scheme.
Longer answer:
The method you describe doesn't provide a challenge. There can be credentials provided such as a username/password pair, but it doesn't challenge the client to provide anything beyond what what it has already provided.
Let's take a look at an old example of challenge/response:
mappu sends me an email. Before my server accepts it at face value, it provides a challenge back to mappu. That is where mappu has the opportunity to confirm his identity and allow the email to be sent to my mailbox. Without that challenge, it is no longer a challenge authentication.


Signal Protocol: How is identity exchanged if a key exchange hasn't happened yet? On Signal's blog they mention that keys for accessing your profile are exchanged normally with your contacts using the Signal Protocol just like messages are (implying they are already contacts and you've already generated a shared ephemeral symmetric key).

They also mention if you start a new thread with someone who isn't in your contacts, you automatically share your profile with them. How is this done if the recipient is offline, not in your contacts and hasn't completed a handshake to create a shared symmetric key?

Here are some specs if you want to look into it further, especially X3DH.

Basically (and this is a simplification), the server stores a number of "prekeys" for each device, which are the public halves of ephemeral DH keys generated by a device when it registers, and regenerated as needed.

When Alice initiates a session with Bob, she retrieves a prekey from the server and creates a new ephemeral key to use with it. The message she sends includes an identifier for which prekey she used, and the public half of her ephemeral key.

When Bob receives the message, he can locate the private half of the prekey used by Alice, and use it with the public key she sent to compute the shared secret.

It's worth noting that the key agreement is necessary not only for sharing the profile, but for sending an encrypted message at all. If two devices were incapable of creating a shared secret asynchronously it wouldn't be possible to initiate a session unless both devices were online, or unless the key agreement messages were cached by the server until delivery, which would still create unnecessary delays. The prekeys are sort of a way of "precaching" key agreement messages.


Why add username to salt before hashing a password? I have seen examples of password hashing that were: H(username + salt + password). What is the purpose of adding username? Is there any purpose?

No, there is no purpose. This is security theater*. The purpose of a salt is to make parallel attacks against all hashed passwords infeasible, and to break rainbow tables. Adding the username in there does not improve that behavior or increase any other aspects of security. It actually has a bit of a downside as you now will run into some troubles if you are changing the username, and you are required to maintain a more complex and non-standard system. In a purely cryptographic sense, there is no downside. Practically speaking though, more complexity means more bugs.
The properties of salts and usernames
You might think that the username itself may not be public, so it couldn't hurt to use it as an additional secret, but the fact is that the database will likely already contain the username in plaintext, invalidating this already questionable benefit. People should stick to pre-existing authentication techniques. But let's look at the properties of each of these objects:
A salt is:

Not secret - Salts are stored in plaintext.

Secure - They are generated randomly and are long.

Unique - Every user's salt is intentionally different.

A password is:

Secret - Assuming they are not put on a sticky note.

Secure - If it's not hunter2. The password should be good.

Unique - Ideally, at least, but not all passwords are ideal.

Now compare this to a username. A username is:

Not secret - They are public or at least stored in plaintext.

Not secure - No one thinks to choose a long and complex username.

Not unique - Usernames are safe to share between sites.

The traits of a good salt
Now, what exactly does a salt do? In general, a good salt provides three benefits:

It prevents an attacker from attacking every user's hash at once. The attacker is no longer able to hash a candidate password and test it against every single entry at once. They are forced to re-compute any given password to be tested for each user's hash. This benefit provided by a salt grows linearly as the number of distinct target hash entries grow. Of course, salts are still important even if only a single hash is in need of protection, as I explain below.

It makes rainbow tables infeasible. A rainbow table is a highly-optimized precomputed table that matches passwords to hashes. They take up less space than a gigantic lookup table, but take a lot of time to generate (a space-time trade-off). In order for rainbow tables to work, a given password must always resolve to the same hash. Salts break this assumption, making rainbow tables impractical as they would have to have a new entry for each possible salt.

It prevents targeted precomputation through rainbow tables, at least when the hash is truly random. An attacker can only begin the attack after they get their hands on the hashes (and with them, salts). If the salt is already public but the hash is not, then the attack can be optimized by generating a rainbow table for that specific salt. This is one reason why WPA2 is such an ugly protocol. The salt is the ESSID (network name), so someone can begin the attack for their target's router before they ever even get their hands on the 4-way handshake.

So what possible benefit would concatenating a value before hashing when this value is public, insecure, and re-used? It doesn't end up requiring the attacker dig for more information. It doesn't add to the security of a salt. It doesn't increase the complexity of the password. There is no benefit.
Proper password hashing
So what should they do to increase security? They can use a KDF such as PBKDF2, bcrypt, scrypt, or argon2 instead of a single hash. They can add a pepper, which is a random global value stored outside of the database and added to the password and salt, making it necessary to steal the pepper to attempt to attack the hashes rather than simply dump the database using SQLi.
EDIT: As some of the comments point out, there is one contrived scenario where the username would be beneficial to add into the mix. That scenario would be one where the implementation is broken badly enough that the salt is not actually a salt, and the username is the only unique or semi-unique per-user value in the database, in which case mixing in the username would be better than nothing. But really, if you have no salt, you should start using one instead of trying to use usernames. Use real security and don't be half-assed when your users' safety is on the line.
* In this context, I am defining security theater as the practice of implementing security measures that do not actually improve security in any meaningful way and are only present to provide the illusion of better security.


Implication of URL injection in an URL shortener service EDIT  There have been upvotes retracted or downvotes due to, I think, a serious misunderstanding of my question.  In the following I'm not concerned about the URL leading to a site containing malware or exploits (not that it's not a concern: it's simply not what this question is about): I'm concerned about injection in the URL string itself.  What I don't want is a pirate being able to dodge "whatever framework" security and be able to inject, say, JavaScript code in an URL that I would then display to other users.  In other words: I'm looking for an additional measure to lower the risk of rogue JavaScript running as if it was coming from my webapp.

In order to harden a webapp, I'm thinking about never ever displaying URLs input by users and yet allow them to input URLs but always use an URL shortener service.  This is not meant to replace other good security practices but to be used in addition to other security practices.

Here's a very simple scenario:

the only thing that one user can input to the website is a single URL
the URL sent by the user is sent to an external URL shortener service
the shortened URL is then served from my website

If during the first step we consider that my parser doesn't have flaws while parsing the POST parameters sent by the user, what can go wrong later on if there's a succesful exploit in the URL that would affect the URL shortener service?

Basically my idea would be to serve, say, an hardcoded:

http://bit.ly/

followed by a very strict rule saying someting like: "insert at most 9 characters and these characters have to be alphanumeric".

I'd do that in order to simplify the rule concerning which characters can and cannot be sent by the user: the output of a bit.ly URL is way simpler than what legit URLs allow (I used bit.ly as an example, any URL shortener service using a very strict subset of characters in the shortened URLs it returns would do).

So what would the worst case scenario be if we consider that the rogue user is unable to exploit my website but still manages to exploit a flaw in the URL shortener service?

What I'd like to better figure out is what it means when it comes to same origin policy / XSS and CSRF and other types of exploits.

And, I guess, my question could be resumed like this: "If security is done correctly on my website, would XSS exploits affecting the URL shortening service still be my concern or not?"

The whole idea would be to add defense-in-depth and to consider that URL shortening service probably know how to defend themselves about URL injections.

This is an inefficient way of doing things.The only security you would get from an external URL shortening service is that they will only shorten valid URLS, and not javascript code etc. However, you are still relying on their security that they will indeed shorten the URL provided by the user, they will be up 100% of the time, and have 0 security vulnerabilities. Why not write your own little parser that verifies URL's.
Somethings like this: https://stackoverflow.com/questions/205923/best-way-to-handle-security-and-avoid-xss-with-user-entered-urls

Some things you can look for:

1-The users have indeed entered a url starting with http:// and not some random java script code.

2- you can also use google safe browsing api to check the URL for malware. https://developers.google.com/safe-browsing/, this is very helpful as the google safebrowsing API will return malware for malware and 200 for valid URLS, for anything else such as invalid URL's the google api will return nothing.


Odd "duplicate" HTTP requests An unexpected duplicate HTTP GET operation triggered an "unusual event" report on my web site.  The duplicate came from the web site of "Trendmicro.com" who seem to be in the internet security business.   It's just my guess, but I suspect they collect sample queries on behalf of their clients, then submit those queries themselves and perform some kind of analysis on the results.

This is usually innocuous, but I wonder what the implications would be for any of traffic which is intended to have side effects, if the server is not aware that another, similar request may appear.

For example, my case in point the request was intended to update a user ranking database, and the duplicate triggered a hacking alert.  Without the check, the update would have occurred twice.

edit: It's also relevant that the "original" request originated from an IP in Australia, and the "Duplicate" arrived a few seconds later, from an IP locatated in San Francisco.  There were a hundred or so HTTP requests in the session, but only 2 or 3 were duplicated.

Trend Micro are a fairly big player in security (well at least I have heard of them).

One of their products is a browser toolbar to warn users of malicious websites. I agree with your guess, that they are fetching pages that their toolbar has seen their users fetch, so they can decide whether it is malicious.

There is a little info on the Trend Micro spider here: http://www.webmasterworld.com/search_engine_spiders/3657953.htm

Ideally they would only replay GET requests, and GET requests should be idempotent (have no side-effects). If your user data is getting changed as the result of a GET request, then I would recommend changing that to a POST. Not only the Trend Micro bot, but any robot or search engine spider might come along and do a GET on any link and cause an unwanted result for you.


Is mod_reqtimeout a sufficient and safe technique to mitigate Slow HTTP DoS Attacks? We've been looking into configuring apache against the Slow HTTP DoS Attacks and stumbled upon this article, which goes over multiple techniques and apache configuration options.

mod_reqtimeout module looks promising and we are considering enabling it, but not everything is clear about it at the moment:

what header, body and minRate settings are considered best practices and what things should we take into account when choosing the values?
can enabling mod_reqtimeout potentially impact web applications running on this web server? And, if yes, what possible problems should we expect?

what header, body and minRate settings are considered best practices and what things should we take into account when choosing the values?

This is heavily dependent on the normal use case for your website. You should profile your site and tune to avoid false positives. If you are just hosting small static http content you can safely set these fairly low. If you return large content, have slow servers, have client side code which pump data into a connection as it generates it or expect users on poor connections you need to set the limits in a way to allow for this.

  can enabling mod_reqtimeout potentially impact web applications running on this web server? And, if yes, what possible problems should we expect?

Yes. If a connection fails to meet the restrictions it will be cut and a 408 REQUEST TIME OUT error will be returned. If you set your limits too low this will happen regularly. I would also assume this will happen to a normal user at some point no matter how loosely you set the restrictions. Ideally your application should be able to recover from it (i.e. resend the request or gracefully notify the user there are connection issues).


Recommendation Key Management and Storage in Cloud Storage I am currently researching about key management in the cloud storage and looking for alternative for it. The current system stores encryption key for each file in the server and each key is encrypted with user's public key (key wrapping), so imagine 500 encrypted file with 500 encrypted encryption key stored in the server. File and key are stored encrypted and separately in different server and file is already encrypted before sent to the server. Everytime user wants to access the file, he needs to decrypt the encrypted key with his private key then use the key to decrypt the file.

I was thinking if there is an alternative to that, say user is able to generate the key without storing it to the server or using key wrapping. Also this alternative should also work with multiple devices.

My idea is that user can calculate the keys by himself without the need to store the key in the server to avoid unauthorized user listening to the communication during key exchange.

Any idea will help.

Thanks

If you are supplying the application that stores and retrieves the encrypted files for the user, here are a few ideas you may want to consider...

1) Rather than encrypting data at the cloud storage, consider encrypting the data files prior to storing in the cloud service. You can find numerous options for encryption libraries on GitHub.

2) Store the Keys used for encryption separate from the data. Consider using an encryption-as-a-service offering and making REST API calls to retrieve the Keys when needed.

3) Use a Key vendor who specializes and has the expertise in crypto, authentication, and identity so that you get reliable and robust Keys.

You may want to try out several options before choosing a specific approach. Here's an example EaaS / Key service you can try for free: www.ncryptify.com


Side channel attack with flush+reload I have been reading about cache side channel attacks and the "Flush+Reload" method came up a decent amount. Before putting forth my question, this is what I understand about the Flush+reload technique.

I understand that if two users (Alice, Bob) run the same program, the typical OS will create a copy of the page tables so that the program is not loaded twice. These are read-only though so all is "fine". If attacker, Bob, can determine which cache lines of the shared memory are in the L3 cache over a period of time, he can possibly determine what cache lines Alice's process accesses overtime. This can be done with the Flush Reload by clearing out the cache and timing how long it takes to read the cache. Very fast = Alice is accessing this piece of memory. Slow = Alice is not accessing this piece of memory. Bob continues to do this overtime to develop a 'baseline' of sorts. Hopefully the majority of my understanding is correct.

I have read how this can be used for programs that have user input. Bob performs the attack on himself with many inputs and calculates the time based on refreshing the cache. He then performs the attack on Alice and basically compares the results to distinguish inputs (high level but this isn't my question).

The majority of my understanding is from here.

My question is, how is this attack any different from a brute force attack or even a timing attack in the context of user input?

Side Channel attacks usually do not leave any traces of intrusion. The attacked program will run without detecting any side effects. With brute force attacks the attacked program is invoked by the attacker many number of times. The attacked program can take counter measures as to check for the frequency of requests.
e.g. brute force would be to try every possible key for decryption of a cipher text.
side channel attack would be to detect/sniff the key by measuring the electric/electromagnetic/cache access characteristics. For RSA encryption if square and multiply method is used it is possible to find out the key by checking the current usage of the device as each step in square and multiply require different power.


Storing config securely in a semi trusted shared hosting environment I'm looking for a pattern to store a config file containing sensitive information in a semi trusted hosting environment. Semi trusted in this case meaning I trust them in general, but not with this info (passwords).

In this case I'm writing a simple daemon to watch a folder for changes, and push those changes to a database hosted somewhere else. I'd rather not store the details for that database in plaintext in this semi trusted environment, as I'm unsure if the admins themselves would use it maliciously.

My original plan was to setup the necessary reporting scripts in my untrusted environment, and then execute them remotely from a trusted location, sending config vars on each execution. However it would seem that they log all commands executed on their servers, so this is a no go as they could simply review those logs.

Alternatively I could have a second layer database, whose credentials I store on their server. This database would act as an in between, allowing one set of scripts in an untrusted environment to push data to it, and another set of scripts in a trust environment to pull data from it and move it to it's final destination. I'm less concern about them maliciously corrupting the data, and if they access this database it isn't a big deal as it's entirely separate from my main data store.

This method is rather cumbersome and not exactly secure, so I'd rather avoid it if I can.

Moving away from this untrusted environment is not an option, unfortunately.

If you're worried about the admins actively snooping on your application, there's nothing you can do except never use their system with any sensitive data. Whatever your program does to decrypt or retrieve credentials, they can also do. For the same reason, you need to trust them not to allow administrative access to their system to any untrustworthy third party.

One area where there is some room to mitigate risks is reaction time in case of a breach. It is difficult to give general advice there because this is a compromise between availability and confidentiality — if something “weird” happens, do you want to take the system down as quickly as possible (and page you to come and sort the whole mess before service can be restored), or do you want to keep running as long as possible and notify you that something may be amiss? Note that even with best effort, you can never be sure that a breach won't happen undetected.

You can slightly reduce the risk by storing the credentials remotely and retrieving them on each connection or at short intervals. For better results, use a password that changes automatically every few minutes. That way, if the server is compromised but the attacker wasn't initially after your application, you may have a little reaction time when you can decide whether to shut down service — just turn off the credentials access. This isn't foolproof; if the attacker is after your application, he'll start using the credentials before you can react. In any case, make sure you can change the credentials quickly before breaking anything else (so no shared password that needs to be changed in 20 different places).

Another way to mitigate risk is to give this semi-trusted system as few privileges as possible. In your situation, the semi-trusted system only needs to push changes into a database somewhere else, so don't give the semi-trusted system any credential that lets it access the database directly. Only give it permission to append records to one table, or some such. Use a proxy application (running in a fully trusted environment) rather than direct database access to perform this authorization check, and make it log everything it does. That way, if the semi-trusted system is compromised, you may end up with fake records (together with a timestamp and perhaps other information that may let you sort the good records from the fake ones) but anything that isn't derived from these records will still be safe.


How can we disable sudo on CentOS 6 to prevent CVE-2021-3156? How can we disable sudo on CentOS 6 to prevent CVE-2021-3156?
We cannot remove RPMs or similar.
We can only change a configuration.
Do we have another fix for CVE-2021-3156 on CentOS 6, except disabling sudo?
Will we be able to execute su - after disabling sudo?

How to disable sudo on CentOS 6 to prevent CVE-2021-3156?

chmod 0644 /usr/bin/sudo will effectively disable sudo for non-root users. It removes the setguid bit, so sudo will work as epxected for scripts executed by root, but not for other users.

Do we have other fix for CVE-2021-3156 on CentOS 6 except disabling sudo?

Upgrade to a supported release. If you run CentOS 6 with untrusted local users, it's probably just a matter of time before a new local privilege escalation surfaces.

Will we be able to execute su - after disabling sudo?

Yes.


Best protection against a "chosen-ciphertext" attack? What is the best protection against a "chosen-ciphertext" attack when transmitting (=streaming) secured (=crypted) data via networks using the TCP protocol?

Firstly, a little crypto background. I'll provide you with links and you can decide how far you read.

The key to avoiding CCA/CCA2 (Chosen ciphertext attacks) is to not provide an "oracle" (something the attacker can query either in a limited fashion or at will). In terms of practical implementations of such oracles, replying to encrypted email messages with the stuff you previously decrypted is an example of providing an oracle - whatever ciphertext went in has been decrypted and provided to the attacker. , a m

The key is to not provide that oracle, to which there are two solutions. One is to encrypt-then-mac - i.e. use a pre-shared secret to produce a message authentication code which the recipient can check before decrypting. That way, if the ciphertext is not from the sender, you reject it. An alternative to this is to use an authenticated encryption mode, a complete, integrated approach (it combines your block cipher with a MAC).

So the approach to solve the CCA/CCA-2 problem is to use some kind of authentication of your messages.

What can you do now? Read about the protocols your ciphers use and ensure they use something like EAX, or a MAC.


OpenSSL Padding Oracle. Specific Ciphers on apache2 seems a little limited I've seen a lot of articles giving the official explanation on how to prevent OpenSSL Padding Oracles, Usually all of them state that its CBC cipher suites that leave you vulnerable.

The following list works for me, and gets me an A on SSLLabs.

SSLProtocol -all +TLSv1.2
SSLHonorCipherOrder On
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:RSA+AESGCM:!aNULL:!MD5:!DSS:!LOW:!MEDIUM

My problem is that I cannot add any more without getting an F, and being open to the Padding Oracle in question.

If I then compare this to the results of a security heavy website like http://binance.com. They get A+ AND they have CBC ciphers present.

My question then, how can I protect against OpenSSL Padding Oracle (CVE-2016-2107), whilst enabling more ciphers? Is there more configuration I can do elsewhere to protect, whilst allowing a larger range of ciphers (WEAK or not)? I also see that TLSv1.0 and TLSv1.1  can also be enabled with a limited range of ciphers too.****

My reasoning here is that my current list is preventing Safari 6-8, Android 2-4, and Windows 7 IE 8-10 users. I'd like to open this up.

Thanks

Please have a look at the specific CVE where it is clearly documented what is affected by the issue in the first place:

  The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a certain padding check, which allows remote attackers to obtain sensitive cleartext information via a padding-oracle attack against an AES CBC

From studying the linked resources you'll find out that the fix is not to disable specific ciphers but to make sure that you don't run any of these affected versions. From the relevant OpenSSL advisory:

  OpenSSL 1.0.2 users should upgrade to 1.0.2h
  OpenSSL 1.0.1 users should upgrade to 1.0.1t