You could always utilize a USB port blocker to physically block access to any USB ports.  You only really need one of these per device... the other USB ports can be dealt with super glue (or most likely a different non-permanent solution).


Browser security - Firefox + NoScript is better than Google Chrome?

For starters, Chrome has better security features and a larger security effort than Firefox.

It's true that JavaScript can be involved in exploitation and exploit kits use JS to hide exploits and profile the browser for exploitation. But disabling JS should not be considered a silver bullet for browser security.

More than just blocking JS, NoScript brings to Firefox security features which Chrome already has, like XSS protection. And features that Chrome lacks, like Clickjacking protection and protection against plugin based attacks. Take into consideration that NoScript will also increase the attack surface.

There isn't a clear winner here considering that the security of Firefox + NoScript depends on the user configuring NoScript and the usability trade-off.

For more about browser security read the Browser Security Handbook by Michal Zalewski. His book, The Tangled Web: A Guide to Securing Modern Web Applications extends this handbook.


If I can disable antivirus tamper protection, couldn't a malicious worm do it as well?

In order for malware to disable anti-malware protection, it typically needs to escalate its privileges to admin levels. And that's what the anti-malware tools prevent.

So sure, an admin level malware could do that, but in most cases that would be pointless, as it already has admin access and can do anything it wants.

In summary - no, anti-malware and antivirus are valuable in stopping many types of attacks.


Android Encryption Implementation Notes has a pretty detailed description of how the disk encryption is implemented from 3.0. When a user enables encryption if they do not already have a pin set they are required to set one.

  The master key is a 128 bit number created by reading from /dev/urandom. It is encrypted with a hash of the user password created with the PBKDF2 function from the SSL library. The footer also contains a random salt (also read from /dev/urandom) used to add entropy to the hash from PBKDF2, and prevent rainbow table attacks on the password

The master key is then stored in the footer of the encrypted partition. Most of the code that is used to start the encryption process is in Vold, Android's volume daemon. If you have the full AOSP source for android you can take a look at /system/core/vold/cryptfs.c which implements many of the commands for encryption in vold as well as commands for verifying and changing the password.

This blog post, Android Disk Encryption also has some good insights into the crypto implmentation as well as the implications of tying the decryption of the master key to the pin/password entered by the user to unlock the device.

Hope this helps.


I suggest you look at the public exploits to learn how they exploit the vulnerability and then ask a more specific question about anything you don't understand.

As a place for you to start, somebody made a page on github that summarizes all the talks and guides.  The published exploit of OpenNMS using ysoserial is about as simple as you are going to get.


Is htaccess secure enought to whitelist clients IPs?

This method is sufficient to protect against Apache serving this directory, but a configuration error may disable this:

If your main Apache configuration contains AllowOverride None (or similar), then .htaccess files are ignored. Thus your IP whitelist does not apply. Depending on the hostname or directory, different configuration might be set.
If you have Satisfy any set (not default) and a client is authenticated with the server, then it is still granted access.

Furthermore, there are other attack surfaces that may bypass your IP restrictions:

On a shared webserver, it might be possible for other users of the server to access your files over the filesystem, bypassing Apache.
If your webapp does not use HTTPS, it is already vulnerable to sniffing and MitM attacks.
Your app could still be vulnerable to CSRF. If someone knows that a particular app is running on this host, (s)he could trick you into opening a page that exploits a CSRF vulnerability in your app (if any).

Suggestions:

If this is a dedicated server for this webapp, configure the firewall to whitelist your IP addresses for this port. Remember to check your IPv6 configuration as well.
Ensure that file permissions are correctly configured. Should any service (running as a different user that is not root) on your server be compromised, then your app should still be safe (providing there are no privilege escalation bugs).


As far as I know, there haven't been leaks or admissions that Skype uses this kind of technology. However, other techniques can be used.
First, law enforcement agencies can ask Skype to give them certain data about a Skype account:

In response to a subpoena or other court order, Skype will provide:
• Registration information provided at time of account registration
• E-mail address
• IP address at the time of registration
• Financial transactions conducted with Skype in the past year, although details of the credit cards used are stored only by the billing provider used (for instance, Bibit, RBS or PayPal)
• Destination telephone numbers for any calls placed to the public switched telephone network (PSTN)
• All service and account information, including any billing address(es) provided, IP address (at each transaction),
and complete transactional information

Note that billing addresses and data related to financial transactions can be more useful than IP and email addresses.
In addition to that, there is an interesting technique for forensic analysis of audio and video recordings, which doesn't rely on watermarking: electrical network frequency analysis.
The basic idea is that you can detect the fluctuations of the frequency of power distribution networks (usually, around 50 or 60 Hz) in audio and video recordings. Since the fluctuations are known by the power distribution company and vary according to the power grid, it is possible to geo-locate any speaker, potentially including a Skype user, at least in an approximate way. These are two sample papers on the topic.
Since Skype is a (closed-source) software, it is possible that it sends system information such as the OS and the processor being used by the user , but I haven't found any evidence of this so far.


Will the same JavaScript fetched by HTTP and HTTPS be cached separately by the browser?

Resources are cached by their URL, and the protocol (http:// or https://) is part of the URL. Since the protocol differs, the URL must also differ, and you have two separate cache entries.


The question (to most people) is an oxymoron. By definition, people will think that "open WiFi" means "un-encrypted WiFi. To me you seem to be asking "Why did the people that wrote the 802.11 standard way back in 1997 make the decisions that they did?"

The short answer - we can only find out by asking them (or seeing if there are any discussion documents floating around on the internet).

However, we can discuss the Firesheep portion of the question. A "Firesheep" attack is a specific type of attack where cookies that authenticate a user to a site are copied by an attacker.

The only requirement is that the cookies can be obtained by the attacker - and therefore WiFi networks using WEP, WPA, or WPA2 with a single pre-shared key are vulnerable, if the attacker has the key. And of course, many small businesses provide WiFi access using a single key.

Having "better" Access Points is an expensive way of fixing this problem, and will still leave users vulnerable to the above attack scenario (where the attacker can use ARP poisoning plus a man-in-the-middle attack against HTTP-only sites).

Therefore as far as solutions go, the best and most useful would be widespread implementation of HTTPS (as recommended by the creator of Firesheep, Eric Butler)


Can someone use WiFi snooping to see data I send through Tor Browser when I'm not using SSL?

When you use Tor, all data is encrypted between your computer and the exit node. As long as the exit node isn't on the same network that you are on (very, very unlikely to occur), the data will be protected from the local network. Note that meta data such as the fact that you're using Tor and rough estimates of how much data you are communicating may be observable, but the contents of that data will not.

As you are talking about using unencrypted communication, the clear txt data will be completely exposed from the exit node onward. Perhaps the biggest threat here is of a malicious exit node snooping or even modifying your data.


Both your questions from the body are already answered in your question. You ask

  Why would I truncate the hash output? Where do you see truncated hash output?

and also cite:

    While it is acceptable to truncate hash function output for the sake of shorter, more usable fingerprints

This is exactly the answer as to why you would truncate hash outputs - modern hash functions do have extremely long outputs that are hard to compare, especially manually (because humans are not good at comparing 32 hexadecimal figures)

You then ask

  Won't it possibly result in some duplicated value if I truncated it unproperly?

and cite:

    the truncated fingerprints must be long enough to preserve the relevant properties of the hash function against brute-force search attacks.

Which can be a security concern if not honored. Hash Collisions (i.e. same hashes for different inputs) are hard to find for modern hash functions. Truncating hashes makes this easier; the bitcoin network for example shows that a certain prefix can be brute forced.

However, the use cases for truncating hashes are usually manual comparison in conjunction with structured data (for example, this might be thinkable for Public Key verification (hence why you found those remarks on that specific wikipedia page), although, gnupg doesn't do that and goes for the full hash, afaik). Finding collisions in structured data is harder than finding them in arbitrary data, choosing a sensible truncation length might preserve a comparable level of security in regards to the untruncated hash function and arbitrary data.

Your title asks

  What does a hash output (a fingerprint) can be truncated mean?

Whereas I'd like to cite wikionary:

  (transitive) To shorten (something) by, or as if by, cutting part of it off.

"Hash output (a fingerprint)" has two parts. The parenthesis seem to suggest that fingerprints are hash outputs, which is (afaik) always true, but could be conceived otherwise (for example by defining a truncated hash output to be the fingerprint, just to make confusion perfect). Nonetheless, usually fingerprints are hash outputs over the to-be-fingerprinted-data.

Truncating a fingerprint means truncating the hash output of the to-be-fingerprinted-data.


What security risks are there in allowing someone to upload PHP scripts?

It's very dangerous, because you are allowing to someone to upload PHP file with unknown code and unknown intentions, so if you need this functionality as part of your web site, you should harden your server, for example:

Set a only one directory to upload PHP files from users, you should apply right user permissions (read, write or execution) for this directory, remember create a specific user for this directory, not use root user.
You can create a .htaccess file for directory, then you could set specific settings for that directory (Configuring .htaccess file).
Validate input user, even you should set a specific name format and size maximum for PHP files, if a PHP file doesn't match with that format or its size is bigger than what is allowed then application shouldn´t allow to user to upload that file.
Use canonicalization before use file functions, for example: realpath, basename. This helps you to avoid path traversal attack.
You should disable PHP functions with high risk, for example: exec, shell_exec. You can do this through php.ini file, for example, you could add the following line helps to disable functions for OS command execution and settings management:

disable_functions =exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source

The following line helps to disable functions for include or open files from external sources:

allow_url_fopen=Off
allow_url_include=Off

Official documentation php.ini file

Those are some basic recommendations.  You should analyze your web application and your needs to set the right settings for your server and web application.

I hope this information helps you.


How to retrieve the admin's password of a webapp?

I have to find the admin's password (I know that it's possible because that is the example's final goal). But admin's password is hashed and cannot be reverse with any lookup table.

You can, however, find a hash collision that computes to the same value.  Will it take a long time?  Yes, but the amount of time may or may not be feasible, depending on the hashing algorithm used.

  Could you please list all the ways via I could login as the admin? That is, what are the many ways I could find the admin's password?

Although they may not seem like it, these are different questions.  For instance, if you find a string that hashes to the same (as described above), you won't have the password, but you'll have a password that works.

A more common approach is session stealing, in which you possess the identifier that is supposed to prove you are a user, but don't have the ability to log in as them once that session expires.  This is fairly trivial to do any time sessions are transmitted over plaintext.

There are many different attacks you could try, but they depend quite a bit on the specific application - if you could do the same thing on every app, we'd just bundle it into a pentesting tool and cut out the person.  It's impossible for us to give you any good advice without knowing the specifics of the app you're trying to break.

And the point of an exercise like this is to learn for yourself, neh?


Is there a way to securely check if a password is one of the most used ones?

Unsalted hashed passwords, especially hashes of common passwords, are trivial to reverse. For example, diamond is a top 100 password. A quick Google of its SHA1 hash of f872caad177d67bbe18c119d0505f2d3caa02af3 quickly reveals the unhashed password.

If a list you created a list that indicated that a set of users all shared the same password and that list was acquired by a hacker, then a password breach of one account would quickly lead to a breach of other the accounts.

This also opens up a new type of attack where an attacker can guess the top 100 passwords for your site by setting their account's password to likely choices. When it fails, they'll know they've found one. Then they can try logging into other user's accounts with that password.

Basically, storing passwords securely is difficult. The current technologies have been developed over decades. Any change you make to the current model will likely risk your user's accounts and passwords.

If you want, grab the list of the top 100, or top 1000, passwords and prevent them from being used. Just keep in mind that there is much controversy over the use of password requirements. Some feel they make things more secure, others that they just irritate users.


Why should one not use the same asymmetric key for encryption as they do for signing?

It is mostly that the management approaches and timeframes differ for the use of signing and encryption keys.

For non-repudiation, you never want someone else to get control to your signing key since they could impersonate you.  But your workplace may want to escrow your encryption key so that others who need to can get to the information you've encrypted.

You also may want a signing key to be valid for a long time so people around the world can check signatures from the past, but with an encryption key, you often want to roll it over sooner, and be able to revoke old ones without as many hassles.


How To Bypass SSL pinning In SPDY protocol?

SPDY work different from HTTP, the proxy must support it.
I guess this is your problem. mitmproxy does not support SPDY.

You need to look for proxy that support SPDY, somethink like this one. If you can make the phone\app trust your certificate, it should work.


How should I select which antivirus software to install on my new laptop?

What you want for software in general is that it:

does the job;
is easy to install and manage;
is cheap.

Windows 8 comes with Microsoft's antivirus already included (it is called "Windows Defender"), which fulfills point 3 (you already paid for it, so it is technically "cheap") and point 2 (the software which is easiest to install is the software which is already installed). As far as I know, it also does the job, and since it is backed by a big company (Microsoft) which has a vested interest into this antivirus keeping on doing its job properly, I tend to think that it is a reasonable choice.

For previous versions of Windows, the same antivirus is known as "Security Essentials" and can be downloaded and installed for free. It is also a reasonable choice.

(I have used other antivirus in the past, but most had some irksome feature, such as "nagging" the user with ads for the full, non-cheap version. Also, this is only for Windows; the main OS on my laptop happens to be a Linux, which can safely operate without any antivirus.)


How are packets received by a Tor exit node routed back through the Tor circuit?

Tor works like a chain of proxies, where each proxy only knows about the next hop and the previous hop.

Simplifying a lot, when your computer sends data using Tor, your tor client will encrypt the payload, and forward it to another node. The next node does the same, and after a few iterations your packet reaches the exit node, is fully decrypted, and sent to the destination webserver.

The webserver sends the packet to the exit node, because the exit node was the computer that connected to the webserver. The exit node uses a table (seems like the NAT table, but with more information) to decide where to send the response. So it will encrypt the packet again, and send it to the next node, which will do the same, until the packet reaches your computer, are decrypted locally, and sent to the application.

The intermediate nodes don't have to wait for all the data before sending it to the next hop, or downloading files several MB big would be a hassle. Instead, they have a limited buffer space, and every time the buffer fills (or a timeout occurs), they encrypt it and send it ahead.

Your application will think the remote server is your tor client, so it only have to acknowledge the packet transfer until the first node. The destination webserver thinks the exit node is the client, and all intermediate nodes will acknowledge the packets between them, as there's a point-to-point connection between then.


May be I am wrong, but try to use wireshark

Also I think that this might be useful http://compnetworking.about.com/od/networkprotocolsip/f/convertipmacadd.htm


How to combine a key and a password in practice

If you use PBKDF2 then you are using a salt, because that's how PBKDF2 is defined: it is a function which takes as input a password and a salt. So there is already a salt somewhere. Or else Bob is using a "fixed salt", i.e. not a salt at all, and we can say that Bob is not really running PBKDF2.

Salts need not be secret. Their virtue is in being unique (as much as possible).

Salts are part of password hashing functions, and they are good to thwart cost-sharing when the hashed secret value can be realistically broken with brute force; i.e., when the secret is a password. There is no need for a salt, or, for that matter, for lots of iterations, when processing keys which are not passwords. When someone deals with a key that is stored in a file, it is assumed that the key is large enough and generated with a strong enough PRNG that brute force is no longer an issue.

Therefore: there is already a salt for the PBKDF2, it must already be stored "somewhere" (not necessarily with any kind of confidentiality). There is no need for any other salt here.

As for the other question: if the places where Alice stores her key are safe, then why would she need extra protection ? That's the point of safe places: they are safe.

Alice wants to encrypt her data because she fears that the storage and transport mediums to which the data will be entrusted may come under the eyes of people who are interested in the data, but should not be able to see it. (At least that's the rational reason why Alice's data should be encrypted. It is possible that Alice wants to encrypt the data because she has an "encryption system" budget line to be spent before the end of the current fiscal year.) Encryption will maintain the confidentiality of the data as long as only Alice can perform the decryption.

A password is tied to Alice by being stored in Alice's brain. The key file is tied to Alice because it is stored in "safe places" that only Alice can access. Both cases can be deemed "slightly vulnerable" because:

A password that fits in a human brain can usually be recovered through a dictionary attack (because human brains are not good at remembering arbitrary bits, and they are extremely bad at making truly random choices).
A key file exists as a file on some physical object, and ensuring the physical security of an object on a 24/7 basis can be challenging (at least Alice cannot help but bringing her brain with her at all times).

Combining the two kinds of secrets for a single encryption is akin to two-factor authentication.

Further encryption of the key file raises the question of: encrypting, yeah, but with what key ? If Alice wants to do password-based encryption of her key file, then we are back to Alice's brain, whereas the point of using a key file was, indeed, not to rely on Alice's brain.

On a generic basis, all applications of encryption should include checked integrity. This is because the "passive-only" attacker model is almost never realistic. Most attackers who are in position to eavesdrop on data (and we encrypt because we think it possible) are also naturally able to alter the data.

Combining encryption and MAC properly is hard. The proper way is not to slap together some block cipher with HMAC in a semi-haphazard way; instead, use an authenticated encryption mode which does the job (e.g. GCM).

As for the details: there are many ways to "process" a key file and a password together into some secret value amenable to use as a symmetric key for encryption. The password part is best done with a dedicated password hashing algorithm, specially designed and reviewed to do get the most protection against dictionary attacks. PBKDF2 is not bad, although bcrypt is arguably better; and cryptographers are working on even better functions.

Using concatenation of the key file and the PBKDF2 output, as input to HKDF, relies on properties of HKDF which are not easy to spell out in all their mathematical glory, but are likely achieved by HKDF (this is a good choice).

The real key to understanding the situation is right there in your first paragraph: Alice is not comfortable with using only a password. The protocol suggested by Bob is not aimed at actually "increasing security"; the real goal is to allow Alice to relax. Therefore, what must be done is: whatever it takes to appease Alice's paranoia. If Alice wants to pile encryption upon encryption, and needs a tower of nested complexity to be relieved of her worries, then so be it. That's her data after all.


How to block all inbound traffic from a specific Internet address or subnet using TomatoUSB router software (LINUX based)

As I wrote "Perhaps the INPUT chain is not where I need to add this" I decided to look more closely at the output of the iptables -L -nv command.  Sure enough, I found a chain called "wanin" that has all my port forwarding rules.  Aha moment - I want to block some port forwarding!

So I changed my command to:

iptables -I wanin -s 45.142.195.5 -j DROP

and lo and behold - the constant logging in my email server logs of attempts to login from this address has stopped!

Now I have to figure out how to add this to a script run when the router reboots.  This command is not "permanent" or remembered between boots.

I'll also probably change the source to 45.142.195.0/24 to block the whole subnet.


Is using a “Red” and a “Green” browser to balance LOB requirements and security a good approach?

Theoretical security is a world of absolutes, but the world we live in is made of compromise. You have to find a good balance between strong security and usability. Your approach pretty much hits the nail on the head.

What you're essentially doing is separation of duties. You have an insecure browser, which is unsuitable for web browsing, but must be used for a particular business purpose. As such, you're creating a second role (filled by Chrome) and separating the duties they have to perform.

The only suggestion I'd give, if it's possible, is to skip the firewall configuration and just unplug the box from the network entirely.


Concerning The OWASP Security Guidelines As They Apply To Site Registration / Could honeypotting work?

From a security standpoint try to understand what advantages a honeypot adds.

When you design your security you should try simulate real world scenarios with an intelligent attacker and how your honeypot would work.

For Starter's your security stands on obscurity which is usually  not preferred (can be an ambiguous subject). In your case if the attacker is aware of the honeypot he will just not be bothered.

Also consider that adding a honeypot opens a new surface for attacks.As mentioned by @nbering a legitimate user could be locked out or worse an attacker could try to lock out your users with spoofed ip while trying different emails.

If your security concern is for an attacker enumerating valid emails, simply you could inform if the registration was successful on the provided email.


How can you know what is distributed with your Linux

I'm curious, in theory, how can one know if for example kernel that is distributed with Ubuntu Linux is really what is on https://github.com/torvalds/linux and not some modified kernel which contains tracking code etc...

Actually, what is distributed with your distribution usually isn't what's distributed via torvald's git tree. Your Linux distro is probably not vanilla kernel.

The reason for this is that distribution vendors usually backport fixes that may impact their customers from various sources. In Fedora, for example (these examples picked purely because I have recent experience custom building these packages):

The kernel (currently 3.11.4-201.fc19.x86_64 at time of writing` contains a number of patches for v4l, iommu fixes, drm-intel-nex, iwl (intel wireless) drivers and so on.
Grub2 contains a number of patches to resolve various (breaking) issues with its build, and patches to make EFI builds work.

On Fedora (and other yum-based systems) yumdownloader --source kernel will pull down the source kernel RPM - open it up and you'll find everything used to build the kernel packages.

So, no, your Linux (and even your packages) might not be vanilla vendor packages.
Now, next:

  The real question is, can you be sure that distributed open source software is really what you expect it to be?

Well, the point of the above was that your package database contents might not be what you expect them to be, but the question I guess is and could this have malicious content in it?.

The answer is that there is little way for you to tell as an end user unless you inspect the source and rebuild the package from that.

However, most package submission processes involve a little rigour. Usually, you can't just turn up and become a maintainer of a popular package. You would need to be known for contributions, approved by a staff member/committee member/whatever it is that gives you rights to push packages.

I can see this being a possible attack vector in obscure software, but major packages I think it is sufficiently likely that an attack would be detected eventually. Most packages are built from source and receive scrutiny due to bugs, user issues and so on. Development continues and packages are rebuilt. Patches may fail. Somebody, somewhere is likely to notice an oddity, basically.

On this basis, I think you have to make a risk based decision. Is what you intend to protect so valuable you believe highly capable and persistent adversaries are going to try to backdoor a package in a Linux distribution to get to you? If so, go ahead and build your own distribution (there is no reason you can't steal an existing distributor's packages and just carefully audit/compile your own, by the way - that's the beauty of open source).

If not, I would (personally) go with accepting the outside risk.


Zeroing empty sectors on various Linux filesystems

There are various tools for the task. It depends on what are think exactly.

If you want to securely delete an already existing file, then the zerofree and sfill tools are for you (as you can read on @BobBrown's link). If these are not available, or you like more do things combining system functionality instead of downloading toos for everything, then there is another solution:

You set a loopback device from the file to erase (losetup /dev/loop0 /this/file/to/delete).
From this point you can pay with /dev/loop0 without the fear that it freed the block of /this/file/to/delete instead of rewriting. You can safely fill them with zeros (dd if=/dev/zero of=/dev/loop0), or with random numbers (using /dev/urandom instead of /dev/zero)m even multiple times if you want.
If you are ready, deallocate the loopback (losetup -d /dev/loop0), and you can safely delete the now rewritten file.

There is another case, if you want to make some already deleted file unrecoverable. In this case you had to ask "free" and not "empty" sectors. The problem is, that you can't address or manipulate sectors on a filesystem, which doesn't belong to any file. Even this is because it is free.

But there is a workaround. If you create a file enough big to fill the whole free _space on the hard disk if you fill it zeroes or random numbers, you will surely overwrite all free sectors in your system. So, there is very simple what you had to do: simply fill you partition with a big, empty file, until it doesn't stop with a "filesystem full" or similar error:

dd if=/dev/urandom of=/filler

...is even enough. While it works, you can even watch with some df commands, how are the things going. After /filler filled your disk with random bytes, and then the dd command stopped with the error, it is practical to sync one (to make sure everything is really overwritten), and then you can remove the /filler.

There were enough to protect from everything which a normal human can do to recover your data. If you want yet more, you had to replay that 3 or even more than 10 times. Even the NSA doesn't do more.


Is it safe to log JavaScript exceptions to the error console?

It is safe as everything on the client-side is, by definition, already accessible client-side.

If you're worried about the password being exposed and read by passers by of the user's screen, then normal users will not have the console active. If they did, it would also be possible to see the password entered via the Network tab:

Screenshot taken from this question.

It would be best practise though to disable console debug output on production sites. For pre-production it might be wise to filter out passwords in case they are accidentally copied into bug reports, but these being test accounts the risk should be low.


Is it possible to speed up WPA/WPA2-PSK cracking using a rogue AP?

The key derivation of the PTK is defined in section 8.5.1.2 of IEEE 802.11-2007, Figure 8-20 (page 198, which is page 247 in the PDF file):

PRF-X(PMK, "Pairwise key expansion",
      Min(AA,SPA) || Max(AA,SPA) ||
      Min(ANonce,SNonce) || Max(ANonce,SNonce))

AA and SPA are the addresses of both communicating partners, ANonce and SNonce are the nonces sent by them.

X is the number of bits needed, and depending on the use, X is here either 384 or 512.

In the previous section 8.5.1.1, the PRF (pseudo-random function) is defined, and it is effectively

PRF-X(K, A, B) = HMAC-SHA-1(K, A || 0 || B || 1) ||
                 HMAC-SHA-1(K, A || 0 || B || 2) ||
                 ...

(with as many repetitions as needed to fill the needed number of bits, discarding the remaining ones.)

So the question effectively is: Can one attack HMAC-SHA-1 in a way that, knowing some of the input and choosing other parts of the input, but not knowing the key, one can (a) derive parts of the output, or (b) derive the key?

As far as is known, neither the HMAC construction nor the SHA-1 hash function has a weakness in this respect.

So the only currently known way to break this would be to brute-force the PSK (or the password from which it is derived), which would need not much more than one listened handshake, but lots of computation to find the key.

There is no realistic chance to break the 256-bit key, but one might find a password from which it is derived quite easier. So use a good password.


RAID-1 and low level formatting (or file shredding), more chances of data recovery?

In RAID-1, writing to the array is always equivalent to writing to each drive individually.

However, if I am to separate them and connect them as separate drives, will I have more chances of recovering the files?

In theory, any drive may accumulate damage over time. A damaged sector that is taking too long for a read to return or which is failing more times than usual will be copied to a fresh sector, and the previous sector will be marked as unusable. This sector remapping can leave previously written sectors untouched even after overwriting the entire drive. This is not particularly common, but it happens. Naturally, using two drives doubles the probability of this happening.
One small note: Most RAID devices will store a little metadata at the beginning of each drive which contains basic information like a UUID, drive number, drive state, array level, etc. This metadata is not touched when you write to the array. If, for whatever reason, you suspect that there is old, unused data which was not overwritten in that metadata region (which is unlikely as it is typically within the first few hundred sectors of each drive), then writing to the array may not be sufficient since it does not overwrite it. This is highly unlikely though, and is just mentioned here for completeness' sake.

I always assumed that there's one master drive out of the RAID-1 setup, and the controller will somehow "be smart" and do some optimization tricks which will lead to keeping some of the deleting data in one of the drives.

RAID-1 does not involve a "master" drive. In that raid level, every drive is a perfect clone of every other drive (excluding perhaps an identifier kept in the RAID metadata to make it easier to identify individual devices). The controller will not be using any "tricks" that lead to keeping data on one of the drives. That is the reason writing to a RAID-1 array is limited by the speed of the slowest drive, since no optimization is going on and the write will only return once it has been sent to every drive in the array.

Now, am I assuming wrong? should I disable the RAID-1 setup and low-level format (or shred) them separately to make sure data is gone.

Writing to the RAID-1 array is functionally equivalent to writing twice to each individual drive. Anything you write to the array will be duplicated and written to each drive in real-time. Note, however, that a low-level format may not be sufficient if it does not actually overwrite all data. Whether or not it is sufficient depends on the exact software and filesystem you use. But instead of formatting, you should use ATA Secure Erase. This is a firmware feature in modern drives which does a low-level automated erasure of all data. It can take a few hours on older drives, or a few seconds on newer drives that make use of SED. ATA Secure Erase may not work with RAID if the software does not support it, in which case you should disconnect the array and issue the command to each drive individually.


How does this site uniquely identify a device?

I can not reproduce any of the behaviour you describe, so this post will be a bit more theoretical in nature.

The ability that you are perplexed by seems to be the ability to recognice the source of a HTTP request even when a VPN is used and a no-features user agent like CURL is used. That would indeed be perplexing.

The super cookies or fingerprinting methods we know of all relies on some kind of feature (like HSTS, Flash, or JavaScript to report screen size or installed fonts). CURL does not support any of those featers, it does not even parse the response for you. So still being able to identify the user would indeed be magic, or at the very least a sign of a faulty VPN.

However, the test you describe in your question does not demonstrate the proposed ability. There are a large number of alternative explanations that you have not yet ruled out. Just to name a few:

The IP of well known VPN:s are listed and blocked.
The IP of the VPN is in a blocked geolocation.
The button is activated by JavaScript, that CURL will not run.
The behaviour is just random.

The test I would do would be to use CURL (with the exact same request) and a VPN for both the first and second attempt, but with different exit nodes, i.e. different IP's. If repeated tests of that kind shoved that some kind of super cookie worked I would indeed be perplexed, but not until then.


Why aren't Microsoft Office macros sandboxed?

Microsoft Office macros are a design of the past. Do note that they were designed back in the days when a userland program could overwrite memory of another application (or even the kernel!), boundaries were not checked when processing network packets, etc.
It is also similar to the ActiveX web page additions that were created by Microsoft. Rather than running inside a sandbox, like java applets, they directly ran unconfined code (in the same memory space as the browser, I guess), with full access to the system. The security they got added was one of signed with a code certificate, do you trust this company?.
I think it is fair to say that security was never part of the macro design. The macro language (VBA) relies heavily on the program OLE interfaces and existing Visual Basic / VBScript engine.
You could design a sandboxed interface for Office macros. You would basically remove dangerous primitives (such as Shell) and disallow importing of foreign objects. Most macros (affecting only its own document) would still work. Macros using complex actions (such as accessing an url, or opening a Word document from Excel) would fail. Some "internal" would also need to be reviewed and filtered somehow (such as "Saving the current document with a given name" or modifying other opened documents).
Blocking all macros is a more simple approach than redesigning their macro system. It also avoids breaking documents with macros designed before the sandbox addition that were not able to be run. Microsoft could add a flag for "this is a macro with no external effects", so that they could opt-in to "safe execution", thus keeping backwards compatibility.
It would be a feature interesting to have, so that some macros could be allowed in the environment, without risking the whole system (I'm sure we would then see exploits and buffer overflows in those "safe macros" being abused, but those would be bugs). Although that wouldn't fully solve the problem: the social engineering would continue to "enable insecure macros". It would help administrators block macros, without such a big pushback for "we need documents with macros, which are business-critical".
Apparently, Microsoft hasn't deemed that use case profitable enough to the effort of developing a "sandboxed macros" feature.


As far as I know, aircrack-ng only supports dictionary attacks when cracking WPA-PSK passwords. This necessarily means that the wordlist used must contain all the values you want to try, and naturally the wordlist will grow excessively long if you want to crack longer passwords.
The solution is to use some other tool like hashcat, which supports multiple cracking modes including brute-force and mask attacks, in which candidate passwords are generated while cracking and no wordlist is required.

This reddit post explains how to crack wifi passwords with hashcat:

Firstly you need to prepare you handshake .cap file and convert it to .hccap:
wpaclean cleaned_handshake.cap handshake.cap
aircrack-ng cleaned_handshake.cap -J final_handshake
You will get final_handshake.hccap file which can be accepted by hashcat.
About mask attack you can read here: https://hashcat.net/wiki/doku.php?id=mask_attack
For example, if you know that the password is 8-10 characters in length command will looks like:
hashcat -a 3 -m 2500 final_handshake.hccap ?a?a?a?a?a?a?a?a --increment --increment-min 8


Preventing user supplied javascript from posting to external server

Code is inherently dynamic and it is and will always be impossible to control the behavior of user-supplied code.  By allowing users to execute JavaScript you are implementing a Cross-Site Scripting (XSS) vulnerability.   XSS is also commonly used to expose users to Drive By Download attacks which is strangely missing from your threat model.

One way of mitigating the threat posed by XSS is to isolate user supplied scripts to a sub-domain such that they cannot access sensitive information due to the Same-Origin Policy.  This does nothing to stop an attacker from executing BeEF on users of your web application or perform another type of drive by download attack.


VPN Authentication over WiFi -- Is it secure?

A VPN which is worth that name will ensure a proper bootstrap for the encryption, i.e. protect the credentials as well. Most VPN will rely on either SSL or IPsec. An SSL-powered VPN is, cryptographically speaking, similar to browsing to a HTTPS Web site: first SSL, then the data under the protection of SSL; once the SSL layer has been established, the client has some guarantee that it talks to the right server, and can safely send the credentials, which will be encrypted like all other data, and won't go to the wrong guy. With IPsec, ISAKMP/IKE or something similar will be used, and the model is the same as with SSL.

SSL and IPsec differ in the encryption details and how they split data into transport packets (with SSL, the inner packets will be serialized into a sequential tunnel which runs over a TCP connection; with IPsec the translation is per-packet and more direct) but for the security model, they don't differ much: the client authenticates the server through the server certificate, and builds up the cryptographic tunnel from it; once the tunnel is up and running, the client sends credentials to the server, under the protection of that tunnel, so that the server knows who is talking to it.

A very poor, badly written VPN may leak your credentials, but hey, that's what you get for using crappy technology.


ASLR in Linux does not randomize libraries separately

However, it packs all libraries and executable in the same order and without gaps. So, as soon as single address gets compromised, this whole part of ASLR goes out of the window.

Not quite. ASLR still works for reducing the chances of blind exploitation, helping to prevent an attacker from reliably jumping to an execution point. If you don't know a particular point to overwrite, then your next tactic is to NOP sled nearby memory anyway. Coupled with the starting address being randomized, you're just as likely to pick something off in never-land as useful code regardless of fragmentation.

  I mean, 64-bit address space is huge, you could just randomly throw each library at it and then check if it overlaps with anything, and successfully place it after a couple retries at most.

True, but that incurs a performance issue. Every randomization entry is going to require an entry in the TLB, resulting in higher resource utilization and more wasted / unused memory due to block alignment.

  My question is, is it the common case as of now? What systems address this issue and how?

For the reasons state above, it is indeed the common case. Understanding the limitations of the attack helps with understanding why using the more expensive "bits of memory  everywhere" has limited benefit.

A bonus point: the most common exploitation is writing too much data to a data block, then executing it. The NX bit is also a substantial countermeasure.


Injecting a TCP packet into existing connection

The "all odds in attackers favor" scenario

Attacker is in the same network as the victim, can monitor the network and can not only eavesdrop the connection, but interfere with it. This is the case when the attacker can execute an ARP Spoofing attack against the victim.

In this case, the attack is possible, and trivial against an unencrypted protocol like HTTP. Attacker can read every packet from the victim and the server, and can alter things when he wants to. He can tell H that he is the gateway, and alter packets going to the server. As he have the entire packet in his hands, he knows the TCP Sequence Numbers, all flags, options, and everything else. This is called Man in the Middle Attack.

Attacker in another network

It's harder than guessing a 32-bit number. In this case, MH must guess the correct sequence number (a 32-bit number) AND craft the injected packet with the correct flags AND correct options AND have his packet reach the server before the package from H. As H and MH are not in the same network, MH will have to employ IP spoofing, and that is almost impossible to execute. As lots of routers have Egress Filtering, they will discard packets with a spoofed source address.

Encrypted protocols

The same constraints as the other scenarios, but with a complication: attacker must forge an encrypted packet, guessing the cypher suite, all the encryption parameters, padding, IV, checksum, and have it merge seamlessly with the next packet coming from the client... No, it's not possible to inject data on an encrypted protocol and expect it to be accepted by the server or client.

  Server can find out that a packet is malicious because content is not decrypted to correct form.

No, server find the malicious packet because the TCP sequence number is incorrect, or correct but late (newer packet already arrived), or much above the expected number plus the transmission window. If all those almost impossible to spoof values are correct, and encryption is employed, server will discard the packet because it does not even remotely look like a valid one.

TCP is a complex protocol, so it's actually hard to bypass. Add an even more complex protocol on top of that (TLS/SSL) and you have an impossible task trying to inject spoofed packets on the communication.


Does trusting a device negate the security benefits provided by 2FA?

No, it won't negate the advantages of 2FA, even if it reduces it a little. Security is only effective if it does not makes the user resort to workarounds, otherwise they won't use the security option. I would not use a 2FA token if it took 5 minutes to arrive, for example.

In this case, remembering the device for a while will not force the user to enter the 2FA token on every request, and will protect the user if his password leaks somehow. An attacker exploiting this perceived weakness would have to compromise the device itself.

And if you value your security, please don't use "token by SMS", "token by phonecall" or anything that uses your phone number to send the token. SIM swap attacks are real, and lots of people are losing access to their accounts because of it.


... am I worrying to much ?

Maybe not.
Unfortunately it is not uncommon that certificate validation is done improperly.  Many think that encryption is enough and that certificate validation is just an annoying thing with all this root CA hassle etc. In not so far away times for example PHP or Python did not check any certificates at all by default and this was only fixed in PHP version 5.6 2 and python 2.7.9 about 2 years ago. And for example most mail server simply ignore bad certificates too.

Thus it might well be that the unknown application you use does not check certificates properly. It might also be that you need to explicitly configure it to check certificates. When in doubt look at the documentation or contact the vendor.


Answer 2 is nonsensical; it literally says "we can prove who the sender is because two people have the ability to create the MAC." With a MAC, either party could have created the MACed message; each party knows who created it (you know if you wrote something or not, and if you didn't the other guy did), but they can't prove that to anyone else, nor can they prove they didn't create it after the fact. To do that, they'd have to be able to prove you sent the text over the channel (including some proof it couldn't have been tampered with in transit, say by someone person 2 gave the HMAC key to), but if they could do that they might as well skip the HMAC and say "he sent it, here's proof he sent it."

The one-way channel would mean anything sent over the channel didn't come from person 2. However, you'd have to prove the message you present was in fact sent over the channel, and that no one could send a faked message over the channel (say, after person 2 had given them the HMAC key). If someone sends you something over a channel where it's verifiable that it went over that channel and only they could send something over the channel, and both these things can be proven, that channel again provides non-repudiation without needing the HMAC.

The shared element between these is that two parties can create valid HMACs, and one is trying to prove the other created a particular one. That's like having two people who have identical signature stamps, with one trying to prove the other is the one who stamped something. A MAC by itself can't help with non-repudiation, because either party can create them, leaving you needing to prove that someone is in fact the one who made a particular MAC, which is no easier than showing they made the message in the first place. So answers 1 and 2 are not right; the shared secret is why HMAC can't effectively provide this. (digital signatures, in contrast, don't involve both parties being able to create them, so they're better at providing non-repudiation). (note: non-repudiation isn't actually a technical concept, and courts often accept s/My Full Name/ as a signature on electronic documents; HMACs might in fact convince someone enough to trust the person claiming you wrote something, even if they don't technically prevent them from forging it).

Answer 3 is indeed wrong; confidentiality isn't needed for non-repudiation. One of the best sources of non-repudiation is a declaration in open court; the non-confidentiality is part of the reason why that provides non-repudiation (i.e. everyone can access the records).

By process of elimination, the answer is 4.


No, that's not going to fool spambots.  I've seen a couple of spambots that were parsing the entire DOM using tools like html5lib or comparables.  Of course, many spammers just "guess" at email addresses: the cost of sending emails when you have a botnet is basically 0, so making combinations of username & domains to guess works out well.

Slightly better techniques I've seen have involved using javascript to render the email address into the DOM at runtime.  A spambot would need to be running in a browser or use something like WebDriver to get at those.

But, in all reality, hiding your email address is a losing battle.  A contact's address book might be compromised, or you might miss one place where its posted, and then you're back where you started.  Good filtering is probably a better investment of time & energy.


This is not a collision attack, but a preimage attack

With a collision attack, the attacker has control over both inputs to the hash function, say x and y, and they want to find x and y such that x ≠ y but h(x) = h(y).

With a first preimage attack, the attacker knows h(x) but not x, and they want to find y such that h(y) = h(x).  Importantly, the attacker cannot change x.

If the message were known, it would be a second preimage attack, where the attacker knows x (and therefore also knows h(x)), and wants to find y where y ≠ x but h(y) = h(x). Again, the attacker cannot change x.

MD5 is still secure against both first and second preimage attacks, so what you want to do is not possible, and knowing the length of the message (or even the entire message) will not help.


What is susceptible to Kon Boot hack tool?

how is such a hack tool guarded against?

Prevent your computer to boot from an external media by setting appropriate options at the BIOS level and protecting this configuration using a BIOS password,
Use Trusted Boot where TPM chip is available (most professional laptops have one, this Dell Latitude has one),
Use full disk encryption, this recommendation being the most important one.

As a side note, Kon Boot documentation states that it does not work on system where the BIOS available memory is too small. Whether this limitation can help to guard against this attack, I'm not sure...

Regarding the video the author claims to have already enabled the two latter recommendations using Dell's Control Point Security Manager, but it seems obviously untrue (encrypted disks are officially unsupported by Kon Boot, see here, here and there), either because the video author mistakenly did not setup these features correctly, or for other reasons. As a side note, he promotes a commercial encryption product in his video description, so...

  Would such a tool be able to hack a virtual machine?

Yes, if someone get administrative access to the virtual machine is able to boot it from an external media it will work the same as way with a physical PC (I have not tested it myself, but encountered blog posts where people actually used VM to safely test this tool and bypassed their password successfully).


A proxy is a system which relays communications. From your server, you see the communication as coming from the proxy machine. The IP address you see is the one of the proxy. If you block that IP, you block all traffic coming from that proxy, but no traffic from elsewhere. If the villain switches to another proxy, he will pass.

Some HTTP proxy add a header line X-Forwarded-For which identifies the true source IP address. Note, though, that if the proxy system is under control of the perpetrator, then he can configure it not to include that header, or, worse, to include a fake X-Forwarded-For value.


Hashing a key: less entropy than the key itself

Entropy is a big word for a mathematical concept (in the context of cryptography), which is thus named out of an approximate analogy with the "entropy" as used in physics. Here, "n bits of entropy" means, more or less, that there are 2n possible values for the key.

For security, there is no practical difference beyond 100 bits of entropy. We want our keys to be safe from exhaustive search and this is achieved when trying out all possible keys, or at least a substantial portion of the key space, is ludicrously unfeasible with existing technology. Cryptographers have long used "80 bits" as the threshold for that; 100 bits ought to account for improvements in technology and a comfortable margin (at these sizes, energy dominates, not Moore's law). Beyond that size, exhaustive search is utterly defeated, and there is no bigger defeat than that.

Therefore, while your "128-character key" has potentially 512 bits of entropy (assuming the "characters" are hexadecimal digits) and the SHA-1 hash has "only" 160 bits (the output size of SHA-1), both are still very far into the "cannot do it" realm, and it does not make sense, from a security point of view, to say that one is "more secure" than the other. Both are immune from exhaustive search.

Correspondingly, there is no need for a salt here. Salts are about preventing parallelism and precomputations: they assume that the attacker can run an exhaustive search on one key, and will want to run the same attack on several keys. Salts ensure that the attack cost for ten keys will be ten times the cost for one key. With a 100+ bits key, the cost for one attack is way beyond what can be done, so there is little point in preventing parallelism. Said otherwise, if the salts change anything to the security situation, then the attacker is a god, and you should sacrifice oxen to appease him, not try to counter him with your puny hash functions.


Are 2FA soft-tokens flawed if the user can log into the website from the same mobile device?

Yes, it loses some of the protection since it fails to protect them if the device is thoroughly compromised.  It still, however, protects against any number of limited attacks.

For example, if they are configured to connect through a proxy that can strip the encryption, the 2FA will remain safe.  If the password DB is compromised somewhere that they used the same PW, the 2FA will remain safe.  If they use the account on another computer sometime and that computer is compromised the 2FA will be safe.

A thorough compromise of the phone is a failure case, but it is only one of many possible failure cases.  It is worth advising the user that it is ill-advised to login on the same device as they use for the 2FA, but ultimately, it still does provide significantly more benefit than having no second factor would.


Teamviewer indicates they secure their connections client to client.

If implemented properly this should mean no one can intercept the data you send over the network in plain text, i.e. find you password and username, because the connection is encrypted.

In other words, in the case you describe (you connecting to your home computer) it should be secure, assuming you don't have any malware/keylogger running on your pc (but again: that has nothing to do with Teamviewer).

The same may not be true if you connect via Teamviewer to a client his computer. Not because the connection is not secure, but because the PC you are connecting to might have monitoring software enabled.

https://www.teamviewer.com/en/products/security.aspx


Is it safe to allow users multiple login at different browsers & computers?

There is a good reason for preventing concurrent connections - if they are not needed by your users.

A good rule of thumb is to not allow more functionality than that which is needed. If your users are never going to connect more than one simultaneous session, disallowing it would reduce the risk of attack (as an attacker would not be able to conduct their attack while the user was logged in.)

If, however, your users may expect to use multiple sessions, then you'll have to have this functionality.

Really, this question comes down to a functionality issue - google know their users may need to connect from multiple machines/locations/browsers at the same time, so they just notify of other sessions, rather than prohibit them.


PGP on Dark Net Markets: What threats does it control?

As always in information security, different scenarios and attack vectors must be considered.

New Communication

Encryption with unverified keys taken from the marketplace can definitely not protect against a compromised marketplace -- obviously, in a compromised marketplace, the keys could have been exchanged. You might realize when keys change for the same seller, though. Pretty much the same applies to a compromised seller account, where the key could be changed to one in control of the attacker.

In the end, there is not a lot of protection when the marketplace or an account on there is compromised, especially if you get in touch with the other side for the first time.

It might help, though if there's a problem in-between, during transmission, when the attacker has no control over the listed keys. For example unencrypted data sent by accident or software issues, or other problems with the transport security, when the message's contents are still encrypted themselves.

Old (Earlier) Communication

More important, message encryption will make old communication safer. Whoever gets hold of the encrypted messages because the seller's account or whole marketplace was compromised, will not be able to read the message's plain text. Depending on the security measures taken by the recipient (like offline keys, and passphrases to encrypt the keys), even a compromised or seized computer will not reveal the message's contents.

Adding Signatures

Finally, this might not only help at securing privacy of the communication, but also assure the identities of the communication partners if signatures are used. Given an account is compromised after some time, you would not be able to realize this. If messages are not only encrypted, but also signed, you could realize the sender is somebody else -- everybody could encrypt using your public key, but as long as the real account owner's key was not compromised, they cannot impersonate him.


File upload security with PHP - Header to text/plain

That line does not impact file upload security, it only sets the HTTP response mime type.

The reasoning I can see for the author using text/plain instead of text/html is simply that this script does not contain any actual HTML in the possible response messages.

Although the possible responses in this particular script do not echo any user input that I can tell, using text/plain as the response type instead of text/html would help to mitigate XSS in the page response, which could be possibly triggered via a combination with a CSRF attack from another site if the page did output anything using user input. This script does not protect against CSRF attacks.

Side note: this script does not actually validate that the files are valid images (mime checking is not sufficient). See the relevant Stack Overflow discussion EDIT: Actually, the script does an ok job at that.

You can use text/html if you want, just be careful with user supplied information.


Strictly based on the context in the presentation, it seems what EC-Council is calling a "Shrink Wrap code attack" is just the act of exploiting holes in unpatched or poorly-configured software.  To use the term another way, a "Shrink Wrap vulnerability" would be one which should only be seen in a product immediately after its initial installation - "fresh out of the shrink wrap" you might say.

Most of the Internet relies upon a relatively small number of different applications, frameworks, and OS's.  Because these platforms are shared across a large target base, and because so many organizations and/or admins choose to ignore the "low-hanging fruit", these sorts of vulnerabilities are often the first an attacker will turn to in order to quickly exploit a system.

Here are some general descriptions of what might be categorized as a "Shrink Wrap vulnerability":

A software bug present in the original version of a product, for which the vendor has released an update but the system admin has not patched.

Example:  CVE-2012-1528 in Windows 8, if the target system does not have the KB2727528 update installed.

An insecure default configuration option still in place after the system has been put into production.

Example:  Default (esp. when publicly known or easily calculated) account usernames & passwords left unchanged.

Debugging scripts or insecure test pages that are bundled with the software, which should have been removed prior to production use.

Example:  A "Hello World" script or page left in place, with an XSS vulnerability.

The above vulnerabilities are not, in most regards, very different from any other vulnerability.  What makes them stand out though, is that they are so easily fixable and really are not the types that should be found in production systems.  These are the types of vulnerabilities that should be resolved during the initial build process of the system or application, but too many sysadmins and developers out there will carelessly or ignorantly leave them open for the whole Internet to exploit.


If forced to download files using FTP, what steps can be taken to provide security?

Setup your own server (A) in an isolated secure enclave. Only allow this system to access the IP address of the remote FTP server (FTP) and nothing else. If the vendor running the FTP server can also restrict access to only your IP that would be ideal.

Then have your internal system (B) connect to this server via a one-way firewall rule using something like Secure Shell.

(FTP) <-------(FW)<---(A)<---(FW)<---(B)

      (A) Polls the (FTP) server every 10 minutes via script
      (B) Polls the (A) server every 10 minutes via script with a 5 min offset.

Note: The (FW) may be the same Firewall but a third network interface

(FTP) <-----(FW)--(B)
             |
            (A)

The important thing is to ensure that (A) cannot access (B) or anything else on your internal networks. Ideally nothing else in the world other than the FTP server. You may also want (B) to run tests on the files from (A) before importing them. There are also tricks with using two directories on (A) for scanned and unscanned files where files are scanned as soon as the FTP GET is completed. Lot's of options with this architecture.

Final note: Some vendors use FTP because they don't know how to use SFTP from the system they are using (most notably this occurs with AS/400's). It is possible to have the AS/400 FTP the files to a loopback address on itself (127.0.0.1) then have you access them via SFTP. This is MUCH safer than using FTP directly. Likewise, you can have the vendor do the reverse of what I wrote above to send these files to an SFTP server on their end instead of forcing you to use FTP at all.

Alternatively, you can run the FTP through a VPN which only allows your organization to initiate connections to the remote vendor but not allowing them to access your network.


Decryption After Public-Private Key Pair Revocation

A revocation doesn't actually change the key - it simply signals others, that they are no longer trustworthy - if the private key has been stolen - or functional (i.e. the receiver is unable to decrypt any messages any longer) - if the private key is lost.

As long as you're in possession of the private key, you can decrypt anything encrypted with the corresponding public key - in fact anyone in possession of the private key can do that.

A passphrase is just a means of protecting the private key by encrypting it - for example if somebody copies the key file.


Why is CVE-2017-12617 considered a vulnerability?

From the CVE

  This JSP could then be requested and any code it contained would be executed by the server.

PUT suggests a resource will be placed. But unless the API explicitly states so it does not imply it will change execution behaviour of the server.


Windows Defender found threats in Kali Linux disc image

No, Windows Defender won't run executables inside an .iso image on "run recommended actions" (or in any other situation), and you can't infect your computer this way.

Yes, Kali Linux has plenty of malicious code on purpose, and the detections you get are surprisingly same than on this article by Lawrence Abrams: Kali Linux Now in Windows Store, but Defender Flags Its Packages as Threats!

  If you take a look at one of the detected threats details, you can
  clearly see that some of the Metasploit components are being detected
  by Windows Defender when we try to install it in Kali.

  While it makes sense that Windows Defender will detect these programs
  as HackTools, because they are, it also makes it difficult to use Kali
  Linux in the Windows Subsystem for Linux.

  For now, if you want to install Kali and its packages, you will need
  to disable the real-time protection of Windows Defender, which is not
  always a smart thing.

Likewise, a lot of alerts will be triggered if you try and apt-get upgrade your Kali Linux on a network that has firewall level IDS/IPS or a virus protection on an HTTP proxy, as all the malicious components are upgraded over plain HTTP.


OpenSSL EVP aes_256_cbc Initialization Vector Size

Moved from the question to an answer.

  Stephen
  was
  correct.
  This was very simple to check, I just changed the IV to be the correct
  length and the ciphertext remained the same. Hence, the extra byte is
  not used in the algorithm and somebody miscounted.

  Default IV:

/* A 128 bit IV */
unsigned char *iv = (unsigned char *)"01234567890123456";

  Output:

Ciphertext is:
0000 - e0 6f 63 a7 11 e8 b7 aa-9f 94 40 10 7d 46 80 a1   .oc.......@.}F..
0010 - 17 99 43 80 ea 31 d2 a2-99 b9 53 02 d4 39 b9 70   ..C..1....S..9.p
0020 - 2c 8e 65 a9 92 36 ec 92-07 04 91 5c f1 a9 8a 44   ,.e..6.....\...D

  New IV:

/* A 128 bit IV */
unsigned char *iv = (unsigned char *)"0123456789012345";

  Run make again to build the program.

  Output:

Ciphertext is:
0000 - e0 6f 63 a7 11 e8 b7 aa-9f 94 40 10 7d 46 80 a1   .oc.......@.}F..
0010 - 17 99 43 80 ea 31 d2 a2-99 b9 53 02 d4 39 b9 70   ..C..1....S..9.p
0020 - 2c 8e 65 a9 92 36 ec 92-07 04 91 5c f1 a9 8a 44   ,.e..6.....\...D


Man-in-the-middle attack over an encrypted channel

Terminology: a secure channel is a communication channel that is protected against man-in-the-middle attacks and eavesdropping. Encryption alone does not make a secure channel. The simple way to establish a secure channel is to use SSL/TLS. but there are subtleties.

Encrypting the traffic is only part of the protection against man-in-the-middle attacks. This prevents the attacker from decoding the traffic, because he doesn't know the decryption key. This also prevents the attacker from injecting arbitrary traffic, because he doesn't know the encryption key.

With only encryption, the man-in-the-middle can inject some traffic by coming up with some ciphertext. He might not know what the plaintext is, but that can still cause trouble — the recipient is getting garbled data, which could even trigger a parser bug. A secure channel provides not only encryption, but authentication — a verification that the data comes from the legitimate source.

If the communication protocol is based on packet, each packet must have a tag that indicates who sent it (so that the attacker can't send traffic from one party back to itself) and some kind of sequence number (so that the attacker can't resend an old packet, which may now have a different effect).

Of course, if the attacker can suppress traffic in addition to listening and injecting, the attacker can disrupt the communication by cutting it off altogether, reordering packets, etc. Reordering packets can be detected (and the packets reordered or discarded) by properly using sequence numbers to authenticate the communication (which is stronger than authenticating each individual packet). No amount of cryptography will remove the attacker's ability to block all traffic, if he can delete packets. You need physical means: armed couriers, radio transmitters that are stronger than the adversary's jammers, …

Encryption might not always ensure that the communication remains confidential. The communication may allow side channels. In particular, the size and timing of packets may be revealing. For example:

If on 5 June 1944 the BBC had suddenly transmitted a flurry of coded messages, that would have indicated that something was afoot, even if the messages had been undecodable. Remedy: send coded messages all the time, and if you have nothing to send, send random messages that are indistinguishable from useful messages.
The size of the message may be an indication. For example, if military orders are sent to a rnpwbhm instead of a mcouzjooyb, you would know that the scope is important enough to involve a captain rather than a lieutenant, even if you wouldn't have been able to decrypt the rank. Remedy: use fixed-length codes for related concepts; dually, randomly vary the length of potentially-recognizable terms (e.g. through variant spellings of proper names, or more systematically append random-length garbage). (Both the attack and the remedy I cite here are from WWII histories, though I don't have the reference at hand.)
Voice traffic is particularly vulnerable to reconstruction because it is typically compressed and sent in real time. The rhythm of packets alone can be enough to reconstruct speech in lab conditions. Remedy: compress less and accept more lag, for example send a fixed-size packet every N milliseconds.

Another difficulty with protecting against man-in-the-middle attacks is initiating the communication. With a pre-shared key, this is not a problem, but if the two parties don't know each other beforehand, the attacker could be a direct man-in-the-middle: when Alice tries to establish a channel with Bob, Eve intercepts all packets and lets Alice establish a channel with her, then she establishes a channel with Bob, and relays traffic or not as she pleases. This is why SSL requires a certificate verification: the client verifies that the channel it's setting up is to the desired server (and, optionally, the server performs the symmetric verification).


Mysql Information schema column_privileges empty

It is no possible see information about database objects for which you don't have permissions. An empty information_schema table suggests a permissions issue for the user you are using to connect to the server.


If the server uses the same server_random in the 'server hello' message, then this could enable an attacker to launch a replay attack.  See SSL replay attack when client/server random is missing for more info.


Is a non-authenticated CSRF still a CSRF?

Would sending that replay link to someone else who would (without being logged in) click on it and increase the voting counter be considered as an CSRF vulnerability?

Checking the 2013 OWASP entry on CSRF, their attack scenario (to my mind) seems to describe something similar to your example:

  The application allows a user to submit a state changing request that does not include anything secret.
  So, the attacker constructs a request that will transfer money from the victim’s account to the attacker’s account, and then embeds this attack in an image request or iframe stored on various sites under the attacker’s control

In the case of your example, because no authentication is required, that scenario holds true in all cases: an attacker can cause a user to issue a request against your site, which will cause a state change.

I think OWASP's mention of the session being authenticated reflects an assumption on their part about what would be required to effect state changes on a site.
I don't think the authentication is in fact part of the definition of CSRF - the wikipedia entry on CSRF mentions:

  CSRF commonly has the following characteristics:

  It involves sites that rely on a user's identity.
  It exploits the site's trust in that identity.
  It tricks the user's browser into sending HTTP requests to a target site.
  It involves HTTP requests that have side effects.

So I think you could in fact consider your application to be vulnerable to CSRF: a user can be compelled to issue a request with side effects, and that request will always succeed (and could, at least in theory, be tied to the user's IP, for example).

I am not sure CSRF is purely about allowing an attacker to 'do something they could not otherwise' - I think one could argue it is about making a user do something they may not have done otherwise.


In case of DHE-RSA the RSA part is only used for authentication that the client speaks with the proper server. While it might be used to detect modifications of the key exchange it will not detect passive analysis of the key exchange, i.e. protect against attacks which only require to sniff but not to modify the data. An attacker who has managed to crack the specific DH group used by the key exchange (or has a planted a cryptopgrahic backdoor in it) does not need to actively fiddle with the connection but only needs to passively sniff on the connection in order in order to get to the exchanged key and decrypt the traffic.

It is known that the Five Eyes (i.e. NSA, GCHQ,...) but also other government services in various countries have access to a large part of the internets core systems and can thus passively listen to these data. Combined with weak or backdoored cryptography this makes it possible to sniff and decrypt the traffic without changing the traffic and in a way that sender and recipient will not notice it.

To address the question in the comment on why RSA is not used to protect the key exchange: one might argue that the knowledge of the servers RSA public key by the client would make it possible to encrypt the part of the key exchange which is send from client to server since the server might decrypt this part using its private key. While this would be possible with RSA it would mean that the DH key exchange is too much bound to the use of RSA and no longer a more or less independent mechanism. For example it would require the client to know the servers public key first. While is possible with TLS 1.0...TLS 1.2 where the DH key exchange is only done after the certificate of the server is known this is no longer the case with TLS 1.3 where the DH key exchange starts before the certificate is known. Also, more modern authentications mechanism based on ECC (i.e. ECDSA) are designed for signature only but not encryption which would mean that they could not be used to protect the DH key exchange anyway.


And how does that table grant them access to the files?  The entire point of encryption should be that the server can't access the files even if it wanted to.  If you just have the data keys stored in a table with a list of who is allowed to access the key, the server can now access the files and encryption is pointless.

Instead, a copy of the content key for the file is encrypted with the public key of the user being granted access and stored in that users keyring (a table much like you described for saying who has access, but storing access keys rather than a simple permission lookup).  Without that user logging in and providing their password, their private key can't be decrypted, the content key can't be decrypted and the file can't be accessed using their copy of the content key.

If you want to reject access, you simply remove the content key from their keyring and destroy it (provided that the server has never leaked the content key while they had access, slightly more secure would be to actually change the content key, but that gets costly as it requires re-encrypting the file and all the other keyrings).


Several hashing routines support client side work. Doesn't the hash just become a password equivalent?

Argon2 the winner of the PHC also allows for client side hashing.

Note that this is an additional feature, and doesn't make Argon2 to a fully fledged authentication protocol. The PHC has awarded it as password hashing algorithm, not as authentication protocol.

  Isn't Secure Remote Password Protocol (SRP) pretty much client side hashing?

For SRP, the hashing happens on the client, yes. This allows for key stretching to not happen on the server, but on the client, making it easier to protect the server from DoS attacks.

  How do these systems avoid the plaintext equivalence problem?

I guess by "plaintext equivalence problem" you mean the ability to mount replay attacks.

These are prevented in #2 by using TLS. This is actually ok, if you are targeting the web browser, because here, if MITM can modify TLS plaintext traffic, they can already get the plaintext password by changing the HTML/JS code.

SRP prevents replay attacks by server and client chosing random values (called a and b by RFC 2945) for every login session, and making the exchanged messages depend on those.


does validating MAC of individual packets validates the integrity of whole file?

The MAC in SSL/TLS is computed over the combination of the record payload and a sequence number, thus ensuring that records are all received, with no missing, out-of-order or duplicated record. The connection is also terminated with an explicit close_notify alert, which is itself part of the protected records, thus cannot be faked by attackers.

See the standard, section 6.3.2.1:

   The MAC is generated as:

      MAC(MAC_write_key, seq_num +
                            TLSCompressed.type +
                            TLSCompressed.version +
                            TLSCompressed.length +
                            TLSCompressed.fragment);

   where "+" denotes concatenation.

   seq_num
      The sequence number for this record.


Do I need PCI DSS compliance when using PayPal Express Checkout?

IANAQSA...

  If I'm using PayPal Express Checkout on my website, am I required to be PCI DSS compliant?

Yes.  If a customer goes to your web site, puts stuff in their cart, and then clicks "I want to pay for this stuff" and gets redirected somehow to a payment page hosted by someone else, you still have PCI compliance obligations.

  With Website Payments Standard, Online Invoicing, Express Checkout and Website Payments Pro Hosted, PayPal handles the payment card information on your behalf and so greatly eases the burden of PCI compliance." What? "greatly eases the burden"? What does that mean?

"greatly eases the burden" means you'll be eligible for a less onerous SAQ than you would be if you weren't using their services.  I don't know enough about the different products they've listed there, but for example, tokenization can help reduce scope from SAQ-D to SAQ-C.  If tokenization is in use and a web redirection is used to transmit payment data through their servers, then you can drop down to SAQ-A EP or SAQ-A, depending on which type of redirection is used.

Looking at the Express Checkout description, it probably means you're looking at SAQ-A or SAQ-A EP.

  Please help, I'm very confused and not sure whether I need to put the work into becoming compliant or not.

You need to become compliant.  In the case of SAQ-A, that's pretty simple.  In the case of SAQ-A EP, just a little bit more complex.  If you go up to SAQ C+, now you have work to do.

To find out which level of compliant you need to be, you work with your processor - which in this case would be PayPal.  Tell your sales contact you want to understand what your PCI obligations will be and ask if you can talk to someone in their Compliance department about understanding which SAQ you'll fall under and what the process is for submitting it to them.


It depends what you mean by "secure" :)

CHAP:

Client authentication request send its user name to the server
Server responds with a nonce
Client calculates hash(nonce|password) and send to the server
Server verifies the password

Cons:

All data is transmitted in clear text i.e. it possible for an attacker to eavesdrop and brute-force the hash offline
The server needs to store the password in clear text


Are these cryptographic methods along the right track?

There are some issues with your code.

$key = hash("sha256", base64_decode($secretpw64));

SHA-256 is very fast, and there is no salt here. An attacker can build a dictionary of (secretpw64, key) and get the key through a quick and dirty dictionary attack. As others have said, consider using a PBKDF. Even iterating the SHA for, say, 1000 times can be OK. For more information on how to derive a cryptographic key from a password, see this answer on Crypto.SE.

 $iv = random_bytes(16);

You are assuming random_bytes is a cryptographically secure PRNG, but this is not something you can handwave. Be careful!

Moreover, take a look at how IVs are generated.

If the application crashes, or you shut down the OS, and start again, is the first IV always the same? It could happen.

If it does, an attacker can crash the application and get two messages with the same key and IV whenever he wants. No need to wait for 2^64 messages!

Confidentiality is not everything in security. Integrity and message authentication are also important in most applications.

As it turns out, CBC is also vulnerable to bit flipping (aka byte flipping) attacks.

Basically, you can flip a byte in the ciphertext so to flip a corresponding byte in the plaintext. This normally scrambles the previous block, but it becomes a practical attack when you want to modify the first block and you can change the IV or, in some cases, by bypassing input validation. For more details, see this Defcamp writeup.

Finally, you should also consider other, non cryptanalytic attacks, depending on your threat model, including:

theft/disclosure of encryption keys (e.g. from the RAM);
malicious modifications or hijacking of the RNG. If, for example, an attacker can replace your RNG with a weak PRNG, everything breaks up.


What CryptoPP APIs Output Round By Round Results for AES Encryption/Decryption?

In fact, "output of each round" is not well-defined. The structure of AES encryption is a sequence of operations that looks like this:

Cipher(byte in[4*Nb], byte out[4*Nb], word w[Nb*(Nr+1)])
begin
   byte  state[4,Nb]
   state = in
   AddRoundKey(state, w[0, Nb-1])
   // See Sec. 5.1.4
   for round = 1 step 1 to Nr–1
      SubBytes(state)
      // See Sec. 5.1.1
      ShiftRows(state)
      // See Sec. 5.1.2
      MixColumns(state)
      // See Sec. 5.1.3
      AddRoundKey(state, w[round*Nb, (round+1)*Nb-1])
   end for
   SubBytes(state)
   ShiftRows(state)
   AddRoundKey(state, w[Nr*Nb, (Nr+1)*Nb-1])
   out = state
end

This pesudo-code is extracted straight from the AES specification (FIPS 197). AES (with a 128-bit key) can be defined as consisting in ten rounds, where each round consists in a few operations (SubBytes, ShiftRows, MixColumns, AddRoundKey). However, that description would have to be amended with an extra AddRoundKey, and without a MixColumns in the final round. The pseudo-code above is structured as nine rounds, where each round is the sequence SubBytes-ShiftRows-MixColumns-AddRoundKey; and there are a few operations before and after this sequence of nine rounds.

What constitutes a "round" is arbitrary here; it would have been equally valid to define a round as the sequence ShiftRows-MixColumns-AddRoundKey-SubBytes; the starting and ending operations would have been a bit different. Neither description is more standard or correct than any other.

A further complication is that the sequence of operations is amenable to algebraic transformations. For instance, ShiftRows and SubBytes commute; and AddRoundKey and MixColumns can be done in reverse order, provided that the subkeys are transformed accordingly; this is described in FIPS 197, section 5.3.5, for AES decryption ("Equivalent Inverse Cipher"). This augments the number of possible descriptions of AES rounds.

Moreover, "normal" AES implementations (based on tables) will merge some operations together, typically SubBytes, ShiftRows and MixColumns, by the magic of linear algebra. Since they don't really occur as separate phases, individual outputs don't exist.

Since round output is not well-defined, there is little point in implementations for providing an access to these values.

If you want, for pedagogical purposes, to print out intermediate values, then you'd better select an implementation that follows the letter of the specification (at the expense of performance), i.e. not Crypto++; in fact, you should write your own (if you print out intermediate values, then you are not doing anything securely, so writing your own code is justified).


How long should I wait before choosing a hash function?

How long should I wait before using a newer (hopefully improved) hash function?

The better question to ask is: "How long should I wait before switching off my current hash". What are you on now? If your data is protected with MD5 or SHA1 then please switch. Please switch now. If you're already on something that's believed to be unbroken, then you have no reason to "upgrade".

The general rule with crypto is to assume everything will be broken eventually, so pick something that's not known to be broken at the time, and have a plan in place to switch your data over to a new algorithm in a hurry if an attack does get published.

At the time of writing, the following are all perfectly acceptable, not known to be broken, hash functions / key derivation functions:

BLAKE, SHA2, SHA3, ... , bcrypt, scrypt, PBKDF2, argon2, ...

Choose the one that best fits your application.

  Is SHA-3 ready for use because of extra testing that went on during the NIST competition?

If NIST has standardized it (which they have in FIPS-202), then it's ready for use!

As @RoryAlsop said, beware that if you need your data to be compatible with multiple pieces of software, then be aware of compatibility issues; just because SHA3's been standardized for two years, doesn't mean that it's been widely adopted.

One final note, reading between the lines, you seem to be implying that SHA3 is a "a newer (hopefully improved) hash function". I want to correct this.

While it is newer, it is not "better" than SHA2, in fact SHA3 offers exactly the same security levels as SHA2. NIST launched the SHA3 competition not because they wanted to "improve" on SHA2, but because they were uncomfortable with the "all your eggs in one basket" nature of only having one approved hash algorithm. That's not to say there's anything wrong with SHA2, but if something does come up, they want to have a migration path at the ready.

SHA3 for password hashing.

Bad idea. SHA3 is ideal for file hashing (because it's fast), but it would actually be considered a weakness to use it for password hashing (because it's fast).

See NIST SP-800-63b:

  Examples of suitable key derivation functions include Password-based Key Derivation Function 2 (PBKDF2) [SP 800-132] and Balloon [BALLOON]. A memory-hard function SHOULD be used because it increases the cost of an attack.

SHA3 is designed to be efficient, it is neither slow (time-hard) nor big (memory-hard).

PBKDF2 and Balloon are schemes that wrap around a standard hash function to make it time-hard / memory-hard, respectively. So if you only wanted to support one hashing primitive in, say, your embedded hardware device, you can wrap PBKDF2 / Balloon around SHA3 and still have FIPS-certified crypto, but please don't use naked SHA3 on passwords.


Protecting yourself from a malicious VPN

Just don't use the VPN. Honestly.

If there is a reason why you want to use that VPN you can do the same as for normal network.

Firewall
Anti-Virus
Use sandbox like virtual machines
Keep uptodate of your software and OS
Maintain maximum network isolation in order not to compromise other computers.


How does a crypter for bypassing antivirus detection work?

In some circles, "crypter" and "packer" are synonymous to mean binaries or programs which are self-checking and/or self-modifying. Crypters may, more specifically, mean self-modification that includes encryption and/or code scrambling (see more below).

I suggest that you read Chris Eagle's The IDA Pro Book for an introductory understanding of packers and their disassembly of components and architecture.

Daniel Reynaud's work on packers and self-modifying code is also very fascinating. He makes some distinction between integrity checking, blind writes, code scrambling, and encryption of PE files in this blog post about visualizing packers and self-modifying programs. His crude system of checking for these various technique implementations in packers using dynamic binary instrumentation (not the best way of going about this, but it can be very fast compared to other methods) is available at https://code.google.com/archive/p/tartetatintools/


"I hacked my way into this interview": Is this a good idea for getting a job?

Gaining access to a computer system without the consent of the owner is a violation of law in most countries (if not all of them). If it is your future employer, then I would guess it shows that you can not be trusted with confidentiality, on top of it being illegal.

Please don't do it.

If you want to show off your skill, then offer to take a test or get permission first. Make sure that whoever gave you permission actually has the rights to do so.


jsp malicious file upload is possible, but no exploit scenario, should I report it?

The fact that you can upload a JSP file is in itself not a vulnerability.

Particularly, if the file contents are put in a database there is no actual JSP file on disk. Therefore, it can't be placed in the webroot and it won't be executed.

If the file is written to disk and you can put it in an arbitrary location, there is a risk. If you failed to exploit this because you don't know the path of the webroot, for example, someone with more time and knowledge may succeed in exploiting it.

I wouldn't advise scanning uploaded files for JSP content. If there is no way to put the uploaded file in the webroot there is no risk.


Disadvantages of a single administrator checking all file permissions

If the task assigned to the staff member is simply to check file permissions not modify them, then a copy of the file system's access control table could be given to the staff member by a more trusted administrator. The staff member could then review the file permissions, independently of the actual access control list. NTFS for example. Directory listing tools and scripts could provide the same information.

If an untrusted staff member needs the root privileges for modification, installation or other activities; I can think of two precautions off-hand:

Backup the computer before giving them access. Revoke access after the work is complete, and then compare the computer against its backup to see what exactly was changed.
Route all console commands through audit logging proxy box that the staff member does not have access to. This way at least the staff member can't pretend they didn't run various suspicious commands. Limited to monitoring non-interactive tools, unless the proxy machine also video logs all screen display and audio.


Should we encrypt in-app user messaging?

We have no way of knowing.

What needs to be done is:

Identify the risks arising from this vulnerability. (What bad things might your admins do? What bad things might other people be able to do if the messages are not encrypted?)
Assess the severity of these risks.
Decide if these risks are acceptable or if they must be treated.
Identify suitable ways of treating these risks.
Treat the risks.

To do all that requires a good understanding of what your app is used for, what your customers want, what the law requires of you, what your contractual obligations are, what resources you have available, what security capabilities are in your infrastructure, and what level of risk your business finds acceptable.

Not the kind of answer you hoped for, I fear, but if security is important then you need to make good, informed decisions about it.


Windows 10 Wi-Fi vs Airplane Mode Security

Airplane mode turns off all active wireless controllers. So that is both Wi-Fi and Bluetooth.

Once turned off, there is no possibility of any external agent getting into the computer without physical access unless malware or remote management is also present that could be use to turn the wireless controllers back on again.

Turning off the controllers means turning power off which saves battery too.

The same is true of turning off Wi-Fi. So no, there is no difference except that turning off Wi-Fi is likely to only turn off a single wireless controller.


Trying to figure out Gmail login in Wireshark

you wont be able to see it plain text in wireshark. the packets are encrypted ettercap is acting as a relay, your pc connects to ettercap which decrypts the login info then encrypts it again to send it to the real gmail server


When does the same-origin policy prevent a request from being sent?

Would it send a request or throw an error without sending the request?

Your POST request would be sent. However, the same-origin policy prevents that are you are able to read the response. Just like an ordinary form submission, it's a type of cross-origin write. Here is an overview from Mozilla:

  Cross-origin writes are typically allowed. Examples are links, redirects and form submissions. Certain rarely used HTTP requests
  require preflight.
  Cross-origin embedding is typically allowed. Examples are listed below.
  Cross-origin reads are typically not allowed, but read access is often leaked by embedding. For example you can read the width and
  height of an embedded image, the actions of an embedded script, or the
  availability of an embedded resource.

In your scenario, the request would trigger an involuntary action (a bank transfer). This type of attack is called cross-site request forgery (CSRF). To prevent these, developers have to actively take countermeasures such as implementing CSRF tokens.

  Are there any cases where SOP prevents the request from being sent and
  catches it before?

Yes. For example, you cannot specify methods other than GET, POST and HEAD by default. Other methods need to be explicitly allowed using a technique called cross-origin resource sharing (CORS).  That's why custom methods are sometimes used as a (questionable) alternative to CSRF tokens.

To allow a custom method FOO from any origin, the server could reply with these headers:

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: FOO

Here is how Google Chrome rejects a request with the method FOO to https://www.google.com:

You can see that the browser first sends a preflight OPTIONS request to check which methods are permitted via CORS. The server then replies with a 405 status indicating that FOO is not allowed - and the entire request fails.