Is it possible to additionally sign a Let's Encrypt certificate with another self-signed root certificate? I have a certificate for my web service issued with Let's Encrypt.
Another service that communicates with my web service requires that my certificate must be signed with theirs, otherwise their client will abort the connection attempt.
Questions:

is it possible for them to "add" their signature to my certificate? Would the answer be different with other issuer than Let's Encrypt?
Does this process require me to share with them any secret values (like private key)?

Their certificate is self-signed and I suppose it is without Basic constraints (I think it matters here, but I am not an expert, hence the question...).
PS
I understand the inconvenience that it will have to be done every 3 months, but nonetheless, question remains valid.

is it possible for them to "add" their signature to my certificate? Would the answer be different with other issuer than Let's Encrypt?

there is nothing you need to do on your end. Remote party must use their own CA to re-sign Let's Encrypt CA certificate. Not yours. This will result in a cross-certificate with:

Issuer matches remote party's CA name
Subject matches original LE name
Public key/SKI extension matches original LE public key/SKI extension
Signature validated by remote party's CA public key
Other fields/extensions may be copied over or overwritten by remote CA. For example, they may add Name Constraints extension to cross-certificate to filter valid LE certificates that matches Name Constraints extension configuration (otherwise, they will blindly accept all LE-issued certs).

A presence of this cross-certificate will allow client to produce two chains:

Main chain that uses normal LE path that ends up with globally trusted root.
Alternate chain that uses created cross-certificate that ends up with remote party's root CA

Client application must be able to handle multiple chains and have an appropriate logic to select the proper chain (with their root).

I understand the inconvenience that it will have to be done every 3 months

no. Cross-certificate validity can match LE CA validity (though, not exceed) which is way more than 3 months.
And again, all this must be done on remote party's end.


What attacks can a subnet gateway perform on the subnet? What attacks can a subnet gateway perform on the subnet?

For example, my ip4 address is 192.168.116.34 and the gateway is 192.168.116.111.

What are the threats I am exposed to from a person sitting on 192.168.116.111
or if someone has changed his ipv4 to 192.168.116.111?

This is a tough question, as the answer to this question in a corporate environment will most likely be different than in a home environment.

An attacker having access to the same vlan/subnet you are on is usually very dangerous. Ignoring that the computer can try lots of tricks that only work with local access (arp attacks on the switch, computer spoofing, bruteforcing behind the firewall) I'd say you're most vulnerable to MiTM and DNS attacks.

For DNS: typically the home router defaults as the DNS forwarder to the ISP's recursive resolvers. If you now own the DNS, you can create fake websites and point people at them. Fake Banking site for example, and steal your bank creds. Always look for the Https symbol in your browser.

MiTM can be done by creating a route on the gateway to another device that will act as a proxy, and effectively as a MiTM host. Then traffic can be SSL stripped, exploits used against it that are only possible in this situation, etc.

Having your gateway get "owned" is very dangerous.


What is DROWN and how does it work? There is a new recent attack "on TLS" named "DROWN". I understand that it appears to use bad SSLv2 requests to recover static (certificate) keys.

My question is: How?

How can you recover static encryption or signature keys using SSLv2?

Bonus questions: How can I prevent the attack from applying to me as a server admin? How could the attack spawn in the first place?

To understand the attack, one must recall Bleichenbacher's attack from the late 20th century. In that attack, the attacker uses the target server as an oracle. When using RSA-based key exchange, the client is supposed to send a secret value (the "pre-master secret") encrypted with the server's public key, using PKCS#1 v1.5 padding (called "type 2"). Bleichenbacher's attack relied on sending carefully crafted values in lieu of a properly encrypted message, and observe the server's reaction. The server might respond (most of the time) with an error saying "I processed that but it did not yield a proper PKCS#1 v1.5 type 2 padding"; but sometimes, the decryption seems to work and the server proceeds with whatever it obtained. The attacker sees that difference in behaviour, and thus gains a tiny bit on information on the private key. After a million connections or so, the attacker knows enough to perform an arbitrary decryption and thus break a previously recorded session.

This attack is of the same kind, but with a new technique that relies on the specificities of SSL 2.0. SSL 2.0 is an old protocol version that has several serious flaws and should not be used. It has been deprecated for more than 15 years. It has been even formally prohibited in 2011. Nevertheless, some people still support SSL 2.0. Even worse, they support it with so-called "export" cipher suites where encryption strength is down to about 40 bits.

So the attack works a bit like this:

The attacker observes an encrypted SSL/TLS session (a modern, robust one, say TLS 1.2) that uses RSA key exchange, and he would like to decrypt it. Not all SSL/TLS sessions are amenable to the attack as described; there is a probability of about 1/1000 that the attack works. So the attacker will need to gather about a thousand encrypted sessions, and will ultimately break through one of them. The authors argue that in a setup which looks like the ones for CRIME and BEAST (hostile Javascript that triggers invisible connections in the background), this collection can be automated.
The server carelessly uses the same RSA private key for a SSL 2.0 system (maybe the same server, maybe another software system that may implement another protocol, e.g. a mail server). The attacker has the possibility to try to talk to that other system.
The attacker begins a SSL 2.0 handshake with that system, using as ClientMasterKey message a value derived from the one that the attacker wants to decrypt. He also asks for using a 40-bit export cipher suite.
The attacker observes the server's response, and brute-forces the 40-bit value that the server came up with when it decrypted the value sent by the attacker. At that point, the attacker knows part of the result of the processing of his crafted value by the server with its private key. This indirectly yields a bit of information on the encrypted message that the attacker is really interested in.
The attacker needs to do steps 3 and 4 about a few thousand times, in order to recover the encrypted pre-master secret from the target session.

For the mathematical details, read the article.

Conditions for application:

The connection must use RSA key exchange. The attack, as described, cannot do much against a connection that uses DHE or ECDHE key exchange (which are recommended anyway for forward secrecy).
The same private key must be used in a system that implements SSL 2.0, accessible to the attacker, and that furthermore accepts to negotiate an "export" cipher suite.Note: If OpenSSL is used and not patched for CVE-2015-3197, even if "export" cipher suites are disabled, a malicious client can still negotiate and complete a handshake with those disabled cipher suites.
The attacker must be able to make a few thousands or so connections to that SSL 2.0 system, and then run a 40-bit brute force for each; the total computing cost is about 250 operations.

It must be well understood that the 250 effort is for each connection that the attacker tries to decrypt. If he wants to, say, read credit card numbers from connections he observes, he will need to make a non-negligible amount of work for each credit card number. While the attack is very serious, it is not really practical in that CCN-grabbing setup.

The solution: don't use SSL 2.0. Dammit. You should have stopped using SSL 2.0 in the previous millenium. When we said "don't use it, it is weak", we really meant it. It is high time to wake up and do your job.

Supporting weak ("export") cipher suites was not a smart move either. Guess what ? Weak crypto is weak.

Deactivating SSL 2.0 is the only right way to fix the issue. While you are at it, deactivate SSL 3.0 as well.

(And that fashion of using all-uppercase acronyms for attacks is really ridiculous.)


Are there any transaction time constraints in EMV contact and contactless cards? I am looking into EMV Contact and Contactless protocols, but I felt there were a few ambiguities which I would appreciate help with:

Is the chip used in EMV Contactless capable of performing the same computations as the contact? I know that the contactless is based on ISO 14443 while the contact is ISO 7816 but they don't really specify in the docs if the 2 chips can actually perform the same tasks...

Aren't there any time constraints for any action done by the card? I'm looking for an action that the card performs that has an upper bound of time, (e.g. I would expect signing dynamic data to take some time but I don't know if EMV have actually set an upper bound to this as a standard in their docs)

Contactless card uses the same chip and PIN module as in contact card. The difference between them is in the medium of communication with the terminal and in application selection. Contactless cards store additional cryptographic keys to authorise contactless transaction. As their keys are separate, the issuer can disable contactless payment by always rejecting contactless transaction authorisation request but still allowing contact payments. Some banks offer this opt-in feature to prevent unauthorised use of stolen contactless cards.
In contact payment, there are no time constraints. Contact card can even tell terminal to wait and call it again after some seconds and then it can do this indefinitely (21:01). Some terminals can also tolerate few seconds round trip delay (23:18) because contact cards are slow (600 bits per second (23:56) and transaction can be few bytes long).
The recommended transaction time for contactless payment is 500ms but it is not globally enforced by the issuers as terminals can itself add latency in processing. Most of the contactless payments take 330ms - 637ms and some terminals can allow max transaction time upto 52 seconds (16:30). This out of specs implementation is to maintain compatibility across card issuers and PoS manufacturers (In UK alone, there are almost 300 approved chip and PIN terminals). This is why relay attacks are successful.
However, there is a max allowed time length in Distance Bounding Protocol which combats relay attacks. Distance bounding is in the EMV contactless specification and Mastercard has taken up this defence, meaning its cards (at least) are protected.

ICC does not have an internal clock. For signal processing and I/O modes, ICC relies on clock signal provided by the terminal.

I/O line can be switched to (reception mode) receive data from the terminal or to (transmission mode) transmit data to the terminal.

EMV Book 1, 7 - Physical Transportation of Characters

During the transaction process, data is passed bi-directionally between the terminal and the ICC over the I/O line in an asynchronous half duplex manner. A clock signal is provided to the ICC by the terminal, and this shall be used to control the timing of this exchange.

ICC cannot measure the time between two command.


Secure Boot on Microsoft Surface Pro 3 (or modern PCs)? Got a Surface Pro 3 today (it's awesome BTW!) and noticed in it's EFI that it's got

TPM enabled,
"Secure Boot" enabled (unsure what such an umbrella/catch all term actually covers)

And then in Windows 8.1, it's got

BitLocker turned on

I was a little surprised that the OS was able to bootup completely (to user login screen) without any input from the user; meaning all keying material is resident and available to the machine without user intervention. It also made me reflect a bit on the process so thought I'd post this here.

Question: Can someone enumerate the secure boot process (as implemented on modern PCs) and how the chain of trust is established and maintained?

Finally, how does this give the user any assurance that their machine hasn't been compromised behind them? (like Evil Maid etc)

Boot Process

Secure Boot

There are quite a few steps to booting Windows 8.  Now secure boot in general means that the boot loader is only run if its integrity can be checked.  In this case, if enabled, the UEFI is started before anything else and checks that the boot loader is signed by a trusted Certificate Authority.  For an operating system generally only the manufacturer is trusted, e.g. Microsoft.  As long as the boot loader is signed by Microsoft, and verified by the UEFI then the boot loader is started.  Even the UEFI drivers are verified[1].

The EUFI contains a database of registered trusted authorities.  Users can add their own trusted authorities to this database in order to enable the loading of non-Microsoft operating systems.

This is where Trusted Platform Modules (TPMs) are used.  TPMs can be used to store keys, or perform encryption/signing/verification routines.  The TPM combined with the UEFI is what allows for the verification of the boot loader, and the loading of an operating system.

Trusted Boot
Now that's not the end of a secure boot process.  Now that the OS is in a trusted boot state it begins loading the kernel, system drivers, etc.  Secure boot also ensures that the system drivers are signed by a trusted certificate authority (e.g. Microsoft).

Full description of the image above

Why?

Rootkits
At each stage of the boot process certain pieces of code (drivers, system services, etc) are being registered with the operating system.  The earlier in the boot process that malware can hook in the more likely they can:

Persist: even on reboot, the malware is re-enabled
Hide: put itself in a position to stealthily keep the operating system (and antivirus) from noticing its there.
Privileged: continue to grant high permissions to itself

All of these boot processes are run at the highest privilege.  Without a secure mechanism for trusting these loaders rootkits could install themselves with high privileges, and the system wouldn't even know they were there.  Requiring signed boot loaders and system services/drivers decreases the chances that a rootkit can get a foothold into your system.  This does not mean that it's 100% secure, it just makes it a lot harder at certain stages of booting.

Evil Maid

Evil Maid is based on the premise that a hacked boot loader can be installed on the system to do mischief, keylog the password used to decrypt the volume, etc.  This is exactly the type of attack this process is meant to prevent.  A boot loader could not be flashed on here and successfully booted unless it was signed by Microsoft (or some other trusted authority IF the user decides to trust someone else).  This seems fairly unlikely, and it would be unsafe to add a trusted 3rd party to the EUFI database.

Could a piece of hardware come with other trusted authorities installed from the distributor?  Maybe, but that's a whole other level of paranoia.  If you're worried at that level then you're probably doing something wrong in life.

Enabling User Authentication

The guide above can guide you through enabling a TPM on Windows 8, and setting a password for it.  I'm unsure if this also applies to tablets.


How to add a cookies parameter to Dotdotpwn script Do you know how I can add a specific cookie parameter like "access token" to dotdotpwn script?

Without this, I have that output "Web server (xxxx) didn't respond !"

According to this github issue dotdotpwn isn't designed to have a cookie option. Although you can use -p option to specify your payload which can be a file that contains your request which may contain cookies. You can find more info about the payload module here and you can also check out some sample payload request files on the github repository.


Full disk encryption for UEFI non-OS GPT drives? (VeraCrypt) Is there a way to fully encrypt UEFI GPT non-system drives?

I'd like to use the open source successor of TrueCrypt VeraCrypt.

Also I'm interested in whether it also works for two drives that were virtually merged into a single drive.

1.18 supports UEFI for boot volume

It is better to use VeraCrypt 1.20B2 from sourceforge

Ordinary data volumes on GPT disks work also.


Security category of command injection attacks? To which (STRIDE/CIA+AAA) security category do command injection attack belong?

Or is my question too simplistic? Does it depend on the specifics of the injection attack (trying to get at confidential information, trying to cause a denial of service), or should it be thought of as tampering (compromise integrity of user input) or elevation of privilege (having some program (the web server) perform an action with their privileges on your behalf)?

Command injection attacks don't fit nicely in the STRIDE framework or in the CIA/AAA paradigm, and there's a reason for that.

The CIA/AAA paradigm provides a set of goals of information security, and it's not meant to characterize attacks.

As for the STRIDE model, it provides a classification of threats for threat modeling purposes. However, that is just the beginning of threat modeling.

In fact, threat modeling often uses threat graphs, or other representations, to identify all the possible threats to a system starting from the broad STRIDE category.

Example. For the Information disclosure category, what kind of information can an attacker disclose? For each kind of information, what different cases should be distinguished? For each such case, what kind of attacks could be successful?

In this way, threat modeling is not tied to specific vulnerabilities and also allows to understand how many threats could a given patch fix. It's very useful.

So, the STRIDE model is just the beginning of threat modeling, which explains why specific attacks (like command injection) don't fit nicely into it. But, in the particular case of command injection attacks, there is another reason.

The point of command injection is that an attacker can send commands to a system. Therefore, a command injection attack could be used to do anything, from erasing logs (Tampering), to carry out a DDoS (Denial of service), to privilege escalation, to information disclosure (see SQLi,...), and much more. Basically, the whole STRIDE model, and the whole CIA/AAA paradigm.

One may argue that command injection is the most general attack ever, since it simply means that the attacker has the capability to send commands to a system. The purpose of these commands is the real threat.


Risk assessment Struggling with scenario I have been given a situation (see below),The question i need to answer to complete the task is: What is the ALE for phishing emails for the company, in pounds; e.g. 203,760? When i multiply the answers i have ARO * AV * EF = 38631600. This answer comes back as incorrect and i am struggling finding the correct:

Asset Value - AV (I get £1575000 - £225*7000)

Exposure Factor - EF (I get 0.01 - 225 is 0.01% of 1575000)

Annualised Rate of Occurrence - ARO

80*7000*365 = 204400000

204400000 * 0.2% = 408800

408800 * 30% = 122640

122640 * 2% = 2452.8

  Phishing is of major concern to an organisation, so they have begun to
  monitor how big a risk it is posing. On average, 80 phishing emails
  are sent to everyone in the company per day. The company email filters
  stop 99.8% of these getting through. Of the emails that do get
  through, 30% of employees click on the link. Out of those employees,
  2% expose their company login details to the phishing website. For
  every set of company login details that are exposed to the hackers,
  the company has found that it costs them £225. The company has 7,000
  employees.

Thanks goes to Davy Strain for providing this answer.

The SLE is given in the data so no need to work out the AV/EF, i was overthinking the data.

SLE = 225

Annualised Rate of Occurrence - ARO

80*7000*365 = 204400000

204400000 * 0.2% = 408800

408800 * 30% = 122640

122640 * 2% = 2452.8

ALE = ARO 2452.8 * SLE 225

=>ALE = 551,880


Length of CSRF Token Is there any standard length of the token which should be used while generating the random tokens? Should we use the same standard which we use for generating Session IDs?

I would consider a 128 bits of entropy in a token to be the de-facto standard. OWASP and CWE both recommend this as a minimum. 20 characters of Base64 (capable of 120 bits) is also handy for something in the URL. I would also note that in many cases poor seeding for those tokens creates problems. For one bit of reference, see the (kind of tastelessly decorated, but very informative) slides from http://samy.pl/bh10/.

Make sure you choose your entropy source well.


TLS- Concept of channel binding TLS-Handshake is based on public-key cryptography for symmetric key exchange, pki for server-authentication and assume the user authentication is realized trough username and password in the application layer. Wich authentication will be bind at the lower layer when channel binding is used?

In RFC 5929:

The concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer. This allows applications to delegate session protection to lower layers, which has various performance benefits.

What are the advantages of channel binding? Can someone please explain channel binding easily? Maybe with the channel binding type tls-server-end-point as an example?

One of the motivations for channel binding is to prevent an attacker who is able to capture users' authentication credentials (e.g. OAuth tokens, session identifiers, etc) from reusing those credentials in another TLS session.  By tying these credentials to a unique fingerprint of the TLS session in which they are used (by way of channel binding), they cannot be reused in another TLS session initiated by the attacker.

For more information:

See "FIDO TechNotes: Channel Binding and FIDO"
for information on how channel binding is used with FIDO
authentication for this purpose.
See "Secure modular password authentication for the web using channel bindings" for information on a PAKE-over-HTTPS implementation that uses channel binding to secure the session.


Is it "normal" to find procedures in the middle of a .mov file with a disassembler? I used hopper disassembler to see if there was any strange activity on this particular mov file. What was bizarre and unexpected was
This .mov file is particularly strange such as it seems to lower the audio quality on people's computers who play the video.

I found processes in the middle of the file which I thought would just be data. Is this normal?

It is kind of cool because the code is way too organized to just be random data.

The only thing that makes this credible is the large amount of x86 jump-like 'opcodes' in the video (7a-7f). What makes it less likely is the memory addresses: the pointers in that piece of disassembly reference edi + > 0x75000000 and - > 0x50000000. This is not entirely impossible, but is highly unusual. If you look at the top instruction, AAD, this is entirely out of place:

  The AAD instruction is only useful when it precedes a DIV instruction that divides (binary division) the adjusted value in the AX register by an unpacked BCD value.
  http://x86.renejeschke.de/html/file_module_x86_id_2.html

So my impression is that you simply have a very forgiving disassembler that will try to make sense of anything you feed it. If you're still unconvinced, give us the file so we can look at it.


Monitoring the HTTP(S) calls being made from android App I want to test for security vulnerabilities in an Android App and hence want to monitor all HTTP(S) calls being made from an Android App.

I have setup BurpSuit in my Laptop and have also set up the proxy in my Android device. After installing the Burp certificate in the user trusted certificates I am able to monitor the HTTP(S) calls properly for Website and almost all apps.

But some apps are showing error by stating "Could not connect. Please check the internet connection.".

I am using an Android 5.0 non-rooted device.

Any help would be grateful

Some apps are configured with hard coded CA certificates or internal certificate stores. This means you can't make them trust your certificate by adding a CA in the shared certificate stores. This is quite common security measure e.g. in the financial industry.


How to make the most secure text editor in Django? As a follow up to this question, I'm wondering what is the most secure way (using either markup or markdown) to allow users to format their inputs and upload images in a Django app?

I'm not asking about detailed step by step guide, but rather the strategy that I should adopt, and possibly available apps/libraries to use.

UPDATE: By most secure, I mean immune to XSS and other common attack vectors against text editors.

Regardless of framework or language, there are some things you should consider:

What functionality do I need (or want)?
How can I balance the features with Principle of Least Privilege?
What resources do I have that can be limitations?

My response is going to be language-agnostic because these principles are going to apply regardless of whatever language or framework that you are using.

From your post, you want to have the ability for users to add comments (such as what's here on SE) and upload images. There are a few common methods of doing this.

HTML controls for users (bad idea)
BBCode or similar markup (can be effective, but annoying for users)
Markdown or RST (both are built to be more natural)
Plaintext (won't allow for UI formatting)

As Wordpress and other applications have demonstrated, allowing users to post HTML code is a Bad Idea(tm). If you want users to have UI formatting, plaintext is the safest, but won't allow for UI formatting. So that leaves BBCode and Markdown as the two remaining common solutions. SE uses Markdown. It's more natural for users to type than it is [b]Blah[/b] because for emphasis, users would type **blah** for bold text anyway. This of course is not the only method, but it does greatly reduce (but not eliminate!) XSS. So why not eliminate? If you aren't careful with your Markdown (or whatever markup language you choose) parsing, you can end up with XSS attacks in links. Most use cases only need http and https protocol handlers in URLs, so you have an opportunity to exercise Principle Of Least Privilege there.

As for uploading images, this can be a bit more difficult. This is where the resources I mentioned come in. Do you have the ability to purchase a sandbox domain? If you do, in addition to processing images, you can serve them from a sandbox domain so that you limit exposure for XSS, RCE, and other attacks. A sandbox domain is one that removes content from the origin of the application. For example, www.google.com applications (Gmail, Google Docs) use googleusercontent.com as the sandbox domain. This domain's sole purpose is to serve user-provided content. Google cookies and DOM are not accessible because the origin is different. Further, this domain should serve content from a server that does not have the ability to do anything other than serve static content, so PHP code cannot be embedded in to the images, or a vulnerability in image processing would not impact your database and application code.

Image processing? Another best practice is to pass image uploads through image processing. If you only expect JPG and PNG for example, this is easy. You can resize an image 1:1, and it will fail on broken images, removing much of the XSS vectors and RCE vectors.

As you've no doubt noticed, my response has been about layering defenses. When you consume user data, there's no panacea. You have to weigh the risks, wanted features, and how to best limit the exposure of the features you want to give users.


Do moved files leave a trace on the drive they created on? I have created a word document on my computer, or any other file like txt, image, PSD etc. Now, I then take that file and move it to an external device, would that file leave a trace on the computer? Is it recoverable on the computer?

YES, the files are recoverable even when they are moved or deleted from the disks. Let's begin with how OS places files in the hard disks. Files are saved on the hard disk in small chunks. These chunks may be scattered all over, rather being placed in contiguous manner.
Your File Manger of the Operating System keeps track of the files by knowing the addresses of all the chunks. These are inodes number, you can think of them as pointers.
When you delete a file, what your OS does is simply remove the data it has stored about these inode values. So, what really happens is that all the links are removed from the table of File Manager System that keeps tracks of the file. The important thing to observe is that the data is still there. HDDs never delete the data, they are always overwritten.
On a general level what recovery tools do is simply check for data on the disks that have no inode values pointing towards them. They use complex algorithms that help them to create something meaningful, such as a file with those small chunks.
It is even possible to recover the data even when you have overwritten the particular block with some other data. In case you are using Hard Disk Drives (HDD) data is stored in the form of magnetic waves. This is binarized prior to being processed by the processor. There are four possibilities when data is overwritten once. Two are when, initially the bit was 0 and then written with 0 or 1, two more when initially it was 1 and then overwritten with 0 or 1. These four values will give different traces on the disk. So, what usually a recovery tool does is simply create four regions via different thresholds and decide what the previous value was. This can be extended when data is overwritten multiple times.
You might have observed that the while formatting your disks or USB you are given two options, one is the fast format and one is the slow format. In the case of fast format, only the links are removed. In the case of slow format, the OS rewrites all the blocks multiple times with random data. This is a secure way of formatting a disk. A number of times this iteration goes can vary with OS and command (or utility) you are using. You can use UNIX command shred, which is a part of GNU core utilities.

  shred -n 100 filename

By default, shred overwrites 25 times, but by using -n you can decide the value.

Edit: Solid State Disks (SSDs) have a very different mechanism of working when compared with HDDs. In SSDs whole storage unit is divided into blocks or pages, and each block can be asked to read/write. These blocks are index-addressable just like an array. Thus there is no overhead for data access as it was the case in HDDs. In order to write anything in these blocks, you need to delete the data first. OS of your device don't access all these blocks directly, instead, it talks to the microcontroller present in the SSD or Flash drive. This microcontroller keeps track of all these blocks using a table (or map). Since deletion takes a lot of time thus, the microcontroller of the Flash drive dynamically maps the requested location for write on some other block which is empty and keep a log for itself to delete the data in the block (that was asked) sometime later. This is what allows the room for recovery even when you have deleted your data. For more details, you can go over this paper.


How can I view the NTFS $MFT using correct field names? I am trying to view an NTFS master file table. Each tool I have used so far extracts all of the entries, but puts non standard headers such as STANDARD_INFORMATION_ON instead of say $STANDARD_INFORMATION.

I have tried MFT2CSV, ntfswalk64, and MFT_Parser, but I would like a tool that gives me the MFT in a rawer format, so I can see the entries as they are suppose to be, even if I can't read the timestamps without decoding.

Does anyone know a more accurate and rawer tool?

Try this PDF: NTFS Forensics: A Programmers View of Raw Filesystem Data Extraction by Jason Medeiros,
Grayscale Research 2008

It should answer your questions.
Also, you can read your image with a Hex editor... Well, good luck with that.


how do we encrypt 100bits of plain text to get 100bits cypher text using DES? We have a scenario like that we need to encrypt 100 bits of plain text using encryption algorithm like DES (algorithm takes 64bits plain text block and generate 64 bits of cypher text block, key using for encryption is 56bits) and want 100bits of cypher text.

My question by using this scenario: Is the encryption algorithm only encrypt 1st 64bits of plain text and left rest 36bits unencrypted ? If no, then what is the process in this scenario?

or:

In simple I want to encrypt 100 bits of plain text and want result in 100 bits of cypher text, using algo DES (algo takes 64bits plain text block and generate 64 bits of cypher text block, key using for encryption is 56bits)
what is the process?

DES is a block cipher, which means that it processes blocks of a fixed size. When you want to encrypt a message, i.e. a sequence of bits whose length is not necessarily that of a single block, you need to apply a mode of operation that applies the block cipher "properly" to encrypt and decrypt a message.

The Wikipedia page has nice schematics. Each mode of operation has its own requirements on the input length; for instance, the CBC mode requires that the input length is an exact multiple of the block size. Thus, CBC requires some padding and invariably results in a ciphertext that is larger than the plaintext. Some other modes can do an exact bit-to-bit encryption (encrypt k bits into exactly k bits, for all k), notably OFB, CFB and CTR. CBC can also be made padding-less with CTS ("ciphertext stealing") as long as the input size is at least as long as a block.

Note, though, that almost all modes of operations need an Initialization Vector, which must be chosen by who encrypts and conveyed to who decrypts; if the IV cannot be inferred from the context, then it must be transmitted, which increases the network requirements. IV selection is crucial for security; some modes need a fully random, unpredictable IV, while some others can achieve security with a non-repeating IV, but a fixed, hardcoded IV will usually be no good at all.

An IV-less mode that turns 100 bits of plaintext into 100 bits of ciphertext would need to be deterministic (this is a mathematical necessity); thus, such a mode would necessarily reveal if two encrypted messages are identical. This may or may not be a problem, depending on usage context. A secure IV-less mode is an IV-less mode that leaks exactly that information but no more. To my knowledge, there is no standard for a secure IV-less mode, but there are some known academic constructions (this one can be made practical; that one is theoretically "better" but a lot less practical).

There are still some remarks to be made. First and foremost, DES is obsolete and weak, precisely because of its key length: the 56-bit key is within reach of an exhaustive search (substantial effort, but achievable, even by amateurs with a moderate budget). 3DES is much stronger, but also three times slower (while DES was already quite slow in "normal" software). Both DES and 3DES use 64-bit blocks, which are a bit too narrow (this can raise security issues when encrypting lots of data with a single key). 3DES is also deprecated; modern protocols should use AES, whose blocks are larger (128 bits), avoiding these security issues. AES is also substantially faster than 3DES.

Also, encryption need to be applied in contexts where there is a need for confidentiality against eavesdroppers. In most such contexts, the attackers can also be active, i.e. alter data in transit. Alterations can be reliably detected through the use of a MAC, but this necessarily increases the message size (again because of the pigeons). Combining encryption and MAC is not easy at all, and successive messages must be somehow "linked" together to defeat replay attacks and other alterations at the packet level. All of this is supposed to be handled by defining a secure protocol: a protocol is an assembly of elementary cryptographic algorithms (e.g. AES) to provide some well-defined security properties. An example of a protocol is TLS. Designing a secure protocol is even harder than designing a secure algorithm; even implementing an already defined protocol is hard to do properly (i.e. without leaking secret information).


How secure is PIN code + substitution authentication? A website make me choose a 4 digit PIN code and then the authentication is done by substituting each digit with the corresponding letter from a randomly generated picture.

How secure is this type of authentication? What are the possible benefits from this solution in comparison with classic password authentication?

It's not secure, because there are only 26 ^ 4 possible solutions. This can be brute-forced. If the picture includes capitals, we can increase this, but even 52 ^ 4 is a very small search space.

I'm assuming that it gives you a different picture at every logon attempt, but that does not effectively make the search space smaller.

However, there is one advantage to this scheme - it prevents replay. You will enter a different letter combination every time, so if an eavesdropper intercepts your input, they can't use that combination again.

Unfortunately, that assumes that the attacker gets your input but not the picture. This is an unlikely scenario, an eavesdropper (whether MITM or shoulder-surfing) is likely to get both. It does offer a little protection if all the attacker has is a keylogger on your system.

So, this is an interesting idea to prevent replay, but poorly executed.


Is it really Security Misconfiguration to show a version number? Our web application uses a HTML file with jQuery embedded inside.
According to the jQuery license (https://jquery.org/license/), we have to leave the license header intact, including the version number.

Our client reported exposure of the product and version combination as a security risk. Strangely, the bootstrap version in the same file is not reported as a security risk.

Many applications use libraries with version numbers inside. It's even possible to get version numbers by running some code in Firebug or Chrome's Developer Console.

In what circumstances does this "security misconfiguration" (https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration) apply to displaying product and version number? And how can we resolve this issue without violating the jQuery license?

The security impact of exposing the version number is that an attacker can instantly see whether your version is vulnerable to a known vulnerability. For example, jQuery before 3.4.0 is vulnerable to CVE-2019-11358, so it is useful information for an attacker to know whether your jQuery is 3.3.9 or 3.4.1.

However, with JavaScript that runs in the browser the complete source code is accessible by the attacker, so it is impossible to hide whether your jQuery is vulnerable. Even if you hide the version, the attacker can compare the code, or just try an exploit, to determine whether you are vulnerable. Hiding the version number may make it slightly more work, but realisticly it accomplishes little.

Furthermore, there are other ways to mitigate this:

Keep in the loop about security problems in the libraries you use. Subscribe to a mailing list or another publishing method for security problems.
Update the client libraries whenever a security problem is identified.

If you always have a non-vulnerable version because you update regurarly, it is no problem that the version is disclosed. And you can tell your client that this is the  way you mitigate the information disclosure.


B2B authentication best practices I'm in the process of developing a B2B (business-to-business) application. I've implemented JWT auth, and it is working as expected. Right now the authentication functions as if it were a B2C (business-to-customer) app.
I'm trying to determine the best practices for B2B authentication.
Is having one authentication account bad practice in a B2B app? For example, every employee at Company A would use the same set of login credentials.

Regardless of the type of application, having only one set of credentials is certainly bad practice. For starters, since it's shared, it's more likely to be treated less carefully; e.g. written down in places where people are likely to see, and thus could more easily fall into the hands of an attacker. Once the password is compromised, it's a bigger deal to change it since you need to notify everyone.
It also greatly reduces your ability to audit user activities; without an unique user ID, you can't track who is doing what.
If the company already uses a central authentication service (e.g. active directory/LDAP) or single-sign-on (SSO), it would be ideal to instead rely on that for authentication, with the added benefit that all the user information is already there, as well as group/permission information.


Heartbleed - Read only the next 64k and hyping the threat My understanding of the Heartbleed vulnerability is that there is no bounds check on the payload length/buffer size so the server can read into memory outside of its process space.

But can the start address be modified?

If not, then the probability of snagging anything interesting from a server with gigs of RAM, where much of the time that space may not change, is far less likely than if any 64K space can be read.

This article seems to sensationalize the impact from a rational discussion of probability to a stance of "you cannot trust anything; your server RAM has been 100% exposed for years".

https://www.schneier.com/blog/archives/2014/04/heartbleed.html

Granted, 64K is a fairly large chunk, enough to store 3,200 SHA1 hashes, but on a 4Gb server, its still only 1 / 67,108th of the total address space - is the threat being hyped?

The 64k block that gets returned is selected effectively at random, which seems like it would make it hard to find worthwhile data.  However, there are two factors that significantly increase the threat:

First, the attack won't return memory that was allocated during program start-up.  This means the area occupied by boring things like program code won't show up in attack results; likewise, the half of the address space reserved for the operating system won't be returned.

Second, because of how memory allocation is done, the 64k block will tend to come from recently-used memory.  For example, if a server handles a lot of login attempts, the memory is likely to have been used for a recent login, and could very well contain a username/password pair or two.  Good timing might get you memory used to set up the SSL connection, and you might be able to find an SSL private key in that.

A third point is that the attack can be performed quickly and repeatedly -- and is almost impossible to detect.  A home internet connection might be able to hit a server with tens of thousands of heartbeat requests per second.


Is using "SHA-256 with RSA-2048 Encryption" a secure certificate hashing algorithm? Is using "SHA-256 with RSA-2048 Encryption" a secure certificate hashing algorithm? I don't think it is. Two examples: nsa.gov [careers site] give.wfp.org

The technical answer is actually "no, because SHA-256 with RSA-2048 Encryption is not a certificate hashing algorithm. However, SHA-256 is a perfectly good secure hashing algorithm and quite suitable for use on certificates, and 2048-bit RSA is a good signing algorithm (signing is not the same as encrypting). Using 2048-bit RSA with SHA-256 is a secure signing scheme for a certificate. Why would you think otherwise?

SHA-256 is a member of the SHA2 family of secure hash functions, and there are not currently any cryptographic weaknesses publicly known for SHA2. It might be less secure than SHA-512, but 256 bits is already completely impractical to brute force (we're talking about timeframes of hundreds of years even with the resources of a nation-state and assuming Moore's Law continues on track, or billions of years for currently-established technology). The only viable attacks would require finding a weakness in the hash algorithm itself, and it's not necessarily the case that SHA-512 would be more resistant to such an attack than SHA-256. There is a new SHA3 standard, but it's not yet widely implemented so your browser probably wouldn't be able to verify the certificate's signature at all if they used SHA3 in the signing algorithm.

RSA is a current standard for public-key cryptography, and a properly-generated 2048-bit RSA key is strong enough to resist factoring for decades. You could use a 4096-bit key if you want to (it'll take a lot longer to generate, and slightly longer to use, but once the certificate's signature is verified that doesn't matter anymore), and that would take even longer to break. However, neither certificate is valid for more than two years anyhow. If you want a signature you can trust for 30 years or more, you might want to use something stronger than 2048-bit RSA, but for now that's fine.


How to configure Burp suite in browsers while my internet connection works behind proxy.? I could not able to configure burp suite with browsers. If I use manual connection settings in browsers,I could not load any site.Because my company uses proxy.

Following Methods I have tried but fails:

I have set manual proxy as "127.0.0.1:8080" but my browser could not load any site after that proxy change.Though burpsuite works at that time.I can able to see requests.Let me know how to configure this burpsuite with browsers?

Burp can use an upstream proxy server.  You would set up your browser to use your burp instance (usually localhost:8080), and in Burp's options, you can set your company's proxy server (say: proxy.company.com:8080).  All traffic will pass through your company's server, after it has been handled using Burp.

To help auditing both internal (intranet) and external web applications, you can set conditional proxy servers


Call and Unsolicited One Time Passwords Context:

I got a call from a US phone number from a guy claiming he was from a dark web website (something .onion, I can't remember) and he was calling regarding my "fake passport application". I hung up (call duration: 20s), he called back and I told him I hadn't applied for any such thing and hung up again (call duration: 40s)

A minute later, my phone is flooding with SMS's regarding One Time Passwords from about 20+ different websites. 20+ SMSs within the 10 seconds. (These were all genuine companies, like Amazon and stuff)

My question is, Am I being attacked?

Is my identity being used to sign up on different websites or this is just spam? Can an attacker gain access to these OTPs? How do I know my calls/texts/location/network usage isn't being monitored? Is my sensitive information at risk?

Extra Info:

I use an iPhone (iOS 12 Beta). My outlook account was compromised one day before this happened. (easy password). I've changed the password now.

Paranoia: The person on call knew my name. The sources of the OTPs are genuine. I don't see the motive behind sending OTPs from tons of different websites unless they can access the OTPs. (possible iOS vulnerability that isn't documented yet?) I see 4 possible intentions:

Using my identity as part of a fake passport/profile on the dark web.
Using my identity on regular websites (Amazon, etc)
Gaining sensitive information from my device.
Elaborate Spam/prank

An easy way to check if they are somehow getting access to the OTPs (and therefore to your accounts) is to log into your account and theck the activity log. Most reputable services (GMail, Amazon, etc) should have some way to view a list of date/time/location of recent successful logins.

If any of those were not you, then you have a problem.

Are you sure they are triggering your account's OTPs (which would sound like they are trying to get in to your account and / or may have already gotten past the password page)? Rather than signing up your phone number on new accounts (which could be the beginning of harassment / extortion)? OTP SMS messages don't typically tell you which account / username triggered them, but are you getting any OTPs for sites on which you don't have an account?

It's hard to say for certain that your sensitive information isn't at risk (apart from whatever was accessed via your Outlook before you changed the password), but this smells more like a social engineering attack of some sort rather than a technical attack.

My condolences that you've been caught up in this.


What are the actions of Locky on the source files which lead to encrypting? During discussions about possible actions to mitigate the risk of the ransomware Locky, someone pointed at the possibility of preventing at OS level the creation of .locky files via the File Server Resource Manager. The idea was that the impossibility to create .locky files could hamper the execution malware.

Since I am extremely skeptical about the efficiency of this technique I would like to understand the methodology used by Locky when dealing with targeted files.

I am not interested about how the encryption is done but rather what are the steps leading from a sane file to the encrypted version (specifically: what happens when Locky fails to encrypt a file and what happens to a file after its content have been (successfully or not) encrypted).

Is such an analysis available?

What happens when Locky fails to encrypt a file?
Locky "fails" the encryption when it cannot reach one of the C&C server. It tries to receive the private key which is located on the C&C server.
Locky cannot fail encryption once it has the private key, unless all the Locky-processes will be canceled while it's encrypting. This means that there is a big chance that a file could become corrupted.

What happens to a file after its content have been (successfully or not) encrypted?
The content of an encrypted file will be all scrambled. This size of the file will be different and the entropy will also be higher.
The content of a failed encrypted file will be probably the same. Except it can be that the content will be smaller than the original content of the unencrypted file. And once you decrypt it with the private key, the file will be most likely be corrupted.


How do AV vendors choose malware names? If you take a look at McAfee's recent malware page, you'll see that the names in the "Malware name" column aren't very human-readable: Downloader.a!cnz, W32/Autorun.worm.bgh, FakeAlert-SecurityTool.fx, etc.

These names have always puzzled me a little. There seems to be a lot of information encoded in these names, but I can't readily make sense of it, and I can't find any kind of guide for reading them.

Are there well-defined standards (or at least common practices) when it comes to naming malware, or is it up to the whims (or proprietary standards) of each vendor?
Is there a well-understood vocabulary (e.g. does "Autorun" have a standard specific meaning, like "relies on Windows autorun functionality"), and do the symbols (!, .) have a fixed particular meaning?
Do the TLD-like suffixes like .ml indicate suspected country of origin, or am I reading that wrong?

I'm aware that different anti-virus vendors may have different naming styles. I'm primarily interested in McAfee, but a good answer might point to multiple references for how each vendor assigns malware names or simply provide a high-level overview of how malware naming works.

Microsoft uses the CARO naming scheme:

Mitre came up with the CME:

  The Common Malware Enumeration (CME) initiative aims to provide single, common identifiers to new virus threats (i.e., malware) and to the most prevalent virus threats in the wild for the benefit of the public. Managed and maintained by The MITRE Corporation, CME is not an attempt to solve the challenges involved with naming schemes for viruses and other forms of malware. Instead, it is an effort to facilitate the adoption of a shared, neutral indexing capability for malware.

Another article about naming.


Can a password cracker reverse engineer my generation method? Lets say I generated a password with really awful entropy seed (5 bits~), but then used another selection process (with a low entropy seed as well) to select at random a method to generate a password (based on the many different methods we see in the wild).

This seems intuitively easy to crack because of the low entropy, but how on earth does a program possible guess at the generation method, if we don't know what that generation method is?

In other words, given a hash+salt can I use some cryptanalysis or other technique to the reduce the scope of the problem without knowledge of underlying dictionary or grammar used to generate the hash.

In theory, one could make a program that generates lots of password generation algorithms at random (or somehow systematically) and then apply them to a variety of different seeds until it break the code.  In practice, this would be very slow depending on the strength and uniqueness of the algorithm.  It might be better to get a good cryptanalyst take a look at the passwords and take educated guesses. In general though, you shouldn't depend on obscurity to protect your security.


Must one have SSL certificates for each domain, to use HTTPS? I read in the following passage in this DigitalOcean article, concerning HTTP/2:

  Even though HTTP/2 does not require encryption, developers of two most
  popular browsers, Google Chrome and Mozilla Firefox, stated that for
  the security reasons they will support HTTP/2 only for HTTPS
  connections. Hence, if you decide to set up servers with HTTP/2
  support, you must also secure them with HTTPS.

Okay, let's say I install OpenSSL on port 443 and use TLS to wrap each packet with an encryption wrapper.

Will I still have HTTPS if I didn't setup an SSL certificate for each domain and associated it with OpenSSL? and if I will, will this be valid in Chrome/Firefox?

I feel like a primer on how TLS works might answer some of your questions. We have a canonical question here for that:

How does SSL/TLS work?

The part that's relevant for your question is that in order to do TLS, the server must have an encryption private key.

This key is private, meaning that no copies of the key should exist anywhere else, so we can use it (and the corresponding public key) to uniquely identify the server.

Consider a browser visiting your site for the first time - how does it know that it's talking to the real yourdomain.com and not an attacker trying to spoof your site?

That's where certificates come in: a Certificate Authority issues a certificate to say "we have verified that this public key does in fact belong to the legitimate owners of mydomain.com. Browsers take this as proof that they are talking to the authentic server for that URL / domain.

Browsers require every server to present a valid certificate matching the domain requested for each TLS connection, and (in theory at least) each server should be using a unique keypair and certificate.

TLS is a bit tricky to wrap your head around, and getting a cert from a CA and installing it properly can be a bit fiddly, but if you follow your guide you should have it up and running in a day or two.


What browsing history exactly would police have under proposed UK law change? Plain english It's very unclear what '12 months' browsing history being kept by network provider' actually means to an uninformed person. Thunderbird? VPN? Startpage searches? Bit-torrent downloads? Epic browser (in Windows)? Proxy browsing? Proxy browsers eg xombrero? Can anyone clarify? Does using firefox security addons like noscript change what they can see?  Thanks a lot!

Currently, the measure is just an idea. It is not even an idea by a politician. It is an idea by the UK police. The exact wording for such a law is not made yet, so we can just guess how it could look.

However, this article by The Guardian gives the impression that the idea is to have the internet service providers do the snooping:

  Senior officers want to revive the measures similar to those contained in the“snooper’s charter”, which would force telecommunications companies to retain for 12 months data that would disclose websites visited by customers

So the rest of this answer focuses on the question what information can your internet service provider collect about your internet activity?

  Web browsing in general

A web browser has two ways to request websites. The unsecure http:// protocol and the secure https:// protocol. Not all websites support both modes of operation. Stackexchange is one which does. Which mode is used can be seen in the address bar.

When you read this text via http, your internet service provider will know that you just visited http://security.stackexchange.com/questions/104284/what-browsing-history-exactly-would-police-have-under-proposed-uk-law-change-pl. They would also be able to log the complete content of the text your read right now.

When you browse this website with https, the data trail is a lot smaller, because the communication with the webserver was encrypted. All your ISP just learned about you is that you requested something from https://security.stackexchange.com, how many bytes you sent and how many bytes you received. But they can not infer from this information that you read this exact question.

  Thunderbird?

Email can be accessed encrypted or unencrypted. Check the server settings in your account settings to see what security mode Thunderbird is using (should be "SSL/TLS" or "STARTTLS"). When encryption is enabled, all your ISP can learn is which email provider you use, how often you check your email and how much email (in byte) you send and receive.

However, even if you access your email encrypted, the exchange of the emails between mailservers might have been unencrypted. Generally, email should not be considered a secure medium. Encryption addons for email (like PGP) can protect the content, but not the meta-information (sender and receiver address).

  Startpage searches?

startpage.com always uses https, so they will learn when you used it, but not what you were searching for and what results you received.

Many search engines always use https, by the way (Google, DuckDuckGo and Yahoo do, Bing does it only on request).

Keep in mind that when you actually visit one of the search results, that request might or might not use https (see "Web browsing in general" above).

  Bit-torrent downloads?

Bit Torrent is always unencrypted. An eavesdropper can learn what files you share and who you are sharing them with. In order to do that, they don't even need to be an ISP, by the way. Joining the same torrent swarm as a client is enough. Information obtained that way is frequently used by companies to press legal actions against filesharers who violate their copyrights.

  Proxy browsing?

Proxy servers can be encrypted or unencrypted. Unencrypted proxy browsing doesn't affect the eavesdropping capabilities of the ISP at all.  When the connection to the proxy is encrypted, they know that you used the proxy, but not what information you accessed through it. However, if an attacker can also monitor the outgoing traffic of the proxy server, they might be able to  correlate it with your requests based on timing.

  VPN?

Internal traffic inside a virtual private network is always encrypted. When you use a VPN as a proxy to access websites, then the situation is identical to an encrypted proxy server.

  noscript?

Sometimes Javascript applications on otherwise encrypted websites can cause the web browser to make unencrypted requests. Under some circumstances this might provide an eavesdropper with additional information.

  Epic browser (in Windows)? xombrero?

I am not familiar enough with these products to provide a good answer, but I don't think they can do anything which is not already covered by the points mentioned above.


Why does password strength matter? I understand from a cryptographic standpoint that you want a password to be as random as possible to resist brute force or dictionary attacks.  That is fine- but in what circumstances can those approaches actually be taken?  Just about every system I have ever had a password to locks you out if you enter more than a couple incorrect guesses.  We're looking at millions of guesses even for very weak passwords, which seems to be impossible on these types of systems.

How do people go about attacking passwords other than by social engineering?

Analysis of the 32 million passwords recently exposed in the breach of social media application developer RockYou last month provides further proof that consumers routinely use easy to guess login credentials. Sensitive login credentials - stored in plain text - were left exposed because of a SQL injection bug in RockYou's website.

  The emails and passwords of around 1.3 million registered users – including those of Gawker Media owner Nick Denton and its employees – were accessed and subsequently published online.

  The social networking website LinkedIn was hacked on 5 June 2012, and passwords for nearly 6.5 million user accounts were stolen

  A hacker collective calling itself D33Ds Co. publicly posted more than 450,000 log-in credentials -- i.e., paired usernames and passwords -- obtained from Yahoo's "Contributor Network" site.

  It all started when Adobe reported the breach of more than 3 million customers' information (including password-identifying information), then upped the number to 38 million. Last week it got a whole lot worse when an outside company found the data of some 152 million Adobe customers on a site frequented by cybercriminals.

  Turkish hacker Maxn3y defaced avadas.de on Saturday (archive here) before dumping what the hacker claimed were customer details online. The purportedly leaked information included incomplete configuration files for the shop.avadas.de domain, what appeared to be authentic admin login details with encrypted passwords, and (most seriously), what security experts believe is the PayPal payment information for an estimated 20,000 consumers. According to Cyberwarnews.info, which analysed the data dump, the hackers also grabbed the email addresses, user names, encrypted passwords as well as certain bank and payment details of the customers.

  Thousands of Tesco customers have had their emails and passwords posted online after hackers got their hands on the login details.

…

Relying on the rate limit on password attacks is all good and well until the password database gets leaked.

When the password database is in cleartext, the game is over for this password. You can't mitigate that by having a strong password, only by not reusing the same password (or an easy-to-modify password such as swordfish!Yahoo vs swordfish!Tesco) on different sites.

When the password database is hashed, it takes some time for attackers to run an offline search and find the passwords. The stronger the password and the better the hash, the longer the attacker will need. If your password is strong enough, then you may have a chance to change your password before any attacker finds your password. This puts users in competition: the weakest passwords will be the first to be exploited. Even in this case, you'll need to change the password everywhere you use it, which strongly argues in favor of genuinely site-unique passwords.


How to restrict a X509 certificate to be used only for a web server I would like to restrict the X509 certificate for a site to be used strictly for a web service, as opposed to code signing or certificate signing.

Which basicConstraints and keyUsage usage attributes would restrict the use of the certificate for other purpose than for web service.

From GlobalSign: Code Signing FAQ:

  Where an SSL certificate for a website would contain an extended key usage of Server Authentication showing it can be used to identify a server, a code signing certificate has an extended key usage of Code Signing to indicate it may be used to sign code.

Thus for code signing you need an extended key usage of Code Signing while for a web server instead a key usage of Server Authentication. And for certificate signing the basic constraints would need to allow the certificate to be used as a CA. By creating certificates which differ in these settings and also have these settings marked as critical so that they are not ignored you can get the appropriate restrictions.


Attack vectors and payloads I have a question about malware. Malware attacks a machine through an attack vector. When it infiltrates the machine, it "unleashes" the payload. Now, let's say that I am infected by a virus, which was downloaded and installed without my knowledge via an internet webpage (or a pop-up or whatever).

So, the attack vector is the delivery method, the payload is the actual malware. What is the term for a function/method, which called, initiates the transfer of the virus (from a webpage)?

To elaborate, by my understanding for a person to actually get infected by malware, there has to be a 3 step process. I do not know the term for step 1.

  1 = ?

  2 = Attack Vector

  3 = Payload

Step 1 initiates the Attack Vector. IE. it detects the vulnerability of the FlashPlayer.

A malware infection consists of all 3 steps, yes?

Short answer: Vulnerability

Longer answer:

The vulnerability in a flash player is what is exploited to deliver the payload. How the payload is delivered is the attack vector, which is, this case, a web page.

Let's work backwards.

Payload: Payload is the code that infects the victim. In this case, it is malware on a computer.
Attack vector: This is the delivery method. Phishing is a common attack vector.
Vulnerability: This is the flaw in the application (Flash).
Exploit: Delivery of the payload to a vulnerability.


Can cross origin iframe be detected in web logs A recent blog post shows hackers owning a web server - at least the content and injecting a web skimming attack.  https://blog.malwarebytes.com/hacking-2/2020/03/criminals-hack-tupperware-website-with-credit-card-skimmer/

Should this be detectable in web server logs? The bad guys redirected to legitimate checkout page after skimming, and since they controlled the main page, referring url could have looked normal there; but would any of malicious iframe request have been logged?

I would expect some log entry for deskofhelp.com to show somewhere - assuming web logs are intact?

I don't see how. When creating an iframe, a GET request is sent to the iframes src, but not to the server hosting the iframe.

So deskofhelp[.]com will likely have tupperware.com in its logs as referer header, but not the other way around.

Cross-origin frames can be logged by using a frame-src CSP directive combined with report-uri (or the newer report-to), but it seems that tupperware.com isn't using CSP at all.


what is the most secure hash for virus definition databases in 2015? I have been told, if I wanted to create virus signatures from infected files to use for detection in the future, I should be careful as some of them are prone to collision attacks?

A collision for a cryptographic hash function h is a pair of data elements (two sequences of bits) m and m', which are distinct from each other, but hash to the same value (m ≠ m' but h(m) = h(m')). Since a hash function accepts as input sequences of bits that can be much longer than the fixed output size, the number of possible inputs to a hash function exceeds the number of possible outputs; therefore, it is a mathematical certainty that collisions exist for any given hash function. A cryptographically secure hash function is such that actually finding a collision is computationally infeasible (we know that collisions exist, but we do not want people to be able to find them).

A collision attack is an attack that exploits the structural weaknesses of a specific hash function to produce collisions. This works only for hash function for which a weakness is known, i.e. functions that, by definition, have been demonstrated not to be cryptographically secure.

What a collision attack would allow for an attacker, in your case, is unclear. Your envisioned "virus database" stores hash values computed over sequences of bytes that have been deemed "malicious" and should be shot on sight; you want to store hash values and not the malicious sequences themselves mostly to make lookups more efficient and to keep the storage costs low. If the attacker arranges for two of his virus to hash to the same value, then this means that inclusion in the database of the (common) hash value would resulting in banning both virus in one go, which is about the opposite of what the attacker would like: the attacker wants his virus to go undetected, not to be spotted even more efficiently.

Collision attacks would be a huge problem in the case of a database of non-virus. If you make a database of "sane" executables, then the attacker would try to make a collision between a harmless executable m, and some malware m'; he would then submit m for verification, so that h(m) is added to the list of "verified harmless files". Since the attacker arranged things so that h(m) = h(m'), that collision would mean that m' (the virus) would also be declared sane.

While it is unclear what could be gained (for the attacker) from hash collisions in a virus database, it is nevertheless considered better to use a cryptographically secure hash function, just in case. The main example of a non-secure hash function is MD5: collisions can be very efficiently produced for this function. The situation of SHA-1 is less clear: no collision has been exhibited yet, but a theoretical attack has been described, which should result in collisions with a computational effort that is huge (261 evaluations of the function) but still substantially less than the efforts which would be required for a "perfect" hash function with the same output size (280).

The usual recommendation for a secure hash function is SHA-256, or, more generally, any function of the SHA-2 family (SHA-256 is one of the currently six members of that family).


Allowing unauthenticated user access web page information Our web application should allow unregistered users to browse certain
information.
This information is returned by apis
Currently we are using hardcoded guest login to achieve this

The mere existence of that guest account seems like a risk for privilege escalation and who knows what else.

I see the disadvantage/risk of the guest user but I don't see what we gain from using it to authenticate.

Would a separate endpoint for unauthenticated users serve the same purpose?

I saw similar questions here and here but I was wondering if they were a little outdated?

In essence, you are using your login system to accomplish two separate goals:

Authenticate regular users
Give guest users access to otherwise authenticated pages

As a general rule of thumb using one thing for two purposes tends to cause its own problems in the long run, and so if nothing else the SRP suggests this is a bad idea.  There are certainly plenty of ways this can cause problems:

You'll still need access controls to make sure that users of this guest account aren't granted access to other API endpoints that are not supposed to be accessible to them.  This, in fact, would probably be my biggest concern: when writing a new API endpoint it would be very easy to forget "Hey, we have guest users that use this other special login" and therefore forget to prevent access to a new API to said guest users.  If that API happens to deal with sensitive information, then you may effectively end up with a public and critical data breach.
By allowing many users to share one account, you make auditing and data access logs much trickier to implement effectively.
If you ever need to change the credentials for the guest account you can't do so without logging out all active guest users

There are two alternate routes you could take:

1. Separate endpoints that don't require login

This has plenty of advantages.  Granted, you do have to create a separate set of endpoints, but it will add a layer between your unauthorized users and your authorized systems.  This both makes it harder for them to potentially find security weaknesses (since they are limited to a much smaller subset of your system) and also makes it harder for your developers to make mistake.  When there is clear separation between, e.g. "This code is for authorized users" and "This code is for unauthorized users" then it is harder for someone to forget what part they are working on and make a security blunder as a result (note that I said harder - not impossible).  This is will make it easier to properly secure your endpoints, even if you can't precisely quantify the end result.

2. Separate guest accounts for each user with restricted access controls

There isn't a ton of background in your question, but based on what little I can see this probably won't make sense for you.  Still I figured it never hurts to mention things.  Another option is to simply create a separate guest account for each "guest" user of your system.  This works best if your system already has clear access controls in place (so you can confidently lock such users out of places they aren't supposed to be) or if used in conjunction with a separate set of API endpoints (i.e. guest users are automatically locked out of all endpoints except these public ones).

You end up with a bit more code to manage this way (as opposed to just having some completely open endpoints) but it has some advantages:

You can more cleanly track guest users in your system, presuming that you are already tracking your users based on their logins
If you have a concept of "converting" these guest users into full users of your system, you'll already have the process half done when it comes time for conversion, and then you will be able to easily track a user's history from before they even "officially" signed up.
Depending on how a user becomes one of these guest accounts, your "public" endpoints don't have to actually be fully wide-open.  I.e. if a user clicks a button to "Accept terms and conditions" and then is automatically becomes a guest user, and you have to be a guest user to access these "public" pages, then you will have effectively kicked out most bots and automated scraping systems from your endpoints.


How does Windows know which part of memory is "intended to hold data only"? I'm learning about DEP implementations, now I'm trying to figure out how does the OS know which part of memory is intended to hold data only?

The memory itself is agnositic.  The operating system defines what each area is used for.  So windows "knows" because it said it was so.


How secure are Windows logins tied to physical human fingerprints? Some business laptops have a fingerprint reader, and Windows has the ability to use your fingerprint to log into an account in lieu of a typed password.

I understand that these open up lines of attack because of their physical nature, but I want to know how secure are the actual algorithms tied to these fingerprint logons?  As in, how are they stored, what is the keyspace like, and does this open up any bruteforce attacks?

WBF
In Windows, at least as of 2019 in Windows 10, uses the Windows Biometric Framework (WBF) to verify a user identity.  Capturing the data is done through an interface through this framework, and that driver could potentially be exploited, but let's assume it's vulnerability-free and an attacker is only able to work with the data that is captured.
WBS
The Windows Biometric Service performs some security immediately by separating applications from accessing the data directly.  It requires applications to be authorised with certain privileges to access data and uses Biometric Units (BUs) to expose devices through a standard interface.
Security
Trusted Platform Module (TPM) is used to ensure that given the hardware software cannot produce valid authentication without biometrics being supplied.
When the sensor is first detected, a secret is shared between the biometric sensor and the TPM which is never seen again by Windows.  For the actual authentication event, WBF opens a session with the TPM and gets an arbitrary number that can be used once (a nonce).  This nonce is sent to the sensor, which attempts a match, which if successful is passed to a HMAC utilising the nonce and the identity of the user - the HMAC expires after a few seconds, which is why you readily need to re-authenticate.  The point is that no sensitive data is held by Windows.
The rest of your questions are then answered by the strength of the HMAC hashing algorithm - the minimum is SHA-1, and a variety are available as defined in RFC3278 and RFC3279.
The last thing to note is that devices have to be marked as secure, and the documentation states that this comes from meeting the following requirements:

The matching engine of the sensor must be isolated from the normal OS (for example, using a trusted execution environment)
The sensor must support secure input of samples to the isolated matching engine; the content of the samples must never be exposed to the normal OS
The matching engine must support secure credential release by implementing the new v4 methods
The sensor must support presentation attack detection


VM Guest network security with NAT? Supposing I have an untrusted guest VM (e.g. I'm running a cloud data centre). If I set the network connection up to use NAT, the guest can still access the internet. But what's to stop them accessing the host LAN too? How does the NAT handling in the VM host manage to distinguish between say www.google.com (on the internet) and my.local.domainserver (on the host LAN), and prevent access to the latter?

When you configure the network on VMware player for instance to be in "NAT" mode, it'll simply do a "NAT HIDE", in which your host, after sending traffic to the network card, will have his SOURCE IP changed to the HOST IP (this is also know as PAT, port address translation).

If you don't have any specific rules on the HOST firewall denying traffic between vm network and host network then you will be able to access your host.


Does it improve security to use obscure port numbers? I recently started a job at a small company where the CTO prefers to host SSH services at obscure, high numbered ports on our servers rather than the well known port 22. His rationale is that "it prevents 99% of script kiddy attacks." I'm curious whether this is considered bad practice.

Intuitively this seems sensible. But we are both largely self taught, and I am uncomfortable with the idea of improvising our own security procedures rather than following well established convention. I know that in general cryptographic schemes and protocols are painstakingly designed by teams of experts, and that every detail is intended to protect against some kind of attack, no matter how insignificant it might seem. I worry about the unintended consequences of deviating from these recommendations.

But my colleague seems to have evidence on his side. He was able to demonstrate that we do get dozens of attacks every day that try port 22 and just move on. I know that generally we should avoid security through obscurity, but moving away from this common target really does seem to thwart most attacks.

Is this good practice or not? Should we use well known ports?

ADDENDUM

We do not rely only on the obscure port. We have many other security measures in place, including mandatory hardware keys. I will restate my question more clearly.

Is there any reason why port 22 in particular was chosen for SSH? Is there anything dangerous about using other ports?

Does it improve security to use obscure port numbers?

If you're already using high entropy passwords or public key authentication, the answer is "not really".  Mostly you're just getting rid of noise in logs.

  I worry about the unintended consequences of deviating from these recommendations.

It depends on what port was picked.  In Linux, by default all ports below 1024 require root access to listen on them.  If you're using a port above 1024, any user account can listen on it if there's not already a process listening.

Why does this matter?  Let's say you chose to set ssh to bind to port 20,000. If someone could stop the SSH process on a server (let's say they somehow found a way to crash the process), and had local access to that server, they could then run their own SSH server on port 20,000 before the service restarted.  Anyone logging in would then be logging in to the bad guys SSH server.

This isn't as big a deal as it used to be, since these days it's only trusted IT staff that are given login access to servers.  But still, it does have the potential for privilege escalation and other nastiness if an attacker gets a foothold on your server.

Other than being below 1024, there's nothing special about the number 22.  Largely it was chosen because SSH was a replacement for telnet at port 23, and 21 was already taken by FTP.  As long as you pick a port below 1024, the port doesn't really matter.

  Is this good practice or not? Should we use well known ports?

I wouldn't say I recommend it.  I also wouldn't advise against it.  As I said, it avoids a lot of noise in log files, but the benefits are largely limited to that.

For anyone interested in the background story on SSH, you can find it at: https://www.ssh.com/ssh/port


PGP encryption passphrase We are using Symantec PGP encryption for AIX to encrypt/decrypt files. Keys are generated with passphrase and the passphrase are set by the business users. The IT admin is responsible to perform the encryption/decryption of files on monthly basis.

When decrypting files the passphrase has to be entered however as the IT admin does not have the passphrase (which is set by the business users), how can we address this? I think the passphrase has to be stored in a table or create a custom program for the decryption to pick up the relevant passphrase. Is there other ways to achieve this without the need for a custom program?

If any third party (such as the IT admin) needs to have access to the files in addition to the owner, the standard solution is to have the third party's public key on each user's keychain, and add the third party as a "recipient" of the file when encrypted. For example, user "userguy" might encrypt a file thus: pgp -se -r userguy -r itadmin a_file.example (that's actually GnuPG / gpg syntax but I believe PGP's command line syntax is compatible). The admin could then decrypt the file using their own private key (for which they'd have the passphrase), and - assuming the admin has every user's public key - re-encrypt the file (if needed) using the exact same command (changing the user's identity for each different user's files, of course).

PGP should come with an "agent" program that supports caching the decrypted (post-passphrase) key of the current user - such as the admin - in RAM, so the key only needs to be entered once per bootup. This is of course slightly riskier, since it increases the time the key spends in RAM and thus might be subject to hijacking by a malicious program or hardware attack (physical or via something like SPECTRE) - but it's a lot more convenient for somebody who has to decrypt and then re-sign (as part of re-encrypting) files all the time.


When hashing, do longer messages have a higher chance of collisions? While discussing maximum password lengths, a poster made this comment:

  The longer the allowed input, the easier to supply an input that could
  cause a hash collision

To explain (since the lack of context might make the statement unclear), the poster is stating that it is easier to find a hash collision for a longer password than for a shorter one.  I had not heard this before, and now I'm curious.  My own (admittedly naive) expectation is that the collision probability should be fairly independent of message size since collisions happen in digest space, and the digest is fixed length.

What pieces of the puzzle am I missing?  Does the ease of finding a collision depend on input length?

What pieces of the puzzle am I missing? Does the ease of finding a collision depend on input length?

For finding a collision it is not relevant how long a string is (apart from the time needed to compute the hash - which is actually longer for long strings) but how many different strings you try. Because the more different inputs you have the higher is the chance that any of these result in the same (fixed length) hash value, i.e. a collision. And there are simply more different long strings than short strings.

For example: there are 10^3 = 1000 strings with 3 digits but already 10^6 = 1000000 strings with 6 digits. If you imagine a hash which consists of 4 digits then there might be a collision with the 3 digit strings but there will be definitely many collisions within the 6 digit strings because there are way more string values than hash values.

  The longer the allowed input, the easier to supply an input that could cause a hash collision

The statement you cite is wrong in the current form. It is true that the chance is higher that the strings you'll find will be long. But since there are many more long than short strings this does not make finding a collision any easier. Again, what counts is the number of different inputs you have and not the length.


Should the client or the server generate the client's public-private key pair? Say I have a mobile messaging app. There is a central server that manages stuff (like a directory of users, onboarding, etc.) and there are all the clients.

My app is professional, so it uses asymmetric encryption to securely send messages.

My question is, in short, should the client or the server generate the public-private key pair?

If the client generates the pair, then the pair can be generated on the client-side and then sent to the server (maybe encrypted with the server's public key).

If the server generates the pair, then I had a more complicated idea:

Client generates secret (S)
Client encrypts secret with server's public key
Client sends encrypted secret to server
Server decrypts encrypted secret with server's private key
Server generates public-private key pair for client
Server encrypts private key with secret (S) and removes it from memory
Server sends encrypted private key to server
Client decrypts encrypted private key with secret (S), which it had from the beginning
Hooray! Client now has private key and public key is on server!!! :)

So, which approach is better--should the client or the server generate the public-private key pair from a security perspective? Is there a better/more efficient/more secure way to do it than my solutions?

My question is, in short, should the client or the server generate the
  public-private key pair?

In theory, the client should generate their own key pair.  That way the private key:

is known only to the client
is not exposed to transfer

In practice, it's not unheard of to see servers generating client keys and handing them out.  However, this is usually only done in cases where the client lacks some necessary resource which can generate a key and a CSR themselves:

limited processor
human interaction required

(Quite literally, most "server hands out the keys" setups I've seen boil down to "our users are too stupid, and our support group doesn't want to hand-hold them all")

It sounds like you're implementing server and clients.  If you have that level of control, then generate client keys at the client because it's the right thing to do.


How to ensure that cookies are always sent via SSL when using ASP.NET on IIS 7.5? Firesheep has brought the issue of insecure cookie exchanges to the forefront.

How can you ensure that all cookie exchanges are forced to occur only via an SSL-secured connection to the server when you're communicating to a web user?

Our scenario is that the web app is written in ASP.NET 4.0 and hosted on Windows Server 2008 R2 running IIS 7.5 if that narrows the scope some.

You can use app.config to force it; the format is (in the <system.web> section)

<httpCookies domain="String"
             httpOnlyCookies="true|false"
             requireSSL="true|false" />

so you really want, at a minimum

<httpCookies requireSSL='true'/>

But preferably you'll also turn httpOnlyCookies on, unless you're doing some really hooky javascript.


Using free subdomains to circumvent web filtering systems (I was told that this was the place to ask this by someone from Webmasters, if I've got it wrong again please give me a chance!)

I'm running a personal proxy service for the use of myself and some of my friends. Currently, in order to circumvent filtering restrictions I've signed up with a free web host to use their subdomain and that works for now, but it's only a matter of time before that subdomain is blacklisted. Is there any way I can use the subdomains provided by a free DNS/subdomain provider (such as http://freedns.afraid.org) as fully featured domains to keep my site unblocked?

...Is there any way I can use the subdomains provided by a free DNS/subdomain provider (such as http://freedns.afraid.org) as fully featured domains to keep my site unblocked?

I assume you mean to have your own proxy at home and just have a static public host name for this proxy.

It depends what kind of block you are trying to circumvent and how you do it:

Running a real web proxy or a SOCKS proxy can easily detected because the traffic looks very typical and different from normal HTTP traffic. Corporate firewalls can often be configured to detect and block this kind of traffic. They block this kind of traffic not by target URL but just by the traffic pattern, so using another hostname does not help.
Running a forwarder which rewrites the URLs (e.g. rewrite http://example.org/foo to http://proxy.example.com/example.org/foo) is harder to detect. But it is a security risk because you effectively disable the protection by same origin policy if you are serving everything from the same domain. Even using a subdomain for each major domain (e.g. example.org.proxy.example.com/foo) would not be enough. And given enough traffic it might be detected because of unusual usage. But in this case it would be either by target host name or by IP address. In the first case using just another host name would work, in the second case the IP where you run the proxy service on is affected. A corporate network might also simply block all traffic to ISP for home users for security reasons (the IP ranges are known, so blocking is easy).
Having a local proxy instead which translates your requests and then forwards them to your external proxy might help be restoring protection by same origin policy. Apart from that the same problem with possible detection applies.

In any case:

If you tunnel only a few traffic inside a network with lots of other traffic the chance of detection is low, unless you use some easily detectable way like a HTTP proxy or SOCKS proxy.
If you try to circumvent some policy this way and you will be detected, than you have to face the consequences. It does not matter if this is a corporate policy, school policy or state policy, although the consequences might be different.


Why does the server ssh public key not look like the key in client known hosts? From my naive understanding of ssh, the server shares its public key ( /etc/shh/ssh_host_rsa_key.pub ) with the client, who then adds it to the list of known hosts ( /user/.ssh/known_hosts ). So, I would expect if I look in those two files to see a long identical string in both (the "key").
When I compare the text in these two files I can see a string in both which is the same at the beginning but then becomes different.
Why can't I see the same long string in both files (which I would assume is the key)?

For privacy.
With modern versions of OpenSSH, the known_hosts file on the client contains a hash of the server name (or IP address), rather than the name directly. The reason for only storing a hash is that if someone obtains a copy of this file (e.g. leaked backup), they can't discover which servers are recorded, i.e. they can't discover which sites you connected to. They can verify guesses, of course: that's unavoidable since the legitimate client must be able to do this.
The ssh-keygen utility has a few options to manipulate the known_hosts entries, but of course can't convert a hash to the non-hash format. You can set HashKnownHosts no in your client configuration (~/.ssh/config) to turn off hashing, then the entries will be in a format where the public key is clearly visible.


Breaking full-disk encryption on a computer that's rarely used I'm writing a story where a security expert has been kidnapped and tasked with gaining access to some files on a stolen computer protected by full-disk encryption, and I'd like some ideas for ways he might accomplish that. The encryption is software-based, and the character has physical access to the entire computer.

The people that kidnapped the character don't know who has the encryption key, so the $5 wrench method is out. The computer has not seen use for a very long time, and is only used occasionally (on the scale of once every couple of years), so introducing a keylogger or some other method that relies on capturing user input to find the key won't be useful. The character knows that he's going to be killed if he doesn't manage to get access to these files, so he's pretty motivated to try anything that might work, even if it would ordinarily be too tedious or fiddly to bother with. He has about a week to produce results.

The computer in question is an alternate-universe system basically equivalent to a 1998 PC, running the fantasy equivalent of Linux. The character is attempting to break into it with roughly 2008-level technology. He definitely doesn't have access to enough computing power to brute force the key in a reasonable amount of time.

So, what are some approaches the character might take? From what I've read about full-disk encryption, cold boot attacks are a method for breaking it if you have physical access to the machine, but since this one hasn't been used in a long time I don't believe that's an option.

In 1998, DES3 was still considered to be a standard for security (fips 46-3 wasn't withdrawn until 2005). But it was already crackable by brute force within days. Your problem however is access to computing resource - if the gun were pointing at my head, my next thought would be to look at a way of distributing the operation via javascript from a busy site...

However if the gun were pointing at my head, then the first thing I'd do is check for post-it notes. The next place I would think to to look for a way into a machine which probably hadn't been patched for 10 years is a vulnerability database - security tools don't have a good security record.


Is there any quick or automated to way to check the version of PHP running on a remote server? Currently running a vulnerability assessment. However, the IP I was provided is a load balancer and the client only wants to test one of the sites running on the load balancer. The vulnerabilities I have found are all PHP related. How can I confirm that their website is running that PHP version rather than another website on the load balancer? I already checked the headers and while it tells me the Apache version that it is running, nothing about PHP. Is there a tool or quick way to determine what the most likely version of PHP running it is?

Unless the version information is presented to you, e.g. in headers, a call to phpinfo() in the code etc., there is likely no way to determine the version.

The only other way I can think of would be to try and exploit known vulnerabilities in PHP itself, and deduce the version based on success. However, this may or may not be appropriate for your assessment.


How to find Windows version from the file on a remote system I need to find out what Windows and Service Pack system is currently running. All I have is ftp access, it means I cannot run any the software.
Is there a way to determine what version of Windows, Service Pack, and what Language is installed on a system?

Based on https://superuser.com/questions/363018/how-do-i-tell-what-version-and-edition-of-windows-is-on-the-filesystem you can find the Windows Version and Service pack in C:\Windows\System32\license.rtf for Windows 7. For Windows XP the information is in C:\Windows\System32\eula.txt. For Windows 10 licenses.rtf does not contain the version. Instead it contains the EULA code, which you can use to find the version online.

I tested this on XP SP3, 7, 7 SP1, and 10 and found that this works for each OS.

The current language pack is a little more tricky. You can find what appears to be the currently available languages in C:\Windows\System32. The folders are in  the format of xx-XX (xx = language, XX = country). For example en-US is English-United States, es-MX is Spanish-Mexico.

The packs that have been used are copied to C:\Windows.

To test this I switched my Windows 7 SP1 and Windows 10 Pro machines over to es-MX and, once I rebooted the computer, found that the es-MX folder was created in C:\Windows. Unfortunately the en-US was still there making the current language ambiguous. However you should be able to use the combination of active packs and the names of Documents, Photos, Music ect. to get the current language.

I was unable to test this in XP as I could not risk bricking my last running example of XP.