What is the danger or downside of using online/cloud web app scanner vs on premise ones?

I have used both. You will get different results with a cloud based scanner versus an on premise scanner.

Typically an on premise scanner would perform authenticated scans against your assets with no port restrictions, or hindrance from other security devices. This gives you a true snapshot of system vulnerabilities.

Cloud based scanners typically scan your externally facing assets, unauthenticated and must traverse the same infrastructure an attacker would. (IPS, WAF, firewall, etc) This gives you an idea of what an attacker would see.

They both paint a different picture of your network and are typically used in tandem, not in lieu of.

Now, with that being said, maybe you are allowing a cloud based scanner unadulterated access to your internal network which I personally would advise against.

Common information gathered by a vulnerability scanner:

Networks
IP addresses
MAC addresses
Operating systems
Installed applications
Hardware specifications
Open ports
Running services
Running processes
Shares
Users / Groups
Domain / Workgroup membership
Event logs
Registry keys
Any vulnerabilities found

There is a chance that some PII could be contained in scan results. For example, many scanners allow you to review the details of a finding.

  Checked for: (SSN Regex)
  Found: 112 25 0027


A problem with the cookie theft detection mechanism of Barry Jaspan's Improved Persistent Login Cookie scheme

You're right, practically the issue will most likely happens when using one of the multiple Firefox facilities allowing to restore and then refresh multiple tabs at the same time.

Based only on the secret itself, I see no way to tell whether it has been stolen or not. The only solution I see is to add an expiration date to the token (there should be one anyway in order to purge very old unused tokens), and when a user shows a token keep it in the base but set its expiration date to a short delay (set expiration to one or two minutes ahead for instance). Maybe there should be an additional "used" flag added to ensure that the expiration date is update only once (otherwise an attacker who can update the date endlessly could preserve the token validity over time).

Then the "token theft" alert can be raised when the server receive a valid series associated to a non-existent or expired token.


Is "Discoverability = low" an acceptable reason to reduce the risk of a vulnerability?

Low discoverability doesn't necessarily mean "security by obscurity".  It could just mean that the vulnerability lies deep in a portion of functionality that's rarely ever investigated.  It could also mean that discovery would require a corner case so narrow that even the initial discovery was unlikely to have ever happened.  Such examples would be Dirty COW and Spectre/Meltdown, both of which took almost a decade to be noticed.

On the other hand, low discoverability shouldn't necessarily mean low priority.  If a vulnerability with low discoverability is reported, other factors should be taken into consideration - such as impact and ease of exploit - in determining an appropriate response.  In fact, such considerations are exactly why risk rating scores like DREAD and CVSS exist.  However, as discussed in the comments, "discoverability" may only have meaning in the context of a private disclosure.  If a vulnerability is already public, the discoverability is essentially 100% and no longer a relevant consideration.


What is the state of smart card/computer interoperability

From your question it looks like you ask for PKI smart cards only, so I will skip other types of smart cards.

Some theory first. Computers talk to all smart cards using APDU commands. They are really low level interface and are mostly different for all cards. There are practical and political reasons for this. Practical reason is that every card can have specific functionality that is hard to standardize. Political reason is that smart card vendor do not want clients to be able to easily change cards with cheaper one from other manufacturer. But for smart card to be usable, there must be standard API. So every vendor provides middleware that exports standard APIs (PKCS#11, CryptoAPI, TokenD) and translates this high level function calls to series of APDU commands. As this is not so easy task, all proprietary middlewares have bugs. There was many attempts for unified smart card interface or specification, but all of them failed, because vendors continued to create and sell proprietary cards.

As for standards/projects:

ISO/IEC 24727 - I did not have personal experience with this standard, but it looks like another failed attempt for API standardization. As all of them it has very limited adoption. I think only Giesecke & Devrient created cards that implements it.
ISO 7816-4 - This standard defines low level commands for some card operations like select file and read binary, but it do not cover more usable commands like signing or key generation.
PKCS#11 - From Wikipedia - The PKCS #11 standard defines a platform-independent API to cryptographic tokens. There are many applications that can use PKCS#11 interface and is only smart card interface that Mozilla supports, so every PKI smart card has middleware that implements it. Usually not all functions are implemented and some are implemented in not standard way. It looks like middleware vendors test their implementation only with Firefox, and there is no guarantee that other PKCS#11 applications will work correctly.
PKCS#15 - Another attempt to fix proprietary middleware problem. I have never used it and AFAIK there is no major software that uses it.
open eCard - it do not mater as no card implement it.
OpenSC - this is open source middleware for many different cards. Some companies have written and actively support OpenSC drivers for their cards, some card drivers are written based on public specification and some are reverse engineered. Most of cards with public specification are national eID cards like IAS-ECC or US PIV card. Some small companies like Aventra are published their APDU commands too.

About smart card use in browsers - all major browsers can use certificates stored on smart card for SSL client authentication.

ActiveX, Java applets or browser extensions are used for legally binding signatures, as no browser has integrated support for them. There was some attempts to add needed functionality to WebCryptoAPI, but it looks like browser vendors are against it. You can read this discussion for details - http://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jun/. So I do not believe that signing document in browser without additional plugins or add-ons will be possible in near future.

Edit:

For TLS clientAuth to work with smart card, without additional installation, operating system or browser must include smart card middleware.

I think that Windows comes with some smart card middleware preinstalled, but many different cards have their middleware in windows update, and it is installed automatically when card is plugged in. This way client authentication will work with all modern browsers except Firefox. As Firefox do not use standard Windows crypto interface (CryptoAPI) it needs additional installation or at least manual configuration.

Older versions of OS X also included support for some cards, but it was removed after 10.6.


Is there another way than session hijacking to access user account through XSS?

If you have XSS, you can perform any action on the website the user can. This can include changing the email address, adding a new user, or granting access to some resource. Whether any of these actions compromise the account depends on the web application.

For example, consider an XSS payload that changes the email adres of the current user to kevin.lance@attacker.com. This may compromise the account if the web application has password reset functionality through email.


JWT with a single audience claim accessing a resource server with multiple configured audience values

It is usually the other way round. A JWT token can have several audiences, but the consumer of the token only identifies as a single audience. In this case, the consumer accepts and validates a token only if his own audience is in the audience claims of the token.

Your scenario only arises if we are talking about an aggregator, like an API gateway. If an API gateway bundles several APIs with different audience claims, it has two options:

It passes the token on without checking the audience, trusting that the consuming API will do the validation.
It verifies that the audience claim is present in the token for the API that it is sent to.

In this scenario the API Gateway is just an intermediary and not the final consumer. The real consumer should always only identify as a single audience.


How can an attacker using Kali/Parrot proxychains, no Tor, no logs kept by proxy providers, be tracked down?

Things that come immediately to mind -

Whilst the proxy operator might not keep logs the ISPs may. Especially if they have been asked to for a specific site / user by authorities.
Even if they can't see the entire route on the parts they do they could attempt packet matching. Especially if sending something of a particularly unique size.
If they control the remote server they could attempt browser fingerprinting or exploitation.
If they suspect you then they can attempt to prove your machine has visited that site - i.e. if you have a file that has come from it or it is contained in your browser cache.


What are the differences between the versions of TLS?

I like this blog entry by yaSSL describing the differences:  http://www.yassl.com/yaSSL/Blog/Entries/2010/10/7_Differences_between_SSL_and_TLS_Protocol_Versions.html

I copied the key snippets from the blog to here:

  "SSL 3.0
  [..] Some major improvements of SSL 3.0 over SSL 2.0 are:

  Separation of the transport of data from the message layer
  Use of a full 128 bits of keying material even when using the Export cipher
  Ability of the client and server to send chains of certificates, thus allowing organizations to use certificate hierarchy which is more than two certificates deep.
  Implementing a generalized key exchange protocol, allowing Diffie-Hellman and Fortezza key exchanges as well as non-RSA certificates.
  Allowing for record compression and decompression
  Ability to fall back to SSL 2.0 when a 2.0 client is encountered

  TLS 1.0
  [..] This was an upgrade from SSL 3.0 and the differences were not dramatic, but they are significant enough that SSL 3.0 and TLS 1.0 don't interoperate.  Some of the major differences between SSL 3.0 and TLS 1.0 are:

  Key derivation functions are different
  MACs are different - SSL 3.0 uses a modification of an early HMAC while
  TLS 1.0 uses HMAC.
  The Finished messages are different
  TLS has more alerts
  TLS requires DSS/DH support

  TLS 1.1
  [..] is an update to TLS 1.0.  The major changes are:

  The Implicit Initialization Vector (IV) is replaced with an explicit IV to protect against Cipher block chaining (CBC) attacks.
  Handling of padded errors is changed to use the bad_record_mac alert rather than the decryption_failed alert to protect against CBC attacks.
  IANA registries are defined for protocol parameters
  Premature closes no longer cause a session to be non-resumable.

  TLS 1.2
  [..] Based on TLS 1.1, TLS 1.2 contains improved flexibility. The major differences include:

  The MD5/SHA-1 combination in the pseudorandom function (PRF) was
  replaced with cipher-suite-specified
  PRFs.
  The MD5/SHA-1 combination in the digitally-signed element was replaced
  with a single hash.  Signed elements
  include a field explicitly specifying
  the hash algorithm used.
  There was substantial cleanup to the client's and server's ability to
  specify which hash and signature
  algorithms they will accept.
  Addition of support for authenticated encryption with
  additional data modes.
  TLS Extensions definition and AES Cipher Suites were merged in.
  Tighter checking of EncryptedPreMasterSecret version
  numbers.
  Many of the requirements were tightened
  Verify_data length depends on the cipher suite
  Description of Bleichenbacher/Dlima attack defenses cleaned up.


I have a scammer's phone number. Now what?

Inform law enforcement.

You can't "build a case" because as a layman you likely have no idea about proper police procedure. Most evidence you collect will likely be inadmissible in court. You might in fact also break laws while you collect evidence (for example, recording phonecalls without the consent of the other party can be illegal in some places).

Attempting to scare them is a really bad idea. Remember that you are dealing with a criminal. That criminal might be violent or have contact to violent criminals. So when you try to intimidate them, they might turn that around and start to intimidate you instead.


Chances are this is a combination of faulty headphones and the smartphones' intelligence. If there is a loose contact with the jack, the song "jumping" about or the "30 minutes of music" phenomena may happen. As for whether this could be because of a virus, the only way for that to even work would be if the headphones had some sort of data storage and a mechanism to digitize analog signals, like the Square Card Reader does. I would say this is highly unlikely for headphones without the data store or requisite firmware.


Secure cookies can be read with JavaScript, but HTTPOnly ones cannot. This means that if both flags are set, they cannot be read - the flags are terribly named.

Secure is to do with transmission - they should only be sent over HTTPS connections - but it is possible to set secure cookies from JS, and there isn't any specific expectation that they cannot be read by JS.

HTTPOnly is to do with client side access - they can't be viewed by JS, but can be sent over HTTP (and HTTPS - I have seen people claiming that they can only be sent over plain HTTP, which is not the case) connections for access by server-side scripts.

In many cases, both flags are set. In that case, the cookie will only be sent over HTTPS connections, and will be inaccessible by client side scripts.

What makes this more complicated is that cookies can have various parameters set, such as the domain and path attributes. If a cookie has the same name as a pre-existing cookie, but different values for any of these flags, a new cookie will be created. By the same token, if a cookie has a domain attribute set, attempting to delete it without including the domain attribute won't work - it deletes the non-existent cookie with the same name and no domain. Oh, and if you have the same domain and path for a secure cookie, and attempt to overwrite it without setting the secure flag, it doesn't create a new cookie, just removes the secure flag and sets the new value - this is a bit counterintuitive given the domain/path behaviour.

In order to delete a cookie from JS, therefore, you need to ensure that you are addressing the correct cookie by both name and flag values, and that it doesn't have HTTPOnly flag set, and that you're on a page with a HTTPS certificate. If any of these are not true, you won't be able to edit/delete it.


How can website server recognize incoming Tor or VPN connection?

One of the ways I know is based on checking IP against a known list.

http://www.gohacking.com/detect-web-proxy/


Encryption tool that supports multiple separate decryptions?

Assuming that all ciphertexts are of the same length (some tricky padding could help with different lengths), you can just XOR the plaintexts together:

C = M1 xor M2 xor M3
K1 = M2 xor M3
K2 = M1 xor M3
K3 = M1 xor M2
M1' = C xor K1
M2' = C xor K2
M3' = C xor K3
... and so forth for Mn and Kn

Important: even if the plaintext is unpredictable, this "encryption" scheme is very weak; do not use it for confidential data.


A ransomware locked my operative system on C. Are the other drives at risk?

As explained in the comments, your problem doesn't sound like ransomware at all.

But if it were ransomware, you can not know if the files on other drives are save. There are countless of different flavors of ransomware out there which all have different strategies to find files worth encrypting. Some might search all available drives for files, some might only concentrate on known locations like C:\Users\. But you generally have to assume that any storage volume where the system has write permissions is a potential target.

Seeing that the files are still in the directories doesn't necessarily mean that they aren't encrypted. It is possible that the ransomware scrambles files without renaming them. You say you can "do operations" on them, but not what kind of "operations" you are talking about. Unless one of these "operations" is to open them with a viewer application and look at their content, you can't be sure the file is unharmed.


OpenSSL Verify: Difference Between "unable to get issuer certificate" and "unable to get local issuer certificate"

Both error cides are very similar. You can view its usage on crypto/x509/x509_vfy.c line 432 onwards:

if (trust != X509_TRUST_TRUSTED && !bad_chain) {
    if ((chain_ss == NULL) || !ctx->check_issued(ctx, x, chain_ss)) {
        if (ctx->last_untrusted >= num)
            ctx->error = X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY;
        else
            ctx->error = X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT;
        ctx->current_cert = x;
    } else {
        …
    }
    …
 }

Thus, the only difference between both error codes is whether ctx->last_untrusted was >= num  when the untrusted certificate was found.

Here, num holds the number of untrusted certs and last_untrusted the index of the last untrusted cert.

The condition last_untrusted >= num (X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY) would be met if a trusted chaing to a certificate in the trust store was not found, whereas X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT seem to happen if a CA matched but the chain validation failed anyway, maybe due a malicious chain but perhaps simply due to a missing intermediate.


Is encryption application credentials using certificate encryption good practice?

On the surface this sounds like a fine idea - if you're trying to provide a buffer against:

Version control (git / svn hosting) compromise
Theft of a physical machine containing the codebase / credentials
Malware on one of your developers machines leaking the credentials in some way.
Any other way in which the files containing credentials are stolen by an attacker

Just remember that this wont protect your database if your web app itself is compromised, as it will still have the unencrypted credentials in memory at some point. If you're just trying to protect the credentials from being stolen from somewhere other than the live machine this should work just fine, though.

Also, in my opinion the environment that you're describing sounds quite non standard, which worries me a little. You're relying on whatever service the hosting provider is exposing to access the private keys in a big way.


The 0x414141 and 0x424242 that are placed in books for educational purposes because these are simply the strings "AAAAAAAA" and "BBBBBBB" in hexadecimal notation.  Assigning them to integers has nothing to do with buffer overflows.

A much better example can be had by using a full program, and a function call that will allow us to know when the overflow happens.  For example, let's alter the program to:

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

void
fun(void)
{
    char buffer[10];

    if (read(STDIN_FILENO, &buffer, 60) < 0) {
        perror("read");
    }
    write(STDOUT_FILENO, "So long and thanks for all the fish.\n", 37);
    return;
}

int
main(void)
{
    fun();
    write(STDOUT_FILENO, "WILL NOT PRINT.\n", 16);
    return 0;
}

Since you're using read and write we are assuming a UNIX system, so let's compile it and run a couple of times.  Assuming that the program source is in buf.c:

[~]$ gcc -g -o prog buf.c
[~]$ perl -e 'print "A"x10' | ./prog
So long and thanks for all the fish.
WILL NOT PRINT.
[~]$ perl -e 'print "A"x20' | ./prog
So long and thanks for all the fish.
WILL NOT PRINT.

Perl is handy because we can control exactly the number of bytes that we give the program.  Since STDIN is connected to a pipe, we can give a varying amount of bytes, up to the hardcoded 60 bytes in the program source.

The first run gives what we expected, 10 bytes are places in the 10bytes long buffer.  In the second run the 10 byte buffer should have overflow with 20 bytes of input.  But nothing appears to happen.  Well, the buffer did overflow, but did not overflow far enough to hinder process execution.  Let's do more:

[grochmal@haps tmp]$ perl -e 'print "A"x30' | ./prog
So long and thanks for all the fish.
Segmentation fault (core dumped)

Good, that's what we expect to see from an overflow.  Now that we have a good input we save it and look at how the program works in GDB:

[grochmal@haps tmp]$ perl -e 'print "A"x30' > input
[grochmal@haps tmp]$ gdb -q prog
Reading symbols from prog...done.
(gdb) list
5   fun(void)
6   {
7       char buffer[10];
8
9       if (read(STDIN_FILENO, &buffer, 30) < 0) {
10          perror("read");
11      }
12      write(STDOUT_FILENO, "So long and thanks for all the fish.\n", 37);
13      return;
14  }
(gdb) list
15
16  int
17  main(void)
18  {
19      fun();
20      write(STDOUT_FILENO, "WILL NOT PRINT.\n", 16);
21      return 0;
22  }
23
(gdb) break 9
Breakpoint 1 at 0x40058e: file buf.c, line 9.
(gdb) break 12
Breakpoint 2 at 0x4005b3: file buf.c, line 12.

Since we added -g to the compiler line we have all debugging symbols (e.g. program code) we may want.  This makes it very easy to setup the break points where the interesting part of the execution happens.  We run the program with the input we just saved and check how the buffer looks:

(gdb) run <input
Starting program: /home/grochmal/tmp/prog <input

Breakpoint 1, fun () at buf.c:9
9       if (read(STDIN_FILENO, &buffer, 30) < 0) {
(gdb) p &buffer
$1 = (char (*)[10]) 0x7fffffffe800
(gdb) x/15wx 0x7fffffffe800
0x7fffffffe800: 0x004005f0  0x00000000  0x00400490  0x00000000
0x7fffffffe810: 0xffffe820  0x00007fff  0x004005d3  0x00000000
0x7fffffffe820: 0x004005f0  0x00000000  0xf7a5c291  0x00007fff
0x7fffffffe830: 0xf7dd0798  0x00007fff  0xffffe908

The buffer is only 10 bytes long, and we printed 60 bytes.  But that gives away 0xffffe820 which is the location where the program needs to return to (in main) from the fun() call.  When the buffer is overflowed, the bytes overwrite that.  Let's see it by continuing with the read call.

(gdb) cont
Continuing.

Breakpoint 2, fun () at buf.c:12
12      write(STDOUT_FILENO, "So long and thanks for all the fish.\n", 37);
(gdb) x/15wx 0x7fffffffe800
0x7fffffffe800: 0x41414141  0x41414141  0x41414141  0x41414141
0x7fffffffe810: 0x41414141  0x41414141  0x41414141  0x00004141
0x7fffffffe820: 0x004005f0  0x00000000  0xf7a5c291  0x00007fff
0x7fffffffe830: 0xf7dd0798  0x00007fff  0xffffe908

And now the program will try to return over to 0x41414141, which will cause the segfault.

(gdb) cont
Continuing.
So long and thanks for all the fish.

Program received signal SIGSEGV, Segmentation fault.
0x0000414141414141 in ?? ()

And it did!  As a bonus we have the 0x41414141 string you're using as an int assignment in your program, and now can deduce from where it comes.

The security implication of this is that I know exactly which part of the input overwrites that return value on the stack.  And, thanks to that, I can drive the program to any instruction within its memory allocation.

(In practice that's much harder today because several measures are there to prevent such overflows from finding useful places to return to.  But the concept is the same.)


How to find a website behind a Firewall?

Penetration testing is done in multiple steps. From the information you have provided, you seem to have understood that the first step is information gathering.

However, you violated a core principle of ethical penetration testing: Never attack a system you don't own or have permission to attack!

Given that your teacher gave you two IP addresses to attack, it's safe to assume that the teacher either owns those systems or has permission to attack them. However, any address aside from those are out-of-scope of this assessment and have nothing to do with it.

Back to the scope: You claimed that you did an nmap scan of the websites, but you did not include the results of those scans. Here are some information you can provide:

Which ports are open?
Which services are behind those ports?
Which protocols are used by those services?

This is the essential information you want to gather. Depending on this information, you can proceed with your assignment. If you get stuck completely, contact your professor, explain to him the steps you have taken, why you have taken them, what you gathered from those steps and where you are stuck now.

Good luck on your assignment!


Looking for a race condition example that we can use internally in training

Back in 2011, Taylor Hornby wrote a TOCTTOU vulnerable PHP web application that is often found in banks and such that can cause Race Condition bugs, its a cool application.

The application is well explained in https://defuse.ca/race-conditions-in-web-applications.htm and I think can become a useful resource. (it explains a lot of issues and responses to each)


What are the security risks associated with storing passwords on the internet?

If something is encrypted well enough, it's unlikely anyone would be able to break the encryption no matter how much processing power they have so I don't see any problems.

And that's a huge if! You have no control over how your data is encrypted with a service like LastPass. You can only trust that they have done so properly and that they do not have malicious intent.

Contrast this with an application like KeePass that stores your data locally. You control the application, you know how it's encrypted. You can take proper steps to secure the key file (if you are using one).

(Shameless advertising, I wrote a blog post about this about a year ago: http://www.infosecstudent.com/2013/02/switching-password-mangers-why-lastpass-just-isnt-working-out-anymore/)


This can't be done simply on your computer. You will need an SSH server which you will use to establish an encrypted tunnel:

Because your traffic is encrypted, the provider will not be able to view and thus not block your traffic. Note that the provider might still try to block you on DNS level. To bypass such a protection you should use public DNS servers, preferably these DNS requests also should be sent through your SSH tunnel.


Should I store my users' certificates and private keys or not?

Well, from security perspective, clients should sign PDF files on their devices. The value of the signature after PDF is uploaded is very low, because there is no guarantee that PDF wasn't tampered during transmit. In your scenario, you can't be sure that sent and signed PDFs are the same, because PDF's integrity is not guaranteed during transmit.

In other words, the procedure should be as follows: client acquires/generates PDF document -> sign -> upload to server -> register. In this scenario you can be sure that you have exact PDF created by client (if signature is valid).

The fact that server holds client certificates and their private keys makes things worse. You can impersonate legitimate client, craft signatures legitimate client never did. If the attacker hacks your server -- keys from all users are automatically compromised. Private keys should be stored at client devices, otherwise they have no control over the key, thus no liability for signatures. The outcome -- signature's zero value and failed project.


Can SSL using Blowfish cipher be considered strong enough?

Blowfish is secure enough for TLS/SSL but AES is preferred. Especially 256, because 128 is still considered unbreakable and 256 is even more secure.


Emacs and EasyPG not performing public key encryption

You already seem to be doing public key encryption.

In public key encryption, the data is encrypted with the public key and it is decrypted with the private key. The password is only used to protect the private key. The public key is public for anyone to use, therefore it is normal that you are not requested a password when encrypting.

Credit to William Hay who suggested both this and another possible explanation in a comment to the original question.


Theoretically, all off this is possible, but in practice it is rare.

could the backup re-compromise the device?

It could but it probably wouldn't since any malware installed on the device generally wouldn't be backed up.
One possible risk would be that if the initial infection occurred through a malicious text/email, and you restore the texts/emails too, then viewing the same text/email might result in reinfection.

have there been any documented cases of persistent threats (outside of jailbreaks) that are remotely exploitable and can persist after a restore?

Yes, for example this proof of concept exploit, which relied on a bug in Broadcom chips, could potentially persist across restores since it overwrote the chip's firmware.


For a user who may run arbitrary commands with sudo, changing environments variables is not a direct security issue. If you like, you can run tmp=$(mktemp); export >$tmp; sudo bash -c ". $tmp; exec bash" — in other words, save the environment and restore it inside the root shell.

As you note, a trojan in a configuration file is not a concern, since the trojan could put a wrapper around sudo anyway (and grab your password while it's at it).

The topic has come up a few times in the Ubuntu mailing lists (1 2). Ubuntu doesn't reset HOME. David Mandelberg's arguments cover most of the case for resetting HOME.

Resetting HOME protects against exploitation of mistakes you might make. For example, one of your configuration file might contain a temporary file vulnerability that could be exploited to gain access to the root account. This example is, as before, not really a concern since the exploit could equally affect your account first and then hook into your call of sudo.

Resetting HOME also protects against mistakes you might make, and this is where the case for doing it has a point — but not a very convincing one.

There's an extreme view that says that you should stick to the default configuration as root. This way, anything done as root is easily distinguishable from what to do under your own customized account, so you won't forget that you're acting as root. Also doing things as root is painful so that you are incited to use the root account as little as possible. I don't buy this: doing things “the hard way” instead of the way you're comfortable with makes it more likely to make mistakes, not less. It's normally easy enough to know whether you're acting as root: if you're editing a file under /etc, you're root¹. If you're running a shell and the prompt ends with # instead of $ or % (following the usual convention), you're root — and you can use things like colors to make the distinction more visible. If you're running a package management program, you're root.
You might mistakenly leave a confidential file lying around in a publicly readable location in your home directory, believing it to be in /root. Or you might leave it in /tmp… This argument seems really far-fetched to me. Sure, it's a mistake you might make, but it's not any more likely than, say, mistakenly adding a firewall rule that leaves everything open, or making /bin/* world-writable.
One of your configuration files might cause confidential information to pop up in your home directory. This is plausible − it could be a history file or an autosave file — but these files would presumably be in a private location anyway, otherwise people could snoop on you.
Applications that automatically save their configuration might write to your home directory. This is not so much a security concern as a matter of convenience for you, and it's more than offset by the convenience of having your usual configuration when acting as root.
You might mistakenly edit files under ~, thinking that this is root's home directory when it is actually you home directory. Yes, but if $HOME is your home directory, then you'll also have your usual configuration, so you're less likely to think that you're running as the root user and more likely to think that you're running in a privileged mode. This argument is hoisted by its own petard.

Scott James Remnant put it this way:

  "sudo -s" is for lazy people who don't want to duplicate config files, "sudo -i" is for forgetful people.

But sudo -i (run a root shell) seems like a bad idea for forgetful people. And duplicating configuration files as root is only possible on a single-user machine, in which case running as root isn't such a big deal in the first place.

Conclusion: no, there aren't any serious security concern, and the case for resetting HOME is pretty weak. The purpose of always_set_home is to protect you against yourself, but it protects so little that it isn't worth it.

¹  Except that you shouldn't be running an editor as root: use sudoedit or Emacs (Tramp)'s sudo method to run the editor as your normal user.


Why isn't email filtered when using contact form

A contact form is setup by the company to explicitly get feedback. Contact forms are also often somehow protected against automatic submissions or at least any automatic submission need to be specifically adapted to the companies specific contact form. That's why such contact forms are not much used to deliver spam, at least not in mass. And that's why not much filtering for spam is done there. And, contact forms usually don't result in an email to the company with the address you've gave as sender. If the contact information are delivered by mail at all (often they don't), these emails are usually from a fixed sender and only include the information about the claimed sender and the message he left in the body of the mail.

With email instead there is no implicit rate limiting, no customization needed for specific recipients etc. This makes email a cheap way for spamming and because of this it is heavily used for spamming. And this is even more true for widely known email addresses like the contact email usually published by companies. To fight the amount of spam companies therefore employ heavy filtering   so that most of the spam gets automatically detected. This might also result in false positives, i.e. non-spam messages treated as spam. This is especially true if these look like spam or they use similar delivery infrastructures as spam, like not using the delivery infrastructure of a major mail provider but instead having setup their own delivery infrastructure.


Does creating new subkeys change an existing master key?

No.

Your quesiton is quite scarce in details, so I will assume that you are talking about PGP keys. And for change a definition such as if that would lead to a key with a different fingerprint.

If you add a new subkey to an existing PGP key:

the fingerprint of your key stays the same (it is the master key)
existing signatures on your key are not lost
the public key is augmented with the new subkey (and the signature binding it), so people that already have your public key will need to reimport/refresh it in order to get the new subkey.
similarly, in order to work with the new private subkey (eg. if you used it on several PCs), you will need the private part imported.


Check out The Penetration Testing Execution Standard (PTES).
And in particular: Intelligence gathering

This video may interest you as well:
Finding general information about an organization via the web (from the show notes he covers how to use Backtrack 5 to do a lot of reconnaissance type work)

Popular tools for quick (i.e. just interested in IPs) reconnaissance:

whois
nslookup, dig
dns recon tools  -> dnsenum, dnsmap, fierce + more ("DNS Analysis" folder in Backtrack)
nmap


Why, indeed?

Allow me to ignore that question for a moment, and answer your implied question: Should we?
That is, should we continue to have users create their own password, which is often weak, instead of just having the system generate a strong password for them?

Well, I am of the controversial opinion that there is a pretty strong trade-off here - having a secure password, and KNOWING how secure it is (as you point out), on the one hand, and on the other side is the user's feeling of security. "Usability", to some extent.

I think there are several aspects to this feeling of security: some users would want to ensure that they have a strong password themselves (e.g. via a password manager, or diceware); some users would want to select an easy password; and some users want to use the same password everywhere. And yes, many users just plain expect to be able to set their password, for whatever reason - so besides any specific cause, you will still need to fight the re-education battle, which is far from easy.

Also, don't forget that once you get a good strong password to the user, the (often non-technical) user still needs to figure out what to do with it - even passphrases become difficult to remember after the first dozen or so, or if you only use it every 6 months... The non-technical user would most likely save it in a word document on their desktop, or in their email. (And of course write the OS password on a sticky note attached to the screen).

Now, don't belittle these reasons, or these causes for using weak passwords - we the security industry have created this scenario for the simple folk over years. But it really comes down to: how secure do you need your site to be. How much risk can the user decide to take upon himself/herself, and how much of that is system risk that should be taken out of the user's hands.

So bottom line: Yes, I think most sites that have non-negligible security requirements should offer password/passphrase generation. Depending on the profile and architecture, you could offer 3 options when registering an account (or changing password, etc...) - just make sure to only display the password after warning the user against shoulder-surfing:

Generate passphrase - with a configured or flexible number of words (default)
Generate crazy-strong password with ridiculous entropy, e.g. for saving to password manager
Create your own.

In fact this is what I've been recommending for some time now (variants dependent on the specific requirements...).

Going back to your original question, why is the above not done?
I would guess a combination of legacy systems and bad habits; mis-education (the overwhelming majority of sites still have BAD password policies and recommendations); and perhaps just a lack of awareness of a better solution.

Yes, this is why passwords suck. :-)


What would one need to do in order to hijack a satellite?

Overview

First, I learned a lot of my information from a combination of my amateur radio experience and an awesome talk I sat in at DEFCON 18. The majority of satellite systems are simple repeaters. The signal that comes in on a transponder is cleaned, amplified, and retransmitted. If you know the location and input frequency, and you pump more effective radiated power than anybody else, you win.

Many satellites also require command modules. These are used to interpret instructions to boost back into orbit or at the end of life, de-orbit into a "graveyard" pattern (or right into the atmosphere itself). Because most satellite systems are custom, it is a real crapshoot what you see for commands and security. I suspect that most command sequences are unencrypted and rely on the fact that a MITM attack on something in space is fairly hard.

Frequencies vary wildly from MHz to several tens of GHz. Your equipment needs to put out the right frequency through a dish that is the right size. Legally speaking, you will at a minimum foul the FCC or your national equivalent, by violating regulations on licensed broadcasting. Also, "birds" and airtime are expensive, so the civil liability if found can be bankrupting.

As far as taking a satellite transponder over is concerned, security relies on rarity of attacks, detection, and triangulation of the signal source. Then people come knocking on your door.

Finding a bird

First, you've got to have a target. Some satellites are geostationary, so they're easy. Other satellites have orbits that sending them in offset patterns around the world. The satellite will come into view at different elevations in the sky tracing different paths, so you'll need to know where it will be and how it will move in order to communicate.

Communications satellites tend to either be geostationary or part of a cluster of many satellites such that one or more is always in view of at least one ground station and any other point on the planet.

There are websites all over the place for this, and they often end up with military / disavowed satellites listed as people will track them with a telescope and then wonder why that one isn't listed yet.

Talking to a bird: Bands

Satellites operate on different frequencies, and the antenna used has to be sized to the frequency of the satellite. Most satellites operate in the microwave spectrum. The ubiquitous (in the United States) DirecTV / Dish Network antennas are usually on the higher end (smaller wavelength) of the spectrum. Because your signal has a lot of travel in its future and your target is small, your goal is to direct as much power in one direction as possible. Anything sent off to the sides, earth, etc. is wasted energy, so you will want an appropriately-sized high-gain antenna. Antenna design can be learned from amateur radio books on the topic.

Before someone chimes in and says, "You don't NEED a directional antenna and tracking motor," that's true... but it will help a hell of a lot. Just because your spot messenger or GPS doesn't have one doesn't mean you shouldn't use one if you can. It will keep your signal where you want it and limit the possibility of interference from or with other things using the same frequency. It also means that it will be harder for somebody to hunt you down. Being nicked just because you let strangers hear you might have some costs associated.

Talking to a bird: Protocol

Now we're getting a bit trickier. Some satellites are very simple, particularly amateur radio satellites. They receive a signal and they transmit that signal back. There are different variations of protocol, polarisation, modulation (QAM is a good one to understand), etc. If your target does more cleanup than just setting a noise floor and spitting things back out, you'll need to know that information as well.

Higher-level protocols may be standard IP/TCP, plaintext, encrypted, or some totally imaginary 17 bit codeword system that was dreamed up by a guy like Mel.

Taking over

You need to deliver more power to the right place with the appropriate protocol. Because almost every satellite is a custom design, that's challenging. If you goal is beyond simple re-broadcast, you're up against a big black box every time. Computers are small, low-power, and probably have next to nothing on them.

The best bet for MITM

If you can't afford to launch your own satellite, figure out where the ground station is and fly over it. Small aircraft are relatively cheap to rent (under $100 / hour to operate), tethered balloons may get high enough to have an effective angle, and if you're quite sneaky you can put something on the transmitter feed line itself.

Many smaller organizations rent their satellite time. I learned when I was 11 that the guy running the local news station's satellite truck is bored as hell when they're in between shots and will definitely show you all the cool things about his rig. Whatever he's renting is probably one of the easier things to get at because that has to be documented and relatively easy to work with.


Port filtering for Ubuntu-Nginx minimal server environment

Since you're using UFW, it's a greatly simplified firewall interface compared to, say, using iptables directly.  Consequently, it does some "magic" for you:

Blocks all incoming traffic by default.
Allows all outbound traffic by default.
Allows some incoming traffic (packets that are related to or part of an established connection)

Then, the rules you create are incoming rules only, but the outbound part will be allowed because all outbound is allowed by default.  So your rules are to allowing incoming traffic.

  I wonder if I shouldn't go 1:1 by means of tcp:udp.

There's no reason to do that.  HTTP, SMTP, HTTPS never go over UDP, so why open holes in the firewall you don't need?  Of the ports you listed, DNS is the only one that might use UDP.  (Note that you only need to allow 53/udp) if you're hosting DNS, not to access an upstream DNS server.  (And if you're hosting DNS, you should allow 53/tcp as well.)

  I wonder if I should distinguish incoming/outgoing for tcp/up or both.

As noted above, UFW does incoming rules by default, so you are distinguishing, it's just not obvious because it's part of the "uncomplicated" nature of UFW.

I assume you're running something on port 9000 that lead you to open that port, but I don't know what it would be -- it's not needed for nginx, postfix, or SSH by default.


Add account to android device seems less secure than allowing access for a single app

Yes, you are correct. There are so many issues with using your normal password for the authentication on a 3rd party app.  IFF the app implements the o-auth correctly, the app should never see the password.. but there's no way for the user to know if they have implemented it correctly. Such a shame.

Also, yes the 2FA doesn't help as much if the authentication app is on the same phone, but sometimes you need to authenticate to 2FA apps with fingerprint and it also would add an extra layer of security if an attacker wanted to install the app on their phone and had your password.


Can a form I filled in online using 3G be traced to my phone?

In a word, Yes

All connections you make to the internet are through an ISP who most likly has a record of the device you connected from and what servers you connected too.


What would be a good way to guarantee security of theft and loss of sensitive data in a shared rack?

How have you assessed risk? I have seen datacentres ranging from

  just a locked server room

to

  stand alone unit with weight measuring man traps, dual keys, biometrics, time locks and remote video, as well as main and backup generators, fire suppression kit, water and air cooling

The first step is to calculate the value of your assets. How dependent is your business on the kit in that rack?

If losing it would destroy your business you need to think about mirroring it in an alternate location.

If the biggest risk to you is assessed to be from someone else in the datacentre then you do need to look at the physical security of the front and back of your servers, and check to see just what happens with those cameras. Does the data centre have a procedure to monitor the feed from the camera so they can check before letting individuals out?


Having trouble with learning Buffer Overflows

This is a document I wrote, and will be presenting at BSides Tokyo tomorrow. Will probably help, since it looks like the same type of simple overflow.
http://sysrisk.com/files/WhyBufferOverflowsMatter.pdf
Add 8 bytes and that should overwrite EIP. Peda tools should be added to GDB to make all that offset calculation easier.


Is there a security risk in using IP address to filter the results in Google Analytics?

You really should have a special flag on your program so that your internal staff's accounts never load the analytics script. Either that or always include a special flag in their reported analytics.

On the IP question: it depends. If you are only concerned about hiding the analytics from the work network you will usually get a static IP if you have business class internet. If not, your IP may not be changing that often anyways. You really don't want to be filtering by IP though.

There is no security risk beyond sensitive data being stolen from your analytics. If your IP changes and suddenly your hidden IP is now in use by one of your users there are still no security issues since you shouldn't be (and really can you even?) using GA for security logging.


Can any goverment permanently ban all the VPN servers around the world

Yes: they can create a whitelist of all allowed sites and order all their ISPs to block everything not on the list.

However, apart from North Korea, which seems to have only a single internet provider and only 28 domestic sites (! really?), no country is probably insane enough to do this. The whitelist would need constant updating and soon become unmanagably huge if the country didn't want to suffer the commercial impact of its internet censorship.

If they did it using a blacklist of known VPNs, they'd always miss some of them. Tor for example has a  number of bridges not on any list, and that number changes as people add bridges or decomission old ones, so using a blacklist wouldn't work.

China is a good example of the blacklist approach; they block many sites for their own people, but they can't get 100% success rate; tech-savvy people know how to circumvent the great chinese firewall. Even so, limiting access for the other 98% of the population (I made that number up, I have no clue what the actual percentage is) may be enough to keep unwanted information out of the public consciousness.


Why would modern OS allocate static addresses or why is ASLR still needed?

Most modern systems have a Memory Management Unit, or MMU. The MMU is responsible for translating physical addresses to virtual addresses. This is used to give each process its own private virtual memory. One process' address X is not the same as another process' address X. This improves performance, security, and reduces the risk of crashes, but it also has the benefit of being usable to implement ASLR. While data may be placed in non-random addresses in physical memory, the system is free to place the data anywhere it wants in a process' virtual memory.
When a process is first created, the only real memory it has access to is the stack, which is limited and is not meant to be used for general purposes. Whenever a non-trivial amount of memory is required, the process needs to use the heap. The only way to do this is to request memory from the kernel via a system call. This system call is given a few arguments specifying the amount of memory it wants, the type of memory, etc. The call returns the base address of some freshly allocated memory of the size specified. One of the things ASLR does is cause this base address to be unpredictable. When ASLR is disabled, allocated memory is placed in predictable locations.
ASLR does more than just randomize the base of allocated memory. When a binary is executed, the dynamic linker connects it to all the shared libraries it needs. Although any given library is kept in only one place in physical memory, the system is able to translate it to a virtual address for each process that uses it. This address translation is done for efficiency reasons, but ASLR makes additional use of it by ensuring the virtual address is random. An executable specially compiled as a Position-Independent Executable (PIE) can call library functions even though the library's base address is randomized.
This is not all ASLR does, and certain security-focused operating systems (OpenBSD, HardenedBSD, Linux with grsecurity/PaX patches, etc.) use a form of ASLR that does even more.


HTTP pages can be read / modified by an attacker through a man-in-the-middle attack.

An attacker could then easily replace any reference to the payment page (or any HTTPS page) to point to HTTP pages instead, so that he will still be able to read / modify the HTTP traffic.

Since a user is unlikely to start his session on the payment page, it will most likely start it on a unsecured HTTP page, and his whole session will be likely to be vulnerable.


When I enable ssl3-methods but disable ssl3 in OpenSSL

The disable-ssl3 (or no-ssl3) option will prevent the SSL 3.0 protocol version from ever being negotiated in the library. This is done by default since OpenSSL 1.1.0 (but of course defaults can be changed).

The enable-ssl3-method option controls what part of the code will be built. If your legacy application links to the SSLv3_method function, then this option must be set if you want to use your legacy application unchanged. I believe that even with this option, no SSLv3.0 will be negotiated if disabled before with disable-ssl3.

Also note that the disable-ssl3-method option implies disable-ssl3.

Applications should use TLS_method instead of the more specific SSLv3_method, TLSv1_method, TLSv1_1_method, etc.


What "MySQL (unauthorized; French)" means when perfoming nmap in port 3306?

When nmap tries to identify a service it tries to read the banner that the service presents to a connecting client.

In this case, the banner shows the string "unauthorized" and might be in French. You can confirm this with nc or telnet and performing a banner grab manually.

There's no specific security issue here. It's just banner contents.


Login: password hash vs successful decrypt

Yes, this is a workable approach, when you use authenticated encryption, as you've indicated.  The authentication tag on the encrypted data is analogous to a stored password hash, and GCM is specifically designed to prevent message forgery (i.e., a valid tag constructed without access to the private key).

In fact, GMAC is a variant of GCM mode that is designed not to encrypt data, but just to provide a signature with a shared key over some data.

It's important to note that this should not be done with non-authenticated ciphers, as even with padding being used to detect "correct" decryption, this would lead to a (slightly better than) 1/256 chance of any password working correctly by having correct padding despite being the incorrect key.

All this being said, I don't think this is a good idea, because it's much easier to have implementation errors in this than it is in a standard password storage scheme.  Attacking this scheme is equally easy/difficult to attacking a separate PBKDF2 hash for the user password, which is a well studied authentication mechanism.  If you're worried about CPU time with computing two PBKDF2 hashes, you can do the following:

Compute key = PBKDF2(Password, Salt, N) to derive the symmetric key.
Compute pwhash = PBKDF2(Password, Salt, N+1) to derive the stored password hash.  (This can be done with only a single extra round on the original hash above.)

Inverting PBKDF2(Password, Salt, N+1) into PBKDF2(Password, Salt, N) is equivalent to inverting HMAC on whatever hash function you use.

The scheme above is the scheme used by Lastpass for authentication vs decrypting your password vault.  (Only pwhash is sent to their server so they cannot recover the key for the password vault from that.)


Is unauthorised deletion an integrity or availability issue?

As pointed out in this (unanswered) question, Availability in CVSSv3 is about how well the web service performs, not whether its data is available:

  While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the impacted component, this metric refers to the loss of availability of the impacted component itself, such as a networked service (e.g., web, database, email).

To answer your question: only Integrity is relevant here.


Well given you once knew the password and assuming it should be a variation of a previously known password use of a password list and a tool such as https://github.com/glv2/bruteforce-luks it should be relatively easy to recover.

On that note, to prevent this scenario I the future you may want to review the process for backing up keys and the metadata used on the disk.


Can Cisco Umbrella be Used Along with Google Classroom?

If this is for on-site security you might prefer to look at:
https://pi-hole.net/
Cisco Umbrella controls DNS requests, it blocks bad ones and allows 'good' ones. Google Classroom is web-based and you will be able to set filters to allow access in the Cisco Umbrella dashboard. It is probably allowed by default. Note for students' mobile devices you will need to ensure they support the Umbrella client and/or use the school's network inc. DNS forwarder / Umbrella public IPs (previously OpenDNS) - this might be difficult to enforce, pi-hole could be a smarter move for on-site security. Meanwhile, ensure you are using Single-sign-on as much as possible: https://ed.link/community/how-to-implement-sso-for-google-classroom/


Can my machine be compromised if I use an outdated application and the input data is trusted?

Good question. It depends.

If you are actually able to segregate this device from the rest of the network, then yes, it may be ok. For instance, you allow this device to only talk to its trusted sources, when those conversations conform to very specific, well-formed conversation parameters. You are referring to Critical Security Control 2.10 "Physically or logically segregating high risk applications."

This shouldn't be a first option. But, when legacy applications need to be run then the risk should be reduced as much as possible by logical/physical segregation. For instance. Don't run this application on the same box as anything else. Defiantly not a DHCP server, SQL database, or web server for obvious reasons. This app gets its own device (virtual or physical) and only gets to talk to trusted sources (OSI layers 2, 3 and 7) that are explicitly allowed.

A great many business need to run apps like this, and while this should be avoided if at all possible, there is a right way to manage the risk imposed by such an application.

The key is to know exactly what a legitimate conversation/interaction with this application looks like and impose strict technical controls that prevent anything outside a "known good" conversation. Know what inputs, devices, applications, conversation cadence, conversation length, session duration, OS services, users... are required to preform the specific function of the vulnerable app, and limit the permissions and controls to prevent any wiggle room. Have IDS alert on anything outside these parameters. Have local and network firewalls tuned to these parameters. Put the device on it's own VLAN. Have a dedicated, lowest possible permission user account for this app if you can.

Will that mitigate all your risk? No. You are using a vulnerable app. Will that risk be acceptable? Maybe. That's up to you and your CISO.


Virus Infected: unable to open anti-virus web sites?

Nuke from orbit ... your system has been compromised and should not be trusted anymore. Wipe everything and start with a new, fresh system.

The virus / malware probably plays with your hosts-file and disables anti-virus or security websites (this one is doing a lazy job, since you seem to be able to surf here...).

But as you dont know, where the virus sits or even where exactly it entered your system, you cant remove a virus with 100% certainty.

After you've created a new, fresh system, make sure install all updates and use the latest virus-scanner.


To detect Steganography it really comes down to statistical analysis (not a subject I know very well).
But here are a few pages that may help you out.

Steganography Countermeasures and detection - Wikipedia page worth a read to cover the basics.
An Overview of Steganography for the Computer Forensics Examiner - Has quite a long list of tools and some other useful information.
Steganography Detection - Some more information about Stegonography.
Steganography Detection with Stegdetect - Stegdetect is an automated tool for detecting steganographic content in images. It is capable of detecting several different steganographic methods to embed hidden information in JPEG images. Tool hasn't been updated in quite a while but it was the best looking free tool I could find with a quick search.


Can risk mitigation controls bring down the impact?

The impact may change if the control put in place alters a potential attacker's abilities should the problem be exploited.

A good example of where the impact would change is when the mitigation involves segregating networks. Before the segregation, an exploit on OldCorp Unsupported Legacy Daemon X might lead to someone getting access to the internal network, then exfiltrating all your yummy internal documents out of SMB shares. After segregation, the box on which OldCorp ULDX sits is no longer in a position to route packets to your "regular" corp network, so the impact of it getting owned is reduced.


What is the security vunerability in this scenario?

You could start sort of a DoS attack by sending packets to out of range 12.1.0.0/16 addresses that would get stuck in a routing loop. Eventually you could get enough traffic in the loop that things would start to break.

So their inbound filter would look like this

12.1.1.0/24 allow
12.1.2/0/24 allow
12.1.0.0/16 drop


Is it possible that an unofficial download of Windows is corrupted?

Yes, it is very much possible that the OS comes with preinstalled malware. It is perhaps even likely. You could scan it with AV, but even if it comes up clean there is still a significant risk the AV missed something. Perhaps you could compare the checksums of the file with the checksum of the official Windows file, but since I don't think Microsoft publish Windows in ISO format you might be out of luck there too.

Basic moral of the story: If you care about security, don't use pirated software.


Can't remove suspicious bridge connection

Yes, it is a case of nuke it from orbit.

The fact that you can not remove this particular piece of visible malware does not matter. Even if you could, there might be loads of malware that you can not see left. No matter how many scans you run or how many hours your spend deleting registry keys you will never know for sure.

It was game over the second your parents fell for the scam. There is nothing to do other than a complete reinstall.

And while you are at it, you might want to consider installing a modern OS. While I understand that your family might not like the change, as Philipp points out in comments, using old software is fundamentally insecure.


How to secure API (private key) for mobile apps

Why do you want the clients to have their own private keys? I'm trying to understand how your scenario is supposed to work but am a bit confused about what you're trying to achieve.

In general here are a couple of comments that may help:

HTTPS is how you can establish a secure communication channel with clients. Once you do this you can transfer whatever you want securely over the wire client <-> server. This is the same thing your bank does.
Article you link to doesn't say anything about HTTPS, looks like they're intending to send that over just HTTP. You should use HTTPS not HTTP for anything you wouldn't want compromised (such as a logged in user). Why try to build your own encryption mechanism when you can use HTTPS? Using HTTP for any kind of authentication sounds like terrible advice to me.
I'm not sure that your clients really need their own public/private key pair. Typically it's a server that's securing your application communication and that has a certificate with private key. Clients will still have a user name and password right? That's the authentication for your client (not a certificate) and you can send the user/pass to the server once you have a secure HTTPS channel established. Server side your app will verify the client login credentials are valid and give the client a way to say "I'm already authenticated for 30 minutes" via a cookie or session mechanism. Obviously once a client is logged in, communication needs to continue to happen over HTTPS or your authentication token/session could get stolen.

Bottom line, if you're just trying to secure communication between clients and a server then use HTTPS and don't re-invent the wheel.


How do I remove or anonymize file names and path that are stored in compiled .NET exe output?

I'm a little confused as to how you have this set up.

What makes you think that file path is stored in either assemblies at all? Are you using that PFX to sign the assemblies? If so, there's a pointer in the assembly attributes.

There is no way to obscure the filename at that level because the compiler needs to know the full path. You could possibly run it through obfuscation software, but that would still likely result in the string being present.

Another option is to make sure you compile in RELEASE so the debug bits aren't added. This will remove the pdb files and remove most of the entries to code file paths.

The only other option really is to compile the thing from a non-sensitive path, e.g.: d:\builds\1, and to remove all sensitive information from the file paths. Simply put: don't store the password in the filename.


Keeping something private is difficult (i.e. expensive). For a confidential data element, usually called a "key" (sometimes a "password" when the said key can be stored in a human-based system), we must think about the whole key life cycle: how, when and where it is created, stored, copied, and erased. In some (many !) contexts, proper key management requires physical tamper-resistant storage systems (smartcards, HSM...); these do not grow on trees. There is no need for any reason for wanting not to keep something private; rather, we need explicit reasons for making something worth being private.

A salt is not a key (otherwise we would call it a key, not a salt). Its point is to be distinct for every instance, even if the same key is used. The salt prevents many types of cost sharing, where an attacker can attack N protected elements (e.g. hashed passwords) for less than N times the cost of attacking one. One form of cost sharing is precomputed tables, e.g. "rainbow tables". A salt defeats that by being unique for each instance.

By allowing the salt to be public, we make it much easier to have a unique salt per instance. Managing so many secret keys would be very hard, but for public elements, we just invoke a PRNG and store the value as it goes, without further ado.


CSRF Protection Is Needed for GET Requests

You are 100% correct on everything in your intro and examples 1 and 2.

Regarding example 3, CORS would kick in and block the script from receiving the result from example.com. The only way the given JavaScript would be able to read the response and send it off to evil.com is if one of the following conditions is met:

This script is running on a domain that example.com has explicitly whitelisted via CORS headers and given it permission to use credentials
The script is running directly on example.com (in which case you have fallen victim to an XSS attack, which is a serious problem).

Even in the event of #2 above you can prevent data from escaping to evil.com with a solid CSP (worth a Google if you are unfamiliar).

In short: This is the exact sort of attack that CORS is designed to protect against. Excepting the above items, CORS should block the response in all cases. So unless you have a specific example in which you believe CORS won't apply, I believe that your assertion that CORS might allow such requests through is incorrect.


Authentication is related to some notion of identity: a message (encrypted or not) is said to be authenticated if it can be guaranteed in some way that its originator is some specific entity. The definition of that entity, and the extent of the guarantee, depends on the context.

For instance, when two people (traditionally called Alice and Bob) share a common secret key K, they can encrypt data with K and also authenticate it relatively to K with a MAC: from the point of view of Bob, the MAC authenticates the message as originating from someone who knows K; from that, Bob infers that the message comes from Alice, because K is supposedly known only to Alice and Bob, and Bob remembers never having sent that specific message, so it must come from Alice.

However, third parties (Charlie), not knowing K, cannot verify the MAC, and thus cannot consider the message as authenticated. Even if Bob reveals K (e.g. Charlie is a Judge and Bob sues Alice with regards to the message contents which could be a contractual element), Bob cannot convince the Judge is really from Alice since Bob also knows K and could have produce the same message himself. In a nutshell, this is why banks are reluctant to authorize big stock exchange orders from customers through a Web-based interface: the bank can get some guarantee about the connected client's identity (that's authentication) but cannot turn that guarantee into a convincing proof for a third party.

In general, authentication is required whenever there is encryption. Encryption without authentication is robust only against passive-only attackers, who spy on the line but never modify any bit. This attack model turns out to be rarely realistic. Combining encryption and authentication properly is non-trivial. There are some encryption mode which do that.

The main drawback of authentication is that it tends to imply some slight overhead. If done properly, we are talking about a dozen extra bytes per message, and maybe a +20% CPU cost (which will not matter in most cases).


How do you exploit Directory Traversal to traverse from one drive/share to another?

In your example, I don't believe traversing to a different drive is possible solely through directory traversal (e.g. ..\..\..\windows\system32).

The most plausible way for an attacker to exploit this may be through a hard/symbolic link which points to somewhere on the C: drive.

If you were then using the path variable as an argument to a command (that is, shelling out) there may be other problems.


Possible to sign an imported key with a subkey using gpg?

“Signing” a user’s key (in fact, that’s signing his identity) requires the “Certify” capability. As far as I know, GnuPG does not allow you to create a subkey with the “Certify” capability (I don’t know whether the OpenPGP standard allows this). So, unfortunately, no, you cannot “sign” a user’s key with your subkey.


Need help to exploit php script vulnerability of a challenge

In Chrome, you can simply press the ESC button to close/abort the connection. Look at the PHP code and you'll see when exactly you should press the ESC button.


Is it possible to run an encrypted java environment?

If an attacker has root access to a machine, they can read all memory, perform debug operations, reverse engineer your java bytecode, etc.  There's no practical way to prevent an attacker from obtaining a secret key that's hidden in RAM somewhere.

Ultimately, somewhere you're going to store the class files in a running JVM.  If an attacker has physical access to the machine it's running on, they can get access to your class files.


Is dedicating ips for each domain better than sharing one ip?

There is no security benefit to either approach.

The only security benefit that you would get is by running the sites on different servers, to separate their duties. That way if one gets compromised the others are left intact. In such a setup the number of IPs is still irrelevant; you could have separate internet-facing IPs for each server or you could have some sort of reverse proxy in front with one internet-facing IP. Neither has any particular security benefit over the other (although the latter does open up more options for high availability).


How could an iPhone be transmitting abnormal loads of data without apparently running anything?

I'm the Head of Mobile at busuu. One of our web devs found this thread while investigating a problem with our site.

The entire set of content for our Japanese app runs to about 110MB in total, across five downloadable bundles. That download process is kicked off manually by the user and entirely in the foreground while the app is running. We also use analytics and ads, but if those were using that much data we'd know immediately.

Assuming Onavo is accurate, looks like something has hijacked our name for nefarious purposes - thanks for flagging it. If the OP didn't have busuu installed, whatever that something is is clearly not just parasitically stealing another valid process name on the device, so we might be baked into someone's malware. Yay.

Will be watching for this now. Any further info appreciated.


How can I make my Windows Server accessible from another Windows PC over the internet safely, without using VPN?

Given what you're saying, you unfortunately don't.

If the client communications are not properly secured (and based on ERP software I've seen, this is almost certainly the case), then you need security at another layer to keep thing secure (and even if they are secured, you should have another layer present before people can access it so that it's harder to attack).

You might be able to get things working with IPSec.  It's a serious pain in the arse to set up compared to stuff like OpenVPN, but it's also not as widely or reliably blocked.

Alternatively, if the client software truly only needs access to the shared folders (I doubt that this is the case, it's much more likely that it also needs some form of IPC with the main system), you may be able to get it working by forwarding port 445 (the port for TCP-based SMB connections) externally.  However to do this securely, you will need a newer version of Windows Server that properly supports SMB encryption (the first edition that did was Windows Server 2012).


Securing connection between redirect from A to B domain

What you have proposed is essentially a hash-based message authentication code, or HMAC.  As long as the shared secret remains secret, no one will be able to pass data to site B other than from site A.

There are some nuances to using a hash for message authentication, including the length extension attack, but depending upon the language you're using, there's probably an HMAC library function already available.

{time passes}  After I've thought about this for a bit, you should include a timestamp in the data.  (And so the timestamp will be passed to the HMAC function as well.)  This is to prevent replay attacks, where an attacker captures a valid message (which would be hard if the connections are TLS/SSL) and sends it again later.  Both servers have to have a good notion of what time it is, which you can do with NTP.  You will also want to establish a timeout period, after which a message expires.  To prevent a replay attack during the timeout period, you will need to cache the messages and reject duplicates.

You may want to just rely on TLS/SSL to prevent replay attacks depending on how much damage such an attack could do.  If it were I, I'd include the timestamp anyway and check for anomalously "old" messages if nothing else.


Unidentified public network sending traffic through my computer

It's interesting that you started to see this after your internet link went down and was restored. It's possible that they are incorrectly routing traffic down your internet link, and that's why you are seeing the increase in traffic. Try calling your ISP and asking them to verify that they aren't routing another subnet down your link.


Random connections to meterpreter reverse tcp listener

I ran into this a few years ago while showing a coworker how to use SET.

Basically you have your listener open and they'll see it in port scans. I was seeing shellcode too being sent over in the console as well, which was hilarious. Basically what you have is a ghetto honeypot.


Is there evidence of Shellshock being exploited before its public announcement?

In summary, no, there are no official reports of shellshock being used prior to its disclosure. Although, that certainly doesn't confirm the negative.

From Sidney Morning Herald

  Whether intelligence agencies or others knew of  its existence remains
  unclear and is unlikely to be confirmed. But Ty Miller, of Sydney firm
  Threat Intelligence, noted reports that the US government allegedly
  knew about the Heartbleed vulnerability for many years before it was
  discovered.

  "I would be amazed if governments haven't known about and exploited
  systems with Shell Shock for years," he said.

From Heartbleed

  Can I detect if someone has exploited this against me?

  Exploitation of this bug does not leave any trace of anything abnormal happening to the logs.

  Has this been abused in the wild?

  We don't know. Security community should deploy TLS/DTLS honeypots
  that entrap attackers and to alert about exploitation attempts.

So, as far as I know, there is no evidence of the state using heartbleed before it's disclosure, even though it is widely known that they knew of its existence.

However, that the state may or may not have known about the vulnerability is where the comparison ends.
Shellshock does leave a log-trace However, once owned, logs are trivial to wipe.

Wikipedia Shellshock

  Within an hour of the announcement of the Bash vulnerability, there
  were reports of machines being compromised by the bug. By 25 September
  2014, botnets based on computers compromised with exploits based on
  the bug were being used by attackers for distributed denial-of-service
  (DDoS) attacks and vulnerability scanning

Obviously exploits were created after the release of CVE-2014-6271 (Shellshock), but is impossible to tell how much administrator-awareness contributed to shellshock's blame for their compromise. If I was malicious, and had a tool like shellshock in my hands, that is not something I would be using frivolously. It's not the kind of vulnerability that a malicious actor wants noticed. I would certainly wipe the logs. But if knowledge is already out there, and scripts and vulnerability scanners are widely available, covering tracks becomes less important...or maybe someone hasn't given them a script to do that.

But, Stephane Chazelas should have the last word:
How did you find shellshock?

  In any case, I didn't find the bug by observing exploits, I have no
  reason to believe it's been exploited before being disclosed (though
  of course I can't rule it out). I did not find it by looking at bash's
  code either.


Is authentication using Facebook/Google considered good practice?

I am quite sure that there are some sites which require you to login with your facebook/google account on their site (so the URL shown is not facebook/google). I am sure there are some desktop application which do this as well.

This is very bad practice for websites, because OAuth / OpenID (which are protocols used to delegate authentication)  is designed to work around that exact use case. But there is no other way to do it in desktop applications, because desktop applications don't have redirect functionality.

A web page can forward you to the google or facebook authentication, where you can enter your credentials, and then when you authenticate successfully, Google / Facebook can redirect you back to where you came from.

This is impossible to do in a desktop application. One way around it is for the desktop application to open a web browser where you authenticate with your auth provider (Google / Facebook), and some magic happening behind the scenes can then authenticate you to the desktop application. But by and large this is an unsolved problem - you'll simply have to trust the desktop application to not steal your credentials. In fact opening a web browser doesn't really solve the problem either; now you're just trusting the browser to not steal your credentials (The browser is a desktop application, too!)

  I have read a couple of times that using other services to login is considered good practice. Is this true?

It's considered good practice because

It's user friendly - users don't have to remember a hundred different credentials
On the whole it offers better security - you don't have to trust a hundred different implementations and hope every site is bug-free and stores your password safely - you only have to trust Google, or Facebook, to take care of security. And they're much more capable to do so than your teen-aged nephew who wrote yet another login system for his new site.

Of course, it also means you're now putting all your eggs in one basket. If someone breaches your Google / Facebook account, you're in much bigger trouble if you use that account to authenticate on a hundred other sites. Also, there are privacy issues in letting your auth provider know which sites you visit and with what frequency you sign in.


Reverse tabnabbing: why not redirect the user in the new tab itself instead of the parent tab?

Tabnabbing is when a malicious website that looks like a normal website (say, a blog), after some time, redirects itself to a phishing website that looks like some trusted website. For example, a blog article might redirect itself to a fake Facebook login page. This attack is only likely to be effective when you have lots of tabs open in your browser and you hardly know why, so you can easily be confused.
Reverse tabnabbing is more dangerous, because it can work even if you only have one tab. In reverse tabnabbing, a vulnerable website contains a link to a malicious website. The malicious website will open in a new tab, and then redirect the parent tab (the vulnerable website) to a malicious lookalike. As a result, while you are concentrating on the content of the site in the child tab (for example a blog post), the other tab (the parent) will magically become a phishing site.
So reverse tabnabbing is much more effective because it actually targets a specific website in a specific tab that is likely to be trusted by the victim. In tabnabbing instead, the attacker needs some good luck in general. You asked: why doesn't a child tab just redirect itself instead of redirecting the parent? Because, whenever you can, it's always better to choose reverse tabnabbing over plain tabnabbing.


Suggest you research the latest Cisco APs.  I believe
these devices are able to isolate each wireless client
from each other and from the network.  All client
traffic is routed instead of switched.

You can then setup ACLs to keep WiFi attached
clients from reaching anything they should
not have access to.

Also most enterprise-grade switches support
anti-ARP-spoofing.  Ports can be configured
to allow no more than one MAC address.
Alternately MAC addresses can be limited
to DHCP assigned values (dynamic ARP).
Virtual server ports and ports for cross-
connects to other network devices would
not get the restrictive policy.

If you're feeling seriously paranoid, you might look
into configuring IPSEC between all the critical
systems on the LAN using X509 certificate
authentication.  This prevents all forms of
traffic sniffing and MITM attacks.  Be sure
to setup a CRL (certificate revocation
list) so that if any one system is compromised
or simply goes end-of-life and is discarded,
that it's certificate can be revoked and
never used to communicate on the LAN again.

One caveat:  If one of the critical systems
becomes compromised by a hacker, the hacker
will be on the "inside" and can still do
all the bad things that hackers do.


Preventing information disclosure from browser back button/history?

Use SSL
Make sure you implement session management correctly - for example the presence of correct session id checked on each page and destroyed with logout
Add cache control: no-cache, pragma: no-cache and expire: -1 headers everywhere
Make sure that forms and every sensitive variable are submitted only through POST requests and not GET (during code audits I've seen countless times pages accepting both methods without any reason)


How safe is Tor from MITM/snooping attacks?

Tor isn't safe from man-in-the-middle attacks.

The unsafe component are the Tor exit nodes. These make the actual, unencrypted request and therefore can read and modify your traffic. Tor provides anonymity by not letting them know where the request came from, but the actual traffic between the exit node and the Internet is not different from normal traffic, as you can see in this picture (via):

Regarding the second question: Yes, it is technically possible to choose exit nodes. I haven't done this before, but you should be able to read up on this topic by yourself. This should allow you to (if possible) run your own exit node, or choose one that you trust.


Techniques for accessing hidden content on a web page

Simply using the developer tools built into many browsers should be enough. Also it is probably easy to write some bookmarklet to show "hidden" parts of the page.

Hiding with CSS is not a security feature (not even security by obscurity) but should only be used to hide some parts of the page for now, i.e. show a summary and hide details until the user wants to see them. Parts simply hidden with CSS are usually indexed by search engines too.


Any Books/Sites/Writeups on IRC bot Security?

Like any software you need to harden it to only allow the user what you intend to allow him. In your specific question it really relies on what language you have programmed your bot in, what types of commands you allow it and how it sanitizes the input from the user.

I am not familiar with any books directly targeting security of an IRC bot, however there should be many clear guidelines on how to program safely in the programming language of your choice.

It is also very relevant to read the RF1459 on how your bot should behave when communicating over IRC.

When you initially set up your IRC bot make sure that the core functionality is in place and working properly. This is the simple stuff like:

replying to ping with pong
join channels

Then you need to dissect these operations and make sure that they are inherently secure. Does your bot reply to a random PING from anyone? What if I supply a buffer overflow attack against your bot with a "PING AAAA x50000"? Does it try to store it in buffer and copy it to the PONG reply? Perhaps the only source allowed to make a PING to you should be the server your connected too.

When you later make the bot to accept commands from anyone you probably want to whitelist (positive security model) the commands you allow (join, kick, ban, ping, ??) and then sanitize properly the input to the bot.

The sanitation that needs to be done is very dependent on what your bot actually does. For instance:

It posts results to a web page (XSS filters)
It stores data in a database (SQL filteres)
It runs commands on OS or similar interface (command filters)

When you design such a bot you have to try think of every possible way someone will try to exploit it. You have to be very careful and paranoid when creating it.


How to make a well-known malicious programs undetectable by anti-virus solutions?

Just to be clear: In the body of the question you ask "How can I modify or obfuscate the programs... to make them undetectable..." This is not the question I am  answering. I am providing an answer to the more general question posed in the title of the post. The reason for this is because it is difficult to answer the modify/obfuscate question without knowing exactly how the AV tools do their fingerprinting.

But anyways, one technique that I have found very helpful is to look at the configuration of the AV program. Often a unprivileged user can view the settings, even though they can not modify the configuration. In the settings there are often a number of "excluded" location. For example, a business may want to exclude certain "Program Files" subfolders from being scanned because it "trusts" the all executable in those folders.

If you find a "trusted" folder then just dump a 7zip/encrypted version of mimikatz (or whatever you want) into the trusted folder and unzip it in place there. Boom, you are in.


That intermediate CA's certificate should specify how revocation can be checked.  If the device performs revocation checks then it is going to access the CRL, use OCSP, or something similar.  That response should specify that the intermediate CA certificate was revoked.  Assuming the device processes this response appropriately it would no longer trust the intermediate CA certificate even if it was previously trusted.

In the real world a common problem is sometimes a device or software isn't designed to check for revocation at all.


What if somebody sends me genuine certificate that they do not own?

What will happen if someone sends me a genuine certificate for authentication which does not really belong to him?

A certificate is really just a public key that someone stamped with their approval.  With that in mind, the special properties of public/private key pairs (e.g., each can uniquely decode what the other encoded) are used to prove "belonging."

That certificate "belongs to" the person who owns the matching private key.  When used for authentication, a certificate is used to decode something that was encoded with the matching private key, thus proving that the connection is in the hands of the person the certificate "belongs to"; because nobody else has the private key required.

That's why certificates (public keys) can be public - if someone hands you a certificate they don't own, then they can't "back it up" with private key-generated proof, and the authentication will fail.


Weaknesses in client-side RSA decryption with passphrase-protected private key received from server

This system is a secure as the passphrases. If they are easy to guess, your security is weak. If, however, the passphrases are randomly generated with a cryptographically secure PRNG and long enough, you can achieve a good theoretical security. Your generated passphrases should have at least 2^128 possible combinations. This is notwithstanding any implementation flaw or other vulnerabilities in your software.


difference between need to know, least privilege and confidential

Depending on how you look at it, they are shades of the same thing. The confusion comes in when the same terms are used for other things, too.

The principle of "least privilege" states that one should only have access to what they need and nothing more. Extend this idea to "confidentiality of data" and you end up with "need to know".

To put it another way, to keep data confidential, you need to make sure that only those who need access to that data have access, and no one else. Again, it's a form of "need to know" and "least privilege".

I would not say that the 3 ideas are the same idea, but to achieve "confidentiality", you end up needing to employ "least privilege", and by extension, "need to know".

BTW, the quote you have is dealing with the application of "least privilege" as its own idea apart from "need to know", which is valid. Least privilege can be applied to access and capability as well as to the confidentiality of data.


FireFox's restore previous session restores logins authenticated by server's sessions

Set PHP's session.cookie_lifetime=0.  With a value of zero the session token will be destroyed when the browser closes. session.gc_maxlifetime will still destroy the session after a period of time.


Is it possible to prevent unauthorized copying or recording of data by photographing screens?

There is mainly two kind of people to consider in this question:

The person working on the computer. This person is your employee, they went through your HR screening and abides by your policies. They have been trusted to access and work with some data. Due to this, since they need to see, no technical measure can prevent them from taking photographs (using a phone, a pen camera, ...), taking notes or remembering what they saw.
The people around the computer. The computer could be a laptop in an airport or at a customer site, a desktop at a front desk etc., the other people may be unknown people, customers, or even other employees. Here the issue is not the same, and for this use-case you can buy privacy screen filters. These filters reduce the viewing angle of the screen, ensuring that only the person right in front of the screen can see its content (this person being obviously assumed to lock the computer when not in front of the screen).


With GPG the file is actually first encrypted using symmetric encryption, and the key used for that is then encrypted to every recipient using their public keys. Therefore, instead of transferring a single private key between the systems, it's possible to just encrypt the file with multiple recipients.
gpg --encrypt --recipient <comp1> --recipient <comp2> \
    --recipient <compN> passwords.txt

There are some caveats with this approach:

How any changes to your password database are synced between the systems. One would need to be able to act as a server, while the others might use e.g. rsync to syncronize the file. Password managers may provide service for this.
If any of the systems is compromised and the password file containing everything is decrypted, every password would be compromised. Software designed for password management have some solutions to minimize this risk e.g. by only decrypting one password at a time and trying to erase it from the memory as soon as possible.
As so many good solutions already exists, I wouldn't try and reinvent the wheel.


I think the common descriptions of "SSL VPNs" conflate three different things:

VPNs which use TLS or DTLS as their base protocol. (Examples: AnyConnect, SSTP, arguably even OpenVPN.) These still require a client just like any other protocol does – there's nothing magic about the usage of SSL/TLS here, and no great advantage (except perhaps passing through IDS systems unnoticed).
VPNs which, regardless of protocol being used, launch a JavaWS or ClickOnce applet directly from a website. Now that's still technically a client, just one that doesn't have to be explicitly installed. I don't get why people call this kind "SSL VPNs" (is it because the client runs from a HTTPS website?), but they do it anyway.
Finally, "VPNs" which aren't actually IP-layer VPNs but merely web-based gateways (proxies; portals) to internal webapps. These don't require a dedicated client because they don't actually intercept IP packets from the OS – they work like ordinary websites that you visit over HTTPS (therefore SSL).

So what makes things confusing is that the same Cisco AnyConnect product can fit any of these descriptions: its protocol is based on DTLS; it provides a Java-applet client; and it provides a webapp gateway in addition to traditional VPN.

But that doesn't mean the same mode fits all three descriptions at once: e.g. if you want to use the system-wide VPN mode, it still requires a client that runs on the local computer, creates a virtual interface, and so on.


How to crack encrypted disk (crypto-LUKS) in an efficient way?

It depends what kind of encryption/format you have. Currently, there are many formats which cryptsetup support. Basically, the most popular are LUKS1 and LUKS2. You can check what kind of format you have with following command:

cryptsetup luksDump <device>

John the Ripper only supports CPU cracking with LUKS1 and specific combination of encryption/hash mode. If it is LUKS1, there is GPU support in Hashcat and you can take advantage of GPU cracking. There are also smart optimisations implemented where it does not perform second PBKDF2 which LUKS performs, but it needs to have first sector of the encrypted data ("payload").

Simple benchmark of common LUKS1 format (luks1 type with aes, cbc-essiv:sha256, sha1) that both Hashcat and John the Ripper reveals that GPU (R9 290x) is faster than CPU (i7 2.2 Ghz):

$ hashcat64.bin -a 0 -m 14600 sample-luks example0.dict
[..]
Speed.#1.........:      882 H/s (2.29ms) @ Accel:2 Loops:64 Thr:64 Vec:1

$ john --test=30 --format=luks
Benchmarking: LUKS [PBKDF2-SHA1 256/256 AVX2 8x]... DONE
Raw:    54.8 c/s real, 56.2 c/s virtual

John the Ripper have 54.8 c/s while Hashcat have 882 c/s which is approximately 16 times faster. Of course, there is option to have multiple GPUs per machine, so this number can be quite bigger. Therefore, Hashcat is currently best option to crack LUKS1 format (because of encryption/hash combinations it supports and speed of cracking).

Currently, there is no GPU support for LUKS2 format cracking currently. It does not mean it is not possible, but it is new format and probably just not yet implemented. If you have short list of passwords, you can take advantage of cryptsetup itself:

cat wordlist.txt | xargs -t -P `nproc` -i echo {} | cryptsetup --verbose --test-passphrase open sdb3-to-crack sdb3_crypt

If you need something more robust, it means you're limited to already mentioned tools (in following order):

bruteforce-luks
modified cryptsetup
grond.sh

If you want to read more about the procedure to crack each format, I would advise reading article Cracking LUKS/dm-crypt passphrases I recently written. I have also written that modified cryptsetup. Advantage of modified cryptsetup is that it supports everything what usual cryptsetup support. There are also static binaries of mentioned LUKS2 cracking tools if you want to play with it.