Getting rid of a large quantity of paper Say you were in charge of getting rid of a large quantity of paper - up to 1,000 in a row. It can't be used as scratch paper because it contains confidential information. It also can't be outsourced to third parties because the company isn't interested in refunding your expenses.

The scenario is real and is wasting the time of a person whose work is useful to me. The current method is tearing them all apart by hand or using a crushing machine when it's available. As mentioned, it takes a lot of time and could probably be done a thousand more efficient ways.

What is the cheapest and fastest method to destroy a large quantity of paper containing confidential information?

The worst thing you can do is tearing them apart. It's time consuming and attacker just needs extra time and patience to put pieces together.

The same rule applies for shredding - if after shredding are left too large pieces, again, attacker just needs time and patience.

There are several shredding techniques (from wikipedia)

  Strip-cut shredders, the least secure, use rotating knives to cut narrow strips as long as the original sheet of paper. Such strips can be reassembled by a determined and patient investigator or adversary, as the product (the destroyed information) of this type of shredder is the least randomized. It also creates the highest volume of waste inasmuch as the chad has the largest surface area and is not compressed.
  Cross-cut or confetti-cut shredders use two contra-rotating drums to cut rectangular, parallelogram, or diamond-shaped (or lozenge) shreds.
  Particle-cut shredders create tiny square or circular pieces.
  Cardboard shredders are designed specifically to shred corrugated material into either strips or a mesh pallet.
  Disintegrators and granulators repeatedly cut the paper at random until the particles are small enough to pass through a mesh.
  Hammermills pound the paper through a screen.
  Pierce and Tear Rotating blades pierce the paper and then tear it apart.
  Grinders A rotating shaft with cutting blades grinds the paper until it is small enough to fall through a screen.

Also, there are several standards for shredding (from wikipedia)

  Level 1 = 12 mm strips OR 11 x 40mm particles
  Level 2 = 6 mm strips OR 8 x 40mm particles
  Level 3 = 2 mm strips OR 4 x 30mm particles (Confidential)
  Level 4 = 2 x 15 mm particles (Commercially Sensitive)
  Level 5 = 0.8 x 12 mm particles (Top Secret or Classified)
  Level 6 = 0.8 x 4 mm particles (Top Secret or Classified)

What I'm trying to say is - it's not about - "Let's torn this paper and we'll be fine!" It's about how hard is to put this pieces together. If it's next to impossible, then shredding is done well.
However, if attacker is aiming for the lowest hanging fruit, then any kind of shredding is better then none.

Example of well done shredding (once it was a money)

I guess setting them on fire or destroying them in chemical reaction would be the fastest, but this techniques should only be preformed in controlled environments by professionals!!!
Alternative is to decompose paper in water, however, it's pretty long process (10-14 days) and you'll need enough space and water to do so.


Diffie Hellman Hash MITM I've seen an application recently that used the Diffie Hellman algorithm. It is not a Ephemeral Diffie-Hellman implementation, but rather a Diffie Hellman one. After the secret keys have been calculated, the client then sends a SHA-512 hash of the key to the server when the server asks for it. The only reason I can think of is, the server computes a SHA-512 hash of its secret key and requests the clients hash to detect MITM attacks. Is this wise? safe? What other reason would the application need to do this for?

By sending a SHA-512 hash of it, you don't expose more useful information about the key, than the attacker had from the Diffie-Hellman messages. However, it is completely insecure to rely on that hash. The man in the middle could give every side its needed hash, and still could intercept the traffic. For Diffie-Hellman to provide any security, either the messages must be signed with a public key cryptosystem, or the negotiated key. Note that when a signature gets transmitted, no more information leaks about the signed content than a hash.


IPSec AH + ESP used together When ESP and AH are used together (ESP transport, AH transport) on the same packet does ESP encrypt the AH's hash, or is the hash left in the clear?

If the hash isn't encrypted, there are obviously security implications (like the AH not ensuring integrity of the authenticated information)

I ask because the AH precedes the ESP header, and ESP encryption in transport mode only applies to the TCP/UDP datagram following the ESP header (SPI and sequence).

I know that these are not commonly used together. That is not relevant. Also, I'm aware that ESP tunnel mode supports optional authentication (in a trailing segment after the message body) that's also not relevant here.

You already mentioned that the AH header precedes the ESP header when applying both. Consequently the ESP header doesn't have any effect on the AH header. But the AH header can be used to protect the IP header when using transport mode and to protect the ESP header for both modes. But this is not very common and requires an additional Security Association for each direction. Thus you will end up with 4 SAs instead of 2 if you have a bi-directional connection.

Furthermore the hash used by AH is a cryptographic hash. You can't change/recalculate it without knowing the key.


Where are the apple-app-site-association files cached/stored on iOS when Universal Links are used? The official documentations states that when users install your app, iOS checks a file that you’ve uploaded to your web server to make sure that your website allows your app to open URLs on its behalf. Only you can create and upload this file, so the association of your website with your app is secure.

So I am wondering where does iOS keep the fetched apple-app-site-association file cached/stored? Keychain? Local storage?

It's stored in keychain. You check it on device, after wiping out keychain you lose universal links.


XVWA PBKDF2 with sha256 and 1000 iteration In XVWA (Xtreme Vulnerable Web Application) I presented with an PBKDF2 with sha256 and 1000 iteration as such:

<?php

function create_hash($password)
{
    // format: algorithm:iterations:salt:hash
    $salt = base64_encode(mcrypt_create_iv(PBKDF2_SALT_BYTE_SIZE, MCRYPT_DEV_URANDOM));
    return  $salt . " : " .
        base64_encode(pbkdf2(
            PBKDF2_HASH_ALGORITHM,
            $password,
            $salt,
            1000,
            24,
            true
        ));
}
// where $password is a user supplied data.

https://github.com/s4n7h0/xvwa/blob/master/vulnerabilities/crypto/PasswordHash.php

Is there a way to retrieve the password?

You can try to reverse a hash value by trying to brute force it, i.e. run the has function over a list of possible (password) values until you encounter the same output. If this procedure can be successful is dependent on two questions:

How fast can I compute a password hash (or in other words: how many passwords can I try per second)
How complicated is the password (how many password will I have to try before I find the password)

The calculation time is the quotient of those two values. That is why one uses designated password hashing functions which are slow.

While PBKDF2 is designed as a password hashing function, it has a rather dated design and the parameters chosen here (1000 iterations) are not appropriate for modern hardware.

So, assuming the password is not too complicated, you might have a realistic chance to reverse the hash. The standard tools for such an attack are hashcat and john the ripper.


Are there DRM techniques to effectively prevent pirating? A question on Skeptics.SE asks whether current DRM techniques effectively prevent pirating: Is DRM effective?

The question for IT Security is: Can DRM be made effective, and are there any examples?

One approach that has been discussed here leverages hardware support for Trusted Computing - see Status of Trusted Computing and Remote Attestation deployment

Firstly, I think the skeptics answer pretty much covers it: DRM annoys people. Some of us actively avoid purchasing anything with it.

In terms of software, this is pretty much impossible. One DRM scheme might be to use public key encryption with content encrypted with symmetric keys (performance of symmetric ciphers being vastly superior to most pk ones). You encrypt the content key with the private key and the software can then decrypt that key with the public key, and decrypt the content.

Which works, except that I'm just going to step your program through a debugger or disassemble your code until I find your key, decrypt your content and the game's up. Crypto is for transmission over insecure networks, not for decrypting securely and in isolation on hostile systems.

So, you could send lots of different keys over the internet for different parts of the content. Well, your paying customers are likely to experience problems with this, but, I can just automate the debugging process, or hook your receive events, or whatever. Either way, I can grab those keys. It isn't easy, but it can be done.

So the next stage is to prevent me using my debugger or hooking your system calls in some way, which is where you start writing rootkits. As it happens, I can take the disk offline and examine/disable your rootkit, or modify it so your software believes it is secure. In fact, this will make it easier for me to identify what you're protecting.

There is another case, one where the OS is complicit and provides some form of secure container. If it is possible for me to load code into ring 0, this security becomes irrelevant. If not, if I can clone your microkernel core and modify it to allow me to load code into ring 0, this security becomes irrelevant again.

At this point you have to start using hardware controls. Simply put, since I can modify the operating system any way I please, you probably need hardware-implemented DRM that I have no chance of modifying or reading. You'd need your crypto to happen on-hardware such that it is impossible to read the decrypted data from the operating system. You'd need the public key I mentioned above to reside on that hardware, not on the OS.

At this point, you've probably defeated me personally, but I am sure there are people capable of modifying their HDMI cables (or whatever) to split the data out onto the display and to another device such as storage.

Also, how you store your keys securely on your device is going to be an issue. You'd need to encrypt them! Otherwise, I'm just going to attach your storage device to an offline system. And store the keys... wait... see the pattern?

Once you have physical access, the game is up.

I don't think DRM is technically possible. Whatever methods you employ, there will always be someone with sufficient skill to undo it, since at some level that protected content must be decrypted for their viewing. Whether they have the motivation to is another matter.

From a software engineering perspective, getting it right, whilst not disrupting your users, allowing them to easily move their content to authorised devices, supporting new devices... all nightmares. Who's going to buy your content, when you haven't got Windows 8 support ready for launch? Does your content work on my Windows XP box too? What do you mean you don't support it?! If you use hardware, you have a deployment issue.

Finally, DRM is just deeply unpopular.


Does repeating one word to form a password result in a similar pattern in its encrypted format? If i use a single word to form a password by repeating it like the examples below:

securesecuresecuresecuresecuresecure
SeCuReSeCuReSeCuReSeCuReSeCuReSeCuReSeCuRe
$eCuRe$eCuRe$eCuRe$eCuRe$eCuRe$eCuRe$eCuRe

Would a similar pattern (repeated symbols) appear in the encrypted format of the password (NTLM, MD5, etc)?

Against a bruteforce attack the latter would be more secure, but the overall length of your password would already be hard to guess.

If someone however would know that you always repeat a regular word with a fixed amount of times, then a dictionary attack might be easier performed with the first example. (providing the  person doesn't know about your signs)

With modern encryption techniques (1 way hashing and CBC) there isn't an easy way to notice repeated words.


What happens when you lose access to the second factor? Imagine you use your phone number as a second factor to access your e-Mails (e.g. through SMS). What happens if I change phone numbers and then no longer have access to that second factor?

Can one still access the e-mail account?

As others have said, you (should) lose access to your account.

A common recommendation is to use TOTP 2FA and to backup the key.


How to use TPM to identify a computer for licensing purposes? I've been comissioned to use TPM to add a licensing system to an existing software project. The idea is to use TPM to uniquely identify the computer (that runs GNU/Linux, probably CentOS/RHEL/Fedora) so that the license file can only be used in that computer. Before knowing about TPM we were going to use a composition of MAC address, motherboard ID and other serial codes present to try to uniquely ID the computer, but most of those weren't tamper-proof.

I've been reading about TPM but I'm a bit confused about the multiple features it seems to offer. As far as I know, using either the Endorsement Key or the an Attestation Identity Key is the key here (pun intended), but other than that I'm not sure how I should proceed or even if I'm actually correct in my approach. Maybe there's an easier way of doing what I'm looking for.

As you are going to run a open source OS, attestation will not work as reliably. The TPM will be able to attestate up to the loader of the OS, but after that, attestation becomes difficult as open source software is easy to modify.

I would suggest using the attestation identity key, to create a remote attestation signature (TPM_Quote) and then use a cloud service to host most parts of your application.

The client app just acts as a "dumb interface" to the cloud server, and the TPM_Quote is sent to the server as a "login". This can also be used to negotiate a "session key" that only the TPM and your server, can use to encrypt/decrypt.

This means that a cracker can copy your application until the cows come home, it wont matter, as your server will not accept a TPM_Quote from a tampered system.

This also makes it easy to revoke licenses if they are misused, for example if a customer is for example abusing a personal license by lending out RDP/VNC access to the computer to individuals outside of the customers premises.

Note that unencrypted application still needs to be available to the host OS, so regardless of which TPM features you use, it will still be crackable as long as the verification is done locally. Even if you use attestation with sealed storage and curtained memory, a cracker will still be able to crack the application, as sealed storage and curtained memory can only contain data, not executeable code. (yes, you can have executeable code in for example curtained memory, but for the host OS to be able to execute it, you need to move it outside of curtained memory).

Thats why you need to use a cloud service, so you can enforce the non-tampered state of the client computer from a central location that a cracker cannot physically access, and then host the application on this location, so even if the cracker has complete access to the client-side source code, they cannot take advantage of the service in question.


Is encryption an efficient way to protect digital media? Recently my friend and I were discussing his idea of protecting the digital media that he has been generating.

His initial idea was to encode the data using proprietary encoding algorithm and distribute the media player to the customers separately. My first reaction was, if it's so easy, everyone would have done that. The problem is that this implementation can easily fall prey to chosen plaintext attack.

His later idea was to encrypt the file using a key (say a combination of some metadata of the media file) and then distribute it to the customers. He would use a standard encryption library instead of writing his own implementation. My concern here is that if the decrypting and then rendering the file would slow down the system to be useful for use cases like live streaming.

Is the above approach an efficient way to securely serve content to a limited audience? Also, the sharing method could be live streaming watched on the proprietary software (not a web application).

Ultimately DRM for multimedia ends up being security through obscurity by necessity. You HAVE to give the person all the information to display the information so they can consume it which means they have all the information they need to save it/copy it/etc. There is ultimately no way to get around that.

The only possible way to get around this is by using things like TPM and secure boot that are built into the hardware and supported by the OS. This can then theoretically limit what you are able to do and protect the video but that isn't something you can throw together itself and is still only as secure as all the combined components are (TPM, Secure boot, OS, Video card driver etc).


Questions on reflected file download (RFD) attack I read this article, and the whitepaper by security researcher Oren Hafif  which mentions the following salient points:

  RFD, like many other Web attacks, begins by sending a malicious link
  to a victim. But unlike other attacks, RFD ends outside of the browser
  context:

  The user follows a malicious link to a trusted web site.
  An executable file is downloaded and saved on the user’s machine.
  All security indicators show that the file was “hosted” on the
  trusted web site.
  The user executes the file which contains shell commands that gain
  complete control over the computer.

An example of a malicious URL looks like this:

https://www.google.com/s;/ChromeSetup.bat;/ChromeSetup.bat?gs_ri=psy-ab&q=%22%7c%7c%74....

This looks similar to the recent shellshock bug, except that the attack is directed at the client instead of the server. My questions are:

Is Google hosting a ChromeSetup.bat file under a directory /s; on its server?
Which OSes are vulnerable? Is this attack specific to a particular
version of Windows OS?
How can clients protect themselves if a website allows its user to
place malicious URLs in the src attribute of an <img> tag?

Google is not hosting ChromeSetup.bat. A requirement for this attack is that a website needs to have an endpoint with a less common Content-Type and preferably a misconfigured Content-Disposition header (namely: no 'filename' attribute). These two headers will cause the browser to download the response as a file, instead of rendering it.

In the URL you provide that endpoint is '/s' which provides autocomplete suggestions as JSON, with a content type of application/json. Older versions of IE will prompt a download just based on the content type, newer versions and Chrome require that incomplete content-disposition header for this attack to work.

Another requirement is that this endpoint must reflect some user input from the querystring ( post or cookie data will obviously work aswell but wouldn't be as effective for the attacker). This will provide the malicious content of the file that is downloaded.

In the URL you provided this will be the value of the querystring parameter.

As no filename is provided for the download, the browsers tries to pick one. Because the Google website allowed loose urls through url parameters (the ;/ChromeSetup.bat; part), the browser picked a cleaned up version of that (namely ChromeSetup.bat) as the filename to present to the user. The webapplication ignores this input, but the browser does use it.

Any browser on any OS might respond in this way. Chrome will download the response with the forged filename, that will also work on OSX.

An additional weakness exists in Windows that doesn't warn the user properly when "setup" occurs in the filename. Windows will also directly run a .bat file if you click it. Osx and Linux won't run this file as the attacker would most likely be unable to provide a full shellscript with the hashbang notation. Even then, it doesn't have the executable bit set, so it wouldn't be run directly.

The user still has to activate/accept the download, so just driving by with an  won't cause immediate "infection". A client (browser) should provide proper warnings for executable files instead of just running them. The user should know better than to run random .bat files, but that's the strength of this attack: the "file" is served from Google.com, so it should be safe right? The most important party here is the vulnerable website: the website shouldn't allow a user to provide a custom path, should provide proper headers to prevent this and should reconsider reflecting user input.


Can revealing Intranet address become a security threat? If I publicly list my company's intranet and extranet website addresses, is it a risk?

If you are talking about the Internet address such as example.com, then you are safe. That is what others will use to find your company website.

If you are talking about the intranet address such as example.net, not really unless it also reveals the network topology, then it is possible to have an issue as knowing the network topology can make a dhcp and dns poisoning attack possible.


Good Practices to secure a Gaming Web Server, Memcached Server & MySQL Server We have developed Game for Facebook platform. We have several Gaming Web Server, Memcached Server & MySQL Server.

Here we have to work with facebook Payment API.

We need to secure enough our Gaming Web Server, Memcached Server & MySQL Server.

We have SSL Certificate
We Monitors Logs Everyday

Is those enough, or any suggestion from you please?

I would make sure you have these things:

Firewall
Host Based Intrusion Detection system on all your machines (OSSEC is a free one, but you have to tweak the rules a little)
Web Application Firewall

These solutions will significantly reduce the chance of a succesful attack by scanners etc. To have reasonable assurance you should also invest in a pentest.

Now since you have different servers, you should have frontend and backend servers. The backend can contain your MySQL servers since no users should have direct access to them.


Hydra fails with "[ERROR] target ssh://192.168.16.128:22/ does not support password authentication."? I've updated Kali 2.0 to newest version - it is installed using VMWare.

Now, every time I use hydra to brute-force SSH, I get the following error:

[ERROR] target ssh://192.168.16.128:22/ does not support password authentication.

The corresponding command is as follows:

hydra -l anne -P /usr/share/wordlists/rockyou.txt 192.168.16.128 -t 32 ssh

I can easily log into the SSH server  (tried a couple of servers) using ssh (ssh anne@192.168.16.128) and entering the password.

I really have no idea what could be wrong? Every tutorial I read on the Internet seems to work flawlessly without the issues I'm experiencing...

The complete session can be seen below:

root@kali:~# hydra -l anne -P /usr/share/wordlists/rockyou.txt 192.168.16.128 -t 32 ssh
Hydra v8.6 (c) 2017 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.

Hydra (http://www.thc.org/thc-hydra) starting at 2018-04-16 19:30:56
[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4
[DATA] max 32 tasks per 1 server, overall 32 tasks, 14344399 login tries (l:1/p:14344399), ~448263 tries per task
[DATA] attacking ssh://192.168.16.128:22/
[ERROR] target ssh://192.168.16.128:22/ does not support password authentication.

SSH supports several different authentication mechanisms. The password authentication mechanism has the client send the password to the server as a password. The more-common keyboard-interactive authentication mechanism opens a channel between the client and an authentication process on the server. The client allows the user to directly interact with the authentication process, which is usually just a password prompt. This allows more complex features like multiple-factor authentication and pre-authentication warnings and checks.

So your target probably supports keyboard-interactive and not password authentication.


Why do the large majority of big organizations have "known bad" password policies? I saw a recent password question on security.stackexchange "Is the NHS wrong about passwords?" The question is very specific about one organization but from what I've seen the same "known bad" password policies are used in most big organizations.

When I say "known bad password policies", I mean to say most big organizations focus on relatively short (8 to 14 characters) passwords with a focus on requiring minimum number of special characters (upper/lower case, symbols, numbers, etc).

When I say "big organizations", I am not just referring to commercial but non-commercial (i.e. NIST's for example. i'm sure others can come up with other such examples). Now that I think of it ... most linux distros have some sort of default password policy that also is very similar (relatively short passwords but requiring special characters).

Why do the large majority of big organizations have "known bad" password policies?

Obligatory XKCD reference about the same subject:

p.s. another very popular question: XKCD #936: Short complex password, or long dictionary passphrase?

p.p.s. Normally I wouldn't ask such a question but I feel strongly this question needs to be asked and answered. Ever since the XKCD comic came out in 2011) I see people asking about this same subject again and again and again... and all the questions are asking legitimate questions... but they all dance around the "why" part without directly addressing it.

[ "Why does someone else do something I consider dumb?" is always a very open-ended question subject to speculation (and is not a great fit for Stack Exchange.)  But because this problem is so prevalent among password policies, I believe it's worth exploring. ]

First, there is a lot of misinformation, superstition, confusing math, and technobabble around passwords.

Some security experts believe that a combination of special characters, numbers, and mixed case letters automatically make passwords unguessable, but they don't know or disagree what the optimal mix is.  The guidance also should be changed depending on the native language of the users, but many site administrators are unaware of the differences.
Some don't understand the massively parallel computing resources available to modern password attackers.  Hard drives containing rainbow tables of every possible 8 character string hashed with MD5 are sold online.  Cloud based computing clusters, purpose-built arrays of graphics cards, and thousands of botnet controlled computers are all being employed by people to crack passwords.  Databases of previously cracked passwords, dictionaries from every language, song lyrics, and movie quotes are all readily available to the enterprising hacker when it comes time to testing guesses.
People remember hearing things like "don't write passwords down", which was advice from 20 years ago when you could count on the secretary to write her boss's password on a post-it note stuck to her monitor, and the biggest threat was someone could walk by her desk when she was at lunch.  I have yet to disassemble a keystroke logger that is able to read a sheet of handwritten paper kept in my wallet. But some people still repeat this advice today.
And technical people don't help when they toss around terms like "entropy" and numbers like "7 to the 95th power" that mean nothing to an average person; at the same time they ignore the psychology of the average user who doesn't want to enter 12 cryptographically random characters, let alone be asked to remember them for each of a dozen web sites.

Next, good passwords are notoriously difficult to study.  If asked to enter a work password into a web site so they could study its complexity, most people would say "no".  Many studies involving people entering a made-up password don't have test conditions that reliably mimic memorization or usage in the real world.  So our primary sources of data on user-chosen passwords are the passwords and hashes published after (the increasingly frequent) data breaches.  But these are often from sites like "long-eared-rabbit-fanciers-forum.com", where people know they have little of value to lose from using a weak password.  They seem to be less often published from sites where the users are protecting their own credit cards, account balances, or other forms of digital valuables.  I'm unaware of any case where a bank's cleartext password database was published online.  And in many cases, the published databases are hashed and to analyze them means the researchers have to brute force attack them with a hashing algorithm before analysis can begin.

There is also education.  Web site administrators don't take classes in "choosing a good password complexity scheme," nor do they take classes in "securely storing passwords".  And a huge number of computer courses use an example of "create a sign-on screen" as an introductory program; but none of the many examples I've seen have ever demonstrated using pbkdf2() to hash the passwords before placing them in the database.  And with all that, if you do come up with effective rules on choosing a good password, you still have to convince users to pick secure more passwords than 'P@ssword1'.

All that said, there are many researchers who have done a lot of work on passwords.  You'll find hundreds of curated scholarly papers on the subject at http://www.passwordresearch.com.  There are presentations on passwords at many of the premier security conferences.  There is an annual International Conference on Passwords.  So there are bodies of knowledge being built up, but they haven't converged on a standardized set of conclusions or recommendations yet.  And this information has yet to be disseminated to many of the architects and engineers who build web sites.  There is simply no straight pipeline of solid information from the researchers into practice.  And that may be the biggest hurdle of all.


How to edit a Hex code without corrupting the file [in bypassing av]? I recently started studying on bypassing AV by finding a AV signature on "nc.exe (NetCat)" and changing it to see how it works. I have already found the place of signature with splitting method then i should open the nc.exe with a hex editor and change the Sig. But, here is what it look like:

On another malware i found that the Signature is in last 355byte of the file:

And both files will get corrupted by editing them (adding or removing bytes)

Question: What should i do for editing in this situations? What should i know for a successful binary editing in bypassing av?

If i get this whole wrong tell me what should i be looking for.

AV signatures are usually based on a hash form a particular file.  They are either known goods, or known bad files.  If it's a known bad file, you can alter a few bytes here and there (for example the "cannot run in dos mode" string), you can have a binary that does the same functionality, with a different hash.

But, most modern AV's / Anti-Malware programs look at a few things; this could include code signing, behavior, etc.

  What should i know for a successful binary editing in bypassing av?

This is exactly what code signing tries to solve.  If you edit the program, the signature will no longer match, and will not be "blindly" trusted.

Bypassing AV is a large subject which is well researched with often insightful techniques.  You can either have an "untrusted binary" which do legitimate things long enough, so that it gets trusted.  Or, have a legitimate binary (ex: something that's shipped with the OS, etc) and try to abuse that to perform something it's not intended to do.


CRL verification with renewed CA I would like to understand how is CRL verified and therefore certificate of end entity verified when there is a new certificate and keys of issuing CA renewed.

Suppose I have the following setup:

Issuing CA publishing CRL
End entity certificates issued by Issuing CA
Validation service that validates issued end entity certificates through certificate chain and CRL

When there is no change, certificate would be validated without any issues.

But what happens when I renew CA certificate with new keys? The DN of CA certificate would be the same but the published CRL would be signed by different key. Old CA certificate and keys would be still valid because its expiration date wasn't reached yet, but it would not be used to publish new CRLs.

How would be end entity certificate issued before renewing CA validated with renewed CA certificate and its corresponding CRLs?

The CRL contains only information about the certificates issued by this particular CA with this particular public key. Revocation information for certificates issued with the older CA key are contained in another CRL file. Which CRL file need to be used to verify revocation for a specific certificate is contained in the certificate itself as CRL distribution point.


Is this a website attack / vulnerability test? I have a specific IP that has been iterating through the directories on my site testing for something. Here is an example of what it keeps trying to hit:

http://<site>/<path>/change._change

http://<site>/<path>/beforeactivate._change

http://<site>/<path>/click._change

http://<site>/<path>/propertychange._change

http://<site>/<path>/submit._submit

http://<site>/<path>/click._submit keypress._submit

http://<site>/<path>/Microsoft.XMLDOM

http://<site>/<path>/1.8.0

http://<site>/<path>/ul.sf-menu

http://<site>/<path>/AjaxControlToolkit.TextBoxWatermarkBehavior

http://<site>/<path>/AjaxControlToolkit.Animation.SequenceAnimation cannot be nested inside AjaxControlToolkit.Animation.ParallelAnimation

http://<site>/<path>/AjaxControlToolkit.AlwaysVisibleControlBehavior must have an element

http://<site>/<path>/AjaxControlToolkit.ControlBase

http://<site>/<path>/AjaxControlToolkit.BoxSide

http://<site>/<path>/public/rss/RssFeed.ashx?moduleId=142

http://<site>/<path>/fancybox/click.fb

http://<site>/<path>/fancybox/resize.fb

http://<site>/<path>/fancybox/scroll.fb

http://<site>/<path>/client/scroll.prettyphoto

There are many more, but I removed some of the similar ones. This happens over and over from the same IP and across several directories on my site. Reading IIS logs is not one of my strengths. It definitely seems like they are testing for something that can be exploited, but does this look like a familiar technique to anyone?

It's probably either a crawler or internet background noise (e.g. automated vulnerability scanners). If all those pages actually exist it's a crawler, if not it's a internet background  noise.

If it annoys you, you can ban the IP on your firewall. Another option is a Host Based Intrusion Detection system like OSSEC which detects these type of attacks and blocks them automatically on the firewall for a period of time.


Publishing an exploit after vendor contact and patching I recently discovered several serious security holes in a vendors product. I worked with them and they just released a patch.

I understand this is a very competitive field so I would like to publish my findings as a way to earn some street credibility.

The company does not seem to publish anything publicly about fixes and no CVE. Is the next correct step to ask and get a CVE identification number for each exploit and then publish my paper linking to those CVEs?

Is the next correct step to ask and get a CVE identification number for each exploit and then publish my paper linking to those CVEs?

As a courtesy, I would inform the vendor that you plan on publishing. They may want to first send out private notices to their customers to give them time to update. Normally, you would mention this when first contacting the vendor, but if you didn't, better late than never.

If you can get a CVE via the process described below, then yes, you would link each vulnerability to its CVE. You may also want to publish your report to a mailing list.

Is a CVE Needed?

  Can I just release this paper or do I need to get a CV Number as well

You don't need a CVE to disclose, but it's recommended, if you can get one (your vulnerability may not be eligible for a CVE, for example if it is in closed sourced software that isn't listed by MITRE, or MITRE may not be able to assign you a CVE in a timely manner).

The idea behind CVEs is to have a centralized way to identify security vulnerabilities, which makes it easier to distinguish between different issues across different tools or vulnerability databases.

So if you can, it would be best to acquire a CVE before publishing, so others can easily identify your vulnerability and to avoid duplicate assignments.

How to get a CVE (in 2016+)

In August 2016, MITRE changed their email-based CVE request process to a webform-based process. In the process, they also changed the rules about what vulnerabilities can request CVEs from them directly.

As far as I understand based on this document, it works like this:

if the affected product is assigned to a CNA, a CVE should be requested from that CNA at the same time as the vulnerability is reported.
if not, you can contact CERT/CC (I assume before disclosing), or a mailing list (while disclosing).
if the affected product is in a seemingly arbitrary list of software, the CVE should be requested after it was reported to the vendor, but before publishing the vulnerability. This request should happen via the MITRE CVE webform.
if the affected product is not in the list, and it is open source, then the CVE should be requested after it was published, via this google docs form (if you disclose via a mailing list, I would make sure to include a link to avoid duplicate CVE assignment)

For your case, point 1. doesn't seem to be the case. You may send your disclosure to a mailing list (point 2.), but I wouldn't expect to get a CVE. If the vendor is in 3., you may use the webform to request a CVE. 4. doesn't apply, so if none of the previous points applied (eg if it is closed software not in the list of covered products), you may not get a CVE.


Command and Control Infrastructure This is an academic question, I googled a lot but couldn't find suitable answers for this question:

  What are the different Command & Control infrastructures (Botnets) &
  what are the countermeasures?

Any help is much appreciated.

Have you tried Wikipedia?
In short, the malware (A) needs to connect to (B).
This can be done using many different methods.

The easiest (in my opinion) to setup is by using the HTTP (Webserver) protocol.
You make a simple web server with short PHP scripts that handle the incoming requests. You send/ask for requests by using sockets (for example) the Windows API.
Countermeasure: Blocking this specific domain/IP Address in your firewall. I should mention that malware often has multiple server addresses hard-coded into its source to countermeasure this countermeasure. If you're working at a security company/government the countermeasure would be contacting the host-provider to take down that website, or in some cases even hack the server.

Another much used is by using IRC chatrooms. You create a secured and private IRC chatroom, and than you can 'chat' with your malware. In other words, you send a command into the chat-box, and the malware ('reading' the chat messages) will receive the commands and execute them. IRC is mainly used because of simplicity and its low bandwidth requirements.
Countermeasure: Block specific TCP ports like 6667 (specific to IRC), again I should mention that IRC tries other ports as well if 6667 is blocked.

What also is often used is P2P (Peer-to-peer), you use your own connection/computers as a C&C server. The malware communicates directly with your network to receive commands.
This is what you most of the time use with frameworks like Metasploit.
Countermeasure: Here the IP of the attacker would be static, so simply blocking that IP should work. Again, if you're working in a security company/government, you can log the IP and with luck you have the IP of the attacker. The attacker could also use a VPN allowing port-forwarding, but then it isn't real P2P anymore.

As you see, your firewall is important.


What is the difference between XSS and Cross Site Flashing? I want to know the basic differences between XSS and XSF

XSF is, essentially, XSS in a Flash applet. Where in XSS you find vectors (e.g. URL parameters or form fields) for injecting content into the DOM that is parsed as script, in XSF you look for cases where you can get untrusted data to be placed into Flash variables, which may then be used in an unescaped context inside the Flash applet, resulting in script execution, open redirect, or other impacts.


Two-way encryption that can be nested? In building a security system, I'm looking to prevent 'man-in-the-middle' attacks in a two-way encryption system, using the following setup:

A sends B a message, encrypted with code 1

B sends it back, having been encrypted with 1 and 2

A reverses 1 and sends it to B, upon which B decodes code 2 and receives the message.

At no point can a man in the middle access this data. Yet this hinges on there being two such functions, that can be nested and decoded out of order. Are there any such functions? Or are there better ways to prevent attacks?

You should not use this in any production system, period. You're trying to design cryptographic primitives, which is something which is extremely easy to get horribly wrong. If you aren't yourself a cryptographer, don't try to design cryptographic algorithms - perfectly good ones already exist. (In general, you should use well-tested systems wherever you can in security - never roll your own primitive, avoid rolling your own protocol wherever you possibly can, avoid rolling your own implementation when practical).

In fact, this scheme is highly vulnerable to MitM attacks. A MitM is not someone who's listening in on traffic; they're active attackers, and can modify any communication going between the two parties. In this case, the MitM intercepts Alice's first message and encrypts it with their key; when Alice removes her encryption, the attacker now has it encrypted with their own key and nothing else. You have to somehow verify that it's Bob's key that was added in step 2, not an attacker's; your scheme doesn't even try to solve this.

A far, far better way to do this is public-key encryption. Alice and Bob give each other their public keys through some out-of-band communication, or a trusted third party verifies their public keys. Alice encrypts her message with Bob's public key, and Bob then decrypts it. You need to share public keys, but that's a plus: in your scheme (where you don't know the key Bob should use nor whether the message was in fact re-encrypted with it), you're extremely vulnerable to a MitM attack.

So use proper public-key encryption in a properly tested protocol, if possible in properly tested library code (note "tested" means "tested for security, which only trained experts can really do).


Use of S/MIME capabilities attribute If you examine an S/MIME-signed file with

$ openssl cms -in file.sgn -noout -cmsout -print

you see that S/MIME capabilities are also included in the signature:

...
object: S/MIME Capabilities (1.2.840.113549.1.9.15)
        value.set:
          SEQUENCE:
 0:d=0  hl=2 l= 106 cons: SEQUENCE
 2:d=1  hl=2 l=  11 cons:  SEQUENCE
 4:d=2  hl=2 l=   9 prim:   OBJECT            :aes-256-cbc
15:d=1  hl=2 l=  11 cons:  SEQUENCE
17:d=2  hl=2 l=   9 prim:   OBJECT            :aes-192-cbc
28:d=1  hl=2 l=  11 cons:  SEQUENCE
30:d=2  hl=2 l=   9 prim:   OBJECT            :aes-128-cbc
41:d=1  hl=2 l=  10 cons:  SEQUENCE
43:d=2  hl=2 l=   8 prim:   OBJECT            :des-ede3-cbc
...

In rfc2633 section 2.5.2 it is stated that these capabilities
are included to show

  ...  what the client announcing the SMIMECapabilites can    support. A
  client does not have to list every capability it supports,    and
  probably should not list all its capabilities so that the
  capabilities list doesn't get too long.

This may explain, why for example sha1WithRSAEncryption is not in my list here. (Although it's quite important.)

But what use has this list then? Is it just there to have more attributes within a signature to design it in a more inimitably way?

The client usually supports more ciphers than it announces because there is a difference between both.
One thing is the capabilities - maybe a better name would be preferences - being a list of those ciphers that the clients wants the other client to use when sending messages.
The other thing is the list of actually supported ciphers, which is usually longer because the client needs to be able to process additional ciphers in incoming messages.
For example, sha1WithRSAEncryption is known to be weak, so while the client is capable of processing an incoming message with sha1WithRSAEncryption, it does not list it in its capabilities because it prefers to use a better algorithm.

Half OT:
However, the S/MIME Capabilities attribute is not written by many email clients. I assume that this is because nowadays, with IMAP mail servers and mobile devices, emails may be written and read using multiple different clients, so sending one client's S/MIME capabilities may not make as much sense as it used ro in earlier days.


Does SSH password authentication provide the server with the password? If an attacker takes control of a server and a user tries to SSH into it using password authentication, can the attacker get the password?

I was under the impression that there was an algorithm in place that demonstrated the client holding the password without revealing it to protect against the case of a malicious server (1), but this article says otherwise:

  The simplest is probably password authentication, in which the server simply prompts the client for the password of the account they are attempting to login with. The password is sent through the negotiated encryption, so it is secure from outside parties.

Could someone clarify if this is correct?

something like the Socialist Millionaire, but with one side only having a salted hash?

What if we sent the hash?

If the hash were the authentication parameter, and not the password, then the hash would be the authentication parameter.

To explain that tautology in more depth: a password is hashed so that if the data store of passwords is compromised, one doesn't have a functional authentication credential. For that reason, it is the password that is sent to the server where the server performs the work to calculate the hash. Sending the hash of a password would be exactly the same as using a password generator with no hashing.

Are your passwords compromised if somebody has control of the server?

They can still steal passwords, either by brute forcing the authentication store to generate the raw password, or more efficiently by altering the server's daemon code to record your password attempts.


SPF and DKIM passes for SPAM message when using SES and Google Mail We have websites hosted on AWS, are using SES to send out mailings, and use Google Mail for sending and receiving company mail.

Every so often I receive SPAM emails to my Priority Inbox in Google because they are marked as coming from our domain with both SPF and DKIM pass, even though they were sent from a spammer on another server.

Here are some sample headers: https://pastebin.com/JjvYSq0A

I believe this may be happening because we are using both SES and Google Mail and have designated both as trusted sources for e-mail.

I guess I'm wondering whether there is any way to keep spoofed messages from being signed as from us. We've had this problem for a while.

From the header you posted, "WEBSITE-DOMAIN.org" is your domain, correct? If so, then this spammer is spoofing the header from address. You can prevent header from spoofing with DMARC.

DMARC confirms that the header from address domain is "in alignment" with either the MAIL FROM domain or the DKIM signing domain. "Alignment" means that either the domains match exactly (strict mode) or it's a subdomain of the header from address domain (relaxed mode).

Implementing DMARC can be a little complicated depending on your specific configuration, and it's easy to accidentally block your own legitimate email if not done correctly. The details will vary, but here's the basic process:

Create a list of all legitimate sources of email from your domain. You mentioned SES and GSuite, but there may be others you don't know about (from shadow IT, for instance).
Create a DMARC DNS record, making sure to set the policy to monitor mode ("none")
Configure all known legitimate email sources to use your domain/subdomain for DKIM signing or use your domain/subdomain for MAIL FROM (preferably both, but not necessary), adding/modifying SPF and DKIM records as appropriate. Most mainstream email services accommodate this, including SES and GSuite, but unfortunately some still don't.
You'll start receiving aggregate DMARC reports at the email address specified in your DMARC record. Review these for at least a few weeks to make sure you haven't overlooked a source of legitimate email from your domain. Also review the headers from emails sent by your company to confirm that they're passing DMARC. Check the headers from as many different receiving services as possible, because they don't all handle DMARC the same way (especially if automatic email forwarding is involved)
When you're sure all of your domain's legitimate emails are passing DMARC, change the DMARC policy specified in the DNS record to "quarantine" or "reject"


why are the first few characters of a DSA Private Key similar? I noticed most DSA private keys often start with the same few characters, MIIBvAIBAAKBgQD .

For example, generate a private key on Ubuntu, by running:

ssh-keygen -t dsa -N '' -f /tmp/id_dsa

This results in a private key file that begins with something like:

-----BEGIN DSA PRIVATE KEY-----
MIIBvAIBAAKBgQD...

The first 16 characters are suspiciously similar.
I expect ssh-keygen is using a random nonce before beginning encipherment.  Assuming ssh-keygen is using a random nonce, why are the first few characters of the DSA Private Key files similar?

Using a script, I found that uniqueness ("randomness", good entropy, etc.) begins at the 17th character.

leading char count  1 - unique combinations   1 among 100 generated keys
leading char count  2 - unique combinations   1 among 100 generated keys
leading char count  3 - unique combinations   1 among 100 generated keys
leading char count  4 - unique combinations   1 among 100 generated keys
leading char count  5 - unique combinations   2 among 100 generated keys
leading char count  6 - unique combinations   4 among 100 generated keys
leading char count  7 - unique combinations   6 among 100 generated keys
leading char count  8 - unique combinations   5 among 100 generated keys
leading char count  9 - unique combinations   4 among 100 generated keys
leading char count 10 - unique combinations   4 among 100 generated keys
leading char count 11 - unique combinations   4 among 100 generated keys
leading char count 12 - unique combinations   4 among 100 generated keys
leading char count 13 - unique combinations   4 among 100 generated keys
leading char count 14 - unique combinations   4 among 100 generated keys
leading char count 15 - unique combinations   7 among 100 generated keys
leading char count 16 - unique combinations  87 among 100 generated keys
leading char count 17 - unique combinations 100 among 100 generated keys
leading char count 18 - unique combinations 100 among 100 generated keys
leading char count 19 - unique combinations 100 among 100 generated keys
leading char count 20 - unique combinations 100 among 100 generated keys
leading char count 21 - unique combinations 100 among 100 generated keys
...

I used the following bash code to determine this

keyf=/tmp/id_dsa-${RANDOM}
for upto in {1..35} ; do
    keys="${keyf}-${upto}"
    rm -f "${keys}" &>/dev/null
    for i in {0..99} ; do
        rm "${keyf}" &>/dev/null
        ssh-keygen -t dsa -N '' -f "${keyf}" &>/dev/null
        sed '2q;d' "${keyf}" | cut -b 1-"${upto}" >> "${keys}"
    done
    keys_count_all=$(cat "${keys}" | wc -l)
    keys_count_uniq=$(sort -u "${keys}" | wc -l)
    printf "leading char count %2d - unique combinations %3d among %3d generated keys\n" ${upto} ${keys_count_uniq} ${keys_count_all}
done
rm "${keyf}"

The DSA private key file has a structure to it, it's not simply a random number (or two). Within the PEM encoded data (base64 + delimiters) is a DER encoded ASN.1 binary structure.
ASN.1 is a system independent way to encode data (think of it like a "binary XML"). Strictly, only the first two bytes of a DSA key encoded this way are fixed, but for a given key size  more can be said. Note there are no "magic numbers" in the underlying data structure.

A DSA key pair has 5 distinct components: P, Q, G, public key part, private key part.
Digging into the source of OpenSSL (used by OpenSSH for this) crypto/dsa/dsa_asn1.c:

ASN1_SEQUENCE_cb(DSAPrivateKey, dsa_cb) = {
    ASN1_SIMPLE(DSA, version, LONG),
    ASN1_SIMPLE(DSA, p, BIGNUM),
    ASN1_SIMPLE(DSA, q, BIGNUM),
    ASN1_SIMPLE(DSA, g, BIGNUM),
    ASN1_SIMPLE(DSA, pub_key, BIGNUM),
    ASN1_SIMPLE(DSA, priv_key, BIGNUM)
} ASN1_SEQUENCE_END_cb(DSA, DSAPrivateKey)

Which corresponds with what you'll see with openssl asn1parse -in id_dsa (though note if you use openssl dsa -in id_dsa -noout -text the version field is omitted, and the order is changed to priv, pub, P, Q, G).

Taking a look at the parsed ASN.1 output:

0:d=0  hl=4 l= 830 cons: SEQUENCE
4:d=1  hl=2 l=   1 prim: INTEGER           :00
7:d=1  hl=4 l= 257 prim: INTEGER           :DFA34F1D[...]

In the DER form of ASN.1 each item of data is a (type tag,length,data) triple. In the above asn1parse output the leading columns indicate the offset, d= depth, hl=header length (size of type tag and length fields), and l= data length. (In non-DER forms it can be a little more complicated, but we don't need to worry about that here.)

If we unwrap the base64 we can see the DER binary format:

$ openssl dsa -in id_dsa -outform DER | hexdump -C | head -1

00000000  30 82 03 3e 02 01 00 02  82 01 01 00 df a3 4f 1d  |0..>........ß£O.|
                                            ^^ ^^ ^^ ^^ ^^

You can expect the leading bytes to be reasonably static (SEQUENCE "container" + version=0), though the sequence size will be dependent on the DSA key size. The DSA "P" (^^) is the long prime (1024, 2048 or 3072 bits) is next, so for a given fixed key size its header of 4 bytes will also be reasonably static. This gives a total of 11 reasonably static bytes for a defined key size (technically sizes, e.g. 2048,256 for p,q). A complication here is minor variations in the size of encoded integers: an extra 0-byte padding will be added to ensure positive integers (leading bit must be 0).

You analysed the base64 encoded data, those 11 reasonably static bytes become encoded in the leading 15 characters of base64 output (11*8/6 =14.66) with two bits of the random P also found in the 15th character (given the padding condition, those two bits will be zero about 75% of the time anyway).
I believe this agrees with your data.

Note the minor increase in variation around the 5th/6th base64 encoded character: this corresponds with the low-octet of the total structure size (4th DER byte), the size has minor variations for fixed key sizes due to the 50% chance of leading 0-padding on each of the 5 encoded DSA integers.

An alternate format for keys is PKCS#8, this omits the public key part, but it adds the dsaEncryption OID so at least the structure is a little less enigmatic:

$ openssl pkcs8 -in id_dsa -topk8 -nocrypt | openssl asn1parse
    0:d=0  hl=4 l= 589 cons: SEQUENCE
    4:d=1  hl=2 l=   1 prim: INTEGER           :00
    7:d=1  hl=4 l= 558 cons: SEQUENCE
   11:d=2  hl=2 l=   7 prim: OBJECT            :dsaEncryption
   20:d=2  hl=4 l= 545 cons: SEQUENCE
   24:d=3  hl=4 l= 257 prim: INTEGER           :DFA34F[...]


What are the privacy conerns with cloud based submission in antivirus? It seems like many antivirus programs use the cloud to scan files for malware. Isn't this a privacy concern if local files are being uploaded to the cloud? For example with Automatic Sample Submission and Cloud Based Protection in Windows 10.

How exactly does this work because if some remote computer in the cloud can detect it, why not just have virus signature updates (like the old way of doing it)? If they use more advanced scanning techniques wouldn't this imply the whole file is being transferred and run?

This works differently depending on the AV that you are using. Some engines send the file to the cloud and generate a signature. In this case, the response is yes, they send the files to the cloud and this is a privacy issue (in some countries). On the other hand, some engines take metrics from the file and send these metrics to the cloud for post analysis or whatever. I would suggest you check the terms and conditions of the AV and you will probably find the answer. Or just ask them, specially if the information that they scan is protected and can not be transfered and things like that.


ASP.NET - why default SecurityStamp validation interval is set to 30 minutes? I'm currently studying authentication mechanisms in ASP.NET Core and came across SecurityStamp feature, which is known also from ASP.NET Standard. From what I understand from the answer here, this was added to perform sign out from all active sessions when something is modified in account configuration (e.g. password).

This could be useful when password is compromised and the attacker's session should be invalidated. However, if this was the purpose, why the default value of validation interval is set to 30 minutes? Such setting makes the whole mechanism work with up to 30 minutes delay. Shouldn't this be a smaller value (let's say 1 minute) to make it more effective?

It's to improve performance on larger scale applications.

Each SecurityStamp validation requires a database hit. With the validation interval set to zero, this would cause a database hit for every request. At 30 minutes, this keeps the window for abuse fairly low while drastically reducing the number of queries required.

As a worked example, a system with 10,000 concurrent users each making just 5 requests per minute would require 50,000 validation hits per minute when the interval is zero. Changing that interval to 1 minute reduces that to 10,000 hits per minute. Leaving the interval at the default of 30 minutes drops the rate to just 333 queries per minute, which is unlikely to be a cause of performance issues in any application at any scale, hence why it's the default. You can imagine that a short validation interval on an Ajax-heavy design making 10-20 web calls per page load and a few ongoing repeated queries might cause problems at scale.

You can tune this interval down to a minute or so if you are not expecting a large number of users.


Alert when unsigned code is run? I know Windows 10 has a lockdown option, to forbid running unsigned code. But in my organization, I'd get shot if I tried to do that. So I'd like the next best thing: a remote alert whenever unsigned code is run. Does Windows have a way to do that?

I'd also really like either Windows itself, or Defender, to have an option to add custom malware definitions, so I can add definitions for crap (even though technically not malware) that people aren't supposed to be installing (regardless of whether it's signed). For this too, I'd get shot if I configured our systems to automatically block/delete the crap, but I'd at least like to get an alert. See my related question: Can I configure Windows Defender to reject competing AV programs?

You can turn on 'audit' mode when unsigned code is run and that will generate Windows event logs which you can ingest into your SIEM and have that alert you. See here for in-depth guide. Why are you interested in unsigned files being loaded? If it's a malware prevention step then it might help but I think you'll receive so many false positives on a network where users are allowed to install their own programs it won't be worth it. There's also the issue that malware is frequently signed nowadays, see here and here.

For your second question about having Defender use custom malware sigs the answer is no, you can't write your own rules. What you could do is run ClamAV on all the endpoints and you can write your own custom rules for that, see this and this. Do you really need signatures though? Can't you push out a script to endpoints to return a list of installed programs and use that?

I think you've got bigger problems though, as an IT admin you should have the power to enforce that users aren't able to install whatever they want on your network. That also suggests have admin rights on boxes as well? I think code signing is the least of your worries and you should start implementing some basic IT security best practices before starting with more advanced ones. This can be a tough sell to management but if you Google around for the cost of malware compromises and network outages and sell it in terms of revenue it might help.


Can I use my HTTP/SSL certificate for mysql? I would like to know if I can use my SSL certificates that I use on my website (based on nodejs and express) for access to mysql database remotely, or if it is better to create new certificate.
My webserver has access to the database by localost, but I would like to access remotely to change data with phpmyadmin.

If they're on the same host, then there's no real harm in re-using the same certificate for mysql administrative access.  There are no cryptographic weaknesses exposed by having two different services present the same certificate.  Since you're on the same host, it doesn't cause you to make extra copies of the private key or move them around, so the key security remains essentially the same.
Just set up phpmyadmin and, assuming you're using Apache to host it, point Apache at the same key and cert already in use by your website.


Adobe PSIRT Average Response Time Anyone have any experience in contacting the Adobe Product Security Incident Response Team (PSIRT)? I sent in an exploit that I found two weeks ago and I have not heard from them since. Would they contact me if they don't think that the exploit is worth patching?

AFAIR they have an auto-response message, have you received it? They say that it may take some time to respond to reports, but they typically do respond.

If you haven't received their auto-response, there are several options:
- you've got the wrong e-mail (I doubt it though)
- you've received the message, but it was filtered


How to store passwords to a remote web site? Say I want to build a public API to access a website that doesn't have one. The website is protected by a standard username/password scheme and the API implementation will use scraping to get the data from it.

What would be the best way to handle passwords in this scenario?

My current best idea is this. Get the username and password in an HTML form on my site (the same one that serves the API), and generated a URL to access the API that includes an encrypted blob of username+password. The encryption is symmetric AES256 based on a key stored only on the API server. When the user will access the API URL, the API server will decrypt the credentials and access the remote website.

As an additional level of protection, I'm thinking of running the API as CGI, so that only a short lived process is ever exposed to plaintext credentials.

Does that make any sense? Are there any standard solutions to this kind of problem?

[Edit]

Possible duplicate: How to store passphrase in this situation?

Your current solution would work, however, you could keep the information on your server by tracking a session.  When a user sends their login credentials, you could store them in a database (possibly encrypted) and then issue them a unique session id (should be difficult to predict the session id, eg. crypto rand + hash).

Once the user has obtained the session key, they would send that id along with every request to your server.  When you verify that this session key is valid, you get the username/password out of the database, and make the request on behalf of the user.  After some amount of time, you'd invalidate this session key and delete it and the login information from your database.  This would help guard against replay style attacks.

If you include the actual login information and don't have some kind of age off, an attacker could obtain the URL used to access the system, and possibly make requests on behalf of the user.  Of course, this depends on how you set up the URL etc.

Typically though, this sort of situation is handled by storing the credentials locally in some sort of secure (e.g. encrypted) storage, and issuing some kind of temporal session identifier.

While there may be some benefit in using short running processes, it is likely more cost than benefit.  If an attacker is to the point at which they can read memory in your processes, the fact that the time in memory is short lived won't help much.  Furthermore, you are still probably storing the encrypted credentials somewhere on your server (e.g. http access logs), along with the encryption key (which I'm guessing is in a database).  If the attacker has access to both, the credentials will be compromised.  Depending on which language you're using to write application, there may be some way to zeroize memory once you're finished with the sensitive information.

If you use timestamps in the URL, you're going to need to make sure that the timestamp can't be tampered with (HMAC, AES-GCM etc).  Keeping credential data, encrypted or not, also represents a problem controlling information.  If you suspect your encryption key has been compromised, you can easily delete the credntials from your server.  If the credentials are in URLs potentially scattered all over the internet in browser caches etc, you won't be able to mitigate the leakage.

If you store the credentials in the database, along with whatever material you use to derive the key, you'll have much more control over the data.  Assuming you have your database application secured, it is arguably more secure.  I would suggest using different keys for each set of credentials, and using some kind of KDF (http://en.wikipedia.org/wiki/Key_derivation_function) to derive the key, instead of storing the key in plaintext in the database.  You could also include some portion of the key derivation material in the session id you issue to the user.

Of course, if someone has complete access to your server, including the database and/or the VA space of your CGI processes, the credentials will be comprimised, but that is true with nearly any solution.

If I were writing this application, I would use session ids to tie a user's requests to a set of credentials.  I would use a database table containing fields for the id, creation time, last seen time, username, password, and key derivation seed (this part depends on how you derive keys).  The session id I would issue to the user would be a large, hard to guess value (stored in the id field), combined with a portion of the material needed to generate the key (this material wouldn't be stored on the server, so both a valid session id and the material stored on the server are needed to decrypt the credentials).

For instance, a session id may look like this:

d7be62755db80ccefb7d802fde153145b6e9_bdb8f9bf599293fd65a020dba1ecd

The first part would be the id portion, and the second half part of the data needed to derive the key.

When a request is made, the id portion of the session id would be verified, and the decryption key generated using the key material portion supplied by the user (via the session id) and the portion stored in the database.  Once the key is generated, you'd decrypt and use the credneitals.

This way, if an attacker gains access to the database, they don't have everything they need to decrypt all of the credentials.  They'd need a session id for every set of credentials they wish to decrypt.

In order to age off sessions you could have a cron job, or some other mechanism, deleting expired sessions from the database.


Attack Web Forms dvwa to achieve lfi Does anyone know how to hack dvwa(http://www.dvwa.co.uk) via submitting a form input like ../../../../../etc/passwd to expose the /etc/passwd of a given server?

Is there a endpoint to hit for this?

Thanks

<?php

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
     $file=$_POST['filename'];
include($file);
}?>

    <title>test</title>

    <form method="post" action="index.php">

filename<input type="text" name="filename">

    </form>

This is usually the vulnerable back end code for Local file inclusion.If you intercept the request and change the filename parameter you can read data from the victim server.This code can also result in remote file inclusion if allow_url_include is turned on.


Is it a bad idea to share a private key generated from a self-signed root CA? Pardon if this is a noob question. I'm writing an authorization function to determine if a REST API request should be allowed to proceed or not. It is using a standard JWT passed in the Authorization: Bearer ... header. For unit testing purposes, I've created some dummy JWTs that will allow me to test my function in a variety of scenarios (e.g. JWT expired, sub not in database, etc.), and that are signed with a public/private key pair derived from a self-signed root CA created with mkcert.

The key pair is not being used to secure anything of significance. I generated them mainly so that I could interact with my local dev server (an alias of localhost) over HTTPS while doing web development (as described here). That being said, I have configured my local machine to "always trust" the self-signed root CA generated by mkcert.

If I decide to distribute my authorization function (as an npm package, for example), that would mean uploading my public/private key pair (upon which the unit tests depend) to an openly accessible location, i.e. a GitHub repo.

What are the practical implications of sharing a private key derived from a self-signed root CA? The FQDN is something like api.example.test. Would I be giving some clever attacker a vector into my local machine? Is there a different/better way for me to generate a public/private key pair that is okay to distribute along with a software library? Let's say somebody liked my authorization function and wanted to download my code and run the unit tests for themselves--would they even be able to run the tests without also having the root CA from which they were derived?

Thanks for your feedback!!!

Yes, it's a bad idea
When you create a Public/Private Keypair, you assign some trust to it. By publishing the Private key, you essentially also trust anyone who is able to download that key.
A better way
Furthermore, it's completely unnecessary. You can create a script which checks if debug.crt.pem and debug.key.pem exist and if not, you generate them. This means that anyone who downloads your code will generate their own self-signed certificate and deploy it themselves.
Will they get SSL errors? Yes, but that's normal and most developers expect them. If you publish your code on GitHub or a similar website, you could add an FAQ similar to this:

Help! I get an SSL error when attempting to run your code!
Yes, this is normal.  automatically generates a self-signed certificate when deployed for the first time. Since your computer cannot verify if this certificate is from a trusted authority, it displays an error.
You can proceed in several ways:

Save the self-signed certificate as a trusted End-Point Certificate
Use an already existing certific


Security wise, is it safe to use bluetooth headphones? I am connsidering getting bluetooth headphones for use with my PC and also ipad, my question is how vunerable am I with bluetooth on?

When asking a question of the form "How vulnerable does (thing X) make me?", you first need to consider what kinds of attacks you're at risk of being victimized by.

Possible Attacks

When using Bluetooth headphones, I can think of the following attacks you might be concerned about:

Traffic snooping (someone reading the data which is going over the connection, or just noticing that a connection exists at all - perhaps revealing that you're listening to something at that time)
Traffic modification (someone altering the data which is going over the connection)
Service disruption (preventing your headphones from working, probably by flooding the airwaves with random or spammy data)
Infiltration (using your PC or iPad's bluetooth capabilities to gain unauthorized access to the PC or iPad)

Let's consider each attack in turn:

This question here on security.stackexchange indicates that Bluetooth is encrypted by default. Many devices exist for capturing Bluetooth traffic as it passes over the airwaves, but the encryption means understanding your traffic won't be as simple as just setting up a Bluetooth sniffer and reading the traffic directly. On the other hand, I don't think there is a guarantee of a minimum key strength on the encryption -- the encryption isn't guaranteed to be strong. You'll need to read the specifications of your devices to find out how trustworthy the encryption is.

To listen to your Bluetooth traffic, an attacker would have to either break or bypass the encryption on the traffic which is likely only going to be feasible for an attacker of medium sophistication or better.

An attacker could merely note the presence of the Bluetooth connection. This attacker wouldn't know what is going over the connection, only that the connection exists. In context, this means the attacker would know your Bluetooth headphones are connected and are communicating with the connected PC or iPad. I suppose this might be usable to try to triangulate your position or determine if you're physically vulnerable (because you're distracted by your killer jams).
As stated above, your Bluetooth connection will likely be encrypted. This means an attacker seeking to modify the traffic must somehow subvert the encryption.

This is possible, but is even more difficult than the first attack type. I can only think of general techniques for doing this, not specific techniques Bluetooth is definitely vulnerable to right now.

The attacker might be running attack software on one of your Bluetooth devices so she can modify data as it arrives/departs, she might intercept your traffic then mirror it back out with modifications included, she might act as a relay between your two Bluetooth devices, etc.

All of these depend on the attacker's ability to rapidly decrypt / re-encrypt the traffic. Casual attackers probably won't have this capability.
Jamming Bluetooth isn't as easy as jamming, say, WiFi. It's possible, but it's illegal and requires specialized equipment / software which a casual attacker is unlikely to possess.
Yes, it is possible to use a Bluetooth connection to gain unauthorized access to a device but this is unlikely to happen to you.

Such a connection could, in theory, do anything any other data connection could do. Most concerning among these are: exfiltrating sensitive data, running unauthorized code, or causing the device to malfunction. Look up Bluesnarfing and Bluejacking for some details and examples.

However, and critically, there are many reasons to believe that this is not likely to happen to you. Modern Bluetooth devices generally require some kind of pairing sequence before they begin communicating with each other. This makes it difficult for someone with a Bluetooth device to connect to your device(s) without permission.

To bypass the pairing procedure, an attacker would have to find some kind of vulnerability in the stack of hardware and software which runs your Bluetooth connections. Really, an attacker would probably need to chain together multiple vulnerabilities to work her way from the Bluetooth connection itself into userspace or kernelspace on the target machine. This is very difficult!

A sophisticated attacker may be able to find and chain together such vulnerabilities, but most wannabe attackers either won't be able to find and exploit such vulnerabilities or will only be able to exploit well known vulnerabilities which a modern and well maintained device (like an iPad) will be secured against (always install Apple's latest security updates!)

Without such a vulnerability available, attackers can still contact your device and hope you give them access yourself. Defending against this is dead simple: Don't pair your devices with other unknown devices!

Assessing Your Personal Risk

It is up to you to decide which attacks you're most concerned with, nobody can decide for you how much risk you're taking. Try to consider the likelihood of the attack along with the severity of harm should the attack succeed.

For example, if you're a college student and the attack is a prankster roommate playing music you don't like, then the likelihood may be medium or high but the severity is low. Overall, the risk is probably not a big deal.

On the other hand, if you're a Chinese dissident living in Europe the likelihood of attack may be low or medium but the severity could be extreme (putting your contacts in China at risk of imprisonment or worse). Overall, the risk is strongly concerning.

Mitigating the Risks

You have choices for risk mitigation. You can painstakingly review the Bluetooth implementations in the devices you want to use so you know how new devices connect, how strongly the connection is encrypted, etc. Compare that against your personal risk profile and decide how much risk you're willing to bear in exchange for using the technology. Then you can choose to use the devices or not.

Critically, note that Bluetooth is generally considered to be "short range". These attacks require that the attacker (or the attacker's equipment) be physically close to your Bluetooth connection. This must factor into your mitigation decisions. If you will only use the Bluetooth devices in the country, far from other people, your risk is significantly lowered. If you will use the devices walking along crowded streets every day, your risks are increased.

My Recommendation For Most Users

Realistically, typical users have very little to worry about from using Bluetooth headphones. Unless you know you're some kind of special target (again consider the Chinese Dissident example), you probably can use the headphones without fear. At most you might consider turning off your PC's and iPad's Bluetooth connections when they're not in active use.

I've written this whole answer while listening to music with Bluetooth headphones. I use them nearly every day, in public and private (incl. well trafficked spaces like airports), and have never had a security problem because of them.


How do user receive server's certificate? Let's imagine our user's computer wants to talk to some server for the first time in history via https. The computer sends a hello message, the server sends his public key and the certificate, containing: server name, CA name, expiry date and server's public key hash, encrypted with the private key of the CA (aka digital signature).

But what stops a hacker from changing the "server name" in the certificate? Does the server encrypt all these fields with his (server's) public key? And how does the user know that the site he is going to visit corresponds to the certificate. Does the user compare URLs?

If the certificate is unencrypted - the hacker may send the user his own certificate, signed with the same CA, but with the server's urls field changed. So how does it work?

All certificates are signed in whole (protected against changes), so you can't change the name, or any other data inside it.

The certificate of the server you connect to is signed by the issuer certificate, which in turn may be signed by other certificates higher up, this is the certificate chain.  The top, aka root is signed by itself.  If you make any changes to any of these certificates, it won't have a valid signature anymore.  If you replace the public key and the signature, the certificates below can't verify using this certificate anymore.

The owner of a root certificate is able to change anything in their own certificate at will, so they can for example extend the validity (replace the expiration date), while still keeping all issued certificates valid.

The browsers are expected to have all current root, and some intermediate  certificates stored already, so you are able to verify all certificates issued by any of those with the security of how securely you acquired your operating system or browser (which may not be very safe, after all).

Whether users compare URLs is a different thing - the browser will warn you if you wanted to go to a site and the certificate is issued for a different name - but if the name you typed is misleading, and it has a valid certificate, it's still a problem.  CAs are expected to only issue certificates to names they can vouch for - and they invented those green EV - extendend verification certificates, which they check even more.

For example if you wanted to go to storemymoneypal, but mistyped storemymoneypai, and the site presented itself as storemymoneypaI (with a capital i at the end), it's hard to see the difference - this is what the verification is expected to avoid.  With unicode characters there are even more similar characters, but these dangers are well known, and any CA worth their salt to earn the trust of browser vendors will be aware of them.


Can an OpenVPN server track the client os type? I was wondering when I connect to an OpenVPN server what kind of information can the server extract from my client?

Obviously the server can detect my user-id, pwd, but can it detect:

My vpn-client-software (say would it know that I'm connecting using tunnelblick)?
My O/S (osx, linux, windows, etc)
My IP (I think the answer to this one is YES)
My mac-address (aa:bb:cc:...)

Not sure how the question @Ohnana has linked answer my question?

I'm not talking about a vpn server tracking my traffic, I'm asking if they can extract information about my machine and my client?

Agree with @Ohnana and I have some to add: it is possible via source tailoring to make an OpenVPN client "faceless", without any os/version/libs fingerprint. But if this openvpn is not used as a tunnel for another OpenVPN - first web browser HTTP plain session will tell everything about you


Hardening against Nmap and other network scanners It is possible to make Server respond with irrelevant data if it is scanned with Nmap? If yes, are there any examples of such SW?

Snort can do what you’re asking. It can detect various types of network scanning behavior, and apply rules to respond with whatever kind of packets or data you configure. Plus, one snort appliance in your network can protect all the systems in its scope, not just one server at a time.

It isn’t exactly what you asked, in that it’s not a modification to a web server, but that shouldn’t matter if it does what you need.


Trail of passwords for major websites over the internet I was curious about how passwords filled in the password fields travel from client side to server side. So, I started exploring online articles and using my own knowledge about networks and cryptography, I reached to a certain conclusion. But I still think I don't understand the full mechanism. This is what I know and correct me if I am wrong.
Today most web browsers use HTTPS which is TLS over the HTTP protocol. In this, a session is created between the two sides using handshake protocol in which keys are exchanged for encrypting data. So, when I log in or create a new account on Google, Facebook or elsewhere, these keys are used to encrypt data before the transfer.(including the password).
When the packet reaches the server, it decrypts the data (including the password). If it is a new account then the server stores the hash value of the password or the salted hash value. I am thinking during this time the password is in text form. In case it's an old account, the server simply checks the hash value of the password with the stored hash value of the client.
Is that all or do the websites take special care about passwords for the transfer? What is the situation when only HTTP is being used? What was the scenario before HTTPS came into the picture?

Since the generalization of HTTPS, most sites rely on the SSL/TLS encryption between the client and their site. Then as you said they only store a hash of the password. It is true that between the SSL endpoint and the actual processing, the password is in clear text, but it is assumed to be the same security zone.

In the older days (only HTTP), two ways had been used, none of which were perfect.

Digest variant of BASIC authentication.

The HTTP protocol has provision to transmit credentials in header fields, the so called basic authentication. The user name and password are combined with a single colon and encoded in a variant of Base64. And can be stolen by anybody able to access network data.

To add some privacy, people imagined to only send a hash of the credentials. This was the digest authentication specified in RFC 2617. In this mode, a hash (MD5) of the credentials combined with a nonce given by the server is transmitted. As MD5 is non invertible, an attacker cannot steal the original password. But the major drawback is that the password must be maintained in an invertible form on the server.
Javascript encryption of login forms

This is mainly a variant of the former for login forms. The credentials are hashed client side, normally with a nonce transmitted in a hidden field. Here again the passwords must be kept on the server in an invertible form.

As it is now generally accepted that it is more secure to exchange the plain text password over a secure line that only a hash on an insecure one, those two ways are no longer really used.


How would one make a network resistant to the unknown? I play in a game which includes normal risks, but also a wide range of supernatural powers which could affect the security of a network. These may be as prosaic as a retrieving data directly from a device's memory with a touch or as dramatic as sending one's mind directly into a network or constructing a small alternate reality where the laws of physics permit construction of a practical large-scale quantum computer. It is impossible to guess the limits of these abilities, as anything that is permitted in any chapter of the game may potentially come up.

Now, obviously, designing a system that can reliably defend itself against arbitrary unknown attacks that don't have to obey the laws of reality is a ludicrous endeavor. What I'm looking for are ways to make the system unknown-arbitrary-attack-resistant.

As an example, all critically sensitive information is kept on a separate network that is air-gapped from anything that connects outside the building. This would normally be an insurmountable obstacle to anyone attempting to compromise the internal network from the outside. However, I cannot discount the possibility that someone could cross the air gap. Ideally, accessing sensitive information should require an attacker to do at least two things that are practically impossible, just in case one of them turns out not to be.

So, without further ado, the parameters of the system:

The system has about ten users. They have widely varying levels of computer skills, and these skills may be decades out of date. They will want to run their own software, and they may outrank the sysadmin.
The users need to be able to access the internet mostly unfettered.
The users need to be access the internal network, but the access controls may be stringent.
Some areas of the building are public, but the secure parts are as physically secure as can be. For an attacker to gain physical access to the network can be safely counted as one "impossible thing".
Off-site backups are a must. Backup sites cannot be guaranteed to be physically secure.
Both networks may be restricted to known devices.
The outer network must permit remote logins from certain known mobile devices.
Files on the inner network will mostly consist of scanned books and papers. There may be many terabytes of such scans. It does not have to be particularly convenient to transfer data to and from the inner network.
Files may need to remain secure for many decades.
It may be assumed that there is a skilled individual monitoring the network for anomalies 24/7.
The budget for the network is around $100k, plus around $10k/year upkeep, unless there's a good reason to go higher. This excludes all labor costs.

Examples of the sort of defense-in-depth approach I'm going for:

Backup tapes are encrypted with AES-256, and then with a one-time-pad that is sent to the backup site beforehand.
The building exterior walls are lined with wire to form a Faraday cage.
The "panic button" physically detaches external network connections, rather than just deactivating them.
Old hardware is erased, degaussed, and set on fire.
All of the firewalls are cumulative – if a firewall detects a condition that should have been blocked by another system, it causes a text message to be sent to the sysadmin.

So, then, my question(s): What sorts of measures might be appropriate for a situation like this? What are some good "impossible things" to put in the path of an attacker? How can I design a system to take maximum advantage of defense-in-depth?

You've hit on the basic premise of IT Security: you can't predict or stop everything, and to try might cost more than what you are trying to protect. Your character is concerned with Mastery of skill to overcome higher-level obstacles, but the race to create obstacles that are higher than other people's skills is foolish in reality.

In reality, you need to ask other questions. What needs protection? What's the risk severity? What's the risk probability? What could be compromised without concern? How are the assets accessed? How can you employ CIA against those assets? You then lower the risks, probabilities, and costs to levels below the costs of the loss of assets.

To address your question directly, your concept of an all-powerful 'technomage' is fine, but it is easily countered with the idea of 'formlessness'. If you build a fortress, you can attack a fortress. However, if you are air, there is nothing to attack. The more you create 'defence in depth' with higher walls and tougher rules, the more fragile it becomes. An adaptive and regenerative system, on the other hand, is resilient to attacks. Least-privilege principles, internal honeypots, monitoring traffic leaving every node in the network, and classifying every piece of data that is to be protected will get you further than innovative design. (of course, all those things are considered 'innovative' by many)

Edit
By 'formlessness' (read The Art of War, Tao Te Ching), consider not having an all-power Admin on the network. Users, even administrators, should only have enough power to do their jobs and no more. When they need more power, give it to them to do the job, then revoke. No Admin means no Admin powers to usurp.


Is displaying a non-encoded HTTP Referer header vulnerable to XSS? Consider the following PHP script (it could be any other language; I chose PHP for simplicity):

<?php
echo $_SERVER['HTTP_REFERER'];
?>

Is it vulnerable to XSS?

Of course I can send a request to the script using curl and set referer to something like <script>alert(document.cookie)</script>. However, at least some browsers seem to encode referer, so if I for example redirect users to that script from the following URL:

http://example.com/<script>alert(document.cookie)</script>

the browser encodes referer and in result the PHP script outputs this:

http://example.com/%3Cscript%3Ealert(document.cookie)%3C/script%3E

Are there any browsers that doesn't encode referer? If not, can it be exploited in any other way?

RFC
RFC 1945 - which first mentions the referer header - specifies that referers need to be URL encoded:

Referer        = "Referer" ":" ( absoluteURI | relativeURI )
absoluteURI    = scheme ":" ( uchar | reserved )
[...]
uchar          = unreserved | escape
unreserved     = ALPHA | DIGIT | safe | extra | national
escape         = "%" HEX HEX
reserved       = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
extra          = "!" | "" | "'" | "(" | ")" | ","
safe           = "$" | "-" | "_" | "."
unsafe         = CTL | SP | <"> | "#" | "%" | "<" | ">"

The more up-to-date RFCs like 7231 are a bit more difficult to read as they cross-reference a lot, but it doesn't seem like they changed this rule.
So <, >, and " need to be URL encoded, according to the relevant RFCs. This was always the case, so even very old browsers should URL encode.
Note that ' does not need to be encoded - and is not encoded by modern browsers - and may thus be used for XSS attacks (eg go back).
In Practice
Even though the RFCs specify that <, >, and " need to be URL encoded, it is still a good idea to encode the referer yourself just in case.
Browsers should follow RFCs - and major browser such as Chrome and Firefox do in this case - but it's a good idea to still follow best practices - ie encoding - on your side just in case some browsers don't, or in case the RFC changes in the future (although it's unlikely).


Is there any evidence misusing the HTTP Pragma header in responses has any (unique) effect? I've been investigating the Pragma header, since there are already two other cache-busting HTTP response headers (Cache-Control & Expires), and I was interested in which browsers use(d) the old HTTP 1.0 one.

It turns out the spec only defines Pragma behavior (no-cache) for HTTP 1.0 requests, not responses.

The only specific browser mentions I can find is for IE4, which seems to require 32 KB of content before honoring it as a <meta> element, meaning that as a header it never worked even when that browser was relevant, and Netscape 4 which apparently also didn't work.

OWASP seems to be recommending this header, and a few big sites use it, but it seems a lot like it got started as a "just in case", was never actually supported, and perpetuated as a superstition.

Has anyone observed a reproducible (and desirable) change in behavior by using the Pragma HTTP header in a response, distinct from the functionality of Cache-Control or Expires?

Pragma is deprecated in favor of Cache-Control, but because of its common misuse as a response header there are clients and proxies who will interpret it as such.

Past squid versions are an example and starting with 3.2, Squid is advertising and attempting to fully support HTTP/1.1 specifications meaning pragma in a server response has no meaning whatsoever and will be ignored.

According to Microsoft KB234067, Internet Explorer 4.01 and 6.0 allow Pragma: no-cache in a secure HTTP response and a Pragma: no-cache meta tag via insecure response.  Other browsers such as Firefox seem to have spotty support of it.

Note RFC2616 states:

  Cache directives are unidirectional in that the presence of a directive in a request does not imply that the same directive is to be given in the response.

  Note that HTTP/1.0 caches might not implement Cache-Control and
        might only implement Pragma: no-cache (see section 14.32).