How does Telegram's secret-splitting scheme work? The Telegram FAQ's state that they are not able to comply with court orders from one country alone because they "split the encryption keys and spread them over multiple jurisdictions".

To protect the data that is not covered by end-to-end encryption, Telegram uses a distributed infrastructure. Cloud chat data is stored in multiple data centers around the globe that are controlled by different legal entities spread across different jurisdictions. The relevant decryption keys are split into parts and are never kept in the same place as the data they protect. As a result, several court orders from different jurisdictions are required to force us to give up any data.
Thanks to this structure, we can ensure that no single government or block of like-minded countries can intrude on people's privacy and freedom of expression. Telegram can be forced to give up data only if an issue is grave and universal enough to pass the scrutiny of several different legal systems around the world.

As this all talks about non-e2ee chats, how is this realistically possible? All messages are stored in a "cloud chat" so they are stored on the server indefinitely. My device(s) need(s) to download these messages somehow, so how can one government not just tell them to download all my messages in my name?
Is this just a legal issue or is there a technical possibility that I'm not seeing here?

Key splitting (best case scenario)
The ideal cryptographic algorithm for this purpose is Shamir's Secret Sharing, as it provides Information theoretical security, meaning it's mathematically impossible to recover the actual key without having the k number of shares specified by the person splitting the key.
We don't know how many shares are needed, and/or if it's even the case Shamir's scheme is used, but to analyze the security in academic way we should assume good faith and assume that is indeed the case.
But even with Shamir's Secret Sharing, it is the case this only applies to the offline-copy of the key. There is no precedent that this argument would hold in court, and since Telegram hasn't shown e.g. third party precedent, we can only trust their word. It is very unlikely it would hold in court, because the Shamir shares are not what the courts would go after. This is because there is another copy.
Database encryption design (best case scenario)
The reason there is another copy, is, the key is also used for something, namely, database encryption. Every time you send a cloud message to Telegram server, that cloud message needs to be committed to the Telegram server's database.
The most secure possible way to handle database encryption is to encrypt data first, and then commit the ciphertext to the database as a binary blob. The server will then decrypt the data right before it's sent to the recipient (or back to the user who e.g. has added a new device, which is now requesting the message history). Again we don't know if this is the case as it might be really inefficient for making searches etc. but again since it's security we're trying to assess, we assume good faith and that this can be done even if it requires spending more computational effort for database management, searches etc.
The "commit encrypted blobs" approach is essentially on-the-fly encryption of data going in and out of the database, i.e., the server constantly encrypts and decrypts data. Every operation of encryption and decryption requires the CPU that does the encryption or decryption, to have access to the key.
Location of the key in memory
The way computers work, is running programs store all their data to the Random Access Memory (RAM) of the server. The CPU can also store frequently used data to its cache memory to make it more readily accessible.
In servers the RAM does not necessarily have to exist on the same motherboard, as RDMA allows access to RAM of close proximity servers with an interface such as InfiniBand.
RAM encryption
Modern servers can also encrypt the RAM with Intel TSME or AMD SME, so again, assuming good faith that such is used, one can't just pull RAM sticks out of Telegram's server and obtain the database encryption key with a cold boot attack.
But RAM encryption or displacement to another motherboard via RDMA doesn't make the key unavailable to the operating system and/or Telegram server application.
Summary of best case scenario
So hypothetically, assume

Telegram servers have been booted only once
Telegram keys were split to shares with Shamir, and carried by Telegram staff to multiple countries before anyone could get their hands on them
Telegram servers have never been rebooted so the incredible trouble of having to reassemble the key has never needed to be done.
Telegram servers encrypt every message before committing the ciphertext as a binary blob to the database.
Telegram servers decrypt every ciphertext read from the database just before sending it to the user with MTProto client-server encryption

The security assessment of the best case scenario
Threat 1: Subpoenas
According to this tweet Telegram has servers in "[...] London for European users, Singapore for Asian, San Francisco for American."
So three servers. As per above, the entire database encryption key for all European users must by definition exist in RAM of the server in London, thus Telegram can access any user's data either via the interface they use to monitor reported chats, or, by printing out the key by adding a single line of code print(server_private_key) to the server, and then using a secondary program to decrypt the database entries. This is so simple to do, failure to do so would with overwhelming probability be considered obstruction of justice. Every major Internet company in the world encrypts its databases, and is obliged to comply with court orders. Telegram's claim that it is unable to do the same thing despite using exactly same database encryption technology, and having the key physically present in the server rack, is pure fabrication.
Threat 2: Telegram staff
When Telegram server receives a client-server encrypted (cloud) message from a contact, it first authenticates and decrypts the client-server MTProto ciphertext to recover the plaintext message.
After the plaintext message is available, Telegram staff can do whatever they want with that message. They can make as many copies of the message as they want, they can analyze it to create a profile about the user in secret, etc. The only thing that's stopping them, is if they have an internal policy to not do that. The public privacy policy does not necessarily reflect the truth, and isn't written in stone, Telegram might in future serve e.g. targeted ads based on that data. So this boils down to whether or not you trust Telegram to do the right thing, always, indefinitely.
Threat 3: Hackers
Telegram's server contains billion of messages from its 400 million users. This makes it a very tempting target for both organized crime, and nation state actors. How would Telegram's key splitting system protect its users in case of breach? How would the breach work?
It all begins with a vulnerability, an un-patched bug that endangers the security of the server. Majority of vulnerabilities are known and fixed, but for every up-to-date system, it is extremely likely there exists at least one vulnerability that the attacker knows, and that the developers of the software that runs in the server (OS, server application etc.) does not know. This is called a zero-day.
The vulnerability is exploited with a piece of code called the exploit, that then opens up the route to deploy what is called the payload. The payload is that does the dirty deeds of the attacker. (An exploit against a zero-day vulnerability is called zero-day exploit.)
So to give an allegory, vulnerability is a weak skin, exploit is the stinger of a wasp, and the payload is the venom of the wasp delivered via the exploit.
In order to wreak havoc, the zero-day exploit must also be able to perform something called privilege escalation. This requires a vulnerability in the operating system of the server.
So when such zero-day exploit is performed, it allows the attacker to run any command and program with kernel-level privileges, which also means that the CPU runs in something called kernel mode. To quote Wikipedia on CPU modes,

Kernel
In kernel mode, the CPU may perform any operation allowed by its architecture; any instruction may be executed, any I/O operation initiated, any area of memory accessed

When the CPU runs in kernel mode, it can access any area of memory. This by definition includes the memory of the Telegram server program that's doing the back-and-forth encryption/decryption for databases. The attacker's payload-program that's running in kernel mode will scan the RAM for the Telegram's database encryption key, and sends it to the attacker.
Since in kernel-mode any I/O operation can also be done, the attacker can also use the payload program to dump the entire Telegram message database, and the attacker can then decrypt the messages with the stolen key either on their end, or at server's end.
Can such an attack be detected?
It depends on the quality of the exploit. E.g. to quote Wikileaks on CIA's GrassHopper framework

The requirement list of the Automated Implant Branch (AIB) for Grasshopper puts special attention on PSP avoidance, so that any Personal Security Products like 'MS Security Essentials', 'Rising', 'Symantec Endpoint' or 'Kaspersky IS' on target machines do not detect Grasshopper elements.

So it's very likely a nation state actor who hacks Telegram servers won't be detected. It is also the case the payload is a form of rootkit which "often masks its existence or the existence of other software.". Thus, the rootkit will change the system so that nobody, not even a root user can detect its presence.
But isn't such attack loud form the perspective of amount of material that needs exfiltration, and detectable from other systems in the server infrastructure?
It is entirely possible. But dumping the database isn't the only way to access client-server encrypted cloud messages. If instead of database encryption key, the attacker compromises the private key that the server uses for the MTProto client-server encryption (either persistent Diffie-Helmman private value, or a RSA signing key), the attacker can perform completely invisible MITM attacks against the client-server protocol. This only requires lifting extremely small amount of data from the server, can be done in milliseconds, and it still allows mass-attack against Telegram users from the backbone of the internet. There is no way for client to detect this attack, and no way for server to detect incoming connections do not come from the phone but from the MITM attacker.
Can the problem be fixed?
Yes. End-to-end encryption exists to eliminate this problem entirely. Telegram also supports end-to-end encrypted 1:1 chats on mobile so the developers clearly recognize the benefits, but alas end-to-end encryption is

not enabled by default
no available for group chats
no available for Windows/Linux desktop clients

There is a lot of misinformation going about that says that these are not doable, but there are counter-examples such as Signal and Wire.
Telegram staff have argued for why they do not make every chat E2EE, which I have refuted here.


JSON Web Encryption (JWE): should one verify the alg and enc similarly to JWS alg whitelisting? Use of JWS may suffer from flaws when relying on the "alg" attribute as described here: Critical vulnerabilities in JSON Web Token libraries.

The advice is to verify that the signing JWS algorithm is in a list of accepted algorithms. Practically, most JWS libraries have added am "alg" whitelist parameter:

verify(string token, string algorithm, string verificationKey)

They haven't, however, added such a parameter for JWE decryption.

When proceeding with JWE decryption, should I verify after successful decryption that the "alg" and "enc" are in a whitelist of acceptable values? In other words, does JWE decryption suffers the same problems than JWS signature verification?

Yes.

From JWT BCP:

  Libraries MUST enable the caller to specify a supported set of
  algorithms and MUST NOT use any other algorithms when performing
  cryptographic operations.  The library MUST ensure that the "alg" or
  "enc" header specifies the same algorithm that is used for the
  cryptographic operation.  Moreover, each key MUST be used with exactly
  one algorithm, and this MUST be checked when the cryptographic
  operation is performed.


Wondering about open port found while using VPN service I have noticed during port scanning that my "anonymous" IP has an open port (111) while I am using VPN.

Does this make me vulnerable as user or is it the provider's failure? Should I change providers or do I have nothing to worry about (since, if the providers' network security is compromised, mine is in risk as well)?

NOTE: All of this assumes you are talking about TCP 111 (vs UDP).

If you are using a VPN service, you are sharing that Public IP with many customers and being NAT'd somewhere along the way. This Public IP is generally not directly routable to you as a user of the service, as such, there isn't much to worry about.

That being said, it's hard to know (without more info/probing) exactly what is running on that open port. In general, ports 1-1023 fall in the Well-Known Ports range, though that's not to say that something else can't be running on this port, but it's likely an RPC (remote procedure call) service like SunRPC.

TL; DR You're probably fine, but if you're still worried about, contact the VPN vendor and ask them exactly what it is and what it's used for.


What is the best way to recycle an old hard drive that might still have sensitive data? Six years ago, I got a Seagate Agent Flexgo hard drive, but recently it started showing signs of failure.

I was unable to get it formatted. I thought of opening up the inside to find some way of destroying the information contained within. I managed to crack open the plastic casing.
I suggested burning the metal components in a furnace, but my family member told me that it could be illegal.

Has there been any method to cleanly erase a hard drive before being recycled if you cannot properly format it?

Let us consider two scenarios, one where you'd like to reuse the hard drive and one where you don't.

This link shows multiple ways to effectively destroy a hard disk ( Some of these are fun, do take a video)

The other scenario is when you'd like to reuse the hard drive. Here's the basic explanation of data storage -
 Any data you store is stored in the form of bits along with meta-data that tell the OS what the data type is. Also there will be a directory which will tell exactly where on the hard disk is the particular data saved. When you delete something, the directory is rewritten to the recycle bin. The data isn't altered. This data can be easily recovered. When you permanently delete something the data still isn't changed, instead the OS is ready to overwrite the data. If the deleted data was not overwritten, it can still be recovered. Even most quick formattings do the same, They just 'free up space' by erasing directories. To keep your data non recoverable, multiple programs exists. What these do is, they overwrite the data over the entire disk randomly a few times. These make it near impossible to recover data. Although a good way is to reuse the disk yourself and fill it up with games & movies a couple of times over the course of 2-3 months and repeat twice. You should be good to go. A final approach is to reinstall an OS on it, this usually clears up the disk properly. A couple of installs and you should be good to go.


Why use .ENV? What's wrong with storing secrets in a config.php file outside root directory? Seems to be the general practice these days is to store secrets (e.g., DB, API credentials) in a .ENV file then load it to $_ENV and $_SERVER automatically. This popular library does that and it's even encouraged as best practice. This library takes it a step further and encrypts the value inside the .ENV file.

They say the whole purpose is to easily manage dev/production configs and to minimize config files being pushed to version control. On top of "never store sensitive credentials in your code".

One glaring issue about this is a simple injection of print_r($_SERVER)or print_r($_ENV) in your code will reveal everything. Or, if you forgot to delete phpinfo.php, all is lost! There are also other ways it could leak (e.g., logs).

I'm quite baffled that this practice is prevalent or maybe I'm just missing something.

Is there anything particularly wrong with the good old config.php stored outside document root? I mean you could put that in git ignore too and it's not going to be part of your code at all. You can even encrypt it too. Why use .ENV?

Update:

Here's an article that agrees to my sentiments

To clarify, the security and flexibility are gained by putting secrets into environment variables.

.ENV is a convenience and, ideally, is not used in production.  Many hosting services will handle deployment for you, and provide a way to store production environment variables securely, without .ENV.

Putting secrets and configuration in environment variables is about mitigating the damage of more common breeches, eliminating classes of mistakes which can lead to security vulnerabilities, and making deployment simple and flexible.

Secrets are put into environment variables so they never touch disk when deployed. Only the server process and its children have the secrets. This mitigates the damage if an attacker...

gains read-access to your production server's filesystem
gains read-access to your code
can execute code, even your code, on your production servers

To get your environment variables, the attacker must be able to alter code on your production server, or inject it into your deployment process. If someone can inject print_r into your production, or if you forgot to delete phpinfo.php, a great many things have gone wrong with your release procedure.

Practical security is layered. If one layer is breached, the rest are still secure. If an attacker gains access to your filesystem, they don't have your secrets. If you're worried they'll alter your running code, put your code on a read-only filesystem.

Configuration is put into environment variables to simplify deployment. One does not need to have separate config files for development, and testing, and staging, and production, and each customer. Instead, each deployment sets its own environment variables.

If you're following Point 10 of the Twelve Factor App, different environments and deployments should have few differences.

.ENV is a optional compromise for convenience. Developers will be running bits of code in many different environments, and remembering to set environment variables in all of them get tedious. Tedium breeds mistakes. So it's better to have a fairly secure process, and all the secrets in a single location.

Development machines have different attack surfaces than a production machine. For example, they can be stolen. One of the important security layers is to ensure developers use an encrypted filesystem, encrypted virtual memory, and screen locks; if their machine is stolen, the information on the disk is safe.

Even so, .ENV should not contain production secrets. Developers should be using development databases and accounts.

If .ENV is used for deployment, then it should be encrypted. Then one must only secure a single, per-developer key which is put in, you guessed it, an environment variable. Rails Encrypted Credentials uses this approach.

  Is there anything particularly wrong with the good old config.php stored outside document root?

There are many disadvantages.

First and foremost, your secrets must live on your production server's disk. Anyone with read access to that file now has your secrets. Putting it outside document root is little protection, there are many security vulnerabilities which allow access to files outside document root.

config.php is code and is vulnerable to additional classes of attacks that a data file is not.

config.php can get large and complex making it difficult to tell which parts are secrets and which are not. This makes security audits difficult.

config.php requires putting your secrets on disk. .ENV is optional, you can develop and deploy using only environment variables.

config.php can easily find its way into the code repository.

Each deployment needs a slightly different config.php with different secrets making deployment more complex.

In contrast, .ENV is a small, simple data file with a single purpose. Your QA and deployment process can automatically detect if .ENV slipped in, or if it is unencrypted. There is a single, simple data file which needs to be changed between environments.

And .ENV is entirely optional.

  I mean you could put that in git ignore too and it's not going to be
  part of your code at all.

config.php is code and should be tested and version controlled. Not having it as part of your repository complicates deployment. This is point 1 of the Twelve Factor App. .ENV minimizes the compromises to your development process. And, unlike config.php, it is optional.

  There are also other ways it could leak (e.g., logs).

You are correct that logging is a potential security leak. That doesn't mean we give up.

You can set different log levels in development vs production using, you guessed it, environment variables. Production log levels would log less and be more careful about what is logged.

You can add a scrubber to your logging function, there are many available, to remove any sensitive information before it is logged. Some look for common patterns such as passwords in URLs, credit card numbers, and PII. With all your secrets in .ENV your logger could automatically remove secrets with a simple regex.

And rather than logging to a local file, you can also stream your logs to a logging service. This is point 11 in the Twelve Factor App. Now your logs are off-site; your production server can be compromised but your logs are still safe.

The Twelve-Factor App takes some getting used to. PHP is an older language with more traditional ideas and may require more adaptation than other languages. I've been following it for a couple years in Ruby. It's made a marked improvement in the speed and reliability of my processes.

And I hope now you understand why Environment Variables Considered Harmful for Your Secrets is itself harmful. The author is concerned about exposing secrets to child processes, a valid concern, but then advocates putting those secrets on disk; a far broader exposure. And since child processes are run by the same user as the parent, the child processes can see the secrets file anyway.

If you truly don't want to store any secrets locally at all, look into Vault.


What are formal parameters for fingerprint scanner selection? I would like to buy a USB fingerprint scanner. I intend to use it to log in into my Windows computer, to secure RoboForm password manager, and generally to replace password entry with a quick finger sweep in as many places as possible.

What I'm asking here is not a shopping recommendation. Instead, I would like to know what are the key technical parameters that I should use to compare different fingerprint biometric scanners available today. Quick search on eBay returns devices that cost from $7 to $200, roughly. They all look very similar to me. I suspect $100 device might perform better than $10 one, but in what respect? I suspect there are characteristics that are deemed important but usually omitted in lower quality devices specs.

First, you have to consider that each maker of fingerprint sensor uses a different technology for creating a fingerprint template (a representation created from a image captured by the fingerprint sensor) and matching the template against a reference template (created during the enrollment, when you register your finger).

In terms of technology, to compare the how secure are these different ways to authenticate a fingerprint, there are 2 main parameters:

rate of false negatives: the percentage of times a finger that should match the reference finger template fails to do so (this will be the rate of 'annoyance': the chance the sensor will not allow a legitimate user to login)
rate of false positives: the percentage of times a finger that should NOT match the reference finger template will actually match (this will be the rate of security failures: it means there is a potential for another finger to be seen as the correct finger)

However, most security problems in consumer fingerprint authentication products will actually not be in the technology itself, but in the implementation. E.g. not properly protecting the passwords that are stored behind the fingerprint authentication, so the attacker can ignore the biometrics and grab them directly, etc.

I would want to see the specific details of how the system is implemented before deciding and I would say that unless system security was a key requirement during the whole design I would not feel confident.

I think this is similar to the encrypted USB keys... most of the 'secure' consumer disks have almost null security and only the expensive ones, usually the ones designed for security (i.e. Ironkey, etc) really provide protection.

Not sure if this answers your question, hope this helps.


Why is it not possible to capture a WPS handshake to WLAN There are well known attacks to WPA by capturing handshake and running offline hashcracking against it. Also there are tools to exploit vulnerability in WPS to get the PIN. My question is why WPS handshake (if it is called handshake) cannot be captured and the PIN revealed. It seems impossible otherwise obviously someone had done it already.

A Diffie-Hellman key exchange occurs before exchanging the sensitive information. Please see https://www.grc.com/sn/sn-338.htm . The relevant part:

"But it absolutely will encrypt the dialogue so that somebody just capturing the packet traffic is unable to, as I said last week, get the data, take it home, and crack the PIN offline. That can't happen because the dialogue is protected by this initial establishment of a secret key which doesn't authenticate, but it does give them privacy."

So cracking the 'handshake' as you call it (it isn't really a handshake), would be much much more complex than just performing a brute-force attack against the PIN, as this 'handshake' is encrypted with strong asymmetric encryption.


How can I make sure that I have the correct root certificate in my browser? How can I make sure that the root certificate in my browser (say VeriSign) is correct and is what it actually should be?

I found that the root certificate information is available here. But what if the site is compromised as well and the fingerprint is modified in a way to match the compromised root certificate? So all the certificates that are signed by root CA could be compromised too.

What am I missing?

At some point, you need to trust someone. Whether this is your browser maintainer who embedded the certificate or the website of the certificate authority that provides the root certificate.

For sure, if your trusted source is compromised, their is a risk of you being tricked.


How to sandbox Firefox ESR for normal browsing? I'm running Debian 9.1 with KDE and for security purposes I'd like to run Firefox ESR in a sandboxed mode.
However I'd still like to use many normal Firefox features for my normal browsing, download files to my computer and store / access browsing -history and -sessions.

How can I do that?

You have several ways to sandbox Firefox (or any similar application), depending on your exact requirements.

From the lighter to the heavier solution, you mainly have:

Firejail is a software precisely designed to easily sandbox other applications while keeping them on the same root filesystem. It relies on standard Linux features (namespaces and seccomp-bpf) and doesn't do any significant assumption on the underlying system, so it should just work on most common Linux distros. It supports sane X applications sandboxing solution (see the note about X application at the end), provides presets for common usages while supporting a wide range of customization.
Most probably overkill for personal usage, but might be suitable in corporate environment: you can customize AppArmor or SELinux rules to enforce the sandbox. You will most likely have to choose a Linux distribution which already provides a set of base rules in the option you chose. This provides a lower-level sandboxing, which can even be extended onto the network (at least with SELinux, I'm not sure that AppArmor support this), but lower-level mean a far higher amount of work to deploy this solution.
You can sandbox Firefox in its own environment, the lightest way being to use a Linux container (LXC), the heaviest being using a full-fledged virtual machine. By doing this manually you may also have to think of a way to securely transfer data to and from the FIrefox's sandboxed environment.
You can leave general public distros and switch to a security-oriented Linux distribution instead, such as Qubes OS or Subgraph OS. These Linux distribution implements software isolation at their core, Qubes pushing the idea the furthest by relying on a set of Xen virtual machines to also isolate device drivers and Subgraph relying on Linux containers instead. Sandboxing here is not a layer added on top of a general purpose distribution anymore, this means that each of these OS provides its own workflow to handle data transfers between each application, etc.
At last you can also use a dedicated computer for casual browsing, and another one for more sensitive tasks. This is not exclusive with the previous case as it may make sense in particular to run Qubes on such computers to isolate them from a otherwise potentially untrusted network (if you assume that the casual browsing computer may be infected, it means you assume that an attacker may attempt to attack your sensitive computer from within your internal network). This may seem overkill but it is common to use different computers for work and for home, this is no different.

Depending on the solution you choose, you may have to double-check how the display is handled as, under normal circumstances, each X application has access to the interface of every other application, allowing it to interact with them or capture their input and output. Here is a thread giving some clues if you need to build your own custom setup.


Safe implementation of sharing encryption secrets (username, password) in the cloud I'm building a multi-tenant (cloud) environment that needs to push out (or make available for download) configuration files for agents (background services) that receive this information.  One of the pieces of information in the config is a username and password.

Assuming that the agent can be identified securely to the cloud, what encryption and security system would you use to encrypt, share, push out this sensitive information?

Is a Public Private key pair sufficient?  I am thinking the secrets will be encrypted to the public key of each agent, and the unencrypted value will be discarded.

What are your thoughts on this implementation?  I'll mostly be using C# in this application, Windows Azure, ASP.NET MVC, and Silverlight.

Sample Agent-side code (RSACryptoProvider)

This will generate the Public Private Key Pair in C#, and not save the key to disk

public static void AssignNewKey(){
    const int PROVIDER_RSA_FULL = 1;
    const string CONTAINER_NAME = "KeyContainer";
    CspParameters cspParams;
    cspParams = new CspParameters(PROVIDER_RSA_FULL);
    cspParams.KeyContainerName = CONTAINER_NAME;
// CspProviderFlags.UseNonExportableKey -- Prevent less-knowledgeable attacks against PK
// CspProviderFlags.UseUserProtectedKey -- Interactively prompt for password
    cspParams.Flags = CspProviderFlags.UseMachineKeyStore;
    cspParams.ProviderName = "Microsoft Strong Cryptographic Provider";
    rsa = new RSACryptoServiceProvider(cspParams);

    rsa.PersistKeyInCsp = false;

    string publicPrivateKeyXML = rsa.ToXmlString(true);
    string publicOnlyKeyXML = rsa.ToXmlString(false);
    // do stuff with keys...
}

Sample Agent-side code Option 2 (Bouncy Castle)

public void GenerateKey(string username, string password, string keyStoreUrl)
        {
            IAsymmetricCipherKeyPairGenerator kpg = new RsaKeyPairGenerator();
            kpg.Init(new RsaKeyGenerationParameters(BigInteger.ValueOf(0x13), new SecureRandom(), 1024, 8));
            AsymmetricCipherKeyPair kp = kpg.GenerateKeyPair();

            FileStream out1 = new FileInfo(string.Format("{0}secret.asc", keyStoreUrl)).OpenWrite();
            FileStream out2 = new FileInfo(string.Format("{0}pub.asc", keyStoreUrl)).OpenWrite();

            ExportKeyPair(out1, out2, kp.Public, kp.Private, username, password.ToCharArray(), true);

            out1.Close();
            out2.Close();

        }

private static void ExportKeyPair(
            Stream secretOut,
            Stream publicOut,
            AsymmetricKeyParameter publicKey,
            AsymmetricKeyParameter privateKey,
            string identity,
            char[] passPhrase,
            bool armor)
        {
            if (armor)
            {
                secretOut = new ArmoredOutputStream(secretOut);
            }

            PgpSecretKey secretKey = new PgpSecretKey(
                PgpSignature.DefaultCertification,
                PublicKeyAlgorithmTag.RsaGeneral,
                publicKey,
                privateKey,
                DateTime.Now,
                identity,
                SymmetricKeyAlgorithmTag.Cast5,
                passPhrase,
                null,
                null,
                new SecureRandom()
                //                ,"BC"
                );

            secretKey.Encode(secretOut);

            secretOut.Close();

            if (armor)
            {
                publicOut = new ArmoredOutputStream(publicOut);
            }

            PgpPublicKey key = secretKey.PublicKey;

            key.Encode(publicOut);

            publicOut.Close();
        }

Encrypting the data with the public key of each agent is a way to implicitly authenticate the agent. You do not really know (in a setup where communications go through a potentially malicious cloud) if the agent really received the data, but you know that only the proper agent could decrypt it; hence, if the data has gone somewhere at all, then it went to the right agent. This looks like the good tool for your problem.

Note that public key encryption could be overkill. If you can arrange for the receiving agent and the data sender to share a common secret key (just a bunch of a few dozen random bytes), then you could use symmetric encryption to encrypt the data.

There are a few gotchas:

If you use a public key encryption scheme, then the sender must know the public keys of the agents beforehand, and in a reliable way. Depending on how you create and deploy the agents, this may or may not be easy.
The power of an agent to receive the data comes from its knowledge of his private key (or of the common shared secret key in the symmetric encryption case). You must take care of the storage of that private key, because acquiring a copy of the key would allow an attacker to decrypt your encrypted data.
Asymmetric encryption works only for limited messages. E.g., with 1024-bit RSA and the usual PKCS#1 padding, there is a hard limit at 117 bytes in a message. Also, RSA encryption and decryption is not too fast (although fast enough for most purposes). Hence, it is customary to use an hybrid scheme, in which you do not encrypt the message itself, but a random secret key (a bunch of random bytes) which you then use to encrypt the data itself, with a symmetric encryption system (AES), which is fast and unlimited in message length.
When there are malicious passive attackers, there often are active attackers as well. Passive attackers just spy on data; active attackers can also modify it. There are many smart attacks which can be made by subtly modifying encrypted data and observing the results (passwords sent in a SSL connection have been recovered that way). So you do not need only encryption, you also need integrity checks. One possibility is that the sender signs the encrypted packets, and the agents verify the signature before trying to decrypt them.

Myriads of deployed systems have stumbled on these, and they cannot be efficiently tested beforehand. You really should use an existing standard format for all that, with a support library which has already gone through the effort of implementing it properly. I suggest using CMS or OpenPGP. I do not know if C# already support those (I doubt it, especially in the case of OpenPGP), but Bouncy Castle is an open source library which does (it has a C# version).

As a final note, if you have many agents which should receive the same data, it may be more network-efficient to encrypt the data once with a secret key, which you then encrypt with the public key of each agent. This is called broadcast encryption and this is what pay TV vendors do (they send the very same voluminous content to millions of customers, which makes the broadcast thing not only worthwhile, but also downright necessary).


Blacklist IP addresses based on number of 404s in Apache I'm getting a lot of hackers spamming my domain with requests for files that just don't exist. This is eating up a lot of my allotted bandwidth and I'd like to blacklist these IP addresses.

Is there is a way to automatically blacklist IP addresses in Apache once they have requested X number of files that 404 in a specified time frame?

Fail2ban does exactly what you ask.

It monitors your log files looking for certain patterns and then executes whatever action you specify. You can block an IP for a length of time.

It does require some skill in regex, but it comes packaged with regex testers.


How much information can be obtained from observing someone type their password? Seems like it wouldn't be too hard to determine if someone is using all lowercase, special characters, or even the length of their password. In fact, the length might be discovered from audio only. After years of typing, I find that I type common English words much faster than random strings. Again information available from audio only.

Any studies on such?

After a few days or weeks, you will find that your type your password much faster than just about any other sequence of letters, simply out of repeated usage. Whether the password "makes sense" in some language or not will not matter for that.

Apart from delays between keystrokes, which can be due to many factors such as the "unnaturalness" of the character sequence but also the involved movements and hand flexibility, each key is likely to emit a slightly distinctive sound. It can be done easily with a human ear for the space bar, but with some recording and computer-aided analysis you can get a lot more information. Recording is easy because any smartphone can do it (and waving around your smartphone no longer constitutes suspicious behaviour, so an attacker can get away with a lot of sneaky recording).

There is some heavy research on that subject. Some googling reveals this article, and also this PhD thesis, and this blog post, and even a previous question on security.SE.

Executive summary: audio analysis of keystrokes works. However, there does not seem to be ready-to-download software for that (for now !), although the various researchers who work on the subject do have code.


How do I get a third-party-signed ssl client certificate? I've been given a requirement of providing a client certificate to authenticate between two application's web services. The other application (that I don't host) is requiring an SSL client certificate that is signed by a 3rd party CA (ie. Symantic, RapidSSL, etc.) and not be self-signed. After going through most of the CA's websites and Googling around, I can't seem to find a proper answer on how to get a signed client cert.

Is there something I'm missing in CSR documentation that'll allow me to generate a client certificate? I've seen a few of the bigger CA's offering "managed PKI" services which are about the only mention of signed client certificates that I can find, however, those seem like they might be terribly expensive services for what I'm trying to get.

Thanks in advance for the help.

Unfortunately, the only way to get a CA client certificate is by using the managed PKI solutions you have mentioned.  As I have mentioned in my comment StartCom StartSSL Corporate may be the cheapest at around $2/certificate but says its for 1,000 certificates you have to contact them for an exact price.

Another solution that may be possible (depending on your requirements) would be to use OpenID with StartSSL Open Identity.  In this instance your users would just have to sign up with StartSSL and could login with their certificate.  Of course, you would not have as much control this way as the certificate would not be revokable by you and such, but you may be able to add aditional code to your application to handle the shortcomings of this solution.

The last option would be to roll your own Certificate Authority (which could be easy if you only need it for authentication).  The only downside is it sounds like this is not allowed by the other application.   You could use OpenSSL to achieve this.


Is bugged CPU mean "gameover" for whole Computer? I'm looking for answer on such question.

Imagine that CPU bugged on the factory simply like Blue Pill, but for the network's interconnections.

How exactly firewall of OS could protect station against Hardware Trojan Horse intercommunication?

E.g. iptables blocks any new incoming packet.
iptables -A INPUT -p tcp -m state --state NEW -s 0.0.0.0/0 -j DROP

Ethernet packet with message A switch CPU into the remote controllable mode. Such way that any next message X with secret prefix would be accepted like a control command on the low level language(Assembler).

Are low level incoming packet goes through the whole of circuit to the CPU for the decision DROP/ACCEPT?

E.g. Internet -> Ethernet(PCI) -> North Bridge(Chip) -> CPU

Will CPU read the whole packet, before mark it as NEW and DROP it?

I mean message A would fill the registers of the CPU and switch it into the malicious mode.

HTH in my scenario injected into the CPU like this one.

Edit. I'm trying to clarify. Is there anything that OS can make with malicious control packet(Ethernet) on Bugged CPU?

Your question is not very clear.

If you mean that the main CPU includes some backdoor for eavesdropping, then in principle, all bets are lost. No matter what protections the operating system might include, the CPU could simply not execute them (but pretend to). In practice, if such a backdoor was identified, there might be a way to work around it, because the CPU is set in stone and cannot evolve whereas software can be designed with the CPU backdoor in mind.

If you mean that the processor of the Ethernet controller contains a spy, then the spy sees all incoming packets. It's no use dropping the packets in the OS since the Ethernet controller sees the packets before the main CPU — its job is to send them to the main CPU. The spy would not be able to decode encrypted communications since these are decrypted by the CPU.

However, malware in an Ethernet controller could do more interesting things than just listen to network traffic. The Ethernet controller generally has access to internal buses such as PCI which allows it to transfer data to and from memory, so on most architectures it could read the RAM of the computer.

There have been buggy Ethernet controllers in the wild. For example, there have been incorrect implementations of Wake-on-LAN. In this particular instance, a machine was vulnerable only when it was plugged into the network but turned off. An attacker would typically have needed to be on the local network since most firewalls filter these packets.


Corporate Domain-Joined PC Used in China What would be the disadvantages of allowing a user to travel to China (business trip) using a domain-joined corporate Windows PC as opposed to a non-domain-joined PC?

It's hard to find any reason why it would be advantageous to sending someone with a non-domain joined PC as opposed to a domain joined PC.

Domain joining a PC has several distinct advantages

Administrator can control update policies to software and anti-virus
Administrators can control firewall settings and VPN tunnels / routing
Policies of all sorts can be forced upon the machine easily and centrally administered (admittedly this can be done with some MDM's)
Full Disk Encryption can be enforced on the PC

I'm not sure why you would think there is any security disadvantage to this machine being domain joined.

SIDE NOTE : Simply working on the Internet in China poses no additional threat to your system than anywhere else in the world. I'm not sure why people have the misconception that as soon as your laptop hits the Internet in China it will be infected with MalWare. Keep your PC locked, don't hand it over to anyone without witnessing what they're doing to it and pay attention to certificate errors and you (or your employee) should be fine.


Is it reasonable to prevent timing attacks by using fixed processing time I have systems that perform cryptographic operations within a SSL/TLS tunnel.  My concern is that I may leak timing information when encrypting, decrypting, or hashing.

Part 1

Is it a good idea to have a fixed processing time (or increment thereof) when performing these crypto operations?
What operations should this apply to (encrypt/decrypt or hashing)?
Are some operations not sensitive to leaking timing information? (decrypt a file, hash a password, using PGP, RSA, AES,  etc)

For example:

When encrypting user supplied data to a private key, the total operation will always take 2 seconds
When decrypting a file, the thread will not return until the total time has reached some multiple of 0.5 seconds

Part 2

If using the "multiple of" approach, what is a good value for the multiple?  0.5, 0.005 seconds?

Fixed processing time is the most basic and thorough method to defend against timing attacks: to avoid exploitation of the data you leak through timing, well, do not leak. However, it is easier said than done. The recent "Lucky Thirteen" shows that it is possible to detect timing differences with a microsecond accuracy when the target is "close" to the attacker (on the same LAN); the attack details exploit the small leak which remained in SSL implementations which were patched with regards to timing attacks -- these implementations were computing the MAC even when the decryption did not yield a proper padding, precisely so as to get a processing time which was as fixed as could be achieved; but a one-microsecond variability was hard to avoid.

If you enforce a fixed "overall" processing time (e.g. 1 second for each request) then you will run into trouble with multi-tasking operating systems. If the implementation is just a sleep() call after the main processing, then the CPU is free to handle other requests, which looks good... but leaks data, since the attacker could send other requests simultaneously and work out whether your server is busy or not. Generally speaking, by sending a lot of requests to your server, the attacker can make processing time for each request arbitrarily long, and exceed any fixed limit. If you just constrain the processing time to be an integral multiple of a fixed granularity (e.g. processing time is always n times 0.1 second, with n being an integer) then you just have "thresholds" which make the task a bit harder for the attacker, but not impossible -- and it could even help the attacker. Indeed, the "Lucky Thirteen" attack shows how the exploit of such a threshold (corresponding to the way SHA-1 and SHA-256 process data by 64-byte blocks) just needs some "phasing" and makes the statistical picture clearer.

Right now, the best defense seems to be the addition of a random delay of a few milliseconds, which will blur the picture and prevent analysis... and, also, don't let the attacker plug in the same LAN as the server. Which should go without saying.


Does the HeartBleed vulnerability affect Apache Tomcat servers using Tomcat Native? Are Apache Tomcat servers using Tomcat Native & APR vulnerable to the HeartBleed OpenSSL bug, or does this layer insulate them?
http://tomcat.apache.org/native-doc/

HeartBleed OpenSSL bug information: http://heartbleed.com/

On my Apache Tomcat server, I have:

A vulnerable version of OpenSSL
Built and installed APR
Built and installed Tomcat Native using --with-apr and --with-ssl
Tomcat is handling requests directly. A Connector on port 443 is configured with attributes SSLEnabled, SSLProtocol, SSLCipherSuite, SSLCertificateFile, SSLCertificateKeyFile, SSLCertificateChainFile

SSLProtocol="-ALL +SSLv3 +TLSv1"
SSLCipherSuite="ALL:!aNULL:!eNULL:!ADH:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXPORT"

Questions:

Do versions of Tomcat, APR, or Tomcat Native have any affect on vulnerability?
Do SSLProtocol or SSLCipherSuite values affect vulnerability?

According to the document you linked to, the APR connector

  Uses OpenSSL for TLS/SSL capabilities (if supported by linked APR library)

Therefore, it would be reasonable to assume that the Tomcat Native Library would be vulnerable to the Heartbleed bug.  However, the conditions are different, because Tomcat is written in Java, and Java has its own allocation system (the famous garbage collector) which obtains memory from the OS by huge blocks, quite apart from the zones where OpenSSL obtains its blocks.

Thus, the heartbleed buffer overrun is unlikely to reveal any secret information which exists as Java-based object. It may, however, obtain information which is allocated from the same heap as where OpenSSL obtains its own buffers. In particular, it is possible that the vulnerability may reveal part or all of the private key used by OpenSSL itself.


Can ssh keyfile security be broken in a few hours if the file is exposed? At this link there is a claim that if an RSA key has a strong passphrase security might be broken in a few hours if an attacker has the private key.

Is there something weak about the security of RSA keys that makes this possible?  It would seem that strong passwords cannot be broken within a few hours so why is it that RSA keys can be broken in a few hours given the private key?

Just for the purpose of a comparison, a strong passphrase might reasonably be upper and lower case and digits and 15 characters, so a space of almost 8*10^26 and an unreasonably fast computer might try 10^9 guesses per second and if you have a cluster of them 10^12 per second.  It would take 8*10^14 seconds or 25 million years to try them all.

No, your SSH key can't be broken in a few hours if you choose a strong passphrase.  I read the web page you quoted, and it is just bad writing that leaves a mistaken impression.  The statement there is inartfully phrased.  The website claims:

  An SSH key passphrase is a secondary form of security that gives you a little time when your keys are stolen. If your RSA key has a strong passphrase, it might take your attacker a few hours to guess by brute force. That extra time should be enough to log in to any computers you have an account on, delete your old key from the .ssh/authorized_keys file, and add a new key.

That's phrased in a pretty confusing way.  I suspect what they mean to say is that a good passphrase will take at least several hours to crack.  In fact, a strong passphrase will take a lot longer than that to crack; probably days or years, or longer, depending upon how strong your passphrase is.

Because of poor phrasing, this web page might leave the impression that even if you choose a strong passphrase, an attacker could still recover your SSH key in at most a few hours.  That is not correct.  If you have a strong passphrase, it will take a long time for an attacker to recover your SSH private key.

Someone with permission to edit the web page should fix it to correct the confusing phrasing.


Security risks of running a php application on PHP 5.4 I'm a senior developer maintaining a FinTech SAAS web application. The web application is currently running on Fat Free Framework on PHP 5.4 on a LAMP stack. I've been instructed that it has not been upgraded because upgrading to 5.6 would cause issues with our authentication plugin (BCRYPT).

I am aware that PHP 5.4 reached its EOL on 3 Sep 2015 which included ending security support. Similarly, I am aware that PHP 5.6 will reach its EOL Dec 2018 and will lose its security support as well. We have also recently completed a web application security audit with a 3rd party contractor. Oddly enough this information regarding the PHP versions was not included in the draft report --which I was expecting to see. I intend to bring this up with them following presidents' day.

To be clear. I have raised the 5.6 EOL to my CTO, but have not raised the 5.4 EOL issue yet (more on that later). Originally I was not aware of it until I expressly checked it following its omission in the draft report. I have recommended we upgrade out of PHP 5.x because of the security risk involved; however, my CTO has rejected this thrice: ostensibly because it'd take to long and/or prioritizing new features promised to clients.

I intend to bring this up a 4th and final time, but wish to do so armed with tangible information on the risks involved. The answers to my question below will be included as well as points raised when I discuss this with my security auditor.

So with respect to risk management what are the distinct risks of continuing to support this application with PHP 5.4 and/or PHP 5.6?

Note: I am well aware that this is a security risk, but I don't know specifically why. I am developer not a security specialist. As such, I would greatly appreciate detailed answers . Inclusion of known unpatched exploits that affect FFF or PHP 5.4 would also be appreciated. If there's a website that supplies such information even better.

Rule one: cover your ass: make sure you've got an offsite record of you reporting a security risk to your CTO and their response.

Beyond that, if their is a risk that the upgrade will break authentication, then the first step is to characterize that risk. I am aware of changes in the blowfish implementation of crypt in 5.3.7 - but those are backwardly compatible and you're currently on 5.4

The most important thing you can to do to ensure the Security of your applications is to keep your patches up to date. In 2015 and 2016 US-CERT advised that 85% of compromises were preventable (by applying patches). The Equifax compromise of 2017 was a result of unpatched software on a web facing application. You don't have to look far to find more examples.

Listing the current vulnerabilities in your stack does not really help with the problem - you should have processes in place to keep your software up to date. You don't need to enumerate the currently known vulnerabilities.

It is reasonable to make a decision not to patch if the organization can prove that the resulting losses would be significantly less than the cost of updating. But has that analysis actually been done?

While you could choose to go around your CTO to the owner/stakeholder, unless this a publicly listed company, they are unlikely to understand your concerns or favour your version of events over that of the CTO. Any competent organization should maintain a risk register - you should document your understanding of the current situation, the danger of being in a situation where you cannot easily upgrade and request that this is added to the corporate risk register.


Is it safe to have a TrueCrypt container file synced with DropBox? I'm planning to store my sensitive files to the cloud. I don't trust the already-made end-to-end encrypted file storage.
I only trust TrueCrypt. Assuming that TrueCrypt itself is safe, would it be secure to use DropBox to synchronize in realtime the container file. In this case DropBox will have any small change to this file in their hands. Would this affect the security?

NO, it is not safe. Truecrypt uses the XTS block mode for encryption, which has severe problems when your adversary is able to see snapshots over time of how the data changes. In fact, an article called You Don't Want XTS, intended for software developers to learn when they can and can't use XTS, specifically uses Dropbox as an example of when NOT to use XTS. It would not be the end of the world, resulting in your password being disclosed or something, but it does bring out the worst in XTS.

To quote the article:

  Again: XTS works like ECB. It’s deterministic. If you’re looking for the penguins, they’re there, but you have to look for them across time instead of space: successive writes to the same sector-block location will repeat, but encryptions of the same plaintext at different locations will be randomized.

This means that hosting it on Dropbox which will see changes over time will "see the penguins". This also makes it extremely easy to tamper with data in predictable ways. While XTS does not have the same crypto malleability issues as, say, CBC or CTR, it still has some, giving them much greater capabilities than any other attacker:

  But whatever margin of safety XTS gets you on physical media probably goes out the window when you stick a Truecrypt volume on Dropbox. From the vantage point of Dropbox, attackers have far more capabilities than the XTS designers planned for.

If you need to host encrypted data on a remote server, you may want to look into duplicity, which in fact supports Dropbox natively. It provides client-side encryption, is very fast, uses incremental, revisioned backups, and signs all transfers. This makes it so that, not only is tampering impossible, but any change to data on the server is in the form of data being added, with the exception of clean-up operations. It's a very useful tool for syncing with remote servers.

I am disappointed that there are already two answers claiming that this is just fine, with no background in cryptography, assuming that because Truecrypt provides confidentiality, it should be completely fine to sync Truecrypt to. They are giving dangerously incorrect advice.


Why include the host in the signature of the Amazon HMAC scheme? The Amazon's HMAC schemes includes the hash of the canonical request in the string to sign in order to create the signature, and the canonical request in turn includes the host. What is the security implication of not including the host in this scheme?

In general, you use an HMAC to ensure that a value isn't changed (ie: it doesn't lose integrity). So including the URL in the HMAC means that Amazon doesn't want to allow it to be changed once the HMAC is created.

In this case, including the URL ensures that a request targeted for one URL but somehow sent to another can be detected because the recipient's recalculation of the HMAC will use the actual URL, not the original URL, and the HMACs won't match.

This check will be in addition to whatever security is provided by encrypted communications (eg: SSL).


Should you encrypt plaintext secrets that will only ever live on your own computer? I stumbled upon https://github.com/pda/aws-keychain.

  The aim of aws-keychain is to run commands that require AWS credentials without ever storing those credentials unencrypted on disk. Mac OS X's keychain is used for storage, and credentials are passed to commands via the well known environment variables that all tools look for.

I thought it was pretty cool, but it made me wonder if the trouble was worth it. The only way someone would ever have access to those keys would be if they gained physical access to your computer, and at that point, you're screwed to the point where it'd be safer to invalidate those keys anyways.

It's not that I think it's a bad idea, but it seems like a marginal security improvement at best. Am I missing something?

That depends, as always, on your threat model.

A malicious application running as your unprivileged user will be able to read your stored AWS credentials and either use them directly or ship them off to a remote server. If you're not particularly concerned with that (eg you carefully vet all the software you run), then feel free to ignore that.


Detection of Substitution attack on Block Cipher ECB mode This is from Christoff Paar's book on Cryptography

Let’s assume a protocol for wire transfers between banks (Fig. 5.2). There are five
fields which specify a transfer: the sending bank’s ID and account number, the receiving bank’s ID and account number, and the amount. We assume now (and this
is a major simplification) that each of the fields has exactly the size of the block
cipher width, e.g., 16 bytes in the case of AES. Furthermore, the encryption key between the two banks does not change too frequently. Due to the nature of the ECB,
an attacker can exploit the deterministic nature of this mode of operation by simple
substitution of the blocks. The attack details are as follows:

The attacker, Oscar, opens one account at bank A and one at bank B.
Oscar taps the encrypted line of the banking communication network.
He sends $1.00 transfers from his account at bank A to his account at bank B
repeatedly. He observes the ciphertexts going through the communication network. Even though he cannot decipher the random-looking ciphertext blocks, he
can check for ciphertext blocks that repeat. After a while he can recognize the
five blocks of his own transfer. He now stores blocks 1, 3 and 4 of these transfers.
These are the encrypted versions of the ID numbers of both banks as well as the
encrypted version of his account at bank B.
Recall that the two banks do not change the key too frequently. This means that
the same key is used for several other transfers between bank A and B. By comparing blocks 1 and 3 of all subsequent messages with the ones he has stored,
Oscar recognizes all transfers that are made from some account at bank A to
some account at bank B. He now simply replaces block 4 — which contains the
receiving account number — with the block 4 that he stored before. This block
contains Oscar’s account number in encrypted form. As a consequence, all transfers from some account of bank A to some account of bank B are redirected to
go into Oscar’s B account! Note that bank B now has means of detecting that the
block 4 has been replaced in some of the transfers it receives.
Withdraw money from bank B quickly and fly to a country that has a relaxed
attitude about the extradition of white-collar criminals.

I don't understand the part which I have bolded. How does bank B have a means of detecting that block 4 has been replaced?

This isn't a question of cryptography, but of auditing.  Bank A and Bank B both keep records of the transactions they've performed.  Eventually, they're going to compare notes and realize that the two sets of records don't match.  Specifically, Bank B has a collection of transactions that transfer money into Oscar's account without counterpart transactions on Bank A's side, while Bank A has a collection of transactions that transfer money into non-Oscar accounts at Bank B without counterpart transactions on Bank B's side.  Since the dollar amounts of the mismatched transactions are identical, that's strongly suggestive of Oscar tampering with the transfer stream.


Decoding requests from potentially malicious Android app I have recently been doing some security evaluation work on our Android applications, by proxying all the communication through Burp Suite.

I noticed one of our devices was sending requests to a domain I did not recognise, one that is registered in China. It turns out the application sending these requests is a file manager app that came pre-installed on the device (cheap Chinese tablet).

It mostly seems to send requests when the application is in use, though occasionally appears to send requests in the background too. The app doesn't display adds or related content so it isn't that, also when it does load content such as help, it comes from a different domain. My suspicion is it is posting some sort of tracking or snooping data.

I am obviously concerned and curious as to what data this application is sending but I am struggling to work out the payloads. The headers do not indicate a content type, I have used all of the decoders in Burp Suite to no avail. Firstly I considered binary and gzip but I end up with the same data, I've also attempted to convert the data to Chinese with zero success.

If anyone can shed any light on my next steps to decoding this request content, that would be much appreciated.

Here's the request / response screenshots

Initial request -

Changed encoding to form:

Run through the decoder:

The response is always the same

Yes, this is malware. Or 'Spyware', depending on which book on the subject you last read and which side of the bed you got out of this-morning.
Your question piqued my interest when i saw that i've actually seen the same domain while looking at another app myself. I thought it seemed unlikely we were alone, so i google'd it and found this:

The Airbnb Android App contains Spyware.

Based on this post we can assume that the suspect-at-best code now uses a secret key to encrypt data rather than gzip it.

I think its most likely that this is code that has made its way into some popular library/framework for the purposes of gathering statistical information about users/devices, or that it's part of another ad-platform library. Regardless, the term 'spyware' still fits. This data harvesting is clearly going far beyond what the app has a legitimate purpose for, and neither the Android or iOS ecosystems are particularly friendly to this sort of thing.

The subdomain even has a pretty big malware ring to it. 'infoc2'... as in C2... as in Command and Control.

I recommend emailing the company behind the app, they might not know what is going on here and they might thank you. If it was legitimately added, you might scare them into removing it. And if you don't get a response at all i would report the developers to Android/Google.

I you are still keen to get the plaintext of the payload, i would suggest decompiling the app and looking at its strings, you might get lucky and find the key. Without knowing the encryption scheme you would have to loop over a bunch of them in a script and just brute-force it.
However, my hunch would be that the developers of this have probably rolled their own basic crypto, in which case you would need to reverse engineer this function from the binary or attempt to force the app to bypass it with dynamic runtime modifications so that requests contained plaintext (look at a framework called 'Substrate' for this).


Any browser that supports script-nonce? I was trying to include script-nonce on my html file, but seems like none of the current browsers support it.

Is anyone aware of any version of any browser that supports this functionality?
I'm currently using Chrome version Version 26.0.1410.63 and have tried version 28 as well, but it doesn't seem to be working

A sample html file with script nonce can be found here

All I see is the error on javascript console, which hints towards the browser not supporting script-nonce yet:

Unrecognized Content-Security-Policy directive 'script-nonce'

It works on Chrome too, but so far (Version 26.0.1410.64 m) only with the temporary X-Content-Security-Policy instead of Content-Security-Policy header, as defined in the already updated code samples. W3C Web Application Security working group just moved the Content Security Policy 1.1 from previous working group draft to a W3C Editor's Draft status today, on 28th of April 2013. What are the chances of that, huh?

I guess Google Code jumped the gun with already updated code samples a few days too soon, and I expect the next Chrome update to change this accordingly.

Anyway, the solution was hiding in the fineprint of the Google's cached copy of previous draft version of CSP 1.1:

  This document describes a proposal that has been discussed by the
  broader community for about two years. There are experimental
  implementations in Firefox and Chrome, using the header names
  X-Content-Security-Policy and X-WebKit-CSP respectively. Internet
  Explorer 10 Platform Preview also contains a partial implementation,
  using the header name X-Content-Security-Policy.

If we check Google Code samples again, the difference in these header values becomes glaringly obvious:

<meta http-equiv="Content-Security-Policy" content="script-nonce noncynonce;">

So it looks that all you have to do (for the time being, until Chrome updates to reflect the status change of the CSP 1.1 proposal) is, to change the header name back to X-Content-Security-Policy.

I've also tested these samples on latest Firefox and Opera browsers, and they already accepted Content-Security-Policy and didn't complain with console errors.


Can Ed25519 be used to mitigate MITM attack on WebRTC with an untrusted signaling channel? Based on this question, I've discovered that the signaling channel for WebRTC must be trusted in order to prevent MITM attacks. This is unfortunate for a P2P use-cases where the signaling channel is some 3rd party device.

One idea I had is to encrypt and authenticate the WebRTC signaling with libsodium box algorithm. This assumes that both peers know each other's public keys.

Would this solve the MITM issue?

Just to add some additional clarification because I frankly don't really know what I'm doing:

I'm using simple-peer which has a simple API for signaling the WebRTC connection. I can create a public pub/sub channel easily using for example signalhub.

Now suppose each peer subscribed to their public key on signalhub. When peerA wants to connect with peerB, peerA uses peerB's public key, boxes the signal from simple-peer with libsodium, and broadcasts the message on signalhub to peerB's public key channel. When peerB receives this signaling message, it can decrypt and authenticate that the message was sent from peerA.

This intuitively feels secure to me. A MITM could attempt to signal to peerB, but wouldn't be able to authenticate as peerA. Also the MITM couldn't decrypt the signal from peerA so they couldn't respond pretending to be peerB either.

As I understand it, once the signaling is complete and the WebRTC connection is established, the P2P channel is end-to-end encrypted so at this point we should be secure.

One idea I had is to encrypt the signals with Ed25519. Would this solve the MITM issue?

First, Ed25519 is no encryption, it is a signature algorithm. And no, switching one signature algorithm with another does not magically protect against MITM. The relevant question in the context of MITM attacks is instead who is doing the signature and if this party can be trusted. This question is independent from the actual signature algorithm or encryption algorithm.

After the question was edited:

  One idea I had is to encrypt the signals with libsodium box/seal. Would this solve the MITM issue?

Again, the choice of encryption or signature algorithm are not relevant against MITM in this context. What matters instead is authentication which essentially boils down which identities can be trusted in the first place and how an identity can be verified.


Has the security of PuTTY been examined? I am wondering how PuTTY stacks up against other SSH implementations with respect to scrutiny and security of its SSH2 protocol implementation.

PuTTY is probably the most-used SSH client on the Windows platform, so its importance cannot be understated.

I am aware that there have been several very crafty attacks in past years against SSL/TLS implementations (and, also, against the protocols themselves, but that is another issue).

In that light, I wonder if anyone has done work to validate/break SSH clients on the Windows platform and whether PuTTY fares well.

Putty being open-source, there have been a number of informal security audits, some resulting in vulnerability reports and patches.

There may have also been some formal security audits commissioned by users of the product. Some searching revealed a bit of unverifiable evidence of such, but most importantly:

Simon doesn't advertise or reference any official audit of his code. Any audits done were done by a private party, for a private party, and may not have been scoped in such a way as to be applicable to your circumstances.


Clickjacking: can't browsers just forbid/reject placing transparent elements over frames? Why not? Seems like this is only used for clickjacking, the solution should be simple enough.

Banning opacity on elements containing an iframe would have negative impact of user interfaces (eg no nice fade effects when iframes are in play), but would not block clickjacking attacks.

Even if transparent iframes were impossible, you could still achieve all the same attacks by using a 1x1 pixel iframe that followed the pointer. Positioning inside that pixel can be achieved by scrolling a doubly-nested iframe. The potential one pixel difference underneath the pointer at rest would almost certainly be undetectable to the user.

So, yes, a browser could block it and temporarily be protected against a common form of attack. But as soon as a significant number of users have browsers that do that, the attacker will just change implementation technique. This is an example of a ‘fix’ that only works by making someone else the low-hanging-fruit; once everyone starts doing it, it is no solution at all. Consequently it makes sense to implement for a browser extension that not many people use, but no sense for a popular browser.


Does a domain name ever leave my local system if the matching IP is defined in my hosts file? Given the domain website.org and an a corresponding webserver with the IP 1.2.3.4.

If a client defines the IP with the domain name in its host file like:

$ cat /etc/hosts
[...]
1.2.3.4    website.org

Does the client ever send the actual domain name in a request, when accessing the website, or does it exclusively use the IP address?

Does the client ever send the actual domain name in a request, when accessing the website, or does it exclusively use the IP address?

The hostname is included in the HTTP request (HTTP is the protocol spoken when accessing a web site). E.g. access to http://www.example.org/foo results in:

 GET /foo HTTP/1.1
 Host: www.example.org

Additionally the hostname is send in plain inside the TLS ClientHello when accessing a site with HTTPS (only with SNI but that's what all modern browsers do).


BitLocker : Update Volume Master Key and meaning of "keyed" vs "re-keyed" Note: Below are some information from searching around the Internet. To skip to my main question, go to the last line of this post.

I've been searching around on how to change the Volume Master Key (VMK) in BitLocker. Thus far, I have not been able to find any information on how to do so. The closest we can get is from the BitLocker Drive Encryption Technical Overview with the following passage.

  When BitLocker is re-enabled, the unencrypted key is removed from the
  disk and BitLocker protection is turned back on. Additionally, the
  volume master key is keyed and encrypted again.

Does this mean that the VMK is regenerated? The confusion here is the use of the word "keyed" instead of "rekeyed". More specifically, we can find that in the same page, we also have the following passage.

  the addition of the volume master key allows the system to be re-keyed
  easily when keys upstream in the trust chain are lost or compromised.

The intentional use of the word "re-keyed" and "keyed" gives the impression that they have different meaning, which led to my confusion. With this information in mind, my question is as follows.

How does one go about changing the Volume Master Key (VMK)?

The diagram in the page you linked demonstrates the functionality quite well. The idea is that the authentication mechanisms are all capable of decrypting the Volume Master Key (VMK), which then in turn can unlock the Full Volume Encryption Key (FVEK).

The idea behind this is that, if any of the individual authentication parts are compromised, the VMK can be changed without having the re-encrypt all of the data on the disk. Essentially, you can just change the VMK and re-encrypt the FVEK with it.

BitLocker itself does not provide any functionality to change the FVEK, as it would require decrypting and re-encrypting the entire volume. The only way to re-key appears to be to fully decrypt the volume and re-encrypt it.

Changing the VMK, however, is certainly possible. When BitLocker is put into disabled mode, the VMK is encrypted with a randomly generated surrogate key, which is stored in cleartext on the disk during this time. As the VMK is essentially not protected during this time, BitLocker automatically generates a new VMK after it is enabled again.


Should I block IP adresses that made attacks attempts and were block from an IPS through the rules? We have an NIPS blocking attacks based on bad behaviors (rules checking the data in the network packets). Should I block the IP that the NIPS linked to attack attempts? It feels like the NIPS is already blocking the attack.

At the same time, what is the risk of an IP being reused multiple times with different attacks? (and the possibility that one of these attacks from the same IP isn't known to the NIPS)

I'm mostly talking about incoming traffic from outside.

Yes, you should.

But you should also ask yourself for how long you will block any address which got onto your blacklist. Reasonable values might range from minutes to weeks, depending indeed on the subject of availability as mentioned on the comment by @Philipp.

Of course, by blocking an IP you run the risk of blocking an otherwise legitimate user. But at the same time, you need to make sure you keep your service and up for all other users as well.

If you are just ignoring IPs which your NIPS detects, you could switch if off as well.


Why would a password requirement prohibit a number in the last character? In configuring a new system today (Juniper Space, Linux-based Network Management platform), I came across a bizarre password requirement that I'm curious about.  Upon logging into the web UI with the default credentials, I was prompted to change the password, which is good, and I went to do, but my randomly generated password was rejected because the last character was a number.  This struck me as all the more strange, given that the password I provided for the command line interface ended in a number, and it was accepted.

In my experience, password requirements like this generally have some underlying reasoning behind them, like Q and Z not being present on old telephone keypads, or legacy systems compatibility or just plain poor systems/policies/whatever. I'm having a much more difficult time explaining this particular policy with any of those explanations, though.

Does anyone have any insight into the reasoning behind a password policy that would prohibit a numeric last character?

It's likely an effort to discourage passwords that fit common formats or character masks.  If a password policy requires use of a number many people will chose to put their number at the end of a word or words.  Here are a couple examples from corporate environments:

NetSPI Top Password Masks for 2015
2015 Trustwave Global Security Report - password masks

Attackers like this user habit because it makes their hybrid password cracking or guessing attacks easier.  They can focus on combining word lists with numbers added to the end rather than a more time consuming brute force approach.

So some organizations implement a policy like this in an attempt to improve security by getting users to put their numbers is a less predictable place.  It sounds like in your situation they're not combining this with any other complexity checking and instead rejecting all passwords that end in a number, regardless of how random they are otherwise.  That's not a very good way to implement this type of checking, but they're not alone in taking this approach.


SMS not received and read by somebody else (no SIM swap)? A friend of mine was phished for his credit card details and driving license. Very foolish, I know. The criminals then bought bitcoin. The fact is his card is VbV. He claims not to have received any OTP message, while it was obviously sent. I checked his phone, no trace of any malware, plus he told me that he hadn't been installing any apps for a couple of months at least. None of his apps can read text messages.

How is this possible?

The fact is his card is VbV. He claims not to have received any OTP message, while it was obviously sent.

There is nothing obvious about that.

As far as I know Verified-by-Visa isn't mandated by the card alone, it also has to be supported by the Merchant where the card is used for payments.
When the Merchant doesn't  support VbV then none of the extra authentication steps that VbV supports are taken and only the basic card details (Card Holder Name - Card Number -  CVC) will be used  to process the payment.

It stands to reason that a criminal with stolen credit card details would prefer  such a Merchant to buy their bitcoin and then obviously no SMS message with an OTP would have been sent to your friend.

Merchants not supporting VbV run a greater risks of charge backs and not receiving their payment when the charges are disputed by the card holder, which will be the case when your friend disputes this charge with  his card issuer.

Also the online documentation suggest that even when a merchant does support Verified by Visa you won't be prompted for the additional verification with every transaction, but only occasionally.


Theoretical key encryption question I have a question regarding encryption and message sending.

There are 2 hosts, A and B with their own secret key kA and kB (assuming this is not PKI).

It is known that when A wants to send a message to B, they do this handshaking protocol:

A sends to B, an encrypted message in this form E(kA, m), where m is the message and kA is used to encrypt it.

B sends to A, an encryption of the previously sent message, E(kB, E(kA, m)), encrypted using kB.

A will then send to B, E(kB, m).

after that, B will just decrypt the message using kB.

My question is that how does A know B's key to encrypt the message.

What I think I know about the question:

-I believe it's some kind of mathematical property like RSA's modulus?

-I think it can also be a logarithmic function? (bring down the power, where power = key?)

-Both A and B do not know about each other's key so I think it can be something using interchangeable functions like Log(Exponential(x)) = Exponential(Log(x))?

There's no one real answer as this is just theoretical so I hope to have suggestions (or links where I can further read up) from you guys on how to go about doing this.

They will absolutely need to do a key exchange so that A knows Kb and B knows Ka. There are different methods but they are usually based in the Diffie Hellman algorithm.

For convenience I will paste here wikipedia's example:

Alice and Bob agree to use a prime number p = 23 and base g = 5.
Alice chooses a secret integer a = 6, then sends Bob A = ga mod p
    A = 56 mod 23
    A = 15,625 mod 23
    A = 8
Bob chooses a secret integer b = 15, then sends Alice B = gb mod p
    B = 515 mod 23
    B = 30,517,578,125 mod 23
    B = 19
Alice computes s = Ba mod p
    s = 196 mod 23
    s = 47,045,881 mod 23
    s = 2
Bob computes s = Ab mod p
    s = 815 mod 23
    s = 35,184,372,088,832 mod 23
    s = 2
Alice and Bob now share a secret (the number 2) because 6 × 15 is the same as 15 × 6.

You will find several answers discussing this algorithm.


Challenge Response Login Authentication with Password Salt I want to implement a challenge-response login authentication for my web application.

My understanding is that the server has to send back the password salt for the user so that the user can calculate the password hash on the client side and then send it back to the server to compare and check if the user is authenticated or not.

I know this type of authentication is vulnerable to dictionary attacks because the attacker can see the password salt in plain text and brute force attack the server with that password salt.

As always, layers of security is best so I would also add SSL to the equation so the attacker would have to break SSL as well as brute force the password with the salt.

Is there ways I can improve upon this, I have look into SRP (Secure Remote Password) but it seems really complex whereas challenge-response can provide just as much benefit.

If you are using SSL why would you send a salt at all? All you need to is allow the user the send username and password and you can calculate H(message + salt) server side. There is no point of sending the salt to the user. Just make sure you use a proper hashing algorithm like PBKDF2, bcrypt or scrypt.

Also if you have broken SSL it would not matter if you send the password or the hash as you could easily just intercept the hash and perform a repetition attack. Unless of course the challenge would change with every single authentication request which would require you to store the password in decryptable or plain text format. Which may be a security risk on its own, furthermore it would be susceptible to a bucket brigade man in the middle attack.

Stick to good secure schemes, username + password across ssl is secure, don't try rolling your own.


Why is Symantec/Verisign CA appearing as an invalid authority? Typical browsing to www.BankOfAmerica.com got me an ERR_CERT_AUTHORITY_INVALID error. This was with an up-to-date production version of Google Chrome for Mac.
I tried with Safari, and got the same result.
The certificate is good until 2016, so it doesn't appear to be an expiration issue.
It appears that the authority Symantec Class 3 EV SSL CA - G3 is deemed invalid. Trying to browse to twitter.com as well as https://my.symantec.com, brings up the same warning.  HTTPS connections to other sites (with GeoTrust, Google and other CAs) work fine.
OTOH, running an SSL checker tool (at sslshopper.com) shows that everything is in order.

Can you reproduce the above behavior? Do you get SSL warnings in your browser(s) at sites like bankofamerica.com and twitter?

Can you explain what is happening?

As for my level of expertise, note that I'm not a dev but an end-user.

Update:
- Mac OS X browsers get the trusted root CAs from the OS, and this started right after I installed an Apple security update. So confirming the behavior would likely require OS X 10.8.5 with latest security patches.

The mistrust starts with the root CA, "VeriSign Class 3 Public Primary Certification Authority - G5". I can see that a CA with this exact name appears in the OS (Mac's "Keychain" database) as a valid and trusted cert, but its serial number (and therefore SHA-1 and MD5 fingerprints) are completely different form what the browsers see.
I wonder, therefore, if Apple's latest security patch broke a good chunk of the web. Ironically, it also broke Apple's OS Software Update because they also rely on VeriSign. I'll sniff around the Apple forums, too.
It's worth noting that Chrome says both "the certificate is not trusted" and "your connection is encrypted with obsolete cryptography".
This isn't what I was planning to do on Sunday morning... but AFAIK the easiest way to break SSL/TLS is for me as a user to say "eh, I'll just add this CA". When it has to do with my bank and a third of the web, I proceed with caution.

Solved.
The problem was indeed triggered by installing Apple Mavericks/ML Security Update 2015-004. As mentioned in this Apple release note, it included updates to the certificate trust policy. There was a duplicate certificate installed (with a wrong serial no.), removing it fixed the problem.

The serial number for the cert as published by Apple matched what was installed in the System cert repository, but there was a "VeriSign Class 3 Public Primary Certification Authority - G5" in the "Login" repository. Once I deleted it, everything got back to normal.

There is still some mystery as to why the certificate appeared in the Login repository in the first place, especially since as I just found out, several other people experienced the same exact problem:
https://discussions.apple.com/thread/6984765
https://apple.stackexchange.com/questions/180570/invalid-certificate-after-security-update-2015-004-in-mavericks


How to investigate potential infected client workstation In this case a central endpoint security or SIEM solution alerts on Indicators of Compromise on one client workstation in a Windows domain.
Should there be an IT staff who has admin accounts (domain accounts) on these workstations?

Admin logs with domain account in per RDP with NTLM-Authentication (interactive logon type):
Dangerous because the credentials are stored in LSASS Memory and are dumpable as ntlm hash from a dump with tools like famous mimikatz, WCE, ...(?)

Admin logs with a domain account using SMB, WMI, WinRM (network logon) (also NTLM-auth, no Kerberos):
Is this safe? Microsoft documentation says that there a no credential cached with a network login. An access token is created but with these, if you use token impersonation techniques, you cannot authenticate remotely to another host on network. But the potential attacker on workstation can replay the netntlmv2 hash? So doing a relay attack with tools like inveight, responder, ...

If Admins are part of "Protected User Group", there are only enabled to authenticate with kerberos isn't it? So it would be safe to use RDP AND/OR smb, wmi, etc?

What is the best practice here?
Every time use the LAPS Account for investigation?

First, why are you suggesting NTLM everywhere? That alone is unsafe. Stick to Kerberos in a domain environment.
Option 1 is unsafe. Regardless of what NLA does for NTLM or Kerberos, it will fire the credential in plaintext to the remote machine and the compromised host will have the raw creds.
Option 2 is better as it doesn't leave any credentials on the machine. It does limit what you can do on the machine, so the utility of this option is "ehhh".
Option 3 does not protect you in RDP scenarios. You still fire the raw credential to the remote machine and the compromised host can do whatever they want with it.
What you should do is use Restricted Admin or Remote Credential Guard. For either of these you need to enable this registry value on the target machines:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa
DisableRestrictedAdmin DWORD = 0

Restricted Admin authenticates you to the remote machine but doesn't fire the raw credentials over. Once you've authenticated it switches to using the target machine account for outbound authentication. The side effect is any outbound access to network shares and is as the machine itself and not as the user. To connect to the remote machine you call the RDP app from the command line:
mstsc /restrictedAdmin

Remote Credential Guard is similar, but it allows you to act as yourself by instead proxying any ticket requests that normally require the credential back to the client itself. This means any outbound requests will operate as your user instead of the machine.
mstsc /remoteGuard


SQL Injection with pass MD5 I want to know, if in my login form there is any SQL injection possible. If there is, what could the exploit's web form entry look like?
I send username and password by html form (POST).
The login function code is:

$username = $_POST['user'];
$password = $_POST['pwd'];
$password = md5(password);

$sql = "SELECT id_user, name FROM 'TAB_USER' WHERE user = '$username' AND passwd = '$password' AND enable='Y'";

$result = mysql_query($sql,$dbCon);
$check = mysql_num_rows($result);
mysql_free_result($result);

if ($check ==  '1') {
  $result = mysql_query($sql,$dbCon);
  $array = mysql_fetch_array($result);

  $id = $array['id_user'];
  $name = $array['name'];

  $_SESSION['SES_id_user']= $id;
  $_SESSION['SES_name']= $name;

  return $id;
}
else return false;

Short answer: It's damn vulnerable.

Why? You are concatenating the values given by POST which come directly from what the user typed. Therefore, it is very simple to manipulate your query. Also, you are using mysql extension which is deprecated. You should be using mysqli or PDO to create prepared statements to protect against injection.

Here's a question from Stackoverflow that explains the matter in depth and how to solve it.

On a side note, you should not be using MD5 to encrypt passwords as it is a broken algorithm. Consider using bcrypt or PBKDF2 as explained here.


Would it be HIPAA compliant to share docs with EHR data between two HIPAA compliant Gsuite organizations Assuming both organizations have HIPAA compliant G-Suite and have signed the necessary legal documents.
My gut says this should not be a problem as its done within the google servers, am I missing something?

If as you say, both entities have entered into a business associate agreement with Google they are able to use G Suite for PHI sharing. Google supports HIPAA compliance for G Suite). Provided the method of sharing information is covered by the terms of that business associate agreement, it would be acceptable to share PHI between the two entities.
Bear in mind that no software solution can be truly HIPAA-compliant as any software solution, even if a BAA is in place, can be used in a manner that is not compliant with HIPAA Rules. Both entities would therefore need to ensure that G Suite has been configured correctly and appropriate security controls have been activated, access controls have been implemented, and an audit trail must exist.

The two entities that wish to share the PHI may also need to have a business associate agreement in place before any PHI is shared. e.g. if one is a healthcare provider and the other is a vendor.


Is Passbolt secure against root access? Is the Passbolt password manager secure against root access, e.g. if I install Passbolt onto a VPS can it be considered secure or could the VPS host access the passwords stored within it?

Full disclosure: I'm one of passbolt developer.

If an attacker has root access to the server they can inject additional javascript to try to perform different type of attack. To our knowledge it is not possible to craft a JavaScript that would allow an attacker to get access to the private key of the end user and/or the passphrase. If you manage to craft this, do get in touch with us at security@passbolt.com.

That being said, it is possible for the attacker to breach the following:
- Confidentiality: the attacker can create/edit a user to trick another user into sharing the password with attacker. This could mitigated in the future using key signatures (for example the admin signing all the users keys).
- Availability: root access means obviously that all passwords can be deleted / tampered with.
- Integrity: idem.


What is attacker trying to do with my server? Some is trying to access this link (and similar ones) frequently in my site:

http://example.com/upload/RS=%5EADAJVxZ5NB.GMTgFV3EMEJX3sN22Jw-

Note that my server doesn't have an upload folder inside of it, but it allows users to upload videos. So it is redirecting the attacker to a 404 page.

So what is the attacker trying to do? And what does seeing this link mean?

This is most likely a botnet trying the "doors" as Bob has suggested. From time-to-time, vulnerabilities appear in standard software that allows attackers access via supposedly innocuous entry points.

If you don't already have it installed, I would recommend something like fail2ban which will automatically ban source IP's that make attempts to get to vulnerable ports/locations.

fail2ban can be also configured with manual checks to filter out new vulnerabilities and annoyances.