How can disabling Diffie-Hellman cipher for packet inspection be secure?

TL,DR: using this product strictly as recommended most likely violates your compliance rules. This is not because of the Diffie-Hellman aspect, but I still wouldn't use it, partly because the DH aspect demonstrates an insecure architecture and partly because other aspects of the documentation demonstrates an awful lack of concern for security.

There are several different ways a TLS handshake can work. Considering the common case where the server is willing to talk to anyone, but the client wants to talk to a specific server, the handshake has two functional goals:

Allow the client to verify that it's talking to the intended server.
Allow the two parties to agree on a session key (the key exchange part).

The key exchange has a security goal, which is that a man-in-the-middle who is capable of observing and modifying the communication cannot impersonate the server or obtain the session key.

The server first sends its public key to the client, plus some additional data (certificates) which allow the client to verify that the public key is the correct one for this server, thanks to PKI. At this stage, the client knows the public key of the legitimate server (or else it detects that it's been sent a fake key and closes the connection), but it still can't trust what it receives since an attacker might have modified the data.

After this, there are three ways to go. (See also What key exchange mechanism should be used in TLS? for a more technical discussion.)

Encryption: the client generates a session key and encrypts that with the legitimate server's public key (confirmed by PKI). Only the legitimate server can detect it, a man-in-the-middle can't, because it doesn't have the server's private key. This happens with ciphersuites that have RSA in their name but not DHE. Apache's category RSA designates these ciphersuites.
Signature: the client and the server use a Diffie-Hellman to exchange data in such a way that both sides are able to calculate the same session key, but a man-in-the-middle cannot find the intended session key. A man-in-the-middle attacker may be able to modify the data to cause the two sides to calculate different session keys that the attacker knows, however. To avoid this, the server sends a signature of the data exchange during the handshake, in such a way that when the client verifies this signature, it knows that the server used the same data to generate its session key. The attacker cannot fake this signature because it doesn't know the server's private key. This happens with ciphersuites that have DHE in their name (including ECDHE). The E in DHE stands for “ephemeral”, because the Diffie-Hellman algorithm is used to generate a single-use session key. The signature part may be RSA or ECDSA. Apache's category EDH designates these ciphersuites.
Key exchange: there are ciphersuites that use static Diffie-Hellman private keys, but basically nobody uses them so I won't discuss them any further.

Now consider what happens if the attacker can observe the traffic but not modify it, and additionally knows the server's private key. With the first method, they can decrypt the packet containing the encrypted session key. With the second method, they can't do anything. An active attacker who knows the server's signing key can impersonate the server during the handshake, which leads to a valid TLS session between the server and the attacker and another valid TLS session between the attacker and the client. But an attacker who can't or won't modify traffic can't do this.

This property of the second method is called perfect forward secrecy (PFS), because if the attacker manages to record traffic and then later manages to obtain the server's key, they still won't be able to decrypt the recorded traffic. They'd need to know the secret parts of the Diffie-Hellman key exchange, but the participants erase them as soon as the handshake is over.

That middlebox apparently wants to monitor the traffic that the server is serving, but not actively forward it. It would need to know the server's private key, otherwise the whole thing is pointless. So the instructions are to disable all the ciphersuites that use ephemeral Diffie-Hellman, i.e. all the ciphersuites with PFS, and keep only the ones RSA-encryption ciphersuites.

This is a terrible way to monitor traffic, because it's degrading security. PFS is not needed to ensure the basic security of TLS, but it is a good thing since it limits the impact of a compromised private key. In particular, a private key becomes useless once the corresponding certificate has expired or has been revoked (assuming that clients correctly check for expiration and revocation). Without PFS, a leaked old backup allows decrypting old traffic. Additionally, this setup requires copying the server's private key to another box, which increases the risk that the private key will leak.

The proper place to monitor traffic would be on the server itself, between the application and the TLS endpoint. I guess this product is designed this way because it makes deployment easier, but it's a terrible design.

In addition to disabling PFS, those instructions enable export ciphers, low-security ciphers such as single DES, and SSLv2. I don't know how old this product is, but even in 2005, which is when Apache 2.2 and RHEL4 (mentioned on the product's web page) came out, all three were obsolete, to be enabled only if you really absolutely had to talk to ancient clients. Enabling any of those three today would violate any cryptographic compliance standard.


I found a password with hashcat, but it doesn't work

The password hashes for MS Office 97-2003 are vulnerable to collision attacks. That is, multiple passwords exist that should be able to open the document.

That also means that the password "iemuzqau" is not necessarily the original password that was set by the author. It is just one of the passwords that should be accepted, because it matches the internal scheme to check for the correct password.

For the $3 type hash that you got, the hashcat methods 9810 and 9820 can be used to create password candidates faster than raw brute-force (mode 9800).
According to the linked thread that should work by first executing the following command:

hashcat64.exe -m 9810 -w 3 s.hash -o hash.rc4 -a 3 ?b?b?b?b?b

The output will be something like:

 $oldoffice$3*1b085471a28011c5348c5f0b8f29d24e*99294d3ebc790cfc325cca851f56d433*9e3556d0775d0aa198060a815be7be4c58e1fe2a:5ffd0b24bd

Then you take the output of that command and execute:

hashcat64.exe -m 9820 -w 3 hash.rc4 -a 3 ?l?l?l?l?l?l?l?l?l?l --increment

This will then produce the following output:

$oldoffice$3*1b085471a28011c5348c5f0b8f29d24e*99294d3ebc790cfc325cca851f56d433*9e3556d0775d0aa198060a815be7be4c58e1fe2a:5ffd0b24bd:iemuzqau
$oldoffice$3*1b085471a28011c5348c5f0b8f29d24e*99294d3ebc790cfc325cca851f56d433*9e3556d0775d0aa198060a815be7be4c58e1fe2a:5ffd0b24bd:cvsfjkwoa
$oldoffice$3*1b085471a28011c5348c5f0b8f29d24e*99294d3ebc790cfc325cca851f56d433*9e3556d0775d0aa198060a815be7be4c58e1fe2a:5ffd0b24bd:yrmbatnya
$oldoffice$3*1b085471a28011c5348c5f0b8f29d24e*99294d3ebc790cfc325cca851f56d433*9e3556d0775d0aa198060a815be7be4c58e1fe2a:5ffd0b24bd:mzvmxmyke
...

The mode 9820 is a mode that "keeps cracking". That is, it will not stop outputting valid passwords after the first match. This behaviour was changed recently so you might have to specify --keep-guessing on your command line, depending on the version that you use.

That does not explain why your password is not accepted by PowerPoint as only valid candidates should be generated by hashcat. But maybe you can use the described workflow to generate additional valid passwords and try them.


You can have SSL/TLS without certificates. This is supported in the TLS standard: the "DH_anon" cipher suites involve no certificate whatsoever. But you have to remember that such an unauthenticated TLS is inherently weak against active attackers, since they cannot prevent client or server impersonation (or both at the same time, which is called a Man-in-the-Middle attack).

Most Web browsers deactivate DH_anon cipher suites because of the inherent vulnerability to MitM. You can have the same conceptual effect with a self-signed SSL certificate, that you can produce yourself without talking to any CA. Of course, the same Web browsers will then show the "scary warnings", for pretty much the same reason.

From the EFF point of view, whose arch-enemy is the NSA, generalized DH_anon cipher suites would make sense, since Evil Spy Agencies™ are know to prefer passive eavesdropping (since it leaves no incriminating traces). Passive eavesdropping is defeated by DH_anon. However, for most other people, the biggest threat is not governmental intrusiveness, but mundane con-artists that try to separate you from your money, and these do not hesitate to run full MitM attacks, e.g. with fake WiFi access points.

The Let's Encrypt initiative aims at making certificate issuance free (as in "no money") and automated, while still maintaining a bit of effort at "verifying" that whoever obtains the certificate has some degree of control over the designated domain. From the look of it (it deserves closer inspection), this system relies on the DNS and implies that any DNS attack (e.g. DNS spoofing) might be leveraged into rogue certificate issuance, in a fully automated way, so this initiative would be a weakening of the current certificate model. On the other hand, if it convinces more people to use SSL, it contributes to a "safer World", at least from NSA-is-the-Devil point of view, where what matters is defeating passive eavesdroppers.

Anyway, without support from Microsoft and Google (i.e. inclusion of the Let's Encrypt root CA in IE and Chrome), there is no way that the initiative really turns into generalized HTTPS. Not a lot of people would activate SSL on their Web site if it means that 70% of users will get insulted and scared away by their browsers. If Microsoft and Google don't jump in the wagon (and I don't believe they will), then the Let's Encrypt system will remain a political gesture, but won't be widespread (and ultimately Mozilla will drop it if someone bothers to mount an automated DNS-based attack).

There is another completely different certificate-less mode for SSL; it is called SRP. That one is safe, but different from normal Web browsing. SRP ensures mutual client/server authentication with regards to a shared secret, and it does so in a way that protects the shared secret against offline brute force -- so it can tolerate the use of a low entropy shared secret, i.e. a password. TLS-SRP makes a lot of sense for accessing password-protected network resources, and it involves no certificate at all; and yet, it is safe against MitM and eavesdropping.

Unfortunately, Web browsers don't currently support SRP.


Assuming your mystery USB audio device is based on the CMedia CM108 chipset (or even if it isn't, since there's not much variation in cheap USB audio devices), the HID device is for optional volume-control buttons; the manufacturer of your device decided not to hook the relevant chip pins up to actual buttons.  The other three interfaces are audio in, audio out, and device control.

Your webcam is probably USB.  It may not have any external wires or use a conventional plug, but USB is a convenient way to hook things up inside a computer.

I don't know why your mouse is describing itself as a keyboard, but it's not unusual for manufacturers to not get things exactly right when configuring USB.


Does asymmetric encryption guarantee data integrity?

You're on the right track, what you want is to use a private/public key pair to create and verify signatures.

But first

Your understanding of signature algorithms is incorrect. You've been given the "standard" encrypt the hash of the data explanation and misinterpreted it.

First, the common explanation is that you encrypt a hash of the data, not the data itself. If you encrypt a hash of the data, then someone modifying the data won't know how to alter the encrypted hash so that it matches. If you encrypt the data itself there is nothing to provide integrity. An attacker can modify it however they want (however they won't be able to know the decrypted value they're changing it from or to).

Second, this all too common explanation is incorrect (see here for a better but lengthy explanation). This explanation only works for RSA, and it's not even really accurate for RSA. One of the operations performed to create an RSA signature is also used in RSA decryption, so it'd be more accurate to say that an RSA signature is the decryption of the hash of the data, but then you're decrypting something which was never encrypted to begin with, which is even more confusing, and that still doesn't account for the different padding required for signatures and encryption.

Now the answer

A signature is definitely what you're looking for, but RSA signatures are large (256 bytes for a 2048 bit key), so I'd recommend that you look into ECDSA, as the signatures are much smaller for a similar security level. According to that Wikipedia article, to have a 128 bit security level (very standard) your signature will be 512 bits, or 64 bytes, which seems acceptable. Just please, please find a library to do it for you, it's far too easy to screw these things up.


What, if any, URL protocols should I whitelist or blacklist when spawning the user's browser?

Should I whitelist? Blacklist? Filter? If so what's the filter? Or should I just pass them to OS?

You should whitelist. I would go for a sensible minimum of http:, https:, mailto: and optionally ftp:. Including more protocols is unnecessary if you don't have a special use case in mind. That said some systems are more permissive than others. The Wordpress docs define this list of safe protocols in their wp_allowed_protocols() function:

  Array of allowed protocols. Defaults to an array containing 'http',
  'https', 'ftp', 'ftps', 'mailto', 'news', 'irc', 'gopher', 'nntp',
  'feed', 'telnet', 'mms', 'rtsp', 'svn', 'tel', 'fax', 'xmpp', and
  'webcal'.

None of these are inherently unsafe but you will not have any use case for a fax: or gopher: URL.

  At the same time I'm worried, are there are potentially bad URLs?

There are pseudo-protocols that have side effects. javascript: URLs should definitely not be possible. The file: scheme is dangerous as well because local files are often more privileged than web content. For Firefox you especially don't want to allow chrome: and resource: URIs.

This is a good example for a problem where only whitelisting works since it's not possible to keep track of all the custom URI schemes and their effects for every single browser.


A library that links against an executable will share all attributes of the process, including UID. For example, a vulnerable OpenSSL library linking against an executable whose process is running as www-data will, if exploited, give access to that user. If the same exact library is linked against an executable whose process is running as root, then exploitation will give access to that user.


What security risks does Firefox 19's built-in PDF reader (pdf.js) bring?

I actually think the Mozilla devs have been pretty smart with this.

Historically, most PDF exploits have come from the rendering engine rather than the parsing side. Adobe got wise early to the fact that malformed structure and content would screw them, and put a lot of effort into making sure that their parsing engine was rock solid. If you look at some of the recent 0-day stuff for Adobe Reader, you'll see that most of it relies on bugs in the rendering engine and some of the more exotic areas of content handling.

The new Firefox PDF engine simply takes the structure of the PDF and translates it into a DOM structure, which can be rendered by the browser's standard HTML renderer and interacted with via JavaScript. This removes a huge portion of the attack surface, and allows them to entirely focus on the security of the document translation engine. Any real exploitable bugs are likely to be reliant on a secondary bug that could be exploited through other means anyway.

If there are exploits, I see them coming from the following areas:

3rd party objects being loaded into the page, which can then exploit a separate Java / Flash / HTML5 / etc. bug. Probably preventable by using a restrictive content origin policy.
Bypassing content escaping so that arbitrary JavaScript can be executed in the context of the PDF. Again a lot of the significance of this is related to origin policies.
Buffer overflows in any native code responsible for PDF translation. Since most of the engine seems to be based in JavaScript, I'm unsure as to how likely this is.

All in all, I don't think it brings much of an increased security risk, and once it's been around for a few months I'd consider it an ideal drop-in replacement for Adobe PDF plugins, which have been a source of many headaches.


Can a stolen Android phone with USB debugging enabled have screen lock bypassed?

A sophisticated threat actor could potentially try to exploit the Android Debug Bridge's authorization protocol by switching your phone's storage media to another same model phone with already active ADB/ADBD authorizations (based on HWID like the network chip's MAC address) and maybe some additional tinkering.
From then on, provided he knew how to get there, even an encrypted device might be under threat of full decryption. Depending on multiple factors, like OS version, startup default mode (lockdown or not), ADBD startup policies...
The key factor here is the fact nothing is encrypted and USB Debugging is enabled.
Essentially anyone with slight IT knowledge should be able to access everything in there.
I'm fairly certain your phone will get wiped and sold.
Protips:

No root.
No debug.
Latest updates.
Full device encryption.
Disable PIN/Fingerprint/Face unlock (Either completely disabled or
lockdown-only disable)
Strong password.

*This should take care of the unfortunate event where your phone is not in your possession and not communicating through any channels (e.g. SIM removed, WiFi disabled).
Optional:

Tasker Automations in case you need to remotely wipe your communicating phone.

e.g. perform rm -f /storage/emulated/0/ when "X" message is received by text, effectively launching wipes from SMS/GSM instead of Data/WiFi
e.g. Launch camera silently to snap the person's face/geolocation

Keep an eye on Google's Find My Phone.

Last note: There is no current known exploit for ADB that would allow a bypass that I am aware of and my post takes in consideration many "if", including possible exploits that are yet to be discovered (e.g. when checkra1n came out, it affected a lot of older versions which in turned allowed other bypasses).


Does MAC spoofing prevent identification?

When using a phone while logged in to your accounts, you're visible.

  I remember reading an article that a determined owner can track you between APs and thus know your location and routine. Now I found out that one can randomize one's MAC address, so I was wondering if that can prevent my identification and consequent tracking.

Spoofing your MAC address is trivial. Encryption here is irrelevant. It doesn't matter if they can't tell what you're communicating, so as long as they can identify you and know where you are.

Even changing your IP address and using random proxies can be used to identify you easily. How? It's very simple. You may be logged in to multiple Google / Apple services. When you log into those services, they store every single IP address that was used to connect to that account. Here's more information on how you can be tracked online:

Identify Unique Computer through Tracking.

It doesn't change the fact that your social media may be still active and gathering information about you. Your MAC address is less relevant than the device you hold, and it's accompanying identification plus accounts.

  Assuming all communication between the client and the outside world is encrypted end-to-end.

The encryption doesn't matter if you're sending encrypted data to advertisers which they can decrypt, such as your device ID, known accounts, etc. They don't really need to know what you're doing -  just that you're there. That's all they need to really dig into your life.

Throwaway Smartphone without your normal accounts = stealthy

With this method, the only way you can be identified and tracked is in person, through cameras, or if you decide to log into your own account(s).

In some rare cases, your smartphone could be hacked and the camera could be used to spy on you, especially if you get the attention of the wrong people. However, this is very unlikely unless you're a criminal of sorts.

Using a Laptop correctly = stealthy

With this method, it's the same as a throwaway smartphone, but you need a different Operating System than Windows. Without logging in to your normal accounts, you'll greatly reduce your footprint.

You don't want your operating system keys / device IDs to point back to you. Windows Update/etc will send information to Microsoft about you, including the IP address you were connected to at the time. If you're using the same windows key / hardware every time, then it'll be very easy to put the pieces of the puzzle together.

So who exactly is using this information, and how are they doing it?

It doesn't matter if you're using encryption: they can still tell you were there. Not using encryption is just icing on the cake. When you connect to WiFi hotspots, you agree to the terms of service. They will collect information about your device, and sell that information to third parties.

Third parties will take that information and use data analysis to correlate your usage patterns, how you travel, where you connect, etc. Remember that advertisement companies want data on you, as they're able to sell it to those who are interested in it.

With a big enough data set, it's easy to show correlations between where you are, where you've been, and which accounts or IP addresses accessed that information. Using your unique device IDs, it's rather easy to tie multiple pieces of information together.

Even if the company claims that they don't sell personal information about you, it quickly becomes personal information through data aggregation, analysis, and correlation.

Remember, if something is free, you are the product.

Too Long, Didn't Read

It won't really help you. At best, randomizing or changing your MAC address will give you a small layer of "protection," so as long as you don't use any of your normal accounts, and don't leak your device IDs.

However, there are too many other things working against you at this time. In every single case, you should note that most public places have cameras, so you will be identified.

Do you really need that much opsec? Who's after you? >:|


How can I detect if someone is using an ssh tunnel as a proxy to connect to a VPN?

A VPN is just routing with protection. In your case, the "proxy" ensures that traffic goes first from the tablet to some server S, from which it then goes to "the Internet", e.g. to the entry point for the company's VPN. The "proxy" uses SSH but that's just between the tablet and server S; you cannot see it from the company.

What you will see, though, from the company, is the IP address of S. A relatively invasive strategy is to use OS fingerprinting on that machine (basically, scanning who is connecting) to try to guess whether S is indeed an Android system, or some other kind of OS. If you detect that "who connects" does not use Android directly, then you have shown that some intermediate system, a "proxy", is in use.

(Whether scanning machines who connect is legal is a complex subject which depends a lot on jurisdictions. Don't deploy that without taking some legal counsel.)

Now, of course, in all generality, there is no such thing as a "proxy / no proxy" dichotomy. A basic tablet user will connect over WiFi when he can, connecting to an access point which will use NAT, and that qualifies as a kind of "proxy". This already prevents the reverse-scanning explained above from really working (i.e. most of the time, the scan will see the access point, not the tablet itself).

The whole point of using a VPN like Cisco AnyConnect is to make the proxy question irrelevant: the VPN uses cryptographic protection exactly so that the paths used by data packets have no impact whatsoever on security. You should not have to ask yourself whether some SSH or NAT or whatever is in place. Thus, your question is kind of weird.


Certificate Hostname Mismatches - Why do they matter?

It is a problem in the general case.

If I make my own certificate for "polynomial-is-evil.com" and have legitimate ownership of that domain, I could easily get it signed by a CA such as Globalsign. Your browser trusts that CA. I have both the public certificate and private key.

Now let's say I perform a man-in-the-middle against one of your customers. I present them with my own certificate, which is actually for a completely different domain name. If they don't check the host name and reject when it doesn't match, then their SSL implementation is useless.

If DNS queries are spoofed, the only thing that changes is the target IP address. The actual domain name you're attempting to communicate with is still the same, so your SSL implementation should reject the certificate still.

It is always a good idea to implement DNSSEC and certificate pinning to mitigate these kinds of issues, in the general case.

On the other hand, if the only source of trust is your own private CA, then the issue becomes lessened. If they can MitM the traffic, they still can't present you with a valid certificate. The problem becomes serious again, though, if you accept any certificate signed by a 3rd party CA, because at that point they can contact that CA, get a signed cert for any arbitrary domain, and perform MitM with it.


how to prevent arp poisoning on my network?

Configure your switch to use Private VLANS (PVLANS).  PVLANS basically say that physical ports Gi1/1 - 47 can only talk to physical port Gi1/48 (where your gateway is).  Even things on the same subnet must go through the gateway to talk.  In a setup with N hosts there is generally no reason for the hosts to talk so a PVLAN config is optimal for security.

ARP (or anything for that matter) that originates from a host can simply not reach the other hosts.


nmap privilege escalation - is still a risk?

Yes.

As the warning says, it's just not made to be used like that.

Note that there are many potential ways for nmap to make it do something other than network operations. From a quick glance at man page, these could do just that:

--script, which uses Lua scripts
-oN <file>, output to file (so you can overwrite something with root)


How does a website owner decrypt ASP.NET's Viewstate, and cookies

As @blowdart mentioned, the default is to not encrypt the view state (again, I think that was changed in the latest versions).

If you just want to do an audit - set the view state to NOT encrypt (either the default, or manually shut it off), and then you don't need to decrypt it. Then when you're done, you can put view state encryption back on.

Though if you're ensuring there is no sensitive info anyway, you probably don't need the encryption, just set it to signing...

As for tools, try any of these (if its not encrypted):

http://sourceforge.net/projects/viewstate/
http://www.fiddler2.com/fiddler2/
http://ashishware.com/ViewStatePeeker.shtml (ala Firesheep, I assume you meant an easy plugin for Firefox)

I also found this question on Stack Overflow.


How to specifiy -CAPath using OpenSSL in windows to perform TLS handshake

#Use someone else's PEM bundle.
You can not use the Windows certificate store directly with OpenSSL. Instead OpenSSL expects its CAs in one of two ways:

Many files: In a special folder structure. One file per certificate with regular names like Verisign-CA.pem. (This is so that humans can understand the cert store.) And then a symlink to each such file. And the symlinks have weird names like 01c34cfa... and so on. They are named for a hash value of the certificate file. (This is so that OpenSSL can understand the cert store. More info: man page for openssl verify.) If you want to add a cert, you just drop the file in the directory and run a script that creates the symlink for you.

You can specify the path to that folder with the CApath command line argument (Case sensitive: Large CA, small path.):
    -CApath arg   - PEM format directory of CA's

Single file: All CA certificates lumped together in a PEM bundle.

You can specify the path to that file with the CAfile command line argument (Case sensitive: Large CA, small file.):
    -CAfile arg   - PEM format file of CA's

And one easy way to get such a PEM bundle is to download it from the testssl.sh site: https://github.com/drwetter/testssl.sh/blob/3.1dev/etc/Microsoft.pem
And this will then work with a Windows installation of OpenSSL:
    c:\> openssl s_client -connect google.com:443 -CAfile "c:\Microsoft.pem"

...

    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
    ---


What packets I'm reciving when running nmap over proxychains?

It appears that your scan worked correctly through the TOR network. Based on the switches you used, nmap only sent a SYN to port 80 and your target responded with a RST.  The timeout from proxychains just means a SYN/ACK wasn't received from the target.


Is it possibile to send NaN value to a param to bypass (PHP)?

While the code is incomplete, there are a few things that stand out...
That if statement logic is terrible if not ($amount is greater than 9) == true is a werid way to write if ($amount <= 9). As the comparison uses the double compare you could potentially have performed type juggling. However $amount is cast to int making this a non issue. Also by assigning it to a temporary value via an int cast further use will contain the same number, however if the check uses $amount and the authorization code uses $_GET['amount'] or $_REQUEST['amount'] you could bypass the check and perform SQL in a later step.
Sometimes you can break PHP logic by making the variable an array, ie: https://www.site.com/?amount[]=1 however, this doesn't work against a cast to int. In this case it looks like you can just straight up authorize by setting the value to something less than 10. ie:

https://www.site.com/?amount=0
https://www.site.com/?amount=BBBB

This kinda feels like homework, so maybe post the code and objective in full?


Can't get rid of “Your connection to website is encrypted with obsolete cryptography”

These ciphers are old:

DHE-DSS-AES128-GCM-SHA256:DHE-DSS-AES256-GCM-SHA384:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:DHE-DSS-AES256-SHA256:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:DHE-DSS-AES128-SHA:DHE-DSS-CAMELLIA256-SHA:CAMELLIA256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA

The fastest way to get rid of them is to append to ciphersuite this:

!EDH-DSS:!SRP

Also, do not forget to define your own DH parameters or all connections with DHE- ciphers are weak!

If you want to have very good security, you can use this cipher suite, as it is:

EECDH+ECDSA+AESGCM:EECDH+ECDSA+AES256:EECDH+ECDSA+AES:EECDH+AESGCM:EECDH+AES256:EECDH+AES:EDH+AESGCM:EDH+AES256:EDH+AES:EECDH+ECDSA+3DES:EECDH+3DES:EDH+3DES:RSA+AESGCM:RSA+AES256:RSA+AES:RSA+3DES:!NULL:!RC4:!EDH+DSS:!MD5


What's the advantage of sending an RST packet after getting a response in a SYN scan?

Leaving a connection in syn_rcvd state will raise flags as well as this is a common denial of service attack.

If you don't send a RST, the server will remain in a syn_rcv state for up to 60 seconds and retransmit the SYN ACK up to 5x.  This will waste resources on the network you're scanning and cause a bunch of (depending on the speed and success of your scan) of retransmitted SYN ACKs being sent back to you.

The 60 second and 5 retries are linux defaults - these values will vary.


You probably mean to include DDoS attacks (Distributed Denial of Service) rather than DoS attacks which could technically be a single packet (think Ping of Death).

None the less the criteria you are asking about is slightly different from provider to provider but a few things which are easily tracked by these devices are the following:

1.) Seeing systems suddenly generate large bursts of traffic, above 10,000 packet per second is a good rule of thumb.

2.) Seeing large numbers of packets leaving a customers network with falsified source IP addresses. In theory this would be blocked by egress rules but it does happen.

3.) Large amounts of intentionally malicious traffic. SYN Flood attacks, UDP Flood attacks, DNS Amplification attacks, Bulk SNMP requests sent from a "target" host.

4.) Large amounts of intentionally fragmented packets.

Cisco, a large commercial routing manufacturer, has a document which may also give you more insight into what can be detected.

http://www.cisco.com/web/about/security/intelligence/guide_ddos_defense.html

Wikipedia has a really useful entry on Denial of Service Attacks that also mentions a lot of the network traffic you will want to look for.

https://en.wikipedia.org/wiki/Denial-of-service_attack

Finally the following paper may also be useful

http://mallikarjunainfosys.com/IEEE-PAPERS-2013-14/Bandwidth%20Distributed%20Denial%20of%20Service/Bandwidth%20Distributed%20Denial%20of%20Service.pdf


Applocker Execution Prevention Bypass - Session parameter

You must first have a working Meterpreter or a handler session that has received an incoming shell (these are the interpreter environments that provide an implant, or backdoor payload, to the system(s) under target). Typically, a handler session can be upgraded to Meterpreter using the sessions -u <selected session> flag. The module you specified is a post-exploitation module -- meaning that you must have already exploited the target(s) in order to utilize it.

Recommend that you get a copy of Cyber Operations: Building, Defending, and Attacking Modern Computer Networks or another book that can help. The reason that I recommend this book is because it walks the reader through generating document-based malware with set filename before introducing the more-advanced methods of generating malware, such as via msfvenom, the backdoor factory, or shellter (although, instead of shellter, the book covers a more-outdated antivirus-bypass framework named Veil-Evasion). It's chapter 10 covers how to create, activate a communications channel, install/persist, and analyze malware -- all a great, complete introduction to the subject matter.

For some additional background on bypassing AppLocker, check out this resource as it contains a lot of information on more-generic bypasses that do not even require the metasploit-framework's post-exploitation module -- http://en.wooyun.io/2016/01/28/Bypass-Windows-AppLocker.html


I will shoot in the dark as there is no way to know exactly what can be the reason without further details...

Each time you forward those emails like : if you don't send this email to 20 accounts and the person who sent it to you in the next minute, you will be cursed..., spammers will receive a lot of information about you and your contacts (many people still don't use BCC). There is no magic in that.

Other possibility is that he set his account in a mail client (e.g. outlook) and his computer got some virus which accessed his contacts, which were sent to some server. Or... some of his friends got a virus / hacked and a spammer was able to get some of those forwarded emails in which all contacts are clearly displayed, for example: your@friend.com -> his_friend1@yahoo.com, his_friend2@gmail.com, etc.... Got the idea?

There are many strategies that can be used to gather such information. Personally, I don't think his account has been compromised or otherwise all emails would have been sent directly from his account (increasing spammer's success rate).


Why is it necessary to validate data in a servlet obtained by calling HttpSession.getAttribute()?

No, you're right, there isn't a way for an external attacker to inject content into a session attribute.

I don't see any reason to validate data from session storage. If you've got attacker code running in your servlet container you're already in a much worse situation than anything to do with input validation.


How does a Short Authentication String (SAS) mitigate MITM attacks?

This question is best answered by reading the Protocol overview published by Silent Circle which describes how it works in much more detail.

In short, the SAS value is derived on each phone by hashing values obtained during the key exchange phase of the protocol. Silent Circle recommends that the SAS value be compared out of band, which makes it very difficult for someone to MITM the conversation.

  Silent Circle recommends that users make use of an alternative method to establish the
  identity of the receiving party and verify that the user has the same SAS value. A phone
  call would be sufﬁcient for this purpose since conﬁdence building cues such as voice
  timbre and manner of speech are present. These cues make it difﬁcult for an adversary
  to convincingly impersonate the other party without being detected. If the two parties are
  physically co-located, they may even be able to compare their short authentication
  strings by placing their devices side-by-side.


Personal Best Practices for Information Security

There are probably as many potential answers as there are ways to break into a computer.
Some tips:

1) Disconnect wifi when you're not using it. Attack surface is the amount of ways that a cracker can get in. Limit attack surface when you can. Internet is the path into your computer and should always be treated as such.

2) It is very easy for an attacker to search the internet for devices with known vulnerabilities. Punk crackers don't know anything besides a specific exploit and how to use a weapon that someone else made. Keep everything up to date to protect against these novice crackers. The talented ones aren't after your personal device. Really, just try not to be the easiest target.

3) Don't visit websites that you don't trust. All sorts of problems can happen from malicious websites. If the website redirects you somewhere that you didn't intend to go, that's fishy, don't go back there.

4) Don't download things from sources that you don't trust

5) Never give personal information on a site that you don't trust completely, and which doesn't start with https. Https is a more-secure version of http. Most self-respecting sites use https.

From Wikipedia HTTPS:

  The main motivation for HTTPS is authentication of the visited website
  and protection of the privacy and integrity of the exchanged data.

6) Some software asks to open holes in your firewall or to open a port. If anything asks for firewall modification, think about it and research it thoroughly. This is a step in attack-surface restriction.

7) This will be the most controversial piece, but it's the kind of thing you can't leave out. Windows is not secure and never will be, it's also the biggest target because it's the most widely used. This goes with 'don't be the easiest target. Disclaimer, I have no affiliation with any Linux distribution, I am very biased against Windows however, and we're talking security here. Open source distributions like Linux, (Ubuntu is a good one for beginners and is very user-friendly) will always be more secure. The source code is available, and more eyes on code tends to root out bugs/vulnerabilities. Bugs are found all the time in Linux, but that's a good thing, because they can be fixed, allowing less Zero Day Vulnerabilities. Another option is Qubes, which is a brilliant design for software if you have time to look into it and experiment. (The main pitfall of Linux is the sheer code-size of it's kernel, big attack surface). If you do have Windows, use protection, it's a dirty world, antivirus I mean.

8) Delete all programs you obviously don't need. Limit attack surface. You're not using them anyway, and it would be a shame for a vulnerability in a program you don't need to be the gateway into your computer for malevolent crackers.

9) Pay heed to warnings that your computer gives you. If it asks for administrative privileges, that's an important decision. The brilliant people that write software at times try to protect ourselves from ourselves, and that's usually a good thing. Research what it's asking.

I'm sure I missed something, but it's a start. The more familiar you are with how people break into computers, the easier safety will be. So it would never hurt to just skim through NVD Vulnerabilities Database. But really. bad websites, bad downloads, old, non-updated software avoid them all like the plague.


Are there any known cases of antivirus software intentionally sending false alarms?

I have not seen false alarms, but I have seen an excessive amount of warnings/notifications, with Avast, for example. You could receive warnings about how vulnerable you 'might' be, and how you could fix it by buying another product or an upgrade (e.g. a VPN solution or web shield), every time you go on a bank website, pull up a login form, or click yes on any "18 or older" boxes. I'm sure there is a way to turn them off, but I believe that's one way they try to make the user feel like they need this software.

So it's not really false alarms, but a lot of warnings that might get non-tech-savy people to buy a license or another solution. Not a big fan of it, but it does help with awareness to some degree.


Overarching term for 'authentication' and 'authorization'?

According to CISSP study guide , access control include IAAA (Identification, Authentication, Authorization and Accountability).

So if you dont care about the rest then you can call Authentication and Authorization  as Access control.

Where:

Identification : User_Name

Authentication : User_Name + Password ( in one factor auth , simple case)

Authorization : Access to resources once authenticated

Accounting :  Tracking who did what


How to store login information on the user's device

Increasingly operating systems and runtime environments are offering APIs to digital wallets. And there are networks let components which can be be used by enterprise systems like hashicorp and cyberark. There's lots to choose from.

When you write your own password manager you take responsibility for your users' passwords. You also potentially exclude a lot of users.

If it were me I would write an interface to get the credentials from a separate process then bundle the solution with some simple examples.


Buffer overflows occur because of a programming bug: due to circumstances unforeseen by the developer, but triggered by the attacker, the code is writing data beyond the end of the buffer. What end ? Well, there are two: toward high addresses, and toward low addresses.

The traditional way to write a loop looks like this:

for (i = 0; i < n; i ++)

and not like this:

for (i = n - 1; i >= 0; i --)

which means that developers tend to apply algorithms in the low-to-high order. There is no mathematical reason for that, but developers are trained to think like that; and hardware's evolution has followed (pre-fetching strategies in RAM chips rely on this pattern, too). Usual suspects for string manipulation (strcat(), sprintf()...) also overflow on the high end for the same reason: they operate low-to-high.

This implies that most buffer overflows also occur on the high end of the buffer, not on the low end. On a stack which grows downwards, this allows these overflows to target the return address of the current function: the best a buffer overflow exploit can hope for is redirecting execution into attacker-chosen code, and for that the overflow shall overwrite a memory slot which contains a pointer to code, which the code will follow at some ulterior point. The "return address" slot on the stack is convenient for that. But that's not the only pointer to code.

In particular, when using C++, any object with virtual methods must contain some sort of reference to a structure containing pointer to these methods (the vtable). This gives a lot of extra targets which may be in range of a buffer overflow. C++ objects can be stack allocated.

Another point is that when a buffer is overflown, it could be located in another stack frame. For instance, this:

void foo(char *s)
{
    char buf[10];
    bar(buf, "x", s);
}

void bar(char *dst, char *s1, char *s2)
{
    sprintf(dst, "%s/%s", s1, s2);
}

In this example, if the attacker can put an oversized string as parameter to foo(), the buffer allocated on the stack frame for foo() will be overflowed in bar(). If the stack grows upwards, the return address for foo() will be undamaged, but the one for bar() will be overwritten.

To sum up:

An upward-growing stack means that the function return address of the function which allocated the buffer will usually be unharmed.
But other function return address slots for other functions may be in range (and actually be more in range than if the stack had grown downwards).
And though they are rarer, buffer overflows on the low end (sometimes called "underflows") also occur in practice.
And the return address slot is just one of the juicy targets for an attacker.

So we cannot really think of upwards-growing stacks as a protection against exploitation of buffer overflows. It changes the attack conditions, but not necessarily toward safer grounds. Experience shows that buffer overflows have been exploited with success on architectures with upwards-growing stacks.

(Note: the PA-RISC CPU, by itself, knows of no stack. The stack is part of the calling convention, which says that GR 30 is to be conventionally used as stack pointer, and that the stack grows upwards. This is how HP defined it but any operating system could decide otherwise. It is a generic trend for most RISC CPU: the hardware knows of no stack, so the position and direction of the stack are a matter of convention between OS and applications.)


Masking password when typing vs hiding input when typing

sudo does not hide input completely because of an alleged security benefit, but because it is much simpler to do in the context of a Unix terminal. A Unix command-line application normally receives user input by whole lines (nothing is sent to the application code until you press the "Enter" key); hiding the input is only a matter of telling the terminal not to display the typed characters, with a tcsetattr() call (e.g. see this answer). To display stars for each entered character, sudo would have to do some more complicated things, i.e. set the terminal in "raw" or "cbreak" mode (see this page for some details); sudo would then have to implement line-editing itself (handling of backspace key, or Ctrl-U to clear the complete input, for instance).

Although completely hiding the input hides the password length, this information is still available to bystanders, who can use their ears instead of their eyes: instead of counting the stars on the screen, they can count the key presses. Therefore, the alleged security benefit of complete hiding would be, at best, very slight.

Displaying the stars makes a much better user experience, in particular people with slightly flaky keyboards, where a keypress can be "lost", or else involuntarily duplicated.


As I cannot find a direct answer to this on this site, I'll provide a quick answer.
There are two primary methods for locating shells:

shell signatures
anomalous network connections

Signature-based
Meterpreter, for example, has a very distinct signature and AV tools can find these. PHP shells and others can likewise contain unique elements that might be detected by automated tools. Custom shells are difficult to find this way.
Network-based
But a shell, in your context, is something that has a network connection. You want to look for

known processes that have no business connecting to the network ("why is calc.exe connecting to a Linode server?")
unknown processes that have a network connection ("what is sefhwebfh and why is it connecting to a Linode server?")
known processes that have a legitimate need to connect to the network, but the connections are unusual ("why is httpd making outbound connections to a Linode server?"

(Note, "Linode" is a generic example.)
To look for these, you need to:

know your OS's tools to list processes and any network connections they make. It's then important to baseline what is "normal" (either through documentation or from personal experience) to compare against.
run packet captures (or similar, like IDS, packet inspection on the firewall, etc.) to listen to the wire to look for anomalies from the network baseline.

What do you do once you find a shell?
Once you discover the shell, you can no longer be confident about anything on the server. You have no idea if permissions have been escalated currently or in the past. While a full forensic investigation might be interesting and satisfying, you can never be sure that you have all the information to declare the machine safe or cleaned.
Your response should be to capture an image of the machine for an investigation into the impacts of the event, then nuke the machine from orbit.


How to see absolute difference between DV and OV certificates?

I know that browsers show no difference to the user between OV and DV certificates, but what is a sure way to find out if a certificate IS or ISNT an OV certificate?
Also, are there any technical differences in the cert?

Another answer partly answers your question: How does an end user differentiate between OV and DV certificates?

DV certificate contains no identifying information in the organization name field. Typically, this value just re-states the domain name or simply says "Persona Not Validated".

The organization name field is not part of a domain validated certificate.
Additionally, the policy identifier is different for DV and OV:

Domain Validated: 2.23.140.1.2.1
Organization Validated: 2.23.140.1.2.2

You can find this field in Extensions > Certificate Policies.


Is using a weak password for the non-hidden volume acceptable?

You really should read in depth all the documentation on Plausible deniability. Hidden volumes are a very powerful tool but still not a magic bullet. In particular:

you must be ready to lose the hidden partition if you have you reveal the outer one: many operations that you could be asked to do will destroy it.
you must be able to explain why you created a VeraCrypt volume, and why you put there the files it contains - only storing pictures of your dog is not really plausible...
you must either use it on a regular base or be able to explain why you do not use it - in short you must be able to explain how you use it in addition to why
if you choose a really weak password you must be able to explain why you did that - this one is to answer your question

Said differently, the choice of a password is only one of the multiple questions you should ask yourself before using a hidden volume.

That being said, being a teenager that just wants to protect files from his younger sister is plausible for example, whatever the password...


Sandbox for GNU/Linux secure enough to run malware in it without harm

Create different sandboxes

Linux currently supports six kernel namespace types:

IPC namespace
Network namespace
Mount namespace
PID namespace
user namespace
UTS namespace

  run different programs in them, including the ones requiring admin privileges (in this case SandboxIE gives them simulated admin).

fakeroot can give programs simulated root access, but you'll find that this is actually not as useful as you think. A fully sandboxed program is a useless program and a program that's not sandboxed enough fails to fulfill the security requirements.

  restrict their access to different APIs, for example restrict internet access to non-whitelisted processes, driver installation, access to different folders, launching processes except the ones from whitelist, low level media access, etc ...

In Linux, these access are restricted using regular system privileges mechanism. There are several systems:

traditional Unix filesystem permission: restricts who can access which files
capabilities: restricts the system calls that can be made by a root process
SELinux/AppArmor/TOMOYO: mandatory access control to enforce security policies

  each sandbox has its own folder where modified files are stored, copy-on-write is used to allow the sandboxed processes to write

Linux supports copy on write filesystem like btrfs, or an overlay filesystem like UnionFS or OverlayFS may be used.

  sandboxed processes within the same sandbox can interact with each other, but cannot with the rest of the processes (unless allowed).

This is kernel namespaces.

  sandboxed processes in fact have the lowest integrity level, but they don't sense this at most cases.

Linux don't have a concept like integrity level. However, Linux allows much more fine grained integrity configuration with the capabilities system and the mandatory access control frameworks.

  all the changes made in the main system are available in sandbox

You can do this with an overlayfs.

  you can transfer files from sandbox to the main OS easily

This depends on how the containers are configured.

These are the kernel features that exists for programs that can be used by program to take advantage of. The userland programs you would use to use these kernel features are usually either Linux Containers (LXC) or Docker.


SSL MITM Proxy Security - Can we rely on it?

It should be secure overall, but it's not as secure as a direct communication (endpoint <-> website) would be, because there is another section that could get compromised (endpoint <-> proxy <-> website) by the attackers and leak your data.

If they want to, they can snoop on everything you are doing and you have agreed to that by signing your work contract.

I am not a legal expert here, but where I am from if you would intercept and monitor bank transactions for any of the employees, the organization can get into serious legal trouble, that's why when SSL MITM proxy is setup we have to whitelist financial sector domains. You should read up on laws about that in your country.


"is it okay to create a new token when some of the credentials change"

Absolutely. Tokens should generally be short-lived anyway so creating a new one isn't a problem.
The answer here partly depends on how you are handling the man-in-the-middle replay attack problem with JWT. If you aren't doing anything, your tokens need to be very short-lived but you may not want your clients to have to constantly log back in. That's where the refresh mechanism comes in. It gives you an optional intermediate capability to refresh tokens without a full login.

If you are handling the MITM issue, you will have additional, server-side security in place to validate user tokens. In that case, you can afford to have longer lived tokens.

Either way, if the users change their security details in any way, it seems sensible to invalidate the token and require another login. But it is entirely up to you. You need to understand the value of the users and their sessions and the risks. When you understand that, you can sensibly decide how much risk you want to carry and how best to mitigate the risk you don't want to carry.


How to detect, if ESP32 or ESP2866 IoT devices hide malicious in their firmware?

Your question is similar to asking if there are any indicators that you can trust a person you've never seen before. The answer in this case is that there are no direct indicators and that you have to rely on the experiences of others with this person. This means in case of these controllers

Check the reputation of the company.
Check how much these products are used.
Check what experts (real experts, not claimed experts) say, i.e. if they recommend these products or not. Note that there might not only be a problem of explicit backdoors but also of bugs which might be used as a backdoor.
And, in times where the NSA and probably other government agencies are able to compromise everything you should also check the distributor and the parcel service, since you might get a version of the controller which was compromised on the way to you.

Of course, how much efforts you take in checking all these depends on your security needs. And this is again the same with the unknown person: if you just risk of loosing $10 when trusting this person you will not do much checks but if you risk of loosing $10.000.0000 you'll probably invest a larger sum in doing deeper background checks.


Public API security: authentication vs. rate limiting etc

Is any of the two positions above horribly wrong or would be laughed at if presented on the market of serious APIs?

Considering the data that is returned from the API is public information I do not really see why authentication is required, assuming your statement "The moot point is whether the API should require authentication for what is essentially public data." is correct. (The essentially part in that sentence makes me wonder though)

The statement:

  'We can't just keep the API open to whoever wants to call it'

is incomplete as it does not describe why. Why can't it be open to anyone? What are you afraid of?

Rate limiting should be implemented obviously and the statement that it should be addressed by the DDoS protection layer in insufficient because you should use the defense in depth approach.

This means that you embed protection in every possible layer (within reason).

  An open API can be abused or load attacked.

An example would be to configure the web server that is serving the API with rate limiting as well and not solely rely on the DDoS protection.

  Is there a right approach here, or are the both approaches sensible in terms of security and could be chosen based on other considerations like convenience/ease to implement?

Yes, they both are sensible and a cost / benefit approach can be applied here. How much are you willing to invest in order to protect public data?


This doesn't have anything to do with DNS poisoning, it's most likely just an error in the configuration of your embedded device (presumably an Internet-facing router).

However, it might just behave like DNS poisoning, heavily impacting the privacy of your activity on the Internet.

As a matter of fact, if you're using whatever VPN connection you may set up but with your stub resolver going into your provider's network (which you'll always still have there on your network interface), the provider would be able to record all your DNS requests at will and stream them to any third party they would like to.

Moreover, your provider would be able to provide you with false DNS responses. For HTTPS requests, that's usually not a real issue if you're aware of basic TLS/PKIX concepts (like, not blindly accepting self-signed certificates or certificates with issues), but it might be a problem for the rest of your actions, e.g. HTTP, e-mail, applications not following best practices, etc.

Actually, modern browsers have started to implement DoH which never leaks your in-browser DNS queries to whatever is configured as a recursive resolver on your network, and if you care about your privacy, you may want to choose one of those. But the rest of applications are still exposed to the risk outlined above.


Server error when entering a percent symbol in search?

% in the URL is the start of a URL encoded character - see Wikipedia: Percent Encoding for details. If you just enter a single % it is an invalid encoding which might explain the error page you see. If you enter %00 it means a character byte 0 (i.e. \000, \0, \x00 for typical notations of this "character"). This gets likely interpreted/sanitized as an empty search term since it does not contain any actual printable characters.


How secure are webservers from linux repos?

The web servers you've menationed as being shipped with Linux distributions (Apache and Nginx) are two of the three most commonly used web servers (stats from the May 2016 Netcraft report).

As such it's safe to say that a very large number of companies consider them safe for widespread use on the Internet (which is by definition a fairly hostile environment).

Having those web servers installed from linux distribution repositories likely doesn't make a large amount of difference to their practical security as most/all linux distributions will provide security patches where new issues are found.  Some linux distributions will "backport" security fixes so that these are applied even where the base versio of the software is not upgraded.  This can provide benefits from a stability perspective.

As to whether they are "secure" enough for your needs, that's impossible to tell without knowing about your organisation in specific.


Protecting folder contents from processes

For isolating access to a mountpoint so only particular programs can access it, you can use MAC or DAC. When using DAC, you must provide a way to automatically run your target program as a group.
Mandatory Access Controls
A Mandatory Access Control system, or MAC, is a framework for limiting what actions a given subject (e.g. a process or thread group) can use to operate on an object (e.g. a file, directory, or network interface). The access controls are usually enforced by the kernel, and the process being confined has no say over what objects it is allowed to access and how. For your use-case, you would need to use SELinux rather than AppArmor. AppArmor requires an explicit profile for every single program it is confining. A new program will not be confined at all. There are ways around this involving setting a profile for the init process, causing it to be inherited by all other processes on the system, but it is a hacky and untested technique. SELinux on the other hand is specifically designed for system-wide isolation policies, though per-process targeted policies are also supported.
You can specify a particular SELinux context for a given mountpoint by specifying the context= option when mounting, either using fstab(5) or by directly invoking mount(8). The context is used to determine what SELinux permissions are required to access it, without needing to label every file.
Discretionary Access Controls
Discretionary Access Controls, or DAC, are the standard UNIX permissions that govern all filesystem access on a Linux system. It is called discretionary because a user who owns a given file or directory can, at his discretion, change its permissions. In order to use DAC to protect a mountpoint so only specific programs can read and write to it, you would want the mountpoint to be mode 0770, owned by the root user and a new group which you create. Any process running under this group will be able to enter, read, write, and execute anything on the mountpoint. There are a few ways to accomplish this:

Mark your program setgid, which will cause it to automatically run as the group the executable possesses. Any transition to a setgid context will cause the system to discard all potentially dangerous environmental variables, and will protect the process from invasive debuggers.
Configure your sudoers to allow you to run your approved programs as a given group, either with or without supplying a password. This works similarly to the former option, but uses sudo.

A much safer but more invasive technique would be to create an entire different user, with its own desktop environment (if you use any), and its own home directory. When you need to access anything sensitive, ensure the sensitive files and directories are readable only by root and your new, safe user. This may break your workflow as you will have to log into a different user, but it will not be subject to the (non-negligible) caveats with application isolation which are explained below.
Caveats
It is extremely important that you fully understand the implications of given a particular process access to sensitive information. Unless the program is designed specifically to remain secure under these circumstances, there could be unforeseen ways to hijack it. A graphical file manager, for example, cannot be isolated under Linux, as it will have access to your X11 cookie, and thus any other graphical program with X11 access running under the same user (even if the group is different) will be able to take screenshots, inject mouse movements and keystrokes, and more. This of course would defeat the isolation attempts. All other issues will be specific to the individual programs. Attempting process isolation without conforming to a particular formal policy such as Biba or Bell-LaPadula can be risky.


Is a precompiled Java program affected by Java vulnerabilities?

It depends if these are security issues of the JVM or the Java libraries. Since the JVM is not used these problems don't affect compiled applications. But issues in the library might affect your application. If these issues are relevant for your program depends on the kind of issues and what your program does. For example problems affecting the validation of TLS certificates will probably affect your program if it does https connections, even if it does not execute external code like a browser plugin does.

In effect you need to find out what kind of issues are fixed in the updates, which component they affect and if this component is used by your application. Then you know if the application is affected or not.


An XSS attack is working on Firefox but not on Chrome..Suggest changes to make it work on Chrome

Usually, demonstrating an attack under a single browser is sufficient for a penetration testing engagement, unless it's an environment where only Chrome is being used or similar.

That being said, I'm guessing this is a reflected XSS, so it's probably being caught by Chrome's XSS auditor: http://blog.chromium.org/2010/01/security-in-depth-new-security-features.html


What is the best material for building an web application firewall?

It depends on what are you looking for and your scope.
As a newbie, you can try already existing ones as:

OWASP ModSecurity Core Rule Set (CRS)
Baracuda
AQTRONIX WebKnight
IronBee

or whatever you like.
Here you can find some suggestions:
http://linuxbsdos.com/2011/12/06/3-application-level-firewalls-for-linux-distributions/


No, this doesn't seem secure.

Collisions

Mersenne Twister is a deterministic RNG, so it's not suitable for most cryptographic tasks (although it's usage makes sense, because if it weren't deterministic, your approach would of course not work).

In this case, collisions would not happen at the stage you assume and base your calculations on. Instead, they would happen when you limit the ascii value to 10 digits, so the probability of collisions is way higher than you assume.

Comments on Approach

What you have is basically a home-made hashing function. You take some input, you apply some function(s) to it, and receive a fixed-length (3 words) output. The input space is larger than the output space, and it is impossible to reverse the procedure (get the password from the three stored words).

Don't roll your own and Don't be a Dave apply. To properly hash passwords, see How to securely hash passwords?.

You are still implementing a login and registration system (a user needs to enter username and password, you store it in some form, and can then later compare the stored value to newly entered values to authenticate the user).

If you would stop at this step: "The password is sent to the server where a hash is created", you would have an ordinary process. But instead, you add additional steps, which do not increase, but decrease, security.


What is the heapspray technique and how to use it as reliably as possible?

Peter(corelanc0d3r) - Corelan team has one of the best Buffer Overflow tutorials on the internet


Are there a standard method(s) for me to give someone else read-only access to my data?

Sure.  There are several standard approaches to this problem:

Export. Alice exports her data to a file or document, and then sends Dr. Bob a copy of the data.  Now Bob can modify his local copy, but that won't affect Alice's resources.

Of course, the disadvantage of this approach is that it only provides Dr. Bob with a snapshot of Alice's data.  If Alice's data is changing over time, Alice will have to make a new copy every time Dr. Bob wants to see the latest data.  However, one advantage is that this is very easy for Alice.  It doesn't require any support from the underlying system or any special expertise.
Proxying. Alice wants to give Dr. Bob read-only access to some of her resources, so she sets up a proxy.  The code of the proxy has full access to Alice's resources, but Alice writes the proxy code so it will only perform read operators.  The proxy exports an API that allows read-only access, and Alice gives Dr. Bob access to the proxy.

Of course, the problem with this is that Alice has to be a programmer or equivalent to follow this approach.  The advantage is that it requires no support from the underlying system.
Support for read-only sharing. You can write the system so that Alice can grant others access to her data.  You can further write the system to provide an option to share the data as read-only.  For instance, Google Docs lets you share a document with others, and if you choose, you can choose to share it as read-only (so they can read the document but not modify it).

Of course, this approach requires support from the underlying system.  The system has to be built to support this use case.  However, this approach is likely to be easy for users to understand.
Attenuated capabilities. Many capability systems provide built-in support for this use case.  Alice has a capability that allows her to access her data.  The system provides a way so that Alice can generate an attenuated version of her capability: a read-only capability that only refers to the same resource, but only grants read access, not write access.  Now Alice can share this capability with others.

For instance, a web application might give Alice a way to generate a link (URL) to her data, so that anyone she shares the link with gets access to her data, too.  (Google Docs also supports this mode of operation.)  If the web application is written to support it, the web application can also let Alice generate a URL that grants read-only access but not write access to anyone Alice shares the link with.

The disadvantage is that this, too, requires support from the underlying system.  The system has to be built with read-only sharing in mind.


Autopsy uncovering slack space of a file

I'm not sure but do you know that file slack is the difference between the physical file size and the logical file size ?

Assuming you are investigating a standard Windows PC with a standard hard drive, and giving the sector size you gave, the cluster size should be of 8 sectors which is 4Kb.

Your file is 677 bytes which means its given 4096 bytes of space (which is 1 cluster or the smallest unit that can be handled by your file system)  this means that the difference between the end of your logical file (677bytes) and the end of the physical size given (4096 bytes) is your slack.

Check this link out it may help :  Analysis of hidden data in the NTFS file system


Why are randomly generated passwords often hexadecimal?

(Do you have evidence that random passwords are usually hex?)

Here are some possible reasons why you frequently find hexadecimal passwords:

The passwords you see might be already hashed. Since hash functions return binary strings, you will often see them stored in a hexadecimal form.
Hashing a random binary sequence (e.g. from /dev/urandom) is a cheap but reasonably safe way to create a random password. You'll occasionally see something like this in the wild:

$ head -c 100 /dev/urandom | sha256sum | head -c 25
c9ea6b67af36753a68ef42429

All characters are easy to distinguish. That is, you won't run into problems with confusing 1 and I, O and 0, etc. if you only permit hexadecimals in the first place.
Randomly generated sequences are usually binary, so displaying them in a hexadecimal form seems logical and efficient.

That said, choosing a random password from a larger range than [0-9a-f] is obviously safer if you don't adjust the length. I usually go with your suggestion of [0-9a-zA-Z] which gives me a broad range and avoids special characters that might cause issues with storing and transmitting.

Also, here is what I put in my shell config to quickly generate passwords on Linux:

function spw() {
    cat /dev/urandom | tr -dc a-zA-Z0-9 | head -c ${1:-20}
}

E.g., spw 25 will give me a 25-character passwords of [0-9a-zA-Z].


The client does not need to support SGX to interface with a service using SGX.  In fact, unless you plan to use remote attestation, there is no way the server would know whether or not the client supports SGX.

SGX allows running specialized code inside a "secure enclave" in the processor: the process state cannot be examined by a debugger, and the memory used by the secure enclave is protected against access by even the operating system.

A typical way to place data in the enclave is to generate a public/private keypair within the enclave, export the public key to outside the enclave, then have the client encrypt data with the public key.  The (now-encrypted) data is copied to the enclave (including over the network, if necessary) and then decrypted within the SGX enclave.  At this point, the enclave can do whatever operations are necessary on the data.

Note that SGX can also use the hardware sealing key to persist data that can only be recovered on the same host.

There was an excellent presentation on SGX at Black Hat USA 2016 that provides more implementation details on some of these aspects.


How to secure test/dev environments from outside world?

Put the test server behind a router/firewall, and don't expose it on the outside. As long as everyone who needs to access the test server is behind the same router, everything is fine (provided you trust the local network); the outside world won't even know the machine exists.

If you need access from outside, VPN or SSH-tunnel into the local network.


Should an IT Security Policy allow employees use public Wi-Fi?

Wi-fi traffic can be intercepted at will. It's essentially a broadcast, in the clear in open wi-fi, or encrypted with the password if one's present; most of the time, even that encryption is insecure.

Public wi-fi is generally unsecured networks or networks with a shared key. This allows an attacker unfettered access. A typical traveler won't know which of the many appropriately-named networks in the airport is official, and which is an opportunistic attacker. So it's a safe assumption that the traffic routinely sent through open wi-fi networks will at some point, in some network, eventually get intercepted.

As to whether it's a security problem, in the perfect scenario where the sensitive data just lies on the drive, preferably encrypted, the user is not an admin, they only use the wi-fi for their personal needs, never to send sensitive mail or access company data, and they use encrypt&authenticate all their traffic, it's not.

In the imperfect real-world scenario, where sensitive and personal data is mixed up, the users alternate between using their laptop like a workstation and like a public terminal (disregarding security, since they're "just checking the weather"), it is. You'd be trusting several human-dependent protections for security, the breach of even one of which will leak the data. Worst-case scenario, the user's laptop can get a RAT (remote access trojan) uploaded to it.

It's not an automatic security fail - much of the web uses SSL now, so it's not like everyone sees everything, and VPN traffic can come through encrypted as well. But it's a large attack surface for a dedicated or opportunistic attacker.

The best solution is, IMO, to ensure the laptops used for travel aren't holding sensitive information, and aren't plugged into the vulnerable parts of the intranet (assuming zero-trust is not in place). On top of that, ensure the personnel on travel follows at least a minimum of security practices, such as not using open networks and not mailing sensitive data without end-to-end encryption.

If it's absolutely necessary to transfer sensitive data beyond mail to and from laptops while traveling, it's possible to design a corporate network that's secure over insecure channels, but it takes considerably more security expertise to set up and keep secure than can be realistically covered in a SE answer. The VPN has to be secure and always up, the laptops have to reject all other connections, including for Windows update, there shouldn't be any ways around it, and so on.

Given the negligible cost of local SIM cards compared to the expense of business travel, it's best to use them in favor of public wi-fi, together with other security measures (encrypted mail, encrypted files, low privileges, compartmentalization, monitoring, VPN). Even secured wi-fi is still someone else's network, someone local that can be impersonated and that gets two-way access to your traffic.


How to defeat CRIME, BREACH, TIME etc... server side (without sacrificing compression)

CRIME and BREACH are attacks on the client. Their setup is that some hostile code is running in the client with limited capabilities (i.e. it is Javascript in a Web page). The attacker also controls the external traffic of the victim: he can inspect it, but also block it. This limits what the server actually sees.

In both cases, the hostile Javascript will trigger several (many) requests aimed at the server for which the secret (the cookie value) is to be retrieved. The attacker only needs to see what goes out of the client; it is not absolutely needed that the request reaches the server. Indeed, HTTPS clients use HTTP: they routinely send several requests in a row over a single channel and don't mind that they don't receive a response immediately. This way, the hostile code makes the victim's browser send a lot of requests that the attackers see, but not the server.

Under these conditions, there is very little that the server can do to protect the client, except not letting it believe that the vulnerable protocol features (unprotected CBC, compression...) can be used at all. Rate limitations won't do much in this case.

Injecting some random padding is a possible defence, but it has to be done in the client, not in the server. There again, the server cannot do anything. A custom header, with random contents and occurring before the cookie in the header, would prevent BREACH. For CRIME, this is more complex; you need a custom header with a random length with a well-chosen distribution (it is not immediately obvious which distribution should be used). Of course, this extra padding implies more bytes to send, which may very well cancel the benefits of using compression in the first place.


How should I start security testing of python standalone application?

This is a two-part answer:

You must overcome any obfuscation or get to some sort of decompiled state. See this question on StackExchangeRE for more details on Python obfuscation.
Once you have the code (or if you have the source in the first place), you will want to utilize a mixture of secure code review, runtime analysis, and security-focused static analysis to uncover potential findings for triage.

If you are looking for security-focused static analysis tools, sadly many of the commercial ones are just not there yet for the Python language. Pylint and Flake8 also are primarily style or correctness checkers with zero security checks. My top recommendation for Python SAST is the Bandit project from the OpenStack Security team. There are only a few basic checks but you can add more. Bandit is only a slight (but important) improvement over older tools' techniques, such as seen in graudit and RATS.

If you are interested in runtime analysis, most security testers leverage Burp Suite Professional for HTTP/TLS traffic and Canape as a pluggable, local-logging proxy for other protocols. In order to understand file handlers or network protocols that utilize encryption or compression routines during runtime analysis, many security testers turn to software tracing (because it's faster than debugging) or hooking techniques, such as found in the Frida framework. A popular set of flaws targeting serialization (pickling in Python) are becoming more widely known, so it may be worth checking out the OWASP Python Security Project page or list for more information.

For a more-detailed look at Dropbox specifically, see this other answer over at StackExchangeRE, in addition to this Security Analysis of Dropbox code.


Can two users share the same Request.UserHostAddress?

Yes, this address can be shared by multiple users. For example:

Mobile phone providers often route their 3G/4G traffic for their subscribers via the same public IP.
Some ISPs have shared public IP addresses - historically notably AOL.
Corporations often have single or multiple gateways, meaning their employee traffic will be shared via the same external interface.

In your case you are not really authenticating clients based upon their IP, you are attempting to rate limit them. One solution could be to allow as many submissions from an IP, however if you detect over say five per hour coming from the same location then you could display a CAPTCHA that has to be completed.

Google are attempting to make these easier for people to complete with their Recaptcha v2 project.


Relying on mobile as a second factor is somewhat haphazard anyway - there are increasing numbers of people relying on mobiles as primary internet access devices (especially in countries with limited wired infrastructure), so an app on a phone, an SMS, or an email can end up on the same device the attacker is using. This already causes problems - try making a payment with Paypal's mobile app if you have 2FA enabled, and it won't let you, since it attempts to protect against this kind of attack. They don't seem to have a good solution to it though.

There are obvious mitigation strategies to the attack in the paper referenced: phones could restrict installation from browsers (e.g. require a code displayed on the browser to be entered on the phone by hand, or disable the function by default, in a similar way to Bluetooth pairing methods, so the phone user needs to be actively looking for installation attempts for them to work), the app stores could be more proactive in detecting SMS reading functions, or the 2FA receiving pages could prompt for extra verification details (e.g. require the site password to be entered, which would add obstacles to session stealing attacks, or prompt for specific characters of the sent code, making human interaction easier than automated entry).

For most accounts, though, it's probably a low risk. If you use a strong password for your app store account, it should be hard for an attacker to trigger such a background load, and you should always pay attention to new applications being installed on your device. There are always applications that slip through any monitoring system, so the problem would appear to be the blind trust placed by the phone in the app store automated install process - a case of usability with a security downside.


Do URLs used in JavaScript AJAX GET calls need to be sanitized through Apache when there is no server side scripting or database involved?

Validation / sanitizing is done on server only. In your example there is no server side code.
If your client loads files that should be available to everyone without any restriction, then there is no need on server to check anything. I.e. you don't have to do anything on the server.
"anyone could just make the simple call anyways" - this is wrong statement. If some resources should only be available to particular users (e.g. web access to emails should provide only emails of logged in user and not of other users), you will probably use some query to find corresponding data in the database. If you don't sanitize your query, you will allow SQL injection and unpredictable behaviour of your application: unpredictable uncontrolled modification of data, uncontrolled access of user to the data of another user.


question about clean reinstallation of infected windows 7 (nuke from orbit approach)

As long as the USB has never been inserted into an infected machine, the original infected operating system is not booted while the USB is present and the virus has not modified lower level systems (like BIOS / firmware) - which the shortcut virus appears not to - you should be fine.

I would suggest if you do not have files you wish to recover on the infected system to fully wipe the drive before/during the install process. Letting Windows move the old files to a Windows.Old folder may risk re-infection.

If you want to be particularly paranoid boot from a linux live USB or Windows PE disk and wipe the HDD before reinstalling Windows.


Why is JS:Cryptonight considered a virus?

You are correct. It's not self-replicating it's not a virus.  It is, however, malware because it steals a victims' resources without their knowledge/consent.

Pretty much anyone who understands the code is going to block it with something like NoScript, while the rest of the victims who don't understand what it is or what it does will have compute power and bandwidth (which ultimately costs them real money when they have a higher electric bill or less battery life on their phone) taken from them.

Just because the code is on a website doesn't make it any less malware ... if someone wrote a bitcoin miner into winzip or the dropbox client ... people would riot (and rightfully so).

Ultimately this question is opinion based and should most likely be closed.


Yes, that is exactly what is talked about when discussing XSS vulnerabilities. In the context you described, one could also add code to redirect a user to any site or present possibly malicious code directly from that website. Changing the target of password forms, posting cookies to other websites and many other malicious acts are possible.


A hardware firewall is a network appliance dedicated strictly to performing the functions of a firewall.  They may have hardware built specifically to speed the routing of packets, such as large RAM buffers on the network adapters.  And they are running an operating system designed to run a network appliance.

A software firewall is an OS-level application performing firewall-like functions running on an ordinary computer that may also be running other applications.  Networking functions are accomplished through software running in the OS.

The idea is that a hardware firewall will be "more secure" than a software firewall because it has a reduced attack surface.  With no other applications running on the hardware firewall, there are no additional memory buffers to exploit, no extra protocols with vulnerabilities, no unknown programs, no stray ports left open.

If you take an ordinary PC running a desktop OS and run a software firewall on it, it's still a software firewall.  The desktop OS may be running dozens of services that don't perform firewall functions, and they increase your attack surface.  You may not even be able to disable some ports on a consumer version of Windows 10, for example.  However, if you install an OS intended to be a dedicated networking appliance, such as OpenWRT, and if you run only a firewall on it, you'll have security much closer to a hardware firewall; although you probably won't get the same performance as you might with a commercial firewall appliance.

Keep in mind that having a dedicated firewall is one thing; but having a secure configuration on it is another.  The best hardware firewall on the market is useless if you don't change the default password, if you don't set deny all by default, or if you fail to disable UPnP support.  This is true regardless of if it's a hardware or software firewall.

Also note that if an attacker passes their attack through a firewall to a web application and manages to violate the web server's integrity, the end result is the same.  Firewalls stop traffic on unknown ports; they do nothing for malicious traffic on known ports.


Help to determine what type of encryption has been used?

It's not clear whether each of the three values that you posted is a result of the hash function in question, or the result of the hash function is all three values concatenated together.

However, it looks like the each of the values that you posted are 55 bits long.  Each of them are made of 12 English uppercase letters.  There are 26 uppercase letters in the English alphabet, so this means that there are 2.54*10^16 (26^12 = 2.54*10^16) possible such combinations.  The equivalent number of bits needed to produce this number of combinations is 55 (2^55 = 3.60*10^16).

Most modern hash functions produce results that are much longer than 55 bits in length (e.g. even the obsolete MD5 hash function produces 128-bit results).  See https://en.wikipedia.org/wiki/List_of_hash_functions, which shows the length of the results produced by various hash functions.  So, my guess is that the result of the hash function in question is all three of the values that you posted concatenated together.

If that's the case, then this means the result is 165 bits in length (55*3=165).  So, it's possible that this could be RIPEMD-160 (160 bits) or MD5 (128 bits), or several others referenced at the link above.


A security analysis was performed in May 2016:

Security  Analysis of Dashlane by Paolo Gentili, Sarah Shader, Richard Yip, Brandon Zeng

That analysis attempts to look for largely the same types of vulnerabilities as the Li et al. paper cited in the question.  They looked for XSS attacks, but found none.  They were also able to bypass Dashlane's device authentication feature.  Overall, they found Dashlane to be quite secure.

They analyzed Dashlane version 4.1.1.  Dashlane has since been updated to version 4.6.8.


How can I intercept and modify HTTP requests?

I personally am partial to Fiddler, a free download from MS.
There are many other decent interactive http proxies, but that one serves me the best.


Does cloudflare protect against BREACH attacks?

Vulnerability scanners can be wrong. They often detect only the circumstances around a vulnerability, like compression, without actually testing to see if that circumstance is vulnerable. It's up to you to verify the validity of each detection presented by your scanner. To do this, you would have to launch a BREACH attack against CloudFlare. Please do not do this without clearing it with their security team first. You would be seen as a real threat if you performed penetration testing without permission. This is illegal in most jurisdictions.
This question can only be answered by their support team. In this case, you already have their answer. They have implemented a mitigation and they have verified it internally.

Cloudflare has patched all servers against these vulnerabilities. Also, the Cloudflare WAF has rules to mitigate several of these vulnerabilities including Heartbleed and ShellShock.

Close this item in your scanner as a False Positive.


Are Chrome file system API not supercookies? Why are people not worried about them?

In order to use persistent storage, the application must request quota, which results in a prompt to the user.  It could obviously be used as a supercookie at that point, but given that the user has been prompted, it seems to be a less concerning avenue than other areas.  (Also, being Chrome specific would likely make it less targeted than other supercookie techniques.)

Temporary storage is not prompted, but the browser can clear it at any time.  I'm not sure when this occurs, but I believe it should occur if you clear all local data.

I'm not aware of any specific security concerns related to this API, since it provides a sandboxed filesystem to each origin.  (It cannot read/write arbitrary data from other applications or locations on the user's computer.)

I consider this a privacy issue more so than a security issue -- in my mind, if the API is working as intended and does not leak/reveal data that was not in the original design, then it's a privacy decision that was made by the spec designers.  (Obviously, many users are unhappy by many privacy decisions that have been made -- I'm not saying it's desirable.)  It becomes a security concern when a privilege boundary is crossed or you can use it to reveal information that the designers did not intend.  (Such as the implications of canvas fingerprinting.)


Whitelisting applications is a defense-in-depth measure.  While it won't prevent a truly determined person from doing something nefarious, it will stop most people -- especially if users are running as non-admin.

Practicality is relative to your environment.  If it's as you say, a home system, then the liklihood is that you don't have group policy in place.  You would have to manage the configuration on each system manually.


Bruteforcing a windows mapped network drive with half of the digits known

You need to attack the SMB protocol with your brute username / password lists.

Hydra has the smb switch can be used
nmap has a smb-brute script which can be used

Remember that if you're attacking a network user you'll want to account for the domain in the username, and bear in mind that dictionary attacks are very noisy.


You can use a key derivation function to convert the user's password into an encryption key. Then you would use a cryptographically secure pseudorandom number generator to generate a separate key that would encrypt the user's data. You would then use the derived key to encrypt the generated key. The resulting ciphertext of the data encryption key could then be stored safely in the user table of your database (call the field "encryptedkey" if you like). In this way, the user's password will become the means to decrypt the user's encrypted key. The key that actually encrypts the data is only decrypted long enough to decrypt the data that it encrypted. You'll need to store that key in the session in order to avoid the need to ask the user for his password on each decryption occurance.

Alternatively, you can store the key encryption key on a Key Management Service such as that offered by Amazon AWS. This way you would retrieve the key from Amazon over TLS using only a reference to the key. Of course in this case you will still need to store the authentication credentials for the KMS somewhere in your architecture, possibly in a remotely retrieved highly secured config file.

Random Number Generator ⟶ Helps create Key #1.
This key encrypts your data.  It stays constant over time.  You must generate this key when the user first registers.  Use a CSPRNG (cryptographically secure pseudo-random number generator) to ensure sufficient randomness and unpredictability.
Password ⟶ Converted into Key #2 with PBKDF2.
This key, Key #2, is used to encrypt Key #1.  You'll want to persist Key #2 in the user's session.  Store the encrypted form of Key #1 in the user table, in a field called (perhaps) "encryptedkey".
Changing passwords
Whenever the user changes their password, you only have to execute step #2 again, rather than encrypting all of your data, all over again.  Just convert the new password into a key (Key #2), re-encrypt Key #1, and overwrite the old value for the encrypted form of Key #1.
Encrypting/decrypting data
When the user has logged in, execute step #2.  Once you have the password converted into a key, just decrypt Key #1.  Now that you have Key #1 decrypted, you can use Key #1 to encrypt and decrypt your data.


How do you Secure VOIP in a large organization

TLS doesn't provide end to end security in SIP, because of the routing architecture.

SIP messages are transmitted from the user agent through SIP routers, and TLS encryption only happens between user agent and routers and between routers.

You could use S/MIME to encrypt and/or sign parts of the SIP messages from one user agent to an other.

For media streams protection, SRTP and ZRTP are fine.


spam: several secret inboxes targeted at once. risk or coincidence?

Given that your email addresses fall under the same pattern, i.e.

  aep-x-company@domain

I would first think of a spam bot that found out that writing to one of those address (randomly created) didn't result in an error message, hence it generated many other emails to similar addresses.

Or it may even be purely random generation, i.e. without checking for error, as you are following a pattern for every address that is not that complicated or unlikely to be generated by a bot.


Is there a option to protect a USB stick from being infected other than flash drives with hardware protection?

You cannot protect the stick from being "infected", if by "infected" you mean that the other computer writes a malware file onto it - unless you have a USB stick with a hardware write protection.

What you want to protect is your own computer against executing that file from the USB stick and thus becoming infected.

You can achieve that in several ways, depending on how you judge the risk:

Throw away the USB stick after the transaction
Re-Format the USB stick
Do a malware scan of the USB stick

Connecting the (possibly "infected") USB stick back to your computer is rather low-risk: You know for sure that it is a simple USB stick (and not some kind of active USB attacking device). Thus, the only danger would be if your OS automatically executed some file automatically - this is possible, but most modern OSes have protections against that.

If you wipe the stick by formatting it, any possible malware file will be removed.