Could an online anonymizer make Tor without HTTPS safe? Tor is fully secure only if I use HTTPS, right? But not every site supports it, so I had an idea - some online anonymizers support HTTPS, so if I connect via Tor (Tor -> anonymyzer -> site), will that be the same?

In that case the connection between anonymizer and webserver would be just as unencrypted as the connection between exit node and webserver. It would still be possible to eavesdrop on it.

All you get from this is that you get an additional layer in your onion circuit (the outer layer is the https connection between you and the anonymizer) and that you shift your trust-relation from your exit-node to the anonymizer service.

There is simply no way to communicate fully-encrypted with a communication-partner who doesn't support encryption. No matter what you do, the last hop must always be unencrypted in that case.


Is it PCI compliant to write down credit card information on paper and store it in unattended boxes? There is a local mom and pop video store that requires new customers to write their names, addresses, and credit card information on 3x5 cards. These cards are actually kept in a recipe cards box that is left sitting on the counter, often times unattended. They also have shoe boxes left in plain site that are full of older cards for infrequent or non-returning customers. Several times I've witnessed these cards scattered across the counter as they use them to attach to movies that are being reserved. In this day of credit card fraud and theft, I'm dumbfounded that this is happening. Is this legal? Doesn't this violate credit cards companies policies of safe credit card storage? Also, is there a way to report this? Customers have complained but they just say that's how they've done it for 30+ years. They have no computer system at all in place to switch over and don't plan on getting one.

IANAQSA, and this is outside my personal experience, but here goes:

  In this day of credit card fraud and theft, I'm dumbfounded that this
  is happening. Is this legal?

Legal?  Depends on where you are, but... probably, yes.  Note that even in the TJX breach, where 45 Million cards were compromised, the legal charges against them were for PII, not for violation of card numbers.  There's generally no laws about that, only Card Brand requirements.

  Doesn't this violate credit cards companies policies of safe credit
  card storage?

Yes, this violates the PCI DSS 9.5:

Now, the DSS is generally only thought of for business with computers and networks.  Since IANAQSA, I can't speak to whether the business you describe would be expected to hew to it.  That being said, I've no doubt that whatever contractual language they sign in order to be allowed to process cards invokes similar cautions because, as you state, they're pretty basic.

  Also, is there a way to report this?

You can report it to their processor, if you can determine who that is, and that may or may not have any effect.  You can also complain to the card brands (form for Visa, form for Mastercard) and there's still no guarantee that'll have any effect.

You can also vote with your feet.  Ask them to destroy your card, watch them do it, and don't go back there again.


Allowing users to upload & download XML safely We have a requirement to allow users to upload an XML document into our system. We don't process it, we just allow them to download it again.

Given various browser XSS vulnerabilities such as this: http://webstersprodigy.net/2012/02/04/serving-back-xml-for-xss/ (various flavours affecting IE, Chrome and FF)

What is our best approach for safely allowing users to download the document again? Things we've considered so far:

Wrap the document in a ZIP file for download
Use a plain/text content type (we've got all the disable content-sniffing headers enabled but haven't yet tested what IE 8 will do in this scenario)
Something else entirely?

There are some ways to do this.

Check if XML contains any malicious code.
Double encode the XML. (https://www.owasp.org/index.php/Double_Encoding)

You could also encrypt the XML when uploading, and decrypt when downloading.

.Htaccess should also be edited to force the user to download instead of viewing in the browser(http://www.michaelbarton.name/2010/01/14/how-to-force-a-download-with-a-save-as-prompt-using-a-htaccess-file-andor-apache/)


How to store encrypted notes in a public git repository? I save my notes in a git repository in plaintext (markdown). Currently, the remote repository is another computer in my appartment. I am thinking about moving this remote repository to a remote server.

Description:

I want this to be as simple as possible. As few external tools as possible.

Because of this, i don't want to use git-crypt, since it is very complex and I don't understand it good enough.
I also don't want to use git annex for the very same reason.

The gitignore file of this repository would ignore every file besides *.asc files.
To increase the simplicity I will not obfuscate the filename of the encrypted file. I plan to just be cautious about the filename and not put sensitive stuff inside the file.
The encryption and decryption would be done with an asymmetric key, and this very asymmetric key would be also included in the repostiory, AES256 encrpyted.
Maybe, I could also sign each commit with the asymmetric key which lies encrypted in the repository itself. That would prevent an attacker to manipulate something. But I also don't know if it is worth to do that?
As my laptop has disk encryption, I don't care about plaintext files lying around in this repo (because I edit stuff inside, read them, etc.)
Being a git repository, I could mirror it to multiple remote repositories.

For that, I have three questions:

Is this safe? Obviously random people will have access to my remote repository. Of course, I could make the repository private and not use github, gitlab or something like that - but the sysadmin of the server will have access to this repo, no matter what.

At least, I am not competent enough to, for instance, encrypt the filesystem in such a way that I can confidently say that this remote repository will be secure.

What key algorithms should I use? Should I use ed25519 (which I trust the most out of ECC's at the moment - although I just superficially read about it) Or should i use RSA 4096 or even bigger?
I do not know if I should use gpg2 or rage?

I dislike the complexity of gpg, but rage is a very young project. (And I dislike Golang, therefore I also dislike to use the its reference implementation age.)
I will never need the legacy options of gpg, so i will always be able to use version 2+.

The simplest answer would be to use a symmetric cipher (e.g. AES).

You are the only user, so you only have to keep the AES key securely stored.
Symmetrical algorithms are generally faster than asymmetrical ones (but probably not by much for text though).
You use only one operation at encryption/decryption time.

Now for your questions:

  Is this safe?

AES is still considered safe, but you have to take care with its mode and size. Regarding your use case, you should go with AES-256-CBC, as it might be easier to use than AES-256-GCM and more common than some recent ciphers.

  What key algorithms should I use?

Well, as I said, symmetric only should do the trick.

  I do not know if I should use gpg2 or rage?

OpenSSL could be use for AES (or many other ciphers), some example here.


Vicious circle with certificates - how to trust the server cert? I have a java app on Android that needs to be able to communicate with a web server over ssl using an client x509 certificate  (for encryption negotiation)  - the private key is in the java keystore to which access is protected by a passphrase.

Now the best part: I don't want to store passphrase in app, instead I want to send this passphrase via secure connection  from server ...   vicious circle.

What possibilities do I have?  It looks like both sides need their own keypairs or symmetric key for encryption, or I need to send a passphrase via unsecured connection which anyone can sniff ;/

I can deploy the cert after first installation and set keystore passphrase to user encrypted password for double protection, this way the client can ensure that the cert was not tampered with during app usage.

how can my app check if it can trust given cert?

The Authority certificate is cross-signed by IdenTrust ("DST Root CA X3" Root CA)

case:

cert is in app
app is deployed on device
server is showing cert to app on negotiation
app is comparing cert (validating by it's copy)
in moment when app is reading cert from file the client need to be sure that cert was not tampered  (lets assume that we do spoofing cert on server  and on client site simultaneously to enforce data exchange in app)

Update in response to your edits in the question
You are correct that validating a cert up to the trusted root is not 100% foolproof. What it guarantees that a trusted CA issued this cert to the domain that you are communicating with (because you can check that the URL in the cert matches the URL that you are establishing the SSL connection with). This was how SSL was designed to work. If that's not good enough and you don't fully trust the CAs in the Android trust store, then there are still things you can do.
It sounds like what you are describing is Certificate Pinning. Here is a guide to certificate pinning by OWASP, which even has a section about Android. The idea is that you include either the public key or a hash of the full certificate of the root CA, intermediate CA, or server cert in the source code of your app. Since all Android apps get code-signed at build-time, you can be confident that the "pinned" public key will arrive at the device un-tampered. Unless the device is rooted (more on that below), you should be confident that it will remain un-tampered.
It's good that you're thinking about this very carefully. That's good. But, as @Limit said,

I think you are overthinking your problem :)

You are not the first person to think about this problem, and there are standard ways to solve it. You are making things much more complicated by trying to invent your own solution. A chain of signatures leading back to a cert in the OS trust store (or a pinned key if you want to go the extra mile) really is enough to guarantee that the certificate is real.

About rooted devices, you said:

nova days [now a days] even EPROMS are writable ???? if you can write into memory there is no such thing like immutability :)
besides rooted device is vulnerable for fs files altering

If your app is running on a rooted device (either rooted intentionally by the user, or by malware) then all guarantees and security proofs are off. There are some tricks you can do, but they are security theater at best. As far as real security goes, it's game over. I'm sorry but you're just going to have to accept that, unless you want to enter into an arms race with rootkit authors - which is well outside the scope of this site.
I also want to point out that while possible, the attack you're alluding to is very advanced. You can add code to your app to check the integrity of the binary against the code-signing signature, and refuse to run if the check fails. Here are some links from a quick google search:

Android Security: Adding Tampering Detection to Your App
Retrieve the apk signature at runtime for Android

With root access to the device, it is possible for a hacker to remove this check from your binary, but this will not happen from casual drive-by malware. It requires expert hackers to spend weeks reverse engineering your app. The kind of experts that you only find in government spy agencies and organized crime. It's time to define your threat model: are you worried that your app will be attacked by nation-states or organized crime? Yes / No?

No: then don't worry about it, doing certificate pinning and a runtime self-test of the code-signing will protect you even on rooted devices.

Yes: then stop getting advice from random people on the internet and go hire a real security consultant!

Your use-case seems a little strange. It sounds like you are trying to re-invent SSL, rather than using SSL the way it was designed.
In SSL, the server always presents a certificate to prove that it is the right server. The point of mutually-authenticated SSL (where both the server and the client have certificates) is for the device to prove to the server that it is the right device. Having the server send the client a key to decrypt the client cert is a bit like having the server prove to itself that it is the right server. ??

How does the client trust the server's certificate?
The client should trust the server's certificate only if it chains back to a root CA cert that is in the Java Keystore. If your server's certificate was issued by a public CA (ie you bought it from Digicert, or Verisign, etc) then the root should already be in the Android keystore. If it was issued by a private CA, then the right thing to do is to include the root CA's certificate in the app resources and add it to the Java Keystore on the app's first run. (This is safe because the app .apk is code signed, so the cert can not be modified.)
All of this should be handled automatically by Android's SSL libraries. If you are getting exceptions about not trusting the server's certificate, then try adding the root CA cert to the Android trust store.
Inventing your own method of establishing trust by having the server send a decryption key is almost certainly wrong, and is almost certainly more work.

For more reading, please see:
How does SSL/TLS work?
(I know it's a lot of text, but it is a very good reference)


is it possible to craft exploits for non-open source C/C++ software without fuzzing? imagine that if i wanted to find a vulnerability in a program that is used by a lot of people in order to exploit it.

the program is open source and is written in C/C++ . would this even be possible (fuzzing excluded) as google tells me that it is not possible to reverse engineer a C/C++ .exe file back to source code, that you only get assembly?

can i craft exploits based on assembly alone? would make me really sad if this is not possible.

Yes, it's completely possible.  You can read through all of the assembly, determine what conditions are not accounted for, and then exploit them.  In fact, even when using fuzzing, you will need to read through the assembly to figure out a) is there an exploitable bug, and b) determine how to create that exploit.

All fuzzing does is help you determine where error conditions might exist by trying as many inputs as possible.


Which format is the PKCS12 successor? The documentation of a PKCS12 implementation for Go states the following:

  It is intended for decoding P12/PFX files for use with the crypto/tls package, and for encoding P12/PFX files for use by legacy applications which do not support newer formats. Since PKCS#12 uses weak encryption primitives, it SHOULD NOT be used for new applications.

I am wondering: which are the new formats succeeding PKCS12?

The documentation from the source of your citation (sslmate.org) defaults to the use of chained, PEM encoded, certificates. This is a common alternative to PKCS#12, because of its ease of use.

The justification "Since PKCS#12 uses weak encryption primitives" is incorrect in the sense that the alternative does not encrypt its content. However, usually PKCS#12 data is encrypted using a default password for its key, which does not provide more security than PEM encoded data.


How is the stack protection enforced in a binary? On a linux box with an Intel CPU, lets say I compiled by binary with -fstack-protect-all.

How is this encoded into the binary? (Can I see this info using readelf? ). Is it encoded into every page/segment or is it added to the binary in one place and the loader picks it up?
How does the kernel/loader get this information when loading a page? How does it use it?
What is the x86 instruction used to set the page to read-only?

On a linux box with an Intel CPU, lets say I compiled by binary with -fstack-protect-all.

Since it is not explicitly stated, it will be assumed that this refers to ELF binaries compiled using GCC with the -fstack-protector-all argument.

GCC Stack Protection Mechanisms

-fstack-protector-all is an extension of -fstack-protector:

  -fstack-protector

  Emit extra code to check for buffer overflows, such as stack smashing          attacks. This is done by adding a guard variable to functions with vulnerable objects. This includes functions that call alloca, and functions with buffers larger than 8 bytes. The guards are initialized when a function is entered and then checked when the function exits. If a guard check fails, an error message is printed and the program exits.

  -fstack-protector-all

  Like -fstack-protector except that all functions are protected.

The aforementioned "guard variable" is commonly referred to as a canary:

  The basic idea behind stack protection is to push a "canary" (a randomly chosen integer) on the stack just after the function return pointer has been pushed. The canary value is then checked before the function returns; if it has changed, the program will abort. Generally, stack buffer overflow (aka "stack smashing") attacks will have to change the value of the canary as they write beyond the end of the buffer before they can get to the return pointer. Since the value of the canary is unknown to the attacker, it cannot be replaced by the attack. Thus, the stack protection allows the program to abort when that happens rather than return to wherever the attacker wanted it to go.1

Now to the first set of questions:

  How is this encoded into the binary? (Can I see this info using readelf? ). Is it encoded into every page/segment or is it added to the binary in one place and the loader picks it up?

The -fstack-protector-all causes the compiler to generate code in which a guard variable is pushed to all functions and checked prior to return. In other words, additional machine instructions are generated that have to do with pushing, checking and popping the stack canary.

This can be illustrated using 2 example binaries produced from the same source, in which one was compiled with the -fstack-protector-all argument and the other was not.

Source code:

int test(int i) {
    return i;
}

int main(void) {
    int x;
    int i = 10;
    x = test(i);
    return x;
}

Function from binary compiled without -fstack-protector-all:

$ objdump -dj .text test | grep -A7 "<test>:"
00000000004004ed <test>:
  4004ed:   55                      push   %rbp
  4004ee:   48 89 e5                mov    %rsp,%rbp
  4004f1:   89 7d fc                mov    %edi,-0x4(%rbp)
  4004f4:   8b 45 fc                mov    -0x4(%rbp),%eax
  4004f7:   5d                      pop    %rbp
  4004f8:   c3                      retq

Function from binary compiled with -fstack-protector-all:

$ objdump -dj .text protected_test | grep -A20 "<test>:"
000000000040055d <test>:
  40055d:   55                      push   %rbp
  40055e:   48 89 e5                mov    %rsp,%rbp
  400561:   48 83 ec 20             sub    $0x20,%rsp
  400565:   89 7d ec                mov    %edi,-0x14(%rbp)
  400568:   64 48 8b 04 25 28 00    mov    %fs:0x28,%rax     <- get guard variable value
  40056f:   00 00
  400571:   48 89 45 f8             mov    %rax,-0x8(%rbp)   <- save guard variable on stack
  400575:   31 c0                   xor    %eax,%eax
  400577:   8b 45 ec                mov    -0x14(%rbp),%eax
  40057a:   48 8b 55 f8             mov    -0x8(%rbp),%rdx   <- move it to register
  40057e:   64 48 33 14 25 28 00    xor    %fs:0x28,%rdx     <- check it against original
  400585:   00 00
  400587:   74 05                   je     40058e <test+0x31>
  400589:   e8 b2 fe ff ff          callq  400440 <__stack_chk_fail@plt>
  40058e:   c9                      leaveq
  40058f:   c3                      retq

Since stack protection is implemented via assembly code, the results of the -fstack-protector family of flags is best investigated using a disassembler like objdump. readelf technically shows this information, since the -x argument produces a hex dump of the selected section.

readelf hex dump of binary compiled without stack protection:

$ readelf -x .text test

Hex dump of section '.text':
  0x00400400 31ed4989 d15e4889 e24883e4 f0505449 1.I..^H..H...PTI
  0x00400410 c7c09005 400048c7 c1200540 0048c7c7 ....@.H.. .@.H..
  0x00400420 f9044000 e8b7ffff fff4660f 1f440000 ..@.......f..D..
  0x00400430 b83f1060 0055482d 38106000 4883f80e .?.`.UH-8.`.H...
  0x00400440 4889e577 025dc3b8 00000000 4885c074 H..w.]......H..t
  0x00400450 f45dbf38 106000ff e00f1f80 00000000 .].8.`..........
  0x00400460 b8381060 0055482d 38106000 48c1f803 .8.`.UH-8.`.H...
  0x00400470 4889e548 89c248c1 ea3f4801 d048d1f8 H..H..H..?H..H..
  0x00400480 75025dc3 ba000000 004885d2 74f45d48 u.]......H..t.]H
  0x00400490 89c6bf38 106000ff e20f1f80 00000000 ...8.`..........
  0x004004a0 803d910b 20000075 11554889 e5e87eff .=.. ..u.UH...~.
  0x004004b0 ffff5dc6 057e0b20 0001f3c3 0f1f4000 ..]..~. ......@.
  0x004004c0 48833d58 09200000 741eb800 00000048 H.=X. ..t......H
  0x004004d0 85c07414 55bf200e 60004889 e5ffd05d ..t.U. .`.H....]
  0x004004e0 e97bffff ff0f1f00 e973ffff ff554889 .{.......s...UH.
  0x004004f0 e5897dfc 8b45fc5d c3554889 e54883ec ..}..E.].UH..H..
  0x00400500 10c745f8 0a000000 8b45f889 c7e8dbff ..E......E......
  0x00400510 ffff8945 fc8b45fc c9c3660f 1f440000 ...E..E...f..D..
  0x00400520 41574189 ff415649 89f64155 4989d541 AWA..AVI..AUI..A
  0x00400530 544c8d25 d8082000 55488d2d d8082000 TL.%.. .UH.-.. .
  0x00400540 534c29e5 31db48c1 fd034883 ec08e855 SL).1.H...H....U
  0x00400550 feffff48 85ed741e 0f1f8400 00000000 ...H..t.........
  0x00400560 4c89ea4c 89f64489 ff41ff14 dc4883c3 L..L..D..A...H..
  0x00400570 014839eb 75ea4883 c4085b5d 415c415d .H9.u.H...[]A\A]
  0x00400580 415e415f c366662e 0f1f8400 00000000 A^A_.ff.........
  0x00400590 f3c3                                ..

readelf hex dump of binary compiled with stack protection:

$ readelf -x .text protected_test

Hex dump of section '.text':
  0x00400470 31ed4989 d15e4889 e24883e4 f0505449 1.I..^H..H...PTI
  0x00400480 c7c05006 400048c7 c1e00540 0048c7c7 ..P.@.H....@.H..
  0x00400490 90054000 e8b7ffff fff4660f 1f440000 ..@.......f..D..
  0x004004a0 b8471060 0055482d 40106000 4883f80e .G.`.UH-@.`.H...
  0x004004b0 4889e577 025dc3b8 00000000 4885c074 H..w.]......H..t
  0x004004c0 f45dbf40 106000ff e00f1f80 00000000 .].@.`..........
  0x004004d0 b8401060 0055482d 40106000 48c1f803 .@.`.UH-@.`.H...
  0x004004e0 4889e548 89c248c1 ea3f4801 d048d1f8 H..H..H..?H..H..
  0x004004f0 75025dc3 ba000000 004885d2 74f45d48 u.]......H..t.]H
  0x00400500 89c6bf40 106000ff e20f1f80 00000000 ...@.`..........
  0x00400510 803d290b 20000075 11554889 e5e87eff .=). ..u.UH...~.
  0x00400520 ffff5dc6 05160b20 0001f3c3 0f1f4000 ..].... ......@.
  0x00400530 48833de8 08200000 741eb800 00000048 H.=.. ..t......H
  0x00400540 85c07414 55bf200e 60004889 e5ffd05d ..t.U. .`.H....]
  0x00400550 e97bffff ff0f1f00 e973ffff ff554889 .{.......s...UH.
  0x00400560 e54883ec 20897dec 64488b04 25280000 .H.. .}.dH..%(..
  0x00400570 00488945 f831c08b 45ec488b 55f86448 .H.E.1..E.H.U.dH
  0x00400580 33142528 00000074 05e8b2fe ffffc9c3 3.%(...t........
  0x00400590 554889e5 4883ec10 64488b04 25280000 UH..H...dH..%(..
  0x004005a0 00488945 f831c0c7 45f00a00 00008b45 .H.E.1..E......E
  0x004005b0 f089c7e8 a5ffffff 8945f48b 45f4488b .........E..E.H.
  0x004005c0 55f86448 33142528 00000074 05e86efe U.dH3.%(...t..n.
  0x004005d0 ffffc9c3 662e0f1f 84000000 00006690 ....f.........f.
  0x004005e0 41574189 ff415649 89f64155 4989d541 AWA..AVI..AUI..A
  0x004005f0 544c8d25 18082000 55488d2d 18082000 TL.%.. .UH.-.. .
  0x00400600 534c29e5 31db48c1 fd034883 ec08e8f5 SL).1.H...H.....
  0x00400610 fdffff48 85ed741e 0f1f8400 00000000 ...H..t.........
  0x00400620 4c89ea4c 89f64489 ff41ff14 dc4883c3 L..L..D..A...H..
  0x00400630 014839eb 75ea4883 c4085b5d 415c415d .H9.u.H...[]A\A]
  0x00400640 415e415f c366662e 0f1f8400 00000000 A^A_.ff.........
  0x00400650 f3c3                                ..

Obviously this isn't very useful.

Discussion of pages and segments is not relevant since all the sections marked as executable in an ELF binary are mapped into the same segment (the text segment).

  How does the kernel/loader get this information when loading a page? How does it use it?

Use of -fstack-protector-all has no bearing on section or segment permissions.

For info about the kernel program loader see:

How programs get run
How programs get run: ELF binaries
How does the Linux kernel run a program

  What is the x86 instruction used to set the page to read-only?

Segment permissions are set by the link editor: Segment Permissions

1. "Strong" stack protection for GCC


How to process or manage Key-Encryption-Key using HSM? Let's consider two Encryption keys:
1.Data-Encryption-Key(DEK)
2.Key-Encryption-Key(KEK)
KEK will be securely stored in HSM, which will be encrypted using master key. Data Encryption Key will be decrypted using KEK.
Based on the above concept, my doubts are:
Do we need to send the Encrypted DEK to the HSM for decrypting it or Do we need to decrypt the KEK and retrieve it from HSM ?
I just want to know the key encryption and decryption process flow, while using HSM.
Also provide any helpful links.

If the encryption/decryption of the data is taking place on the HSM, the KEK will decrypt the DEK for performing encryption/decryption operations. All key management, key storage and crypto takes place within the HSM.

If the encryption/decryption of the data is taking place in the application, you could interface with the HSM to extract the DEK and do your crypto at the application. All key management and storage would remain within the HSM though cryptographic operations would be handled on the application server.

If the encryption/decryption of the data is taking place in the application and the application holds the DEK secured with the KEK, you may retrieve the KEK from the HSM, decrypt the DEK and do your crypto. All key management and storage is handled between the HSM and the application and cryptographic operations would be handled on the application server.

You can use the HSM however best suits your requirements.


Using OpenVPN on Windows instead of VPN apps: missing certificate Sorry this might be a noob question, but I subscribed to a VPN provider which ships its own app on Windows. Now I thought I'd prefer to use the OpenVPN client app instead.

I create a profile by providing it with a .ovpn file, which contains a <ca> block and a <tls-auth> block as well.

Upon connecting, OpenVPN fails with "Connection Error. Missing external certificate".

All those different certificates are quite abstract to me, but I think it needs a "client certificate". Is it something created for my profile by the VPN provider when I registered? Or can I generate it myself? When trying to add a certificate in the Windows OpenVPN app, I am asked for .p12 files. Also, when hitting "continue" (without external certificate), the connection never establishes.

For comparison, when putting .ovpn file in Linux in Network-Manager, it works out of the box.

What is the missing step or package? It's never made clear on the VPN provider help pages.

Here's what worked for me:
In my case, I'm using SurfShark. I don't know what resources other VPN providers offer, but I was able to download a certificate from SurfShark's website and install it on my Windows 10 PC by double clicking the downloaded file.
The next step is to open Windows certificate manager where you should be able to navigate to the location of the certificate that was installed. In my case it was under "Trusted Root Certification Authorities" Labeled "SurfShark Root CA".
Use the tool bar or right click to copy the certificate and then navigate to the OpenVPN Certificate Store folder in the certificate manager and paste the certificate there.
At this point you should be able to launch the OpenVPN app on Windows, select one of your profiles, edit, and you should be able to see your certificate in a drop down list.
Hope this helps...


leftoutsidemyprofile - Wordpress hack? A friend of mine asked me to upgrade his Wordpress instance to PHP 7.2. When I wanted to login on wp-admin to verify his plugins, I got redirected to http://leftoutsidemyprofile.info/up.js

I then noticed that this URL has also been inserted into the HTML and CSS files of the instance.

I haven't found anything on google except for other Wordpress instances which contain that link. archive.org knows this URL since the end of April.
I tried to de-obfuscate the contents of this Javascript file (https://pastebin.com/WBpXpvvb) but I can't really make sense of it.

What's also strange: I tried to send that URL to my friend via Facebook Messenger to ask him if he knew anything about it and the message got blocked.

Is this a new hack?

Update: I also found the domain hellofromhony, and this is available in Google.

With this new domain that I found throughout the investigation (hellofromhony) I was able to gather some information about the attack:

Basically, an attacker could get WP admin rights and change the siteurl and home url, redirecting all requests for images, js and css files to the attackers servers.

Yes, this is obviously a hack.

Unknown code inserted
obfuscated code
the domain was registered on April 26
chat filters blocking the domain


Data remanence on mobile devices The methods in which data should be deleted is strictly enforced by the DoD as well as others security sensitive organizations.  However, there are complications with deleting data on an SSD.

Given the constrains of an unprivileged application,  what is the best that one can hope for in terms of removing sensitive information from a mobile device?

Within an unprivileged application, there's no good way to store confidential data and hope to erase it and only it. If you write the data to a file, you don't know where this data will end up. SSD remanence is the least of your worries (and it may or may not be a worry depending on whether the flash controller implements a secure erase — I don't know how common this is on mobile devices). There may be multiple copies of the data on the filesystem if the file was written multiple times (either overwritten or replaced), if the filesystem was rearranged as part of defragmentation, if the device was backed up and restored, in the filesystem logs, …

On iOS, your best bet for small amounts of confidential data is the keychain. (If you have large amounts of data, encrypt it with a random (per-device) key and store the key in the keychain.) This is not a panacea (FAQ, SO thread), and as all things Apple there is very little publicly available technical information, but is likely to be better than most of what you can find on current mobile devices. There is nothing similar on Android.

If you want a full device wipe, that's a very different matter. Recent enough versions of iOS and Android offer a fast wipe feature (and I believe Blackberry does as well). This is handled at the OS level, not at the application level, but in an enterprise setting, it is common to grant the organization's IT team the permission to trigger a wipe remotely. (The fact that this indiscriminately erases both enterprise data and user data is a hurdle for BYOD adoption.) Fast wipes work by encrypting the whole storage except for a header containing the encryption key, and overwriting the encryption key. This is not foolproof as you may be vulnerable to SSD remanence, but it raises the bar significantly for an attacker.

On iOS, this feature is available on all devices running iOS 5 as well as some older devices running iOS 4. Android also has a device wipe feature which can be triggered by applications with the appropriate permission; I don't know what versions or settings wipe by overwriting the encryption key.

Remember that even if you throw the device in a volcano, there may exist other copies of the data in backups in the cloud (somewhere on Google's or Apple's servers) or on the user's PC.


Is it safe to connect phone to desktop computer on USB? For example, if my phone is compromised, can it execute code on my desktop computer just by plugging it in USB? Or vice versa. I ask because banks' and other services' 2-factor authentication commonly depends on sending a text message to the user's phone. If this is a risk, follow up questions: is it a theoretical or practical risk? What's the suggested way for moving data between devices?

Edit: To add a concrete example, let's say I have a Windows 10 desktop pc and an Android phone. My pc is infected with a banking trojan which wants to transfer money out of my bank. In order to do that, it needs access to my phone, because my bank sends the 2-factor authentication code as a text message. Once I plug the phone into the computer (to transfer photos or something) the trojan now infects the phone. The next time I log into my bank, the trojan on my pc can make a transfer out of my bank account while showing me an innocuous page. When the 2-factor auth code is sent to my phone, the trojan in my phone will hide the message from me and send it over the internet to the trojan on my pc, to finalize the transfer.

due to the USB protocol design and lack of vendor signatures especially with USB firmware updates it's possible to install malicious firmware into the internal chip if a USB; antivirus are of no use in this case check out nohl & lell research called bad USB presented at black hat 2014

http://m.youtube.com/watch?v=nuruzFqMgIw


What's a secure way to generate a keypair from a secret password? I like to generate a public-private key pair that is seeded from a string. So having the string and the generation algorithm is enough to recreate the keys. I want to do this because I can then combine a password (that I'll memorize), with a long, secret (randomly generated) text file (that I'll store securely), and generate a key pair. I'll then delete the key pair after each usage and regenerate them when needed. Thus, for the keys to be compromised, someone would need both the long text file, and the password in my head. (Or they need to intercept the key in the narrow intervals that it exists.) This seems safer to me than just storing the keys securely, where anyone with physical access to the keys can use them.
PS: I am obviously confident in not forgetting the password.
There is a similar question, but it's old and doesn't have a useful answer.

You can achieve the same effect by encrypting the keypair with a key derived from your memorized password. So rather than 'generating' a keypair you'll be encrypting a pre-generated one.
Take your long password, and pass it through a key derivation function (e.g. PBKDF2), use the output to encrypt the private key, and then store only the encrypted file.
Hence in order for someone to compromise the pair, they'd need both your password and the encrypted private key file.


How to securely destroy old cellphone, to avoid personal data recuperation? While cleaning I've found an old cellphone. This phone does not turn on, and I'm not sure if contains personal data.

I would like to throw away this phone, but I'm concerted if this data can be recovered some way.

What could be the best way to securely destroy it?

Not sure if relevant, it's an iPhone 3G.

You could disassemble the phone and drive a nail through the NAND. But since some companies (like DriveSavers) can rebuild flash chips on a certain extent, you might want to further destroy it by smashing the chip to bits.

(Note here that I do not know how "recoverable" a NAND flash is once there is physical damage. I just know that there are specialist equipment that can reconstruct NAND flashes off of SSDs. Granted, these SSDs are brought in with a cell failure rather than actual deformation, but if you think your data is that sensitive you have bigger problems.)

Here is a link to the iPhone 3G iFixit teardown that reveals where the chip resides. It's the Toshiba TH58G6D1DTG80 chip found on the back of the logic board, step 20. (I didn't post it here because of copyright.) Be sure not to puncture the battery as it might cause fire, smoke, and start leaking nasty chemicals.

Finally, if you can afford to wait it out, NAND flashes usually wear down with time if there is no power supplied to it. If you don't want to physically break your phone, you could lock it in a safe and preserve it for a couple of years. Some sources say you only need to wait two years (or even one year) under ideal conditions (high temperatures) for the data to become corrupt, while other sources claim it's false and NAND flashes can retain data for long periods of time. (The articles talk about SSDs, but the same could be applied to NAND flash because SSDs use NAND to store data.) Note that newer advances in the field could help retain data more than old chips, but I don't know how much that can impact data retention. So depending on how sensitive your data is, this might not be feasible, but could be the option if you want to preserve your phone, maybe for sentimental purposes.


Why is it more secure to use intermediate CA certificates? I've read that using Intermediate CA certificates is more secure because this way the Root CA is offline. So, if the Intermediate is compromised it does not impact the Root CA.

What I understand is doing that:

Allows to CA to revoke the Intermediate CA certificate.
Thus, new server certificates with compromised Intermediate CA certificates are invalidated.
Root CA can issue new Intermediate CA certificates, which in turn can create new server certificates.

But, anyway, CA must issue new Intermediate CA certificates and revoke the old ones... so the only benefit that I can find is that CA issue different Intermediate certificate for different purposes.

So the "universe" of compromised certificates is smaller that if Root CA would have signed all of the certificates.

Is that correct? Is there another benefit?

Yes, the number of compromised certificates are much larger with Root Certificate compromise. But it's not just the number certificates. Getting a new root certificates deployed due to compromised root is massively more difficult than replacing the certificates whose intermediates are compromised.

For starters, replacing Root Certificate of a public CA, even in normal scenario, involves lots of paperwork and audits. In the scenario of a compromised root, the CA need to convince software vendors (browsers and OS) to readd their new Root Certificate to the default trust store. In the fall out of a leak, the CA pretty much lost all the trust that had been built over the years, and vendors would rightly be skeptical about the capability of the CA and the viability of the CA's business going forward. At the very least, vendors would demand reauditing and lots of additional paperworks before allowing the new Root Certificate Authority.

Vendors then would need to deploy the new trusted Certificate. This is extremely hard to do in a short time. People don't upgrade their browser often enough. Some softwares like browsers have mechanism to quickly broadcasts revoked root certificates, and some software vendors have processes to rush release when a critical security vulnerability is found in their product, however you could be almost sure that they would not necessarily consider adding a new Root to warrant a rush update. Nor would people rush to update their software to get the new Root.

These are in addition to having to resign and reissue the certificates.

There were a number of Intermediate certificate compromises (e.g. Comodo) where the CA quickly handled the situation and leave without any major consequences. The closest we have ever got to root certificates compromise of a public CA, is DigiNotar. DigiNotar went bankrupt in the following weeks after the compromise was made public.


How does Burpsuite sitemap (find) this PHP file from a PortSwigger lab? I am doing the PortSwigger labs and came across this one: https://portswigger.net/web-security/deserialization/exploiting/lab-deserialization-arbitrary-object-injection-in-php
The first step of the solution is:

From the site map, notice that the website references the file /libs/CustomTemplate.php

How does Burpsuite find this file? It's not being loaded by any network requests that I can see and its only reference is in an HTML comment:

                <!-- TODO: Refactor once /libs/CustomTemplate.php is updated -->

Does burpsuite look for potential file names/directories in comments or something? It seems like this could easily return a lot of false positives. Or is it finding this some other way?

Yes, Burp Suite looks at comments to locate potential directories and pages, even if they do not exist.
I installed Burp Suite fresh, default config, and a fresh XAMPP on my machine and added the comment:
<!-- TODO: Refactor once /questions/237693/fake.php is updated -->

to the default index.hmtl page and browsed to the main page to trigger Burp's passive crawling. Nothing else. I did not create the path or the file nor did I try to navigate to that location.
This was what was added to the Burp Suite sitemap:


Which IPTables chains should I log from a security perspective So far I've always been logging the INPUT and OUTPUT chains because I only used iptables as host firewall.

Now I'm configuring network firewall which uses iptables, but I don't know whether I should be logging another chains like FORWARD, PREROUTING or POSTROUTING.

What security benefits would I get enabling those logs?

FORWARD:

It can be beneficial to log the FORWARD chain to doublecheck that routing decisions act as intended or to check that logic holes in the rules that you know to exist are covered. Often, logging the FORWARD chain is very targeted.

PREROUTING:

There is not a lot of value here to log because you will get flooded with noise. Unless you have processes in place to sort out the signal-to-noise ratio, there is little benefit.

POSTROUTING:

Because this happens after all the rules have fired, you should already know what is going to be in this log. If you want to know what bad things might have passed through, you would be better off running IDS systems after the firewall to give you this intelligence. The signal-to-noise ratio is also "off" at this point, but in the opposite direction: if you know how to properly identify the noise in the signal, then you would also be able to craft the rules properly. So, not a lot of actual benefit.

There may be other benefits to logging at these points, but from a "firewall security perspective" I'd stick to the higher value chains.


Fuzzing a webserver using DirBuster So I've been attempting to use dirbuster to fuzz a few vulnerable machines. I haven't been satisfied with the outputs so I started trying some manual fuzzing and then referencing the default dirbuster wordlist as well as others to make sure it wasn't a singular issue.

For example, when fuzzing using the default dirbuster medium size wordlist, 5 results appear. I know I can manually get 200 & 403 responses from pages like /config, /admin, or /mail, but they are not appearing in my dirbuster results even though they exist in the wordlist I'm using. I get an output like /error, /icons, /mailman, /pipermail, /cgi-bin, and nothing else, even though I verified the other pages exist in the wordlist and manually test correctly.   Does anyone out ther have an idea on what mistake I'm making that  is getting such a weird output?

I love the OWASP project and community (I'm actually part of it), but I don't like DirBuster at all, which is an OWASP project. It's very slow compared to other similar tools, and it easily crashes if you try to load a big wordlist.

  "Does anyone out there have an idea on what mistake I'm making that is getting such a weird output?"

You may be not making any mistakes; from my experience about 1-2 years ago DirBuster seemed a fairly unreliable tool, especially when using middle/large-sized lists, so it may be simply malfunctioning.

I strongly recommend gobuster. It's a command line tool, fairly flexible, and super fast. Most pentesters I know choose gobuster over any other similar free tools.

You could start with a command like the following one, explore the different options, and tune it according to your specific needs:

gobuster -u http://A.B.C.D/ -w /usr/share/seclists/Discovery/Web-Content/raft-large-words-lowercase.txt -s 200,204,301,302,307,403,500 -e

If you don't have one already, I recommend you get a Kali Linux VM so you can have lots of tools (including gobuster, dirb, and DirBuster) to play around with. Kali also comes with many good wordlists such as the one referenced in the command above.


How do I analyze traffic chain when using both Tor and a browser-configured proxy For example, I have set up the Tor network in Debian. I then set up proxy in Iceweasel browser (via the Preferences).

How can I examine the traffic chain to determine if browser requests first go through Tor and then through the proxy, or directly through the proxy, bypassing Tor? I am interested in this for examining the traffic chain in Debian and similar Windows configurations.

There is no way to do it with "external" tools. Because the information about the circuits is kept within Tor.

However you can utilise Tor's control protocol. This means you can connect to your Tor client and extract information out of your client. So sending GETINFO circuit-status prints out information to your current circuit(s). Usually Tor opens several circuits in parallel. So it's not easy to say which circuit was used for which connection. See the Path specification for more details. Roger Dingledine explained also some things in this answer on Tor.SE.


How does Google search extract text from pages behind a paywall? For a recent example, type in to Google (with quotes) "Reggie Kray as a character witness" and your first result should be this article from The Times. Even with all of my best JavaScript tricks, I can only read up to the start of the fourth paragraph. However, the Google search result is clearly showing a part of the article that was further on than I could read.
What sorcery is this? I don't find it likely that Google is paying for a newspaper subscription or that they're using some underhanded trick to bypass paywalls, so how have they got through this security?

If this happens, usually the webserver is detecting the GoogleBot and delivering a different result to google.
There where websites that just used the User-Agent header, so you could just change that in your client and read the full article.
Proper implementations will at least check that the IP also is actually one used by the Google Crawler.
If they have it properly implemented, you cannot get the content, unless you are Google.
I know one newspaper that obviously whitelists all Google IPs, so it is possible to bypass the paywall by using a Google Compute Engine VM, which uses an IP address owned by google but not one of the designated crawler IPs.


Siri DDoS over FM Radio A few days ago I was driving home and suddenly Siri started to talk by herself in reply to a command I never gave. As you can imagine I have the "hey siri..." feature active, so I can make calls without moving my hands from the wheel.

I was wondering...

Is it possible for a radio announcer to say something like "Hey Siri, open site www.victimsite.com" generating a DDoS or even say something like "Hey siri tweet #radiocool is a great station" creating a trending topic in seconds?

It is absolutely possible. There was a publicized case of this in a Xbox ad that demonstrated the voice activation features that seemed to have worked a bit too well.

Some quick-and-dirty remedies for this are:

Allowing users to program their own initiation phrase. This isn't perfect as the radio can still "get lucky" and hit the initiation phrase, causing an accidental triggering. Also, there's a time window between when you've initiated Siri and issued a command where the radio can talk to Siri.
Requiring confirmation for some/all actions. Unless the confirmation is physical, there is still an opportunity for the radio to confirm the task as well.

I guess the best solution would be for Siri to be able to distinguish your voice from the voices of others. That seems trickier though as, according to my understanding of the implementations, the initiation phrase (eg: "Hey Siri") is recognized locally by the phone while the full voice recognition utilizes cloud computing resources and the phone's local power is limited by CPU and battery.

I suspect that all that is needed is one successful attack for vendors like Siri and Android to come up with better defenses.


How short can a shortened base 62 url path be and be reasonably protected from a brute force attack? If one is creating pseudo-random base 62 url paths, and one didn't want those paths to be reasonably vulnerable to brute force attack.  How short could they be?

Reasoning

Now one could have expiring short urls and urls expecting to be read from a particular device key, and many other measures.  Also I'm sure there are ways to sniff out a url as it routes its way around the internet.  But I just want to set that aside to simplify the question towards what the minimum length of a url can be without it being fairly vulnerable to a brute force attack.

Of course, any url could be guessed at random, but if there are enough characters in a secret code then guessing that code can become almost impossible.  For example, password length requirements often force users to pick longer passwords so that they can be hardened to certain brute force and/or guessing attacks.  Most web servers or arrays of web servers can only respond so quickly to secret key requests, so there is generally an upper bound on how many attempts can be tried per second.

With a base 62 url path code, if my vague memory of math serves me, there are 62 to the N power possible path codes, where N is the length of the url path code.  4 characters is too short because that would only provide about 14  million codes, some popular web sites and applications have more users than that such that you wouldn't even be able to provide enough shortened urls.  6 characters seems popular among quickly expiring codes, but even that is pushing it if one had a lot of usages.   On the other hand, a 100 character length code is probably unnecessarily large.  A code that large seems both impossible to guess at random and difficult to brute force while providing more usages than most humans living on earth could find for a code of that length.

So that leads me to wonder where is a nice middle ground between 6 characters and 100 character length codes?  What is a good minimum length for a base 62 url code? 16 characters?

Only YOU can stop brute force attacks!

But, seriously - we must model what it is that we have, and what we want to achieve.

Let us start with how many "real" URLs we need. Let this number be N.

Now assume there is some level of protection (possibly none; actually, bandwidth and computing power to receive the request and reply with a 404 Error always provides a practical, if possibly very high, limit) against brute force attacks, that limits them to M attempts per second.

Finally let us assume that by "stopping brute force" we mean we want the URL to remain secret for an average time of T seconds.

When brute forcing an item from a space of cardinality K, the first attempt has a probability of (K-1)/K of failing (all values but one of the K available are incorrect). The second has a probability of (K-2)/(K-1), because the space to be explored is now diminished to K-1, and all these values but one are still incorrect. The probability of failing both attempts is the product of the two probabilities, so ((K-1)/K)*((K-2)/(K-1)), which is (K-2)/K. In the end, the probability of failing all of the first H attempts is (K-H)/K.

If we want, say, a 99% probability of the URL to remain undisclosed for T seconds (which equates to M*T attempts), it must be that the unknown number of possible values K is such, that (K-MT)/K = 99%, or (K-MT) = 0.99*K, which means M*T = 0.01*K; or K = 100*MT (for a generic safety probability of P%, it is K = MT*100/(100-P) ).

This gives us K for any given M, T and P.

We need this K to hold for all our N codes, so the actual width of the data space must be MNT/(100-P).

If we can limit the attempts to 10 per second, and want one year's leeway (about 32 million seconds) with a safety of 99% for our 10 million codes, 10*1E7*3.2E7*100 = 3.2E17. Since log10 of 62 is about 1.7924, CEIL(18/1.7924) = 11 should be a reasonable figure.

In the end, the number we seek is CEIL(LOG10(MNT/(100-P))/LOG10(62)).


How to find entry points to physical systems I read an article on wired about a whole transit system getting hacked. The intruder disabled ticket machines and displayed messages on the station displays.

I was wondering how an attacker finds an entry point if he doesn`t know the IP of the device he is targetting. Did he manipulate the physical devices found in the stations? Did he ever have to enter a station or could he act from the anonymity of his PC?

According to Krebs, the attacker was scanning the Internet looking for a specific vulnerability. Once found, the attacker infected the network.

No physical access required.


Is SSH server secure from internet access outside private network? I have a desktop computer in my home network with SSH server running on it. Using another computer in my private and local network (class C IP addresses: e.g., 192.168.0.2, etc) I sometimes use SSH to enter into the desktop PC with command ssh <user_name>@192.168.0.2 and work remotely.
I am wondering if someone from the internet (thus from outside my local network) may gather access to my desktop computer via SSH (i.e., by guessing the user_name and password). Is this SSH server/service accessible from the outside if the username and password are known? Or is impossible to gather access without knowing other details such as the IP of the network gateway and others.
My goal is to keep using SSH internally in my local network but at the same time block any possibility to gain access to any device in the network from the outside. So securely use SSH.

SSH is a professional grade protocol, and most server and client SSH software have been intensively scrutinized for possible flaws, so if you use it in a conformant way it is secure.
Simply best practices recommend to have more than one defense line. If you want a professional grade security, you must behave as a professional admin:

if it is an option, prefere ssh keys to passwords, because they are deemed impossible to guess
add an additional defense line at the router level by ensuring that no input connection to a SSH port are allowed - for a private network, ensure that no incoming connection at all are allowed
add a last defense line at the server level by only allowing local addresses

It implies a bit of configuration but security only comes at that price.


How SSL server can select cipher suite from Client proposed parameter? When Client send list of cipher suites in client hello.. at that time server will select from one cipher suite. I want to know how it is selected?

The server checks which ciphers are offered by the client and are also supported by the server. From this it then select the final cipher. If this choice is more based on the clients preference (order of ciphers in the ClientHello) or on the servers preference depends on the server configuration, e.g. the ssl_prefer_server_ciphers setting in nginx or similar settings in other servers.


Is that possible for Linux and windows machines to be infected with KeRanger ransomware? According to theguardian The Transmission site offers the open source software that was infected with the ransomware called KeRanger malware, it's programmed to encrypt files on an infected personal computer then the hackers will asks users to pay ransoms.
Is that possible for windows and linux users to be affected by KeRanger after using Transmission client?

No, but it's hard to say this because it's a new kind of ransomware.

Ransomware isn't currently spreading to other computers, it only stays on the infected computer.


SSL Certificate Management and Expiration Notification What utilities are good for notifying admins of SSL certificates that are about to expire?

Symantec and DigiCert have certificate management products, but what systems or utilities do you use to keep track of expiring certificates?

They are lot of utilities available to notify the expiry date of the SSL certificate and most of them depends upon the application specific. For simplicity, you can write your own script or code and you can customize the things more simpler. even  you can do with openssl or keytool to run in a cron job to send a mail or sms automatically.


Difference between certificates with "extension fields" and "Non Repudiation" usage For example we have two certificate pairs:

First pair:

Server cert with "Non Repudiation" (sometimes called Content Commitment) usage,
Client cert without any "extension fields".

Second pair:

Server cert with "TLS Web Server Authentication" usage,
Client cert with "TLS Web Client Authentication" usage.

Both clients can authenticate against server. But what is the difference between all these methods? Does certificate with "Non Repudiation" usage allow to authenticate all clients with/without "TLS Web Client Authentication" usage?

But "TLS Web Server Authentication" without "Non Repudiation" allows to auth clients only with "TLS Web Client Authentication" usage?

Is it correct?

The extensions are only some kind of policy meta-data attached to the certificate. Technically, no matter the extensions, a certificate remains the same thing: a file linking a key to an identity. Its information could be used for any purpose: authenticating a server, a client, signing other certificates, signing emails, signing software/driver code, etc.

That's where extensions enters into play: they tell the application which usages are applicable to this certificate, so that when the application encounters the certificate in an unauthorized context it could (or must, depending if the usage is set to critical or not) consider the certificate as invalid and refuse it.

However, this check must be done at the application level. A poorly implemented application may not check these usages properly and accept any certificate at any time.

Also, few supplementary things must be noted:

These extension are only restriction. A certificate with no extension is allowed to be used in any role (no usage limitation), while a certificate containing some extension is restricted to the usage defined by these extensions,
Theses extension are actually divided in two main parts (plus one merely hstorical):

The key usage (like "Non-repudiation" in you example) defines lower-level cryptography usage allowed for this certificate,
The extended key usage provides a higher level usage authorized for this certificate ("TLS Web Server Authentication" and "TLS Web Client Authentication" in your examples).
Some applications also handle what's called Netscape Cert Type, it can be seen as the precursor of the extended key usages and gather usages such as "SSL Server", "SSL Client", etc.

All of these key usages may be associated and used in a complementary way.
Some extension might be flagged as "critical": this flag determine how an application not recognizing / having not implemented a specific extension must handle the certificate. Under such situation, if the "critical" flag is enabled the application must reject the certificate, when this flag is not set the application may still accept the certificate.

Extended key usages names (as well as Netscape cert type) are rather straightforward to understand. Key usages however deeply depend on how the protocol (in case of a network communication) will use the certificates. Commonly found key usages for a SSL/TLS client/server application are the following ones:

Server: Digital Signature, Non Repudiation, Key Encipherment,
Client: Digital Signature, Key Encipherment, Data Encipherment.

So, to answer to your edited questions:

  Does certificate with "Non Repudiation" usage allow to authenticate all clients with/without "TLS Web Client Authentication" usage?

  But "TLS Web Server Authentication" without "Non Repudiation" allows to auth clients only with "TLS Web Client Authentication" usage?

The "Non Repudiation" usage from the server's certificate will be mostly checked by client software, not by the server, and it will have no impact on the way the server will validate client's certificates.

"TLS Web Client Authentication" usage will prevent client's certificates from being used in a server context. It's absence will not block any authentication. However, if a client tries to authenticate using a certificate without this usage but with "TLS Web Server Authentication" instead then the authentication will most likely be refused by the server.


Secure SSL Session from losing itself into unsecure http I've seen some implementations of HTTPS SSL and, as a visitor, forced to rely to a lot of those. What would a secure implementation look like and where can one expect problems? I expect the installer to understand what should be done by implementing the SSL itself.

The question come of the fact that some https sites suddenly forget that you are using https. Such problem appear after a submitted form, a silenced error message (i.e. you got a blank template page and press back button).

When establish a new or porting a established site into HTTPS, how do you deal with some facts, like

You probably into mixed mode if you forgot some reference to old http:// (which seem to apply even on the biggest web sites that have streams, different servers, user-uploaded content).
Are there more complicated descisions like parse the ip adress and "accept http on some traffic / ip sources"?
Force visitors into HTTPS. There may be hundred of thousands of links from outside, to the page that you don't want to shutdown with a complete closing of the HTTP entry. Or would you?
Probably not least, how do you avoid try/cached/throwed Error and such unexpected (or not studied) actions, port your users into HTTP mode?

This question can appear language specific, but I'm sure the security point of view is enough visible. The most simple scenario should be just close down the http entry, but how applicable are that - if you want current entries to remain (but redirected)?

Basic rules for SSL protection for a website

  How would a secure implementations look like and where can one expect problems?

These rules are intended to provide SSL protection, that is protection against an opponent that can intercept and alter packets.

Subcomponents

  You probably into mixed mode in some scenarios

If, in a HTTPS page, you load any script, or CSS resource in plain http, that nullifies the SSL benefit (not just reduce).

As a rule, in a HTTPS page, load every subcomponents (frames, scripts, styles, images) over HTTPS, from trustworthy hosts.

Cookies

A particularly unfortunate mistake is to forget to make all cookies "secure". If you forget to mark all security relevant cookies with this attribute, it nullifies the SSL security. (Obviously a login/session cookie is security sensitive.)

As you want your website to be entirely over HTTPS, mark all cookies "secure".

One problem is that even "secure" cookies can be replaced by cookies HTTP non-secure cookies! What makes it even worse is that the browser will not even tell you if the cookie came from HTTP or HTTPS!

You can assume that a secure cookie cannot be read by an opponent. But you cannot assume that a cookie sent by a browser over HTTPS is the secure cookie you sent previously.

Whole site SSL protection

By providing content over HTTPS not just for some "sensitive" pages, but for the whole site, you will train users to only use your site over HTTPS which is quite good for security.

In order for users to be able to enter an HTTP URL, you will certainly do an HTTP redirect from HTTP to HTTPS, so that the only non-encrypted HTTP traffic is a HTTP redirect (in the usual, no attack, case).

The problem here is that if users get used to type the HTTP URL, and they might fail to check every time that they are properly redirected to the corresponding HTTPS site: an attacker that can intercept and modify packets can alter the HTTP request to redirect to another misleading HTTPS site, or just assume that the user doesn't usually doesn't detect the HTTP/HTTPS difference: this is a good reason to use HSTS.

Other website security principles

The SSL cryptographic protection is an essential part of website security, especially to protect the secrecy of passwords. But it isn't the end of the security requirements that are specific to websites.

Just as a reminder, some other essential security principles:

Safe handling of untrusted data

When taking user input and outputting it in web page, you must apply proper escaping to avoid XSS vulnerabilities. For this, you must understand that different parts of the HTML page have different syntax (normal HTML, attribute value, URL have completely different syntaxes) and thus need different escaping.

As in any other program taking external untrusted input, you must properly validate every input, and store and output it in a way that does not misbehaved if an unusual character is present (see: SQL injection).

Verification of authorisation on the web

You cannot only rely on cookies (or HTTP authentication) to validate that a specific order from a HTTP client is authorised: doing so would expose your website to a CSS attack from another website if the user browse both websites in the same browser.

My view of secure design

The problem with website security is often caused either by not understanding the different specific requirements of these web protocols, or by securing all but one "entry point".

Before you even to design a "secure" website, you should understand all these requirements; then you should apply them in a systematic way. Your design should be simple, regular, understandable, and easy to audit.

The best style is one where you just cannot forget to apply to escape text that is going to be interpreted as HTML/HTML attribute/SQL/SQL "regexp"/shell commands/shell regexp. The best approach, when possible, is to prevent variable data that is not intended to be interpreted as HTML/HTML attribute/SQL/SQL "wildcard expr"/shell commands/shell regexp to appear in such context that it requires escaping: avoiding need to escape is safer because you cannot forget to escape things.

I know that I am drifting off topic here... so I will stop now. I just wanted to it clear that HTTP security doesn't stop at "100 % over SSL".


How well-protected should customer billling & invoice data be? Specifically, I'm curious about Recurly.com's hosted_login_token, described here: https://docs.recurly.com/docs/hosted-account-management

Basically, it's a token that they allow to be stored in cleartext and even emailed with customer invoices and notifications. It's unique per customer, but never expires. It's also embedded in the link that users use to access these hosted pages, so anywhere the URL might be collected (SSL helps with this, yes?) could be a vulnerability.

The UIs it provides access to contain:

User PII, like name, address, and phone number,
Obfuscated payment info, e.g. 43XX-XXXX-XXXX-1234 for a CC# (no CVV),
Invoice data about what the customer has purchased.

On the one hand, that's a lot of data to gather if, say, we stored the tokens and were compromised or an email relay somewhere were compromised. On the other hand, this is all data that's regularly sent out via snail mail every day.

More troublingly, these UIs can also be configured to allow users to update (but, again, not view) their payment information, or cancel their subscriptions.

We would like to use it to provide our customers access to hosted, self-service billing admin pages with all of the above features. We'd provide them access by embedding a link (containing the token) to these UIs behind our own login, on our domain. All pages on our site containing the token would be served over HTTPS.

How should I handle these hosted_login_tokens?

(Thank you in advance, from this security.stackexchange newbie.)

Token as an equivalent of a document
As I understand from your question, the token essentially provides access to all the information typically contained in a customer invoice. This implies that you should approach the security of this token (both in storage and in transit e.g. over email) in the exact same manner as you would the document itself.
If sending that invoice in pdf format over email is acceptable, then sending that token is acceptable as well. If you would only allow downloading such invoices over https but not over http, then the urls with these tokens should also be set https-only. A database containing a lot of these tokens has the same risks as a file storage system containing a lot of historical invoices.
The only token specific risk that comes to mind is guessability - if the tokens are not properly implemented, an attacker would be able to obtain this data without having a proper token by either random guessing or by modifying an existing token. However, it seems that it's not the case for these particular tokens; a simple true random ID from a very large space of possibilities is safe against such attacks.


(WMI Infections) Suspect behavior from scrcons.exe detected? In almost every five minutes, I come out of the AVG avg stop downloading files and do not know which program wants to download these files.

I have read this before WMI Infections

So, i opened this question because, i think this malware variant used WMI to maintain persistence.

I have read this too : Explained: WMI hijackers

  Effectively, the script to be executed is hidden from the user, and
  the script (as a file) isn’t stored on the system. Which is why it is
  considered as another fileless infection. WMI techniques were used by
  malware like Stuxnet in the past.

The target IP belongs to KRYPT TECHNOLOGIES, which is a cloud hosting company.

Their IPs are known to be used in an abusive manner:

they are known for using and hosting ambiguous domain names
they tend to also have malicious traffic and internet abuse trends
many of their so called legitimate websites hosted by them are actually fronts for hosting virus’s and other malicious distributed files, attacks and other malicious activities
BOTNET activities
activities that have been monitored through their internet access has been Spam, Virus Activity, Hacking Attempts, as well as Malicious file distribution

Verdic: Virus/malware.

Recommended Actions: delete files, blacklist IP in firewall.


What is the difference between an anti-virus and an IPS? As I understand it, an intrusion protection system (IPS) detects anomalous behavior, does detection of protocol anomalies, and does signature filtering that blocks malware, DDoS, etc.  An antivirus also scans the traffic and blocks malware.

I am confused then - what is the difference?

Is an IPS like Checkpoint ultimately adding antivirus signature in IPS only, or is it using entirely new software?

Can Suricata acts as IPS as well as antivirus if i add CLAMAV signatures in it?

A good simplistic way to think of this is that an IPS generally is associated with a firewall, whereas AV is associated with software.

In the McAfee environment I administer, I use IPS to block/allow firewall traffic.  So I take what is known and expected, and then block the rest.  IPS also looks at what applications are communicating over which ports and to where.

Antivirus, on the other hand, looks at software that wants to run on your device and compares that against a list of known bad executables and, along with heuristics, against a list of known bad behaviors.  So AV would stop CryptoLocker by blocking the encryption behavior, and IPS would (theoretically) block it by blocking traffic to its C&C server.

I'm not familiar with Checkpoint so I'm going to defer answers to that question to other folks here.


Are there any modern governments which use a proprietary encryption algorithm? Germany used Enigma during WWII. The Soviet Union used GOST during the cold war. USA used to use DES. Now that encryption algorithms are believed best as open source, are there any modern governments using proprietary encryption algorithms?

Quite frankly, the answer is obviously "yes". There's been quite a few disasters regarding crypto devices sold to governments that had other government's backdoors in their proprietary crypto.

Also, common sense dictates that it's highly unlikely that seldom-used military systems would be exchanged completely – if you transmit 10 bit in 20 years, it really doesn't matter how easy to crack it'd be if you had a couple 100 kb observations of known plaintext etc.

Also, I just googled "proprietary encryption" communication devices for military and you might want to do the same, read a couple of the first 20 results or so.


How to safely "reply" to spam email? I have received an email flagged as spam from Yahoo but it was strange since it contained part of my password. The email states that they know my password so I better pay them in BTC.
I think I had to change my password some years ago since Yahoo said it may have leaked, but I used the same base password with slight change, so my new once still contains the word that was quoted in the spam email.
Yahoo logs for sessions didn't show anyone else logging in recently so I changed my password to something completely different (oh, I already forgot it...) and also I changed my recovery email password, to be on the safe side.

Since the sender claims to have videos of me from my computer camera, but I don't have a camera, I feel safe knowing they have just my old password and I would like to send an email to the sender, but from a different email address.

Probably I should create a new email just for this purpose, but is there something else I should look for so that I don't get identified in any way?
Can I be traced by using for example Yahoo website to send an email?

Of course I will not mention the specific data from the email that was sent to me

TL;DR
Don't reply to spam emails

There are many databases where corporations had been exposed and your data in them. You can check your accounts on services like https://haveibeenpwned.com/.
When you reply to those emails you're also telling the spammer that your account it's still active and they can perform a direct attack on you, they also could try to hit you with different spam attempts than just reporting them.
And as a friendly reminder try to always use 2FA (Two Factor Authentication) and a password manager.


Which approach is technically more effective to hinder user tracking - fingerprint generalization or randomization? Tor's approach to countering fingerprinting is to make as many users "appear the same" as possible. Let us call this "generalization". While Brave tries to randomize all fingerprints of each and every user in a unique way (for each new opened session).

A short quote from Brave to get the context:

  "We're adding subtle, non-human perceivable noise to the JS readable
  outputs of the audio, canvas and WebGL APIs. The randomized end points
  give you unlinkability across sessions for (for any fingerprinter who
  consumes a randomized endpoint)"

Which of those two approaches
(randomize vs generalize fingerprints) is technically more effective
in making it more difficult to track/pinpoint
that a user across weeks of different browsing sessions is the same
user?

This is about technical facts not opinions. I am not a expert, but I assume that this is a clear technical question and experts should be able to tell the difference of both approaches' impact on user identification.

You are comparing apples with oranges.

Tor makes standard only those parameters that can be the same without any disadvantages to the user. For instance, window size or agent string. But some parameters like result of drawing something on canvas cannot be done standard. If you draw things in the same way everywhere, the web page can look unreadable.

What Brave and many FireFox and Chrome extensions do, is adding some noise to such  data like drawing on canvas.  As long as changes remain small and not perceivable, users don't complain about the negative effects of such noise. But this is also a limitation of such protection method. Because making sure the noise is not perceivable means that some statistical parameters must remain in a limited range. This means that despite some information provided by canvas is lost, it remains still not null and can still be used to compute a fingerprint.

What of these methods is more effective depends on particular fingerprinting algorithm. If algorithm uses canvas fingerprint blindly, believing it gets say 15 bits, then actually we should subtract these bits because they will be different each time. Thus Brave approach would be more effective.

But if some site uses another fingerprinting, calculates some statistical values (some average values, deviations, etc.), then in general it gets less bits of information, let say 5 bits instead of 15. But it remains resistant to small noise added. Thus this fingerprint will be the same for Brave and for Tor, where as Tor has some other parameters standardized. In such case Tor will be more effective.

There is no simple answer.

Update

We should consider also the other side: the web site that computes your fingerprint. The meaning of effective depends a lot depends on many factors:

... on the purpose of fingerprinting: may be the web site doesn't have any interest in particular persons, but just wants to have to measure some metrics about its users; as long as they get statistics with acceptable precision, they will not invest much budget into development of very complex fingerprinting. Other web sites for their needs will develop more complex algorithms so that both Tor and Brave are fingerprintable
... on the skills of developers designing and implementing fingerprinting for particular web site: in one case Tor and Brave can both be effective, in other case the countermeasures of the both can be insufficient
... on the budget available: if a web site can afford sufficient budget for research, for design of complex algorithm, for its implementation in a good quality, for its maintenance, then both Tor and Brave can be too weak to prevent precise fingerprinting

And this is of course an arms race: after one side found a countermeasure, the other will work to make it ineffective.

In general, I think fingerprinting is in the most cases unavoidable as long as the code you download from web sites is allowed to communicate with these web sites.

That's why I find it very naive, that there is a legal requirements in the last years to inform users about cookies used. Fingerprinting requires more resources to keep data and to correlate across different web sites, but it does its job. One can delete cookies in the browser or user ad blocker. But preventing unique fingerprints is much more complex.


What guarantees does GPG-signing a git commit provide? It's pretty clear that GPG signing and GitHub ssh keys serve different purposes

But what is the use of GPG signing commits? Is it just that you know that commit abcd1234 was signed by Alice's key? Is there anything else that GPG signing a commit is useful for?

With git, a cryptographic signature at the tip of the branch provides strong integrity guarantees of the entire history of that branch going backwards, including all metadata and all contents of the repository, all the way back to the initial commit. This is possible because git records the hash of the previous commit in each next commit's metadata, creating an unbreakable cryptographic chain of records. If you can verify the cryptographic signature at the tip of the branch, you effectively verify that branch's entire history.

For example, let's take a look at linux.git, where the latest tag at the time of writing, v5.5-rc4, is signed by Linus Torvalds. (This is slightly different from your question because you asked about signing commits, while we're looking at signed tags -- but in every practical sense this is exactly the same.)

$ git cat-file -p v5.5-rc4
object fd6988496e79a6a4bdb514a4655d2920209eb85d
type commit
tag v5.5-rc4
tagger Linus Torvalds <torvalds@linux-foundation.org> 1577662169 -0800

Linux 5.5-rc4
-----BEGIN PGP SIGNATURE-----

iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAl4JNtkeHHRvcnZhbGRz
...
=rNsn
-----END PGP SIGNATURE-----

The entire contents of this tag are signed, so this tells us that when Linus signed the tag, the "object hash" on his system was fd6988496e79a6a4bdb514a4655d2920209eb85d.

But what exactly is that "object hash?" What are the contents that are hashed here? We can find out by asking git to tell us more about that object:

$ git cat-file -p fd6988496e79a6a4bdb514a4655d2920209eb85d
tree 30efc38ed890f113f9e1f0cbc801bab7090365eb
parent a99efa00891b66405ebd25e49868efc701fe1546
author Linus Torvalds <torvalds@linux-foundation.org> 1577662156 -0800
committer Linus Torvalds <torvalds@linux-foundation.org> 1577662156 -0800

Linux 5.5-rc4

The above contents in their entirety (slightly differently formatted) is what gives us the sha1 hash fd6988496e79a6a4bdb514a4655d2920209eb85d. So, thus far, we have unbroken cryptographic attestation from Linus's PGP signature to two other important bits about his git repository:

information about the state of his source code (tree)
information about the previous commit in the history (parent)
information about the author of the commit and the committer, which are the one and the same in this particular case
information about the date and time when the commit was made

Let's take a look a the tree line -- what contents were hashed to arrive at that checksum? Let's ask git:

$ git cat-file -p 30efc38ed890f113f9e1f0cbc801bab7090365eb
100644 blob 196ca317bd1f24ad57ad9ded549bc0b7994d8111    .clang-format
100644 blob 43967c6b20151ee126db08e24758e3c789bcb844    .cocciconfig
100644 blob a64d219137455f407a7b1f2c6b156c5575852e9e    .get_maintainer.ignore
100644 blob 4b32eaa9571e64e47b51c43537063f56b204d8b3    .gitattributes
100644 blob 72ef86a5570d28015d0ccb95ccd212bf8820c1c2    .gitignore
100644 blob a7bc8cabd157b89adbc2d8f6c4d6e3c88b14e3cd    .mailmap
100644 blob da4cb28febe66172a9fdf1a235525ae6c00cde1d    COPYING
100644 blob 9602b0fa1c958da4b605127c2b8da0628efeb34e    CREDITS
040000 tree b239b5eaacf2619bf564d152661ee425c4ee76f9    Documentation
...
040000 tree 82dd6833b421625c7b15d4d1c26964fc65874eb4    virt

This is the entirety of the top-level Linux kernel directory contents. The blob entries are sha1sum's of the actual file contents in that directory, so these are straightforward. Subdirectories are represented as other tree entries, which also consist of blob and tree records going all the way down to the last sublevel, which will only contain blobs.

So, tree 30efc38ed890f113f9e1f0cbc801bab7090365eb in the commit record is a checksum of other checksums and it allows us to verify that each and every file in linux.git is exactly the same as it was on Linus Torvalds' system when he created the commit. If any file is changed, the tree checksum would be different and the whole repository would be considered invalid, because the object hash would be different than in the commit.

Finally, if we look at the object mentioned in parent a99efa00891b66405ebd25e49868efc701fe1546, we will see that it is a hash of another commit, containing its own tree and parent records. If we cared to, we could walk each commit all the way back to the beginning of Linux git history, but we don't need to do that -- verifying the checksum of the latest commit is sufficient to provide us all the necessary assurances about the entire history of that tree.

So, if we verify the signature on the tag and confirm that it matches the key belonging to Linus Torvalds, we will have strong cryptographic assurances that the repository on our disk is exactly, byte-for-byte the same as the repository on the computer belonging to Linus Torvalds -- with all its contents and its entire history going back to the initial commit.

Since you asked specifically about signing commits as opposed to signing tags, I have to mention that it's generally a good practice to PGP-sign commits, particularly in environments where multiple people can push to the same repository branch. Signed commits provide easy forensic proof of code origins (e.g. without commit signing Alice can fake a commit to pretend that it was actually authored by Bob). It also allows for easy verification in cases where someone wants to cherry-pick specific commits into their own tree without performing a git merge.

If you are looking to get started with git and PGP signatures, I can recommend my guide here: https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md

Important note: sha1 is not considered sufficiently strong for hashing purposes these days, and this is widely acknowledged by the git development community. Significant efforts are under way to migrate git to stronger cryptographic hashes, but they require careful planning and implementation in order to minimize disruption to various projects using git. To my knowledge, there are no effective attacks against sha1 as used by git, and git developers have added further precautions against sha1 collision attacks in git itself, which helps buy some time until stronger hashing implementations are ready to go.


Android/iOS application security testing checklist According to OWASP, we have a list of top ten mobile application vulnerabilities.
But we are damn sure that the number of vulnerabilities on mobile apps, especially android apps are far more than listed here. And also I couldn't find a comprehensive checklist for either android or iOS penetration testing anywhere in the internet. If anyone have such a list with mobile application vulnerabilities and their testing methodologies please share here. Anything like a link to any such sources are also entertained.

There is a project called OASAM that aims to define a methodology to test Android devices.

You can find it here: http://oasam.org/en

The guide has the following sections:

OASAM-INFO:  Information Gathering:  Information gathering and attack surface definition.
OASAM-CONF: Configuration and Deploy Management: Configuration and deploy assessment.
OASAM-AUTH: Authentication: Authentication assessment.
OASAM-CRYPT:  Cryptography: Cryptography use assessment.
OASAM-LEAK: Information Leak: Confidential information leak assessment.
OASAM-DV: Data Validation:User entry management assessment.
OASAM-IS: Intent Spoofing: Intent reception management assessment.
OASAM-UIR: Unauthorized Intent Receipt:Intent resolution assessment.
OASAM-BL Business Logic: Application business logic assessment.


What SSL certificate do I need? I have 2 domains, one where the website is hosted (lets call it www.a.com), and another (lets call it www.b.com) which has a CNAME record pointing to the first one (www.a.com). Which one should have a SSL certificate? Should they both?

Certificate validation is done against the hostname given in the URL, which means you'll need a certificate for any hostname which you expect to be used inside a URL.

Thus, if you want to use both www.a.com and www.b.com in the URL you need a certificate for each, even if they are the same host and if one redirects to the other. DNS settings like same IP address or alias (CNAME) do not matter at all, all that matters is the name given in the URL.


How do OTT providers protect LIVE streams? For Video on Demand, DRM seems the way to go. I've been told that providers might be using a token-based system, but I haven't found any provider so far that uses token, just DRM (except Akamai, although it integrates with DRMs anyway).

However, I'm not sure which technologies are being used to protect LIVE streams.

The industry is using something called "forensics watermarking", which is a technology to track who's the source of an illegal video stream and eventually shut it down. That technology is rather a detective control though. I'm interested in technologies to prevent that unauthorized users access the original stream.

So my question is, what technologies are there available to protect an OTT LIVE stream?

Notice that geoblocking, IP access control, HLS/DASH encryption (AES-128) or use EME/CENC are not the answers I'm looking for. My question is regarding the technologies that make it possible to implement these things based on user authentication/authorization.

So to support Live Stream and requirement that only logged-in users are allowed, the database of the users is needed. This also means there's need for registration.

To allow only registered users to view the live stream, you need your own website with user registration, and then you need a media server or CDN which will check with your web site if token (cookie) is valid.

The below scheme is in its simplest form. Normally there's dedicated "Key Server" as with typical encryption system. Additionally the stream is also encrypted and the key server is not only checking your username / password or token but if the content owner allows you to play the stream. It would also send you the decryption key (or the license, depends on the technology used).

Most media servers and CDNs support this. With HTTP servers can have custom authentication module.

If you look for technology which can do all of that look at Kaltura, they got free version as well.

Regarding HLS and DASH streams, ideally it would be:

CDN service which checks the tokens with your Key Server (because main app server is not the one you want to query because of performance, the Key Server must have cache of tokens or dedicated scalable database).
Your media server can have simple plugin to check for tokens
Your HTTPd server can have custom module to check for the tokens

In case of DASH and HLS you have 1. metadata files (like m3u8 or manifests) and media fragments. All fragments are usually encoded with single AES key and the key is normally stored in the meta-data files. It's quite different for DASH as there can be optional key server.

So the solution for HLS is for example to send Cookie to every possible request and then check for that Cookie. HTTPD server has to have cache of this stuff. You could extend this method to DASH however they provide  more decent mechanisms.

The current technology to protect content:

Most live streams are using Flash Access (as flash is major platform for live stream delivery)
There's Widevine by Google which is slowly being adopted (Android)
Microsoft Playready
W3C EME
Custom token-based authentication in simplest form - and that's not a technology but a way of integration.


Mitigating the risk for a successful ransomware infection The company I work for has been getting hit with loads and loads of frightfully sophisticated ransomware spam lately, people masking as consultants, customers, very specific company requests, etc. Even though we do daily offline backups, and even though we have Enterprise Endpoint protection by Kaspersky, im worried that one of those days one will slip through the cracks and severely damage us. Here are some steps we have already taken to mitigate:

Tell people they should never open suspicious email attachments, and err on the side of caution.
Restrict access to all network shares to a need-to-know basis
Automatically strip .exe .rar and .zip files in our exchange server

Still, despite all this, the spam emails are getting better, and our Kaspersky has to stop infections almost daily. Our staff are mostly office people, so most of them have understandably little idea of whats going on. What else can we do to mitigate our risks?

There are different ways to approach this, including:

Mitigation of the infection
Filtering emails better
Educating users

As your question regards the mitigation of a infection, I will keep the other parts short.
Filtering emails
The problem are not only attachments but also html emails that could directly attack the email client - or contain fraudulent links.
Depending on the business, this method may or may not be applicable:
Deploy greylisting in conjunction with an attachment check and SPF and/or DKIM. E.g.

That sender is new to me - it has an attachment. If the DKIM signature cannot be verified, I'm not letting this through.

Mitigating the risks
Again, this depends on your business. If there isn't loads of data being used (and written to), this might be a possibility:
Have a "staging area" for each login session - e.g. the "Documents" directory being the only directory with write access for users.
Then, they may write new files (or open read-only old files and edit them) there - the sandbox get's then migrated to permanent storage with a logout script, changing permissions to read only.
The problem with this is: if the malware uses priviledge escalation, there is a chance it changes permissions and encrypts anyhow.
There is also another question (by me) here that has higher demands on the write access, maybe that helps you.
The key point is to rescrict write access as much as possible - maybe introducing some organizational overhead with manually requesting rights from the sysadmin, but minimizing the damage that can be done.
As FerryBig pointed out in the comments: of course all software should be kept up-to-date at all time (with verified updates) and no software should be used that is discontinued or known to have unfixed vulnerabilities (looking at you, flash!).
User education
Basically, even not-suspicous looking file attachments are a bad idea.
The general rule of thumb would be to not open attachments that are not expected. Cross reference this answer on malware infection, also - unfortunately, also by me.


Bad USB malware and Chrome OS I have recently been reading about the unpatchable BadUSB and similar malware. I use Chrome OS, which is supposed to be very secure, but could someone with physical access to my system compromise it with malware such as this?

TL;DR: ChromeOS is vulnerable to BadUSB, but this is probably not a big security concern.

BadUSB works by installing malicious code in a USB device controller. This can allow one type of device to impersonate another. For example, a thumb drive may impersonate a keyboard; one that starts typing commands right when it is plugged in. While operating systems have moved away from autorun functionality to prevent an attack from happening the moment you plug in a drive, OSs still allow a keyboard to begin typing without any security prompts. So any OS that allows a keyboard (or mouse or potentially other USB devices) to immediately start interacting with the computer is potentially vulnerable to BadUSB. Unless I'm mistaken, this is true for Chrome OS.

That said, I doubt that this should be your biggest security concern. BadUSB is difficult to execute. It involves finding a hackable USB device (it seems this isn't difficult as USB microcontrollers aren't well protected), creating software appropriate to the device type and the attack you are planning, hacking the device (either physically or by flashing the microcontroller), engineering the process of getting the device used on the target computer, and then being able to perform the attack without being noticed. Note that this last part is non-trivial as this is not some backdoor, over-the-net type attack. This is a USB device that unexpectedly starts typing characters, albeit very quickly, while you are looking at your computer.


Security impact of cheap L2 switches What is the importance of firmware in Managed L2 switches? Does using ancient software matter from a security standpoint? Is a Linux 2.6.x firmware easier to hack than a 4.x one? What about outdated eCos? Do those switches really have an attack surface outside the servers (Radius?) and management VLAN? If one only doesVLAN what could possibly go wrong? Could a Zyxel or HP (Linux or eCos) switch with outdated firmware be secure? How would the firmware interface itself with the hardware in this case?

My wired alarm system could run MS-DOS for all I care, it will never get in touch with hostile code (short of physical tampering)... What's the deal with managed L2 switches?

I'm mainly considering integrity (worms, pwnage etc) rather than availability (DoS).

It can matter in some areas, notably how secure the management interfaces are. One potential issue with older switches is that they might support broken or weak encryption, which might allow an attacker to obtain credentials (e.g. the switch might only use a 1024 bit key to secure https).

Similarly, web security has improved over the years, and for switches that provide a web-based administration panel, there may be vulnerabilities in either the web server itself (lighttpd springs to mind, and has CVEs up to 2015: https://web.nvd.nist.gov/view/vuln/search-results?query=lighttpd&search_type=all&cves=on).

A lot of the risks related to these issues can be mitigated by controlling access to the administration interfaces (and the network that provides that access).
In all cases, I would generally tend to think it worthwhile to periodically review known issues and vulnerabilities, to determine what risks may be related to your equipement.

Taking for example the 2.6.7 kernel, a quick, non-scientific check suggests there are two remote exploits to be aware of:

https://www.exploit-db.com/search/?action=search&q=Linux+Kernel+2.6&type=3

I would make sure that those vulnerabilities could be detected, possibly by using or creating appropriate IDS rules. I would also check if there are anyt further remotely exploitable vulnerabilities related to the specific vendor/product.

Local exploits would be the next area I would consider, to understand the risk profile (for example, it may be that local exploits are enough of a concern you will want to prevent humans having access to your equipment, and instead write some kind of script to execute specified actions (or even look at using something like rundeck).

Generally, I think this is a case of first understanding what the actual risks are, and then determining what mitigations exist. This is the same process irrespective of the age of the software.

But do keep in mind the other comments and answers here, which also take into consideration the difference between 'old and working fine' and 'new, possibly safe, but not working'.