how does a return to system allow an attacker to evade a non-executable stack? I am learning about return to system call attacks for a security class. I understand that in this kind of attack, attackers replace the standard return value for a stack frame with the address of a library function. The slides from class say that this is a way to evade a non-executable stack. How so? Is the idea that the library function has been tampered with and so when the frame returns it goes to the malicious library code? Is a return to system call attack only useful if the library function has already been corrupted?

When a function exits, execution jumps to the address which was saved on the stack. "Classical" exploits of a buffer overflow alter that saved address so that it points to, precisely, the contents of the stack buffer which was just overflown. This assumes that the attacker gets to choose the contents of the buffer, and places there the code he wishes to get executed.

When the stack is non-executable, the classic exploit no longer works. However, the buffer can still be filled, and overflow over the rest of the stack, which includes the return address, but also other things. Consider that the stack looks like this:

address     contents
0x07fff8c8  ...
0x07fff8c4  ...
0x07fff8c0  ...
0x07fff8bc  ...
0x07fff8b8  ...
0x07fff8b4  return address
0x07fff8b0  ...
0x07fff8ac  ...
0x07fff8a8  buffer
0x07fff8a4  buffer
0x07fff8a0  buffer
(...)
0x07fff858  buffer
0x07fff854  buffer

In this rough diagram, the stack grows downwards (as it happens in most architectures); addresses are fictitious but realistic for a 32-bit little-endian architecture on a Unix-like system. The attacker will try, by inserting maliciously crafted data in the buffer, to obtain this situation:

address     contents
0x07fff8c8  ...
0x07fff8c4  0
0x07fff8c0  0x07fff854
0x07fff8bc  0x07fff854
0x07fff8b8  ...
0x07fff8b4  address of execlp()
0x07fff8b0  ...
0x07fff8ac  ...
0x07fff8a8  buffer
0x07fff8a4  buffer
0x07fff8a0  buffer
(...)
0x07fff858  0x0068732f
0x07fff854  0x6e69622f

If the attacker can get this, then, when the attacked function returns, the stack pointer is set to 0x07fff8b4, then one word is popped from the stack, and interpreted as the "return address", i.e. the point where execution shall continue. In this case, this makes the CPU jump to the standard library function execlp() (that's a Unix function). This function is, by definition, located in an area of RAM which is amenable to execution.

The code of execlp() expects to find the stack populated like this:

address     contents
0x07fff8c8  ...
0x07fff8c4  arg2
0x07fff8c0  arg1
0x07fff8bc  arg0
0x07fff8b8  address of calling code

execlp() will interpret arg0 as a pointer to a zero-terminated character string which is the path of an executable file, which execlp() will run. arg1, arg2... shall be pointers to other strings which are the arguments to be passed to the executable file.

In our situation, execlp() has no idea how it was "called"; all it knows is that the CPU is now entering it. It finds as arg0 the value 0x07fff854 that the attacker arranged to put at this place on the stack, with his buffer overflow. That value, 0x07fff854, happens to be a pointer to the area of RAM which formerly contained the buffer, and still contains the data that the attacker placed in it because while this area is "free", the stack has not yet regrown into it. At address 0x07ff854, the attacker placed the two 32-bit words 0x6e69622f and 0x0068732f, which happen to be the encoding of the ASCII string "/bin/sh" (with a terminating 0).

Thus, execlp() finds properly formed arguments which instruct it to run a shell, and so it does.

Summary: a buffer overflow which overruns the return address is used to make the attacked code jump to an arbitrary place. The attacker wants the CPU to run some code which gives the attacker some advantage (e.g. code which runs a shell). Since the stack is non-executable, the attacker cannot put his code in the stack. But the standard library is a collection of functions which are, by nature, executable, and some may do just what the attacker wishes to obtain. It then suffices for the attacker to make the return address point to the library function which corresponds to the desired effect, and the same buffer overflow can be made to place on the stack the "arguments" that the library function will use, right at the place where that function expects them. Since none of this uses the stack area as code, only as data, the non-executable property of the stack does not matter.

Notes:

There is no need to jump to the start of a library function. Jumping to the middle of a function also works. The possibilities are almost endless.
Things work similarly for overflows which replace pointers to functions, e.g. vtables for C++ objects in the heap. What matters is that the target library code finds on the stack what it expects as arguments.
Non-x86 architectures make things a bit more complex because the calling conventions for most RISC architectures (ARM, Sparc, PowerPC, Mips...) define that the first arguments are taken from conventional registers, not read from the stack. The basic principle remains valid, though, but it means that it is harder to make a one-size-fits-all exploit code. The attacker has to tune more details with regards to the exact application he attacks.
The attacker must be able to predict, with good probability, where the library code will be loaded in the application address space. ASLR is a security feature which chooses the loading address more or less randomly, precisely to make such games harder for the attacker.


AES in CTR mode with same random IV to create same ciphertext I am currently working on a little project.

I am trying to generate an AES key with that I would like to encrypt a private RSA key. I have to do it this way. However, I do not want to save the AES key, but generate it everytime when I would like to decrypt my RSA key.

I wanted to use AES in CTR mode with random IVs. Since the plaintext the AES encrypts does not matter, I figured I just used my initial starting IV to be encrypted with the AES itself. As a passphrase I have a user's password in plaintext.

CCBox._user.masterkey = CryptoJS.AES.encrypt(CCCBox._user.serial, CCCBox._user.password ,
                                {
                                    iv: CCCBox._user.serial,
                                    mode: CryptoJS.mode.CTR
                                });

I am using the CryptoJS library. CCCBox is my Javascript class.
Actually I am saving the IV ( the CCCBox._user.serial ) in my database as well, but I would like to change that as well.

The problem is, that whenever I generate the masterkey I do not get the same key twice. What way is there around so that I can allow a user to generate its own masterkey everytime without saving it in my database ?

All the best,
Richard

If I understood your question correctly, you're trying to generate an AES key using AES and the user password as a key, then use that key to encrypt an RSA key.

Granted, AES will give you a very indistinguishable ciphertext that you can use as an encryption key if you wanted. But AES isn't really a password-based key derivation function, mainly because it's pretty damn fast.

What you're looking for is PBKDF2. You can feed it the user's password, and as long as you feed it the same parameters, it will give you the same fixed-length key. You can use that key for your encryption and later decryption. So you'd end up with something like this:

Enrypted_RSA_Key = AES-CTR(RSA_KEY, PBKDF2(USER_PASSWORD))


Captive Portal Security Measures I am currently working on a Captive Portal solution, which can be distributed in an device that has an ethernet and wlan port. In short, I use iptables to restrict access to all devices unless they were previously added to the table via MAC address. A website is hosted on the same machine, which uses a Node JS process to add the device MAC address to the tables once the user accepts terms and conditions.

I know for people with adequate knowledge it's not hard to grab someone's MAC address that's already authenticated and spoof it to access the network. What are some security measures to prevent this from happening and is there anything else I should consider.

Ps.: this is not in production at this stage and since it's designed to cover free wireless AP's.

Depending on how your wireless network is set up if you could detect the same MAC on different access points communicating at the same time then it could be spoofed.

If this is detected you could then try and re-authenticate the user, but as soon as the legitimate user authenticates the malicious spoofer will be granted access again. It might be annoying to the user if they happen to be on a coverage boundary between two APs and is flipping between them.

You could also look at other identifiers such as differing TTL values on packets etc to try and identify the legitimate user but it gets involved. How much do you really care?

If you really don't want people to spoof their way on to a network perhaps look at username and password protection using EAP and a RADIUS server, but delivering credentials to the user in the first place is an additional step in the on-boarding process.


It appears that your server is the target of an automated attack involving the ZmEu scanner.

That first request appears to be from another automated attack involving the Morfeus Scanner.

That last request appears to be an attempt to exploit vulnerabilities in the Home Network Administration Protocol (HNAP) implementations of D-Link routers. More information about the attack can be found here.

From a cusory glance at the request it's making, I'd say you have nothing to worry about if you aren't running phpmyadmin on your systems. Such attacks are commonplace for servers connected to the internet and the scans are getting 404's indicating that your server does not have what they are looking for.


A faster method than Blind SQL Injection? Blind SQL Injection is based on TRUE/FALSE tests. Here is an example:

is first letter A? --> NO
is first letter B? --> YES
is second letter A? --> NO
...
is last letter X? --> YES

It's not a fast method. Do you know something better to guess the word from the database faster?

Your approach to this problem is very bad. You are trying to find letters in the linear time complexity: O(n). Comparing letters, one after the other. It means, that in the pessimistic model you have to check the whole alphabet. Let’s assume that your alphabet consists of only lower-case letters: {a,z}, and your password is zzz. You will have 26 tries to find the first letter, 26 tries to find the second letter and 26 tries to find the last one.

As it was mentioned above, you can speed up this process. Please notice, that the order of letters in the alphabet is always the same (letters are sorted). You can use binary search with O(log(n)) time complexity. This method is used by most people. However, you can speed it up too.

If we know, that the searching password is the dictionary-word, we could use linguistic analysis to build our blind sql injection tries. We could use our knowledge about the frequency of letters in text (for example, the most frequent letter in English is ‘e’). We could also use the knowledge: what’s the probability that after letter X, letter Y occurs. We could also try to guess how many letters X are in our word. In this approach regular expressions can help us a lot. We define the range of characters that will be matched by LIKE (for MSSQL) or REGEXP (for MySQL) functions. Pretty nice explanation about regular expression in sql injection attacks could be find here: http://www.ihteam.net/papers/blind-sqli-regexp-attack.pdf


Is password entry being recorded on camera a realistic concern? I live in a city where CCTV camera coverage is comprehensive and increasing. Cameras are getting cheaper and higher resolution. Everyone has a video camera in their pocket already, and we are starting to see trends which indicate always-on cameras may become commonplace in other devices like glasses.

It has occurred to me, when out in public and entering my username/password into apps on my phone and laptop, that if a camera could capture both my screen and my keyboard, it could be fairly straightforward for a viewer to grab or guess my credentials from the footage assuming a high enough resolution image and the view not being (too) obscured.

Without going too much into the details of how it would be implemented, the accuracy and cost etc, I have a background in image processing and so am also aware that this would likely be automatable to at least some degree.

So I thought I would ask the community here if this is actually a viable risk? Have there been any known instances of it happening already? Are people thinking about this with respect to the viability of plaintext credential entry into apps in the long run?

Lots of examples. A high-profile and recent example is when Kanye was caught on camera entering his "00000" password to unlock his device.

Shoulder-surfing is one reason why applications do not display the password text on the screen, but show ****** instead.

And this is one reason why multi-factor authentication is so important; even if you know the password, you cannot use it without another factor.

I have even seen viable research into capturing the sound of the keyboard when a user types the password, even over the computer's microphone.

So, yes, you describe a viable risk that the industry has been addressing for a long time. The specifics of high-res cameras is just not a significant enough of a new factor to consider. Shoulder-surfing and keyloggers are a current risk.

The industry knows that it needs to develop something better than passwords, and there are many active attempts to do so, but nothing is mature or stable enough yet.


A doubt in certificate chain validation and revocation checking So when i do a tls handshake with the server, it responds with a cert chain which the browser verifies and which ends at a trusted root CA. In this the browser checks if the cert presented by the server is valid or it has expired/revoked.

So my question is , is this done for each cert in the chain ? or just the leaf ? . Also, how does OS impact the behavior of the browser. I read somewhere that in case of EV certificates, OS settings are overriden, while the os can for revocation checking in other cases.  I want a bit detailed understanding of how the chain is validated and what exactly does the CA bundle contain ?

The theory of X.509 is that revocation checks should occur on all certificates -- not only all certificates in the chain, but also for any extra certificate which was needed to validate the revocation information (CRL, OCSP response...), recursively.

Of course, theory and practice match perfectly only in theory. Some systems (browsers, OS...) will do not check at all. Some will check only the leaf. Some will check revocation status for all certificates in the chain (but not for extra certificates, if these happen to be used). Moreover, the systems differ in their behaviour when revocation status cannot be obtained (e.g. CRL download fails, or no CRL/OCSP URL can be located). Moreover, such behaviour also depends on whether the certificate is supposed to be "EV" or not: EV certificates are called such because they result from agreements between CA and browser vendors; browsers display them with a specific graphic code (which supposedly increases user's confidence and trust) on the basis that they also enforce stricter checks, including a whole-chain revocation status check.

See this page for a discussion of issues and solutions about revocation status checks in the Mozilla family of browsers (i.e. Firefox).

Also, remember that revocation status check is, ultimately, a damage containment feature: when a private key is stolen, and the theft is discovered, then the CA can enforce through revocation an "early expiration", which shortens the time window during which the key thief can leverage his indelicacy. In practice, you would be hard pressed to find an actual case where revocation saved the day. As Peter Gutmann says, stricter revocation checks don't actually prevent anything that attackers really do on non-EV certificates (as observed in the wild).

Even when private keys are actually stolen (this does not happen often), the asynchronism which is inherent to revocation handling means that attackers get at least a few hours of free access. The core point is that revocation is reactive: regardless on how often you issue CRL or update OCSP servers, revocation may occur only after the key theft has been discovered and reported to the CA. In practice, when a private key is stolen and used by attackers, the theft is detected because the attackers have setup a fake site which uses the stolen key.


How to check for a key *and* store encrypted data? I wish to create a system wherein I store encrypted data.

Users can access this data if they have the key. If they give a wrong key, they don't get access at all. If they give the right key, they get the data, and they may modify that data.

One idea I came up with is to store the bcrypt of the key, a salt, and AES-encrypted data using a PBKDF2 with the salt, and a high iteration number.

Getting the data would follow this process:

Get the key from the user.
Get the bcrypt of that key.
If the bcrypt doesn't match, deny access.
Get the PBKDF2 of the key with the salt.
Use that PBKDF2 to decrypt the data.
Give the data to the user through a secure channel (beyond this design).

The system should make it hard to get the data, even if you have access to the raw, encrypted, data.

My design seems to achieve that goal, but I have differential cryptanalysis concerns around the fact that the key is both encrypted with bcrypt and with a PBKDF2 encrypting AES. Could cross-referencing the bcrypt and the raw, AES-encrypted data make it easier to break the key? Are there known issues with this kind of designs?

Is there a simpler way?

Obviously I can't get rid of the bcrypt part, because any key would decrypt the AES data (although the result would be gibberish). I can't use bcrypt as the key for AES, because the key would be stored along with the encrypted data, which defeats the purpose of encrypting.

Why don't you use Authenticated Encryption? If user gives right key, encryption succeeds and you can return data to the user. If key is wrong, encryption fails and you won't give the data.

Look at solution used in TrueCrypt. User's password is stored nowhere in encrypted container. It is verified by decrypting of TC volume header and verifying some data after decryption. More details here: Encryption Scheme

Solution used in TrueCrypt is not an Authentication Encryption, but it shows well that you don't have to store user key/password to know if password entered is correct.


Who initiates an authorization code flow? I'd like to understand OAuth 2.0 in more detail and especially the authorization code flow. This might be nit-picking but according to RFC6749 the client initiates the flow.

(A) The client initiates the flow by directing the resource owner's
user-agent to the authorization endpoint.

But isn't it really the resource owner who initiates the flow by clicking a button like Connect with service xyz or Import photos from abc on the client application site when requesting authorization?
I mean it's this button click that sends out a HTTP GET originating from the resource owners machine/IP, right?
GET https://www.auth-server.com/oauth2/authorize?

client_id=18f4ad63-01fa-41ae-b632-092a8f5d340b&
redirect_uri=https://www.awesome-printservice.com/callback&
scope=openid photos.read
response_type=code&
response_mode=query&
nonce=ugasq9v1bq&

Consider the example of signing into your site (https://example.net) via your Google account.
In this case, you [and, by extension, your digital "user agent": Firefox or Chrome] are the "resource owner"; ExampleNET is the "client" (and also the "relying party").
The client, ExampleNET, initiates the flow by directing you, the resource owner, to emit that HTTP request you described.
Sounds weird? Look closer at that request.
See the nonce field? That had to be prepared by the client. More significantly (though missing from your example), in the same vein is the state field: also prepared by the client as they prepare to initiate the flow by [re]directing the resource owner to that big URL.
Now, they may or may not have "warmed the flow up" by pre-initializing the nonce (which, if they're using, they should be recording to check it against later), or by quickly generating it when the resource owner expresses intent to use that flow (by e.g., loading the Login page), and they may have done this in response to activity from you which clearly signaled intent to start that flow (such as e.g. clicking the Sign In Via Google link...)
but they're still the ones initiating the flow by giving you the (potentially ephemeral) necessaries to take the—from the resource owner's point-of-view—"first" step of the login flow. That's why the client is described as initiating it here.


What to do about email threats containing leaked passwords? A few days ago I got an email from a hacker supposedly using an email of mine (he was using the same email address TO and FROM) from my own email domain, and had a part of a password I use to purchase items with this particular email but not the one associated with the email server at HostGator, and threatening me with bogus claims and demanding a ransom.

I used haveibeenpwned and resulted in 7 sites (i.e. Linkedin hacks) and 1 paste. I read your sites answers and Troy's info but do not understand how to proceed. I am a small biz man and not a coder.

This is a known scam. The scammers look up emails and cracked passwords in public leaks of site databases and then send an extortion email to people. The password is already out in the open, sorry. You should change the passwords on all sites using that password. On the up-side, this does mean that the person who is emailing you is not actually a hacker and does not have any malware on your system.

You should use a password manager to prevent this from being an issue in the future.


Is it possible to tell if two ssh users are the same, based on the keys they use? If a user has an account on an SSH server with a certain public key in its authorized_keys file, and an account on another SSH server B with the same public key in its authorized_keys file, can a third party figure out that these two accounts belong to the same individual?

In this scenario the third party is does not have an account or any sort of access to the servers.

Yes. Public and private keys are linked in such a way that a certain public key belongs to a certain private key. So if you see two identical public keys you would know that they match to one private key, which likely belongs to one individual.


How could a system be zero-knowledge? I'm actually interested about zero-knowledge storage system. Those system where the storage provider claims he can't have any access to the data stored.

As far I know, the data are encrypted using a symmetric encryption system, such as AES or another, But those systems need a key to function.

So what happens to the key? Is it stored? Where? If a user connects from another location, and wants to retrieve one of his files, he must retrieve the key first. So if the storage provider stores the key too, he could have access to the encrypted data. It's like having a chest locked and the code on a paper next to the chest, and then claiming that you couldn't open the chest.

So is there a flaw in that? I'm I mistaking completely about those zero-knowledge system?
If they can finally open the file, how some of them could escape justice by saying "We can not know that we are hosting illegal files?"

In the simplest models for symmetric (reversible) encryption, you just need a decryption key - which can be as simple as a common password.

For the system to be zero-knowledge, the encryption must be done on the client's system and ONLY encrypted information passed to storage provider. This way the storage provider technically has the data stored, yet it has no way to access the clear text (human-readable un-encrypted version) because it doesn't have the key.

Note that in the old-days, we did this with simple FTP and "password protected ZIP files".

The weakness of this system is then that if the decryption key is just a common password then the storage provider (or anyone that intercepts the data) could trivially brute-force crack it and get the clear-text.

So, to make this system even more safe and robust, usually a public-private key system is used, again with the client's private key always being left on the client and NEVER given to the storage provider. Any storage provider that accepts or can access the decryption key is not zero-knowledge, by definition.

As you point out, this could be inconvenient - if I store information with the provider and want to access it at home, I have to manage the key myself. Many tools exist for this, from "keyrings" to secure USB dongle's to biometric storage devices with TPM chips, etc. But yes, you have to carry the key around with you or store it on some other provider's server, with all the potential dangers and inconvenience that has.

The simplest way to understand the systems is just to compare them to a keyed safe. You put in things you don't want anyone to touch, and you lock the safe. You give the safe to a storage company, and then you have the security of knowing the storage company only has access to your safe - not it's contents. If you also have the storage company store the keys to the safe, well then obviously they could trivially access it anytime they want.

The price of security and privacy is very often inconvenience - sometimes tremendous inconvenience. You just have to decide if what you gain is worth the price you must pay in time and potential insecurity (if you lose your key that data is pretty much gone forever, no one can get it back for you).


GSM encryption suppression The following papers explain that it is possible to suppress the encryption (or downgrade) in GSM using faked messages:

https://pdfs.semanticscholar.org/3a86/4f867aadaea449623ddbf288c18815e7eb00.pdf
https://www.researchgate.net/publication/283723257_Investigating_Vulnerabilities_in_GSM_Security

The main problem seems, that the messages, which are used to determine which encryption protocols are supported, are not integrity protected so an attacker can modify them.

I am just wondering how you would realize that? Do I have to drop the message which comes from the base station (is that even possible?) or can I impersonate the user and send a message to the base station that indicates that I am only supporting A5/1 ?
How would you guys realize that? Using osmocomBB or are there other ways?

This concept is used in the IMSI catchers you have heard about law enforcement using.

They spoof cellphone towers and cause all the phones in their range to register with them.

They also downgrade the encryption so they can retrieve text and voice in addition to the metadata.

The best example that  talked about the details was shown at DEFCON.

Hacker Spoofs Cell Phone Tower to Intercept Calls

Here is a Google search that talks to this issue:

https://www.google.com/search?q=defcon+fake+cell+site+gsm+downgrade


Blockchain + shared unused bandwidth as the proxy front = ddos mitigated? Pentesting the new webapp that we have developed before having an external source have a go at it and give us a risk assessment. Now we have come to the portion right at the end; DDOS.

For the most part guides outlining best practices have been followed at an attempt to mitigate DDOS with some rules in our proxy layer before hitting our webapp. The question is not based around that though.

Reading up online I have come across some readings stating that blockchain could potentially solve the DDOS problem. I struggle to understand how. The whole problem behind DDOS as I understand it is that there is always a single point of failure. Even with the Filters in front you are just moving that point to the whatever is the Filter instead of your webapp - the attack just has a different physical destination - and while your webapp may never be touched, your proxy will and that's just as good. So the current solution to DDOS is throwing money at the problem in forms of big infrastructure?

If I think about it - would they use block chain as the underlying mechanism to build a system to co-ordinate a peer to peer sharing of bandwidth( some articles mentioned Gladius company, though not sure if this is what they are going after)
where subscribed users share their unused bandwidth(i.e. when at work) and basically you place this system as a fallback proxy when under attack to route traffic to your webapp trying to throttle any traffic with bad indicators attached to them under some defined rules. This does not change the solution to a DDOS attack but rather the execution as you are no longer renting hardware from a big company but getting the hardware needed from a pooled source on demand - so community driven to lower the cost of the solution making it open to medium businesses as well instead of only massive ones?

Is this what is meant by using block chain to fight DDOS attacks? If no, why and what is meant? If yes, are there technical docs I may read? I am not clued up on block chain at all and probably do not know which key words to search for such docs.

Thanks.

I can't speak about the security of private blockchains, because, frankly, I do not believe in private blockchain solutions. I can, however, speak about my experience with public blockchains and why I believe in the security they can provide.

Utilizing a public blockchain, like the one we leverage at our company- in this case I am referring to the Ethereum mainnet- does not necessarily solve the DDoS problem or prevent heavy request load from bogging down the network. Rather, it makes launching DDoS, or even DoS attacks, extremely costly to the attacker because in order to write to the blockchain, one must pay gas, which is essentially a POST request fee.

It is also very difficult to launch a DDoS attack due to the decentralized nature of the network. The nodes are scattered around allowing requests to the network to be handled by hundreds or thousands of points rather than one, central point of failure. As it may be possible to take down a collection of network nodes, the other nodes in the network will still able to handle requests, though perhaps maybe be responding at a slower rate.

With regards to pentesting a web-app that utilizes smart contracts or a blockchain back-end, the server hosting the web-app front-end resources (or using something like s3 to host static pages) will still need to utilize traditional systems, and will therefore not be protected by a blockchain at all, requiring the company to rely on traditional DDoS protections. The blockchain back-end, however, will still be accessible via some gateway for whatever duration the web-app remains offline. The exception to this would be if the web-app was able to host its files and resources using additional distributed technologies (e.g. IPFS). Thus, making the web-app truly decentralized and more resistant to attacks.

Please don't misunderstand me, it is very possible to DDoS a public blockchain, though it is difficult and extremely costly. There have been a few cases of this happening in the history of Ethereum, yet these attacks have not prevented the consensus algorithm from working correctly, nor has it prevented access to the network resources (e.g. accessing smart contract functionality, stored data). What these attacks have done is significantly increase the time it takes for transactions to be validated, thus encouraging Ethereum users to add higher gas fees to their transactions in hopes of getting their transactions mined in a more timely fashion.


Why isn't there a certificate revocation request standard? Say I am building a Certificate Authority software and I want to automate certificate revocation as much as possible. I know it will not be possible in some cases, like if the building where the certificate, keys and other support documents were burned down to the ground.

But there are many cases where automation would help:

A typo was made in the name
A subject alt name is missing
The key was compromised

In those cases where the key is still available, I could issue a signed "certificate revocation request". Of course, a bad guy could issue the same request, but this is what we want in the end.

But there is no standard revocation request. RFC 5280, section 3.5 says this at item (f):

  revocation request:  An authorized person advises a CA of an abnormal
  situation requiring certificate revocation.

Was this hypothetical standard revocation request left out of the standard because of a security issue, or was it and oversight, not a design goal, etc.?

There is a standard for that, and, more generally, for all communications with a PKI. It is called Certificate Management Protocol (CMP). Revocation requests are specified in section 5.3.9.

Now, finding a PKI that actually implements CMP... this may be challenging.


Shutdown: Clear virtual memory pagefile I was reading about Windows Local Policy of "Shutdown: Clear virtual memory pagefile". I need some clarification on this brief policy description:

What do it mean by operating system that allow booting to the other.
Why OS has to make sure that the system pagefile is wiped clean when its shuts down.
How can a unauthorized user can  get direct access to the pagefile.

“Systems that are configured to allow booting to other operating systems” encompass two situations:

A computer with dual boot between two operating systems (e.g. Windows 2003 and Windows 8, or Windows 2003 and Linux) where the two operating systems have different user databases, and in particular different groups of people have administrative access. An administrator on OS 1 can read the swap from OS 2. This is of limited impact as the administrator on OS 1 can also read the data from OS 2, but it does mean that data which was accessed from OS 2 and never explicitly saved to disk is at risk.
A computer (typically a laptop) which is stolen by an attacker while powered off, or a computer whose hard disk is stolen by an attacker. The attacker has access to the storage medium unfettered so can read all the data on the disk.

Wiping the swap area on shutdown ensures that any data that wasn't explicitly saved to disk, will be properly erased after a clean shutdown. Data can end up on the disk implicitly due to swapping. Note that in practice, data can end up on disk for other reasons due to application design, e.g. temporary files, print and mail spools, browser cache, …

Wiping the swap on clean shutdown is of limited impact, because in some scenarios (e.g. attacker stealing a running laptop) you cannot rely on a clean shutdown. Some Linux distributions encrypt the swap area with a random key which changes at each boot (I have no idea if Windows can do this). This doesn't protect against warm boot attacks where the attacker can dump the content of the RAM, nor against sensitive data left in files.


Why do people check the passport on key signing events? I find the common procedure of key signing parties a little awkward:

Person A presents the passport and a fingerprint "This is my key!". Person B checks the passports and decides a level of trust to sign the key at home.

Now the only thing person B can really confirm is that person A was present (based on trusting the passport) claiming that the printed key is his/hers.
The only mapping to the key is by name though - which might not even be unique.

In fact person A could have looked up someone that has the same name and payed him/her to go to that key signing instead. Unless the key has a photo id (very few have) no one would notice. Maybe not very likely or even an attack vector but an example to show the problem.

The only way to confirm that person A has access to the private key is for her/him to sign something. Yet signing (or even just bringing keys) is usually not permitted/wanted on most key signing events.

But wouldn't that make much more sense?
No trust delegation to a passport.
No visual matching to a photo.
What am I missing?

Would you consider the common procedure more secure than signing on the spot? Can you imagine a better alternative to the common procedure?

Key signing parties are, indeed, kind of useless if it's between people who have never encountered each-other before. Unless you're an expert at recognizing forged documents, you would never be able to tell a real passport from a well-done fake passport (or, worse, a real laminated ID from a fake laminated ID, if it's from another state of province). Also, it's in the human nature to act agreeable when dealing with other humans, so nobody is going to poke at an ID trying to see if it's a fake or a real thing. The shut-in human nerd you'll be dealing with will just smile, say something like "yeah, it looks like an ID" and agree sign your key -- all while feeling super awkward and embarrassed.

The OpenPGP standard actually has a mechanism to indicate how much effort you've put into verifying someone's identity. If you run gpg with --ask-cert-level when signing a key, it will offer you a way to indicate how much identity validation you've done, from "none at all" to "very extensive verification." This option is off by default because extremely few people use it correctly, so it's pretty meaningless these days.

Meaningful keysigning parties do not involve passports or any other kind of identification documents, because they happen between people who know each other from previous engagements. For example, when someone like Linus Torvalds signs a key belonging to another Linux kernel developer, he does not do it to indicate that "this is Dirk Hohndel because I checked his government-issued ID," but to say "this key belongs to a person whom I know as Dirk Hohndel." It is not important to other Linux kernel developers under which name Dirk files his taxes -- all they really want to know is that "this is the same Dirk who works with Linus Torvalds."

So, if you're attending a keysigning party where nobody knows each-other, just leave -- any key signatures obtained at such events will have very little value.


Is Google Analytics HIPAA compliant? How can I find out? I'd really like to implement Google Analytics at my work on web software that is required to be HIPAA compliant. But I'm wondering if it's against the rules. Does anyone know how I can find out? I've searched Google, but there isn't much there on the subject. In the mean time I'm going to be reading up on HIPAA Privacy.

Our system is used to manage healthcare documents and PDFs.  There's no specific patient information, but there is information relating to certain plans to a specific client/company might have.  All we would like to do with Analytics is determine the browsers using our system, what documents are most frequently used and what times of the day we're the busiest.  We have no intention of collecting any other information.

We would probably end up using custom event reporting as well.

Update: I'm going to do some more research, but wanted to post this link which was extremely helpful: http://www.hipaa.com/2009/09/hipaa-protected-health-information-what-does-phi-include/

My Solution:

Since I only need to track custom events and basic user activity/browser data.  What I ended up doing is embedding an iframe on the page

<iframe id="analyticsFrame" name="analyticsFrame" src="/analytics.htm" border="0" height="0" width="0"></iframe>

Source of analytics.htm:

<script type="text/javascript">
    //keep analytics going gaining access to the top window
    var top = null,
        parent = null;
</script>
<script type="text/javascript" async="" src="https://ssl.google-analytics.com/ga.js"></script>
<script type="text/javascript">
  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-xxxxxxxx-xx']);
  _gaq.push(['_setDomainName', 'domain.com']);
  _gaq.push(['_trackPageview']);

  (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[1]; s.parentNode.insertBefore(ga, s);
  })();

</script>

Then I used a custom event recording function...

// see http://code.google.com/apis/analytics/docs/tracking/eventTrackerGuide.html for documentation
function trackEvent (eventType, action, label) {
    if (document.getElementById('analyticsFrame')) {
        self.frames['analyticsFrame']._gaq.push(['_trackEvent', eventType, action, label]);
    }
}

The whole idea is to try to lock GA out of the main window, limiting it to within the iframe so it can still gather data on users, but nothing related to the content.  Then I record whatever events I want to record.

If your ePHI is shared with Google, then you need to have a Business Associates Agreement with them. Google will probably not sign a BAA with you, so that is probably not an option. The only option that remains is not to share any ePHI with them.

It is hard to tell, from your question, whether you are sharing ePHI with them or not. I am not entirely sure, but merely having health insurance might be considered ePHI, which means if your "client/company" can ever be mapped to a person, then it might be considered ePHI. I will assume that you have ePHI in your content for the rest of my answer. If you cannot be sure you do not have ePHI in your content, you should assume that you are covered until you can prove otherwise. This basic question "is it HIPAA covered or not" is the real issue here. Shameless plug: this issue covered carefully in O'Reillys Meaningful Use and Beyond which I wrote (look in chapter 12 does HIPAA cover me?). Because you cannot get a BAA with Google, you must not share, or practically speaking, be in danger of sharing, ePHI with them. If I was your lawyer (and I am both IANAL and IANYL) then I would be concerned that you start using a service like Google Analytics in a channel that does not have ePHI today, and do not re-evaluate that use even after that channel gets ePHI. Make good decisions for what you are doing, and for what you will be doing.

But there is probably a workaround. All you have to do is be sure you are not sharing PHI, and apparently, all you want is to collect data regarding information that is not HIPAA covered (I am assuming that the documents that you are talking about are publicly available non-client specific documents).

To accomplish this, create an hidden iframe in each page of the site that might contain PHI. Inside that iframe, load a document that does nothing except launch google analytics. Ensure that you do not follow googles instructions on making iframe google analytics work "properly". This will allow you to gather brower data on all of your users on every page, without tracking the pages they load or the content of those pages. To Google it should look like you are loading the same page, again and again. Then, assuming you have a single "general documents page" that links to the documents, but contains no ePHI, you can also include the analytics code on that page. This should tell you what document links are being clicked.

Essentially, without knowing how your site is constructed, this is one guess about how you could create a "analytics zone" on your site that would ensure you never made a PHI mistake. I may be wrong about how your site is constructed, but given any reasonable architecture, there may be a way to get this "zone" effect without screwing things up totally.


What are the implications of NSA surveillance on the average internet user? It would appear as though the tinfoil hat-wearing were vindicated today, as news broke of the true scale of the U.S. government's surveillance of its citizens' online activities, conducted primarily through the NSA and seemingly beyond the realm of the law.

If the reports are to be believed, metadata about virtually every aspect of individuals' lives - phone records and geographic data, emails, web application login times and locations, credit card transactions - are being aggregated and subjected to 'big data' analysis.

The potential for abuse, especially in light of the recent IRS scandal and AP leak investigation, appears unlimited.

Knowing this, what steps can ordinary individuals take to safeguard themselves against the collection, and exposure, of such sensitive personal information?

I would start with greater adoption of PGP for emails, open source alternatives to web applications, and the use of VPNs. Are there any other (or better) steps that can be taken to minimize one's exposure to the surveillance dragnet?

Foreword: This problem isn't necessarily about governments. At the most general level, it's about online services giving their data about you (willingly or accidentally) to any third party. For the purposes of readability, I'll use the term "government" here, but understand that it could instead be replaced with any institution that a service provider has a compelling reason to cooperate with (or any institution the service could become totally compromised by -- the implications are reasonably similar). The advice below is generalizable to any case in which you want to use an external service while maintaining confidentiality against anyone who may have access to that service's data.

Now, to address the question itself:

  ...what steps can ordinary individuals take to safeguard themselves against the collection, and exposure, of such sensitive personal information?

If you don't want the government of any nation to have access to your data, don't put it on a data-storage service that might possibly collude with a government agency of that nation.

For our model, let's assume that some government has access to your data stored on particular major services at rest (as well as their server logs, possibly). If you're dealing with a service that does storage (Google Drive, email) then SSL will do absolutely nothing to help you: maybe a surveillance effort against you cannot see what you're storing as you're sending it over the wire, but they can see what you've stored once you've stored it.

Presumably, such a government could have access to the same data about you that Google or Microsoft or Apple has. Therefore, the problem of keeping information secret from surveillance reduces to the problem of keeping it secret from the service provider itself (i.e., Google, MS, Apple, etc.). Practically, I might offer the specific tips to reduce your risk of data exposure:

If there's some persistent information (i.e., a document) you don't want some government to see, don't let your service provider see it either. That means either use a service you absolutely trust (i.e., an installation of FengOffice or EtherPad that's running off your SheevaPlug at home (provided you trust the physical security of your home, of course)) or use encryption at rest -- i.e., encrypt your documents with a strong cipher before you send them to Google Drive (I might personally recommend AES, but see the discussion below in the comments).

In fact, this second strategy is exactly how "host-proof" Web applications work (also called "zero-knowledge" applications, but unrelated to the concept of zero-knowledge proofs). The server holds only encrypted data, and the client does encryption and decryption to read and write to the server.

For personal information that you don't need persistent access to, like your search history, you can probably prevent that information from being linked back to you personally by confusing the point of origin for each search using a VPN or onion routing like Tor.

I'm reminded of this xkcd:

:

Once a service has your data, it's impossible to control what that service does with it (or how well that service defends it). If you want control of your data, don't give it away. If you want to keep a secret, don't tell it to anyone. So long as the possibility of surveillance collusion or data compromise against a service is non-trivially high, do not expect your externally-stored data to be private from inspection by any government, even if you had expected that data to be generally private.

A separate question is whether there will be any significant actual impact to the average internet user from such information-gathering programs. It's impossible to say, at least in part because it's impossible to transparently audit the behavior of people involved in a secret information-collection program. In fact, there could be impact from such a program that would be impossible for the general public to recognize as impact from such a program.

In the case of NSA in particular, NSA is chartered to deal with foreign surveillance, so U.S. citizens are not generally targets for analysis, unless perhaps they happen to have a foreign national nearby in their social graph. The NSA publicly makes an effort not to collect information about U.S. citizens (though the degree to which this is followed in practice is impossible to verify, as discussed above).


Should I regenerate SSL certificates after upgrading Openssl As you may already know old Openssl versions were vulnerable(OpenSSL 1.0.1 through 1.0.1f (inclusive)) by the HeartBleed vulnerability. Currently our server is running Tomcat7 which is built in a vulnerable Openssl, so we upgraded into Tomcat8 but we didn't regenerate the SSL certificates.

So my question is I wonder if we should regenerate the SSL certificates with the new installed version Openssl, to avoid the Heartbleed vulnerability and may be performance issues with Tomcat?

Heartbleed is a vulnerability in the OpenSSL library, specifically how it handles the Heartbeat Extension. It is completely unrelated to certificate generation. A certificate can't be vulnerable to Heartbleed, only the OpenSSL library version.

That said, if your certificate and its associated private key was deployed on a server, which had a Heartbleed-vulnerable OpenSSL version deployed, it may be possible that your private key got leaked. In this case, I would recommend you to do the following steps:

Revoke the certificate. This shows that you can no longer be reasonably certain that your private key is actually private.
Generate a new private key and certificate. Take this chance to ensure that the parameters you picked for the certificate are up-to-date as well.


Which resources can help me learn how to use metasploit? I tried google search but I can't find good resources to learn how to use the metasploit framework.

Where would you suggest a beginner go to learn about using metasploit?

Yes, there is, it's called metasploit unleashed.

It is an official metasploit wiki with lots of information. It is structured kind of as a tutorial/course, and it gets upgraded and updated regularly. It is probably the best place to start.


Securing Diskless Clients from Data Leakage I am experimenting with securing diskless clients booting both RHEL 6.5 and Windows 7 via PXE (and iPXE in the future) from iSCSI targets. These computers run only on an internal network and are disconnected from the Internet so the only way for data to be taken without authorization would be for a user to bring in a hard drive, connect it, and transfer the data.

I know that I can mitigate this to some degree by disabling the SATA and USB ports in the BIOS and setting up a BIOS password. However, the BIOS settings can be reset via the jumper. The only option I can think of that could prevent this threat would be through the destruction of the ports themselves, perhaps through the use of something like super glue.

Do I have any other options, that would not cause physical damage, to prevent data from being transferred via a drive that someone brought in and connected?

For RHEL, you should be able to create a custom kernel with support for SATA/ATA and USB mass storage disabled.  If the kernel won't recognize the devices, the user can't access them.


Best practices for storing credentials used by code Currently, I've many scripts that need to log in as superuser to automate many tasks. (For example, creating tables in databases, creating other users, etc.)

Instead of having the credentials (especially the passwords) stored directly in the script, I'm reading them from a file (call it pwds.txt), which can be accessed only by root user.

Some of my colleagues say that a more secure approach is to have the password encrypted in pswds.txt, hide the key somewhere and decrypt the encrypted data in the script before I use it.

I claim that it just reduces the problem into finding where key is located, which doesn't seem hard at all to and adversary that can read the script. I think that this process just complicates the programming without actually providing any real layer of protection.

Two questions:

Who is more correct, me or them? (and why)
I know that 100% security doesn't exist, but what are the best practices for my problem?

1) You are 100% correct, Why? If machine gets compromised the attacker will be still able to retrieve the decryption key as it's necessary to be symmetric encryption to decrypt by app and the key file has to have same read permissions as the app so the app can read it.

I mean app still needs to have hardcoded secret decrypt key directory in it so attacker just looks for it :D , even if app is an binary executable
attacker can easily dump strings of file directories and files from it.

I know because I did it from an Go language program that I needed to debug and I didn't have source code (one of clients app hosted on server) :)

Buffer overflow and so on attacks will function if hole is present as
app ether ways stores data in memory to reuse for example for database auth.

2) The best solution is to have a central vault where each app requests its secrets and leases them. One solution of this kind is https://www.vaultproject.io/ and more details on it https://www.vaultproject.io/docs/internals/architecture.html

Best general practice is to minimise access and control rights of each role for each app resource.
Example:
If an app just uses one database don't give that user rights to view other
or to execute DML on others, remove drop table rights if the app doesn't do migrations, and so on.

If you don't use vault if script is executed by example root user don't store secrets with ownership of less privileged users. Let the owner be the same user, use read, write, execute permissions only what you really need.

Use TLS when you can for your resources as one tcp dump leaks data if attacker manages to get the auth phase however you store the secret data.


How do I prevent this type of SQL injection attack? Our company has been using several tool (Veracode, Appscan, etc) to verify that our applications meet minimum security requirements. I have inherited a legacy application which has several flaws. I've managed to mitigate most of the vulnerabilities, but am having troubles fixing this next one because I simply do not know what it is doing. In our report, it seems that it is changing one of our POST variables to

25%27+having+1%3D1--+

What is this and what is it effectively doing? What can I do to prevented by this type of attack?

When this string is decoded from its url-encoded form it becomes the following:

25' having 1=1--

This string, when placed as is into, for example, the following (PHP) database query function:

mysql_query("SELECT * FROM users WHERE username = '$username'");

Becomes this:

mysql_query("SELECT * FROM users WHERE username = '25' having 1=1--'");

Note here that the %27 (') breaks out of the argument in the WHERE clause and continues the executable part of the statement. The -- after 1=1 makes the rest of the statement a comment which is not executed.

The HAVING statement in SQL is supposed to be used within queries which use the GROUP BY operator, and should fail in queries which do not. My guess here is that this string is being used to check simply for the presence of an unsanitised variable which gets placed into an executed query.

To prevent this type of attack I would suggest using a good input sanitation function, or parameterised queries. The implementation of this depends on the programming environment in question.

Addition: The normal use of 1=1 in SQL injection queries is to cause all rows to be returned, voiding any other WHERE conditions. An example input could be:

a' OR 1=1 --

When inserted as the $password parameter in a query such as:

SELECT * FROM users WHERE username = '$username' AND password = '$password'

The statement becomes:

SELECT * FROM users WHERE username = 'mark' AND password = 'a' OR 1=1 --

The resulting dataset will include all entries in the 'users' table, as 1=1 is always true.


Can I trust Post-Quantum VPN for protection against quantum computers? Should I trust VPN services that provide post-quantum encryption like NewHope for protection against future quantum computers? How can I tell if the connection between me and the VPN is using post-quantum encryption?

It seem a but premature to make a VPN decision based on post quantum protection considerations, at this time.  I think much more important questions would be, company reputation and past actions.  None/few of the major trusted VPN providers, I see have that as a feature and my speculation is that any services using the new crypto is likely still experimental, Microsoft just began looking into it about year and a half ago.

In summary,  I would not use post-Quantum Crypto at the moment, and re-evaluate in the future.

To evaluate traffic from a vpn, you need to review your network traffic.  I would start by looking into wire shark.


Updating Root/Intermediate Certificates over NDES/SCEP In attempts to setup our first instance of NDES/SCEP in the wild on Cisco routers we have run into a concern.

Currently our organization has a three tier PKI. We have an AD CS server on the third tier running NDES. All aspects of the system are functioning, but through discussion and testing we have a concern.

How do Root and Intermediary CA certificates get updated on the end device?

If we have a router configured and functioning with a trusted CA/RA using SCEP, but the issuing CA certificate is nearing expiration will the SCEP service execute the GetCACert command again to refresh the local cache of the issuing certificate?

SCEP RFC (draft-nourse-scep-23)

Thomas Pornin provided an acceptable answer for a similar question at:

Renewing Microsoft Certificate Services Root Certificate


In Open ID Connect, why is the id token a JWT token whereas the access token is not? I know that the access token can be of any format(it is up to the authorization server), but I noticed that most of the times the access token is not a JWT whereas the id token is a JWT. Why is that so? If it is to check the authenticity of id token over non-ssl connections, wouldn't the same be needed on the access tokens?
Thank you.

The id_token contains the claims ("iss","sub","aud","nonce",...) and is a JWT, as per the OIDC Specification : https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse
Access tokens are used as bearer tokens, therefore, the format is not mandated by the OIDC specification.


I want know if a file with php code but without extension name could be exploted? I'm testing a site and I found a file with critical php code but this does not have extension name, my question is it could be exploited for a shell attack or something like?

I don't found nothing about this case.

I have this file in the server.
http://midomain.com/yii

And I have this code.

#!/usr/bin/env php
<?php
/**
 * Yii console bootstrap file.
 *
 * @link http://www.yiiframework.com/
 * @copyright Copyright (c) 2008 Yii Software LLC
 * @license http://www.yiiframework.com/license/
 */

defined('YII_DEBUG') or define('YII_DEBUG', true);

require(__DIR__ . '/vendor/autoload.php');
require(__DIR__ . '/vendor/yiisoft/yii2/Yii.php');

$config = require(__DIR__ . '/config/console.php');

$application = new yii\console\Application($config);
$exitCode = $application->run();
exit($exitCode);

Yes
The presence of #!/usr/bin/env php as the first line means that this is meant to be used from a shell context - not from the web.  When executing from the command line with a line like the above, the extension doesn't matter.  So yes, this can be exploited in an attack.
If you found a file like this on your server and you didn't put it there, I would assume your server is compromised and the file is being actively used by your attacker.  Nuke it from orbit.  This is very different from the sort of malicious PHP scripts you normally see (apparently a hacker decided to build their payload on top of Yii?), but that doesn't change the facts or my advice.
It's worth pointing out that extensions are not really very important.  Windows makes them more important than they need to be, but especially in *nix style systems, the extension is rarely important to the underlying system.  Even in a web-server context a PHP file without a PHP extension might get executed as PHP, depending on the server configuration.  It would take a non-default and less-than-ideal server configuration, but it is entirely possible and not even hard to do.  Not only that, but (h/t Ghedipunk) the application executing for the web server can further invoke shell commands or do anything else it wants.  As a result an attacker with remote-code-execution abilities on your server can certainly execute code wherever they want, however they want, regardless of extension.


Are there any holes in this security design? This design is for transport security between a client and a server. I'm planning on using it for a cloud storage system. I would like it to be secure against you-know-who.

I'm trying to prevent the anyone (like the NSA) from forcing me to hand over my keys to the data, so the goal is for even me not to be able to access it.

Here's how it works:

There are two layers. On the outside there is a layer of RSA-4096 encryption with a permanent encryption/decryption key pair. On the inside there is another layer of RSA-4096 encryption, but it uses a temporary key pair which is not saved anywhere, and can not be turned over. It uses the outside layer to verify the identity of the server, and the inside layer to secure the connection.

Are there any possible holes in this schematic I'm not seeing, besides the fact that if I was forced to turn over the permanent private key, impersonation of the server would be possible, and the temporary keys would be useless? Also, how can I resolve this?

Yes.  The first problem is that you are writing your own crypto protocol.  Please don't do that. Use TLS or SSH instead.

Second, there are many books written about writing secure protocols, and even common problems in protocols.  Your algorithm has them.

Third, you do nothing about out of order traffic, modified messages (you mention encryption but you don't mention integrity checks), your mode of encryption is not defined (and may have problems), your initialization vector is not described (and may have problems), you don't mention compression, you don't do anything about removed messages, you don't track messages from a previous conversation with the same key inserted in this conversation, you don't define how temporary your temporary key is.

Fourth, you are using public key crypto, which is slow.

Fifth, you have no threat model.  Your post originally had no definition of what you're actually trying to achieve (though you've added that in a comment).

And since I'm not really a crypto expert and see all these flaws at a glance, imagine how many flaws there really are that experts would see.

Please don't create a new, flawed protocol.  Use one that already exists for what you want.


Encrypting PHI query params In a bunch of APIs, there are several possible query parameters.  Some of these may be PHI.  So even if we are using HTTPS, they could go to a logfile or somewhere else and hence violate PHI.

Was thinking of an approach where the parameters would be encrypted in the client and then decrypted by the server.  On login, the server would give the client an encryption key and then the client has to use this for query param values.  The server than decrypts the query params using the same encryption key.

I am reluctant to solve a security risk in a way that is not commonly known.

So, I am wondering is the approach I am suggesting used at all? The only other approach would be to use POST and instead of query params, the params come up in  the BODY?

Overall GET is something you would avoid to send query parameters, POST is the way to go.

If you would like to encrypt the messages inside the POST, for they can also easily be logged the same way GET requests are, I would suggest using something like JWE (Json Web Encryption). This is basically a JSON payload encrypted inside a JWT (Json Web Token)
https://tools.ietf.org/html/rfc7516


Encryption of PCI data, and PCI-DSS scoping I read another question which made me think...

If you encrypt PCI data (credit card numbers, etc.) using PGP or AES and send it through a firewall, is that firewall in scope?

Alternatively, what if you only use a data-in-motion security mechanism like SSH or TLS, would that same firewall be in or out of scope?

Perhaps I can add more context.

Sure, our "PCI Area" firewall is in scope, but what if a firewall separates two different Intranets, and the encrypted PCI data (using either method) passes through it to get to another server.  For instance, it passes through our "PCI Area" firewall and our "Intranet 2" firewall to get into Intranet 2.

PCI says that anything that "stores, forwards, or processes" credit card data should be in scope.  Does Intranet 2 firewall do those?  It definitely routes/forwards the data stream, processes the packets, and stores some information in its logs, but I'm not sure if any of those are actually PCI scoped because the information is encrypted.  It's not actually handling any raw PCI data, it's handling encrypted information.

You could make the argument that the encryption is reversable, and therefore could still be PCI, but I'm not clear on where that sits from a QSA's perspective.

I am inclined to treat all networks as PCI, and to layer on additional security mechanisms as I see fit, however I'm trying to figure out priorities should lie for companies that need to be PCI compliant.

Oh.  As per your update...

No.  Firewalls not connected to the CDE are not in scope simply because encrypted PAN data transits them.  If that were the case, the whole freaking Internet would be in scope.

Part of being PCI compliant involves mapping out cardholder data and network topology.  The firewall closest to your CDE is in scope, and if the assessor determines it provides appropriate controls, then it removes outward devices from scope.  You may wish to review Network Segmentation on pages 10-11 of PCI DSS 2.0 and Appendix D.

You also need to watch how scope creeps in - you may want to look at the Open PCI DSS Scoping Toolkit, which isn't official but which reflects the way many QSAs try to break this down.  So if your second firewall only sees encrypted PAN data, it's not in scope, but what if it protects your Windows Active Directory Domain Controller, and your CDE environment uses AD credentials?  Maybe that puts AD in scope.  Maybe that puts the firewalls protecting the AD servers in scope.  It can get tricky, and it can vary by QSA, and from what I've heard scope infection is going to get worse with DSS 3.0.

Old answer (pre-question update):

Yes, it is.  The entirety of PCI DSS Requirement 1 (Install and maintain a firewall configuration to protect cardholder data) is about making sure you've got a firewall in front of your cardholder data environment to protect it, and making sure it's set up and maintained properly.

Encrypting PCI data to send it through the firewall is Requirement 4 (Encrypt transmission of cardholder data across open, public networks).  It's a base requirement, not something you do to try and remove firewalls out of scope.

The encryption protects that data.  The firewalls protect the servers and networks.  PCI DSS require you implement both.


My country is attempting to block WhatsApp, what to do? My country (Brazil) will start a 48 hour block on WhatsApp tomorrow, with cooperation from data (3G/4G) companies, but not home ISP companies (yet).

My question is:

How can I still access and send messages after the block is in effect using 3G/4G, preferably a option that can work either on Android and iPhone, without requiring root ( I need my friends on WhatsApp too, and I don't know anyone with a Jailbreak or Root, so...)?

It appears that the blocking will be at IP level.

Some news on that (in Portuguese): http://www.tecmundo.com.br/whatsapp/91909-whatsapp-bloqueado-brasil-48h-justica-bloqueia.htm

http://g1.globo.com/tecnologia/noticia/2015/12/operadoras-sao-intimadas-bloquear-whatsapp-no-brasil-por-48-horas.html

(English) http://www.demotix.com/news/9316706/justice-brazil-determines-lock-whatsapp-48-hours#media-9316661

Edit : The block is in effect, most of people are using those free VPN apps but that's not really the optimal solution since you can't really trust them(some may even be malicious)...

Edit2 : The ban has been lifted, however I think that if my country really went to extremes to block WhatsApp they could just block all known VPNs and Tor exits (it's trivial those days to scan the entire IPV4 address range) things wouldn't be so easy like that

Note: See updates about WhatsApp man-in-the-middle exploit, potential WhatsApp backdoor which can allow snooping, and article on how the CIA can bypass WhatsApp message encryption by accessing the phones directly below:

How to block:

Generally, this means your country will either block the website/applications IP address Range which will prevent packets from reaching the website or null route the BGP/AS number (blocking these IP's from being routed).

Getting around a blocked IP restriction:

There are MANY ways to do this but generally this means you will want to use a VPN provider in another country or a tool like Tor if either of those are an option.

https://tor.eff.org/

Note: There are many Tor-based web browsers for various phones. These would be a good solution for access to web pages for your phone but this won't secure connections from your phones other apps.

There are many VPN solutions which will work well on mobile devices. In many cases this may be easier to configure if it's not outlawed.

If neither of those are an option (legally or technically) you may want to check and see if the application or website are accessible via IPv6. If there is an IP restriction it may only be blocked on the IPv4 addresses and not the IPv6 addresses so you may be able to connect directly without using any type of encryption or service which is currently outlawed in your country.

Note: It is very important to understand your local laws when doing any of this and likely worth consulting an attorney to make sure you are not unknowingly breaking any laws in the process.

Update: This post by Bruce Schneier about a man-in-the-middle exploit for WhatsApp is very relevant to your question.

https://www.schneier.com/blog/archives/2016/10/is_whatsapp_hac.html

Update2: This post discussing a potential backdoor discovered in WhatsApp which allows snooping of encrypted messages.

https://www.theguardian.com/technology/2017/jan/13/whatsapp-backdoor-allows-snooping-on-encrypted-messages

For additional technical clarity, this post is also useful to read

https://slashcrypto.org/2017/01/13/WhatsApp_backdoor/

Update3: The most recent Wikileaks release of CIA documents shows how the CIA can access the phone to read WhatsApp messages effectively bypassing its encryption. It's likely other governments can do the same thing using the same or similar methods.

https://www.cnet.com/how-to/wikileaks-cia-hack-phone-tv-router-vault-7-year-zero-weeping-angel/


When is an intermediate page needed before directing a user off my primary website? What is the best implementation? The NSA has a page that intercepts  redirections off the primary site.  (click "TLS: "Suite B Cipher Suites for TLS," RFC 5430" for an example).

I've seen this used in Exchange Outlook Web Access (OWA) to prevent information disclosure through the referer: header.

  What type of information would be risky to disclose via a referer: header?

There seems to be two different approaches here: The NSA requires the user to "click off" the site, while OWA allows for HTTP redirection to handle this privacy feature.

  Which is a better approach?  Click to redirect, or HTTP 301/302 redirection

The "automatic" approach seems to lend itself to abuse and possible XSS attacks.

  If a 301/302, or Javascript redirection to an external URL is used, what additional security precautions must be taken place?

What type of information would be risky to disclose via a referrer: header?

Any kind of private or sensitive information shouldn't be exposed to external websites - it all depends on your application. The most common things to consider are:

session IDs (you can sometimes see them in URL params like ?PHPSESSID=....)
user ids / resource ids (they may give a hint to 3rd party on who exactly the user is)
any kind of sensitive tokens like anti CSRF tokens, confirm action tokens, account activation tokens etc.
some sensitive user data e.g. search terms he used on your website.

  Which is a better approach? Click to redirect, or HTTP 301/302 redirection

30x redirect is perfectly fine from the technical point of view as it will lose the Referer header. Consider using a 'click to redirect' if you want to inform your users about the redirection happening.

  If a 301/302, or Javascript redirection to an external URL is used, what additional security precautions must be taken place?

For example, imagine that attacker sets up a phishing site with your site design and a spoofed login form and uses your open redirection to drive users into his website, gathering their logins and passwords. For example, he might send out spam campaign with the URLs pointing to your redirection script. It's a common security vulnerability commonly called open redirection. Click through protection would be better in this regard as the users would be informed about the redirection happening, but it's much much better to have a process of manual/semi-automatic validation of redirect targets so that you can monitor for malicious URLs and block them.

You'll never have a total control over the target URLs as there are many ways for the attackers to hide the malicious content from you, but having a process ready to block unwanted URLs will allow you to develop better filters, blacklist common domains or implement a greylisting feature: for known good URLs a 301 redirect, for known bad - 501, and for all the others - user confirmation. This is what Facebook does more or less.


I wonder if my MacBook Pro with OS X got hacked? Maybe I am getting a little paranoid. Lately my MacBook Pro with Mac OS X 10.8.2 is behaving a little different the usual.

The last strange thing that happend was that in iTerm2 when I tried to sudo I get "XXXX is not in the sudoers file.  This incident will be reported". I just updated iTerm2 after being prompted of an update. On the standard Mac OS X terminal everything works smoothly.

Can it be a rootkit that works on the stock terminal?

Any suggestions?

I assume that you are in the /etc/sudoers file. Therefore, things are working as expected in the stock terminal. Also, it would be weird for a rootkit of any ohter hack to remove you from your own sudoers file; rootkits enable extra accesses to the attacker, but don't disable access to the normal users (if only because functionality breakage attracts attention, exactly the opposite of what a rootkit aims at).

So all symptoms so far point at a bug in iTerm2 (especially since you just updated it), not at an attack.

My guess would be that iTerm2 changed the way it allocates its pseudo terminal. In Unix systems (including MacOS X), command-line utilities must run in a special device called a terminal; it is an input-output device which handles characters but also concepts such as a "terminal size" with a given number of columns and lines. This comes from a time when terminals where really tangible hardware, like that one (I spent many coding hours on a VT220). In less ancient systems, we have graphic cards, millions of pixels and colours, and terminal emulators which are applications like iTerm2 which make believe that there is still a terminal connected to the machine. To do its job, a terminal emulator obtains from the kernel a pair of pseudo terminals: these are two devices (i.e. special files), one which will look like a true terminal to the shell and command-line applications, and the other which offers a backwards view of the former. The terminal emulator translates what it reads from and writes to the second pseudo-terminal into graphical concepts like drawing characters on the screen.

Therefore sudo will run in a pseudo-terminal which was allocated and set up by iTerm2. sudo is known to be picky about terminals; see for instance the requiretty option in the man page. "For security reasons" (an all-time favourite excuse), sudo may require the terminal to be somehow "genuine" and linked to a real session from the operating system. To be compatible with these sudo requirements, terminal emulators must jump through a variety of hoops in a complex ritual dance. I find it possible that the iTerm2 update changed some obscure parameter which sudo now declares heretic, explaining the message.

As investigation steps, try to launch these commands in a standard Terminal and in iTerm2:

id
ls -la `tty`
w

First command will tell you who you are (from the point of view of the machine), second command will show the pseudo-terminal device currently in use, with access rights, and third command shows currently open "sessions" (then again with corresponding terminals). Any discrepancy between the two terminals could point at the proximate cause for your issue.


Hashing request - What type of hash this? I have a text which is hashed using several layers of hashing. The final hash looks like 2E55A1DD65AB839E62362DEF86D329D7. What type of hashing can it be? How can I find out what kind of hash sum I do have in a general way?

This is most likely a hexadecimal representation of a 16 bytes (128 bit) hash output, which can be one of many hash functions, the most popular of them: MD5

But it can be so many other hashes for example md2, md4, Haval, RipeMD etc...

And it can also be some transformation of some other hash function, for example computing a Sha1 hash and taking only first/last 128 bits

If it would have been a popular hash of a popular password with no layering, you could have found it in rainbow tables... But with layering there is no way to tell


Where is the public key of the Certificate authority stored? I'm talking about SSL/TLS certificate authorities. I know that they store their private key on a very secure location. but what about their public key that our browsers use to make sure the signatures are actually signed by the certificate authority we are talking about, where is that public key stored?

Is it possible to edit these public keys thus by having physical access to someone's web browser/computer can an attacker change those public keys to their own public keys and render the CA on that particular computer/web browser useless?

The public key of the CA is stored in the certificate of the CA. And this certificate is stored in the local trust store on the clients system. It is true that an attacker which has access to the local trust store could replace existing CA certificates or add new ones. But if the attacker has this kind of access he can do lot more harm anyway, like replacing the existing software on the system with a similar one having a backdoor or other malicious behavior.

For more information see SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?
.


Ransom-ware nuclear. how did it get into my pc? Got infected, it happened as i was sitting on the PC (Windows 10), i noticed a slow-down and one of the external disks had high activity, upon inspection noticed some files had the .nuclear extension. I immediately pulled the hard-drive out.

I have no hope of recovery, and am not paying the b@st@rds - only lost downloads which i can download again. But just want to work-out how it could have happened?

I had qbitTorrent running for weeks, no issues, no dramas happily progressing. Then i decide to download a youtube vid, went to the keepvid website, type the url, choose the download option, and the file starts downloading.

I walk away to do other stuff, come back 1 hour later to check progress of download, and it appears the PC had re-started. and looks suspicious, antivirus is off, etc. and i notice the slowdown.

I am led to think some popup ad on keepvid website was the culprit, because things started going wrong from that point.

Q. What is the most likely source, qbitTorrent or keepvid?

(i know this is opinion based, but need some expert opinions so we can all learn).

Many ransomware types lie dormant for a while before attacking so that you can't track down where it came from. Also, you may not have initially been infected with this type of ransomware. You may have gotten some other dropper malware and it later pushed out a bunch of different malware to infected computers. Without an in depth forensic analysis of the computer nobody can tell you specifically where it came from.

You want us to tell you an a or b answer but the issue is that it's very likely neither of the two.


Limiting information disclosed by server I host a web application on an Ubuntu 14.04 based VM hosted on Microsoft Azure infrastructure. The webserver is nginx. Recently, someone was trying to probe my server, and later correctly surmised that I was using Microsoft's cloud.

How would they have found this out and how can I mask this information from probers (if at all)?

Note that if I run curl -I http://localhost, it doesn't give away a lot of information since I've turned server tokens off.

It most likely doesn't matter what your server tells the client, the IP address used to communicate with your virtual azure server is owned by Microsoft and most likely labeled as being used for their cloud offering. You have no influence on this, but it is not a security risk either.


Can a school legally access an account that a student logged in to at school? Is this scenario legal,

A school has a few public computers that can be used.  The only browsers that are installed are chrome and internet explorer, and the entire network is man-in-the-middled.  Keylogging records are kept by the school as well.  This school gets the account details of the student in question, and logs into the accounts of the student.  The school gets records of things said at school through a chat.

The school argues that because the student logged into the account on their network(s), that they can legally view what is in the accounts, even if they do not own them.  On top of this, they also say that they have the authority to view the messages because they were sent within the network of the school.

The student claims that the school's actions are illegal.  The account(s) that have been compromised do not belong to the school, and the student says that regardless of what network he accesses them on, they cannot legally obtain and/or use the credentials.

Who is legally correct, the student or the school?  What laws dictate as such, and why? For the purposes of this scenario, assume the school is in the US state of Indiana.

I think the basic idea here is "unauthorized access." If the school accessed a student's non-school account, there can be a case made for the school accessing that account without authorization.

There are a couple things that could negate matters:

The account is a school account - the school is authorized because it is their account
The network access policy included a clause granting the school permission to access accounts that it discovers
The school did not log into the account, but had a record of what was transmitted over its network to the account


Forward Secrecy not supported with referenced browsers? I am running a scan against one of our servers from the Qualys SSL tester site and it says that my server "does not support forward secrecy with the referenced browsers". What exactly does that mean? My server is setup to use ECDHE_RSA_* ciphers which I know do support forward secrecy if negotiated and is recognized on the Qualys scan. Is this a browser issue since it says "referenced browsers".

The «reference browsers» are marked with an R in the table below. What results were you given there? The problem may be on some of them (IE?) not supporting those ECDHE_RSA_* ciphers.


Does it matter if my recovery media is read only? In the past, it was fairly simple to create read only recovery media for a computer: you just made sure to use write once disks. This meant that if you accidentally booted the machine to the normal OS, any malware you are trying to get rid of couldn't infect the recovery media. In times past, you might even receive a premade disk (or a set of them) from the manufacturer.

However, most modern computers don't even have a CD/DVD drive anymore, and the size of recovery media is fast making DVDs impractical for this purpose. USB drives are becoming a more common alternative for storing external recovery media.

However, unlike CDs and DVDs, USB drives do not typically have hardware level protection from writes. (There are some more expensive models that have such a feature.) In fact, USB drives are (or at least used to be) an extremely simple and common way of spreading malware between computers. This makes me concerned that if the machine boots to the normal OS instead of the back up (due to user error, the BIOS not recognizing it's bootable, etc.), the recovery media itself could very easily become infected.

Am I overly concerned, or is my concern legitimate? Even though I by no means regularly contract malware, I prefer to have the peace of mind that comes with a fairly reliable recovery plan.

Your concern is absolutely legitimate.

My disaster recovery plan involves a Linux ISO on a read-only drive which I use to nuke compromised machines from orbit before booting on standard writable media. The machine gets nuked from read-only media (no way for malware to alter it), then is fully powered down, and finally started back up using writable media once the malware is believed to be gone (firmware attacks are excluded).

If for some reason write-once media such as optical discs aren't an option, you could try booting over the network from an up to date machine with a proper firewall configuration (that drops anything other than the required DHCP and TFTP packets).

Another solution is to simply disconnect the hard drive of the machine, boot from whatever writable media you use, and connect the drive once the machine is started off the install media. Assuming the reinstallation image is up to date, there shouldn't be too much risk of malware from the drive somehow compromising the reinstallation system and writing back on the reinstall media.


Security implications of exposing payment gateway secret API key Introduction

In payment gateways such as Coinbase or G2A Pay, the typical payment flow goes as follow:

POST to the gateway with the secret API key and metadata (price etc) to generate a payment URL.
Redirect the client to the payment URL.
Server receives payment notification through webhook and verify the payment (through the signature attached to the payload).

Question

Step 1 is typically performed by the server to avoid leaking the API key to the client.

However, if I were to generate the payment URL on the client's side (for performance -- eliminate one RTT to server), the API key will be leaked to the public.
What would be the security implications of that?

Step 3 security

For Coinbase, the webhook signature uses a different API key so I can still verify the authenticity of the payment notification through the signature.
For G2A Pay, I can perform a GET to the payment gateway with the transaction id to verify the payment.

Potential vulnerabilities considered

With the API key, any user will be able to make a payment and attribute it to another user (by specifying the other user's id in the metadata). However, there would be no incentive for any user to do so.

It is really important to start with the mindset of an attacker, rather than an engineer. As an attacker there could be a litany of reasons I may want to leverage your private key to meet my own desires. Lets start with your eCommerce information.

By having your eCommerce information, I can start racking up a bill on other people's accounts. I can even create my own form to order what I want, use someone else's card, and have it shipped to a location I choose. The best part is you don't have to be in this conversation at all so you wont even see the activity occur.

Going even further, say I have this person I REALLY hate because they keep waking me up in my apartment in the middle of the night with loud music. If I happened to get their payment information, I could make a bunch of bogus purchases that will cause them to cancel their card, deal with fraudulent activity, and it will look like your commerce account is to blame. I feel happy knowing they've been inconvenienced and you might not ever figure out it was me. Win win.

Lastly, many API keys perform more than just eCommerce approvals. Account changes can be made through many APIs so changing the business name, address, even customer information. Worse, you can start stealing client information through an API so I could start spamming your customers with viagra ads or worse; and again still be connected to your service. It's a big security risk.

Your secret, be it a password, certificate, or API key must ALWAYS be protected. You should never underestimate the lengths people will go to screw other people over. As a developer or systems administrator, it is your responsibility to think about this and ensure that your clientele are protected.

Finally, I never advise to do anything illegal, amoral, or otherwise maliciously. However, it can be a very good practice to look at anything you build and see how you could misuse it. View your work through an attackers eyes and try to exploit the very tools you create. The attackers mindset is best learned through application, and if you're attacking your self you will learn more about your own projects than you would have ever known otherwise.


Is CAPTCHA necessary when I use an anti-CSRF token? I wonder is it a good idea using captcha when using an anti-CSRF token on login page? I think it's impossible for robots to mess with login page because the token changes on every request.

Yes its neccessary. A token can still be requested by a bruteforcer. Yes, it would cost the bruteforcer one request extra per try, but a captcha still blocks attempts completely instead.

If you dont want to bother your users with a captcha, you could set so when a incorrect password is used, the account in question will require a captcha. This both thwarth bruteforcers, but also alert the original account holder, that someone might try to access his account. To avoid that a bot might figure which accounts that exist or not, store this flag also for non-existing accounts.


How to recommend a (more) secure router A colleague asked me to recommend a router for her small business.  I asked her for a specification list, and on her list, she specifies secure.

Well, we all know that nothing is completely secure in the tech world, but I started researching router security for her.  My first stop was the CERT Vulnerability Database.  I typed in the names of router manufacturers, and was (somewhat) surprised to see how many routers have serious vulnerabilities.

Besides searching CERT, what other specific methods are available to help accomplish this task?

Here are the types of things I'm thinking about:

Additional online resources or databases.  From what I gather, CERT intentionally keeps some of their reports hidden.
Public results of exploit and penetration testing.
Software to perform testing.
Online tools to perform testing.
A list of criteria to consider.
Anything else.

Besides searching CERT, what other methods are available to help accomplish this task?

Look for vendor specific patterns and penelize any vendors which

have lots of vulnerabilities
take a lot of time for fixes
expire products too quickly, i.e. make them obsolete after only few years and stop supporting them
make it hard for you to find the updates

Check if the router can auto-update itself.
Check if it comes with sensible and secure defaults.
Make sure it is hard to be configured insecure, i.e. warns users when switching off WiFi security, disabling password... .
Make sure that there are no commonly known admin passwords, WPA keys or similar, i.e. the user should be forced to change any such default settings.

If these things show that the vendor has the right mindset regarding security then the systems will probably be more secure too. routersecurity.org has lots of information which will help you with this research.


Secure way of sending a excel document to a third party? Looking to send an excel log file to a third party securely, any sensitive data will be obfuscated.

Initially was looking to use PGP but the third party does not have this and time is a constraint.

Was thinking of password protecting the excel file and sending this as normal email. What then would be a secure way of sending this password, either SMS or via a conference call which is not recorded?

The appropriate level of security depends on the threats involved, so you to make some judgment calls. Password-protected Excel files have not been that secure in past versions and there are tools to break the older protections.

If you need a GUI-based, easy-to-use, Windows-based solution (I'm making assumptions), then many Windows file compression tools offer encryption (7zip is also a popular option and easy to use). You zip the file, then add encryption with a password. This process would protect the contents of the file but often exposes the file name (if that's a concern).

But you asked about sharing the password. The general idea is that you share the password through a different channel than the channel you used to share the file. So if you are emailing the file, you SMS or phone the recipient with the password, for example. This protects against someone who has access to the recipient's emails (or the email stream between you and the recipient) gaining both the file and the password.


Why is the HTTP protocol more susceptible to being intercepted than the BitTorrent protocol? I'm downloading an .iso file that is offered through the main website, which recommends users to use BitTorrent. In addition, they offer the download via HTTP using different mirror sites that belong to different countries, and they claim that the downloads from an HTTP mirror are more prone to be intercepted to serve malicious downloads. I'm curious as to why these kinds of downloads would be more prone than the original downloads.

If I had to guess, it would be because of the differences in security implementations between servers around the world that hold the files. Am I completely off?

The difference is that the BitTorrent protocol has a mechanism to verify that you received what you intended to receive, whereas HTTP does not.

HTTP has no mechanism...

to verify that you are actually connected to the server that you intend to connect to,
or actually downloading the file that you expected to receive.

If any of the HTTP mirrors have security vulnerabilities, or are not under the provider's control, an attacker could simply replace the file, and it would go undetected on the side of the recipient.

Furthermore, if the circumstances allow, HTTP is susceptible to a Man-in-the-Middle attack. Meaning, from your end it looks like you are connected to example.com, but actually you are connected to a third party which is intercepting the traffic, manipulating the network traffic, and only making it look like you are connected to example.com. You then request to download a certain file, but the attacker  sends you a malicious file instead. (On a side note, correctly configured HTTPS, with S, prevents this.)

A file that is transmitted via BitTorrent, on the other hand is first divided into chunks. Each of those chunks is then hashed using SHA-1, i.e. a checksum is generated, by the torrent creator. The hashes are given to each BitTorrent client prior to the download - usually contained in a .torrent file. As the file chunks are then downloaded by the client, they are first hashed by the client itself, and compared with the previously received hash. Only if the hash matches, meaning that the chunk contains exactly the same bytes as the expected chunk, is it accepted. It is a practical impossibility to manufacture altered chunks that have malicious content, but retain their original hashsum.

Since these hashes are shared with you prior to the download, presumably from a trusted source, it is harder (to impossible) to manipulate the expected files in transit when received via BitTorrent compared to a HTTP download. The provider can distribute the torrent, which is a small file, from a single secured server via HTTPS under his own control, and the hashing mechanism will provide a validation for the actual download.

If on the other hand, your hashes or torrent file are tampered with prior to the download, or due to a MitM attack if downloading the torrent itself via HTTP, then the checksum validation offers no security.

Lastly, there is a way how the checksum mechanism can be circumvented by an attacker if he has access to the file prior to the hashsum generation, i.e. prior to the original creation of the torrent. It is then possible for an attacker to modify the file in such a way that some of the file's content can later be substitute with pre-engineered code during transmission of the torrent without being detected by the SHA-1 hashsum check, despite being different to the file that was originally checksummed.