Intrusion Prevention Systems: NIPS vs NBA I was going through the wikipedia article on Intrusion Prevention Systems.

It states two of the four types of IPS as follows:

Network-based intrusion prevention system (NIPS): monitors the entire network for suspicious traffic by analyzing protocol activity.

Network behavior analysis (NBA): examines network traffic to identify threats that generate unusual traffic flows, such as distributed denial of service (DDoS) attacks, certain forms of malware and policy violations.

How exactly are these two types different from one another? To be more specific, what is the difference between analyzing "protocol activity" and examining "network traffic"?

My current understanding is that a NIPS may dig deeper into packets (e.g. possibly examine multiple OSI layer contents) and check if any of the parameters are invalid/prohibited etc. On the other hand, a NBA may concentrate on parameters such as packets per second, number of connections per host etc. Is this understanding correct?

As far as I can tell, your understanding should be correct.

Many NIPS systems, including the open source standard Snort, combines the two. From Snort's webpage:

  Combining the benefits of signature, protocol, and anomaly-based inspection, Snort is the most widely deployed IDS/IPS technology worldwide.

So the distinction is mostly just classification for classifications sake.


How secure is split tunneling on a VPN? What protocols get encrypted and go through the VPN? Is it just port 80 and DNS traffic that does not go through the VPN?

Does this impose any security risks by running a split tunnel? Making the assumption that maybe we connected to a rogue AP by mistake because it looked exactly like a public wifi spot.

I know that running a full VPN will tunnel everything so you are immune to MITM attacks and several other attacks as everything is connecting directly to your own network.

This depends on your split tunneling configuration.

Most split tunnels that I'm aware of are cases such as "road warriors": people who are working from outside the office.  In these cases, traffic to the company's network is tunneled over the VPN and other traffic is sent directly.

For example, say your company's LAN is on the 10.99.0.0/16 network.  The VPN would add a route, but rather than adding a default route, it would add a route only for 10.99.0.0/16 to send traffic via the VPN.  Anything not matching that would go directly to the internet via normal routing rules.

I've never seen a split tunnel VPN that was per-protocol or per-port, though I suppose you could do it via firewall rules or something.


How would replacing Bearer tokens with HMAC work in OAuth 2.0, and how would the client/server validate? This Pluralsight class discusses Bearer tokens, and that one of the things missing from OAuth 2.0 is HMAC based validation.  Elsewhere on the thinktecture blogs, they are called PoP tokens (Proof of Possession)

HMAC based validation would prevent the CSRF based attacks where exchanging the bearer token would result in an impersonation.

What confused me was that in one of the slides regarding OAuth 2.0 risks, Dominic Baier discussed that this validation would occur on the client.

HMAC based validation was never added to the OAuth specification, and its omission was a key reason Eran Hammer (original author of OAuth) decided to remove his name from the specification.

Diving into this deeper, I'm a little confused on how HMAC tokens in OAuth would be:

Constructed in either code or implicit flows
How would the client validate these HMAC tokens? Should I assume this is only regarding SPA applications?
Does the JWT construction in OpenID Connect resolve all the HMAC concerns in OAuth 2.0?

Whatever the flow, the MAC token would be generated the same: a symmetric secret key and an id is sent to the client once. This secret is never sent over the wire again.

The client doesn't validate the token*, the client uses it as it would use a bearer token, except that the secret is not sent over the wire and thus can't be leaked:

  +--------------+                                        +--------------+
  |              |>------Request with authenticator------>|              |
  |              |                                        |   Resource   |
  |    Client    |                                        |    server    |
  |              |<--------Requested resource------------<|              |
  |              |                                        +--------------+
  +--------------+                                                ^
         ^                                                        |
         |                                                        |
         |                                                        |
         |                                                        |
         |                                                 MAC algorithm
   MAC algorithm                                           over key+params
   over key+params

The client constructs the authenticator calculating a MAC using the secret key and some parameters (that includes the token ID, a nonce, a timestamp and some other data), and attaches that to the request.

The resource server (or a third server the RS uses to validate tokens) knows this secret key, so it performs the same calculations as the client did using the same params. If everything matches it proceeds with the request.

The server is also tasked with preventing replay attacks by checking the timestamp and preventing nonce-reuse.

This protects agains many scenarios in which the token could be leaked: TLS misconfiguration/bug, attacker controlled endpoints finding their way into the client's database, etc.

Regarding your 3rd question, yes and no. The OAuth2 MAC spec draft defines a few claims for JWT to encode the information required for the emission and use of MAC tokens using JWT, but OpenID Connect is still using bearer tokens.

The main concern with bearer tokens is that the client's developer has to be very security-aware, and that its security depends exclusively on TLS.

A lot of people misunderstand this last statement and conclude that OAuth2 is inherently insecure and useless and doomed. Even worse, they blindly repeat this kind of conclussions in talks and posts and comments and simply confuse people.

OAuth2 is very good for some use cases and sucks for others. It requires a good understanding of some security principles. It requires some compromises as well. But it's out there, it's working and it solves a very hard problem.

The use of MACs was never standarized, but the draft is pretty good and easily implementable. Today there are several alternatives as well.

(*): I mean the client doesn't perform MAC validation. Of course, audience and other fields should still be validated.


Current status of SameSite cookie Recently I got to know about SameSite cookie attribute which is used to mitigate the CSRF attacks. AFAIK SameSite attribute for cookies is implemented in Chrome and some other browsers. Since I'm Using Tomcat server to deploy my web apps, I have raised a discussion with Tomcat dev to see whether they have plans to support this in an upcoming release. They said that if the spec work had not stopped and/or the protection it offered was more complete, then they can consider supporting SameSite Cookie. Here I want to clarify below-mentioned questions.

Since the draft is expired [1], what is the Current status of SameSite cookie?
Will it be a standard solution?

[1] [https://www.ietf.org/archive/id/draft-ietf-httpbis-rfc6265bis-02.txt]

SameSite cookies are here to stay.

They were available for a long time in Chrome (since v51) and more recently got implemented in Firefox.

Making cookies samesite protect against a whole range of CSRF vulnerabilities. It protects against BREACH, a compression side channel attack that can steal a cookie by forging a lot of authenticated requests. It protects against some client-side Spectre attacks, where the response to a cross-origin request is read using speculative execution vulnerabilties.

The spec is still being worked on. For example, how strict samesite cookies should behave in redirects is not entirely clear.

I would currently advise everybody to set samesite=Lax on all cookies. It offers a reasonable security advantage without breaking things or being too much work. Using samesite=Strict cookies gives more security, but may break some functions on your site.

Server software needs to give the option to set the samesite attribute to either Lax or Strict. That part of the spec is very stable and it would not be premature to offer that. For example, PHP is planning to add samesite to their setcookie function.

Also, I would expect that you could use samesite cookies even if Tomcat doesn't implement it, if you create your own Set-Cookie headers.

Update: Chrome is planning to make all cookies SameSite=Lax by default, which you can disable by setting SameSite=None.


When exactly is Diffie-Hellman used in TLS? I'm aware that Diffie-Hellman  is a key exchange algorithm whereas RSA is an asymmetric encryption algorithm.

I have the following questions:

During TLS handshake, will both RSA and DH be used?
(I don't see the use of it, either RSA or DH, we will be using it to end up with a safe symmetric key for AES or DES.)
An example of a cipher suite is EDH-RSA-DES-CBC3-SHA. That is pretty confusing. Should it not be RSA-DES-CBC3-SHA and EDH-DES-CBC3-SHA, two separate cipher suites?
Apart from historical reasons, is there a reason for us still to use DH?
When would I use DH over RSA? (Thinking as a practitioner)

If my understanding of TLS is wrong, please do correct me.

DH is a key exchange algorithm, it is used to derive the session key that's later used in the symmetric encryption. DH by itself is not authenticated, so while you can derive the session key without a MITM being intercepted, there's no guarantee that the guy on the other end that you're deriving keys together with is whoever they say they are. Not being able to authenticate the other party means that you'd still be vulnerable to MITM anyway.

RSA is an asymmetric encryption algorithm. RSA can be used as a key exchange algorithm too (without DH), however the RSA key exchange algorithm lacks the property of Forward Secrecy. Forward Secrecy is the property that an attacker that recorded your encrypted communication and then later obtained your private key, they shouldn't be able to decrypt the previously recorded communication. However, RSA can be used for signing and authentication.

DH is used together with RSA so that you get a communication channel that are both authenticated and is forward secure.


Does "Certificate Authority" refer to the organization or the software? Does the term "certificate authority" refer to the organization issuing certificates (symantec, comodo, let's encrypt, ...) or to the device and software that issues certificates from CSRs or both?

When speaking about a trustworthy "Certificate Authority", we refer to the organization/entity issuing the certificates, and not the tool used to generate them. It refers to the entity in the "Issuer/Issued by" field of your certificate (e.g. DigiCert for this website). Thus, if you issued your own certificates using the same tools as DigiCert, say OpenSSL, you would still not be a CA trusted by most browsers. You could, of course, be a trusted CA within your organization/network/device group.


Is it insecure to let users know which framework I am using? Suppose I use a framework X to build a mobile game, and the website of X allows me to submit the name of app that uses X to build. But I suspect if I should submit my app name because it would let users know my app is using X. Is letting users to know which framework I am using a security issue?

Security through obscurity is not sufficient, but can be used aggregated to other security mechanisms and practices. Always remember that system security should not depend only on the secrecy of the implementation or its components.

You can know the framework code very well, but you can't suppose it's completely safe. Hiding it does not change that, but certainly can add an extra safety, which doesn't mean you shouldn't care about how code is implemented because it's hidden.

Avoid unused libraries, keep the code clean and lean, validate input data and encode output data, authenticate credentials, control access, treat log error messages, etc. There are a lot of good practices that should be used, because only hiding your code is not enough.


Is there any benefit to providing multiple types of public keys? Say I have a page on my website which lists public keys to be used in case people would either allow me access to a server, or send me encrypted information.

Is there any benefit to me providing different types of keys for users to use, or multiple keys of the same type but different sizes?

For example, a page on my website that looks like this (with links to the full keys, not just the fingerprints):

  RSA v1:   20:ad:11:7f:f1:39:8a:e8:58:3f:a0:62:d8:98:cf:2f
  DSA:  93:c2:ad:b7:cd:15:1f:ee:50:7b:c1:a0:13:79:a2:e7
  ECDSA:    3b:83:67:dd:c7:66:07:05:a7:39:41:a8:90:76:c4:d7
  RSA v2 (2048 bits): 54:4f:6d:a1:22:ec:84:24:2f:aa:99:e1:66:cb:b5:29
  RSA v2 (4096 bits): 11:98:59:14:d1:42:20:68:97:29:9d:b3:fd:5e:6f:f9

Since encryption and signatures are distinct operations, it makes sense to have distinct keys. This really boils down to the need for distinct lifecycle management characteristics (backup or not backup, that is the question).
Supporting several types of keys theoretically allows for better interoperability: clients who know only RSA use the RSA key, while clients who don't support RSA can use ECDSA. (This is only theoretical, because in practice everybody supports RSA.)
Having several types of keys can potentially ease things if a catastrophic breakthrough occurs: if some half-mad mathematician comes up with, say, a very efficient factorization algorithm, RSA is toast, so being able to switch to something based on elliptic curves would be required. Having prepared the terrain with already deployed keys and implementations will make the transition smoother. People often talk of this as "biodiversity of algorithm", even though algorithms are not living entities, thus not relevant to biology.
In the case of RSA-2048 vs RSA-4096, my guess is that the key owner was just overenthusiastic. It makes little sense to go to 4096 bits, since 2048 bits are more than enough to defeat known and foreseeable cracking technology. It makes no sense at all to have both keys active at the same time. However, some people really love big numbers.


Storing bank account numbers I need to store bank details of users in our system's database.

I'm thinking of encrypting the account number in case somebody gains access to our database or backups thereof.

We are using Heroku and our database is running on a separate server to the webserver. My idea is to store the encryption key on the web server as an environmental variable so that at least it is not stored on the same machine as the DB.

Is this a good approach to follow? Any other suggestions?

A full answer would be far beyond a post on this site, so I will only give hints here.

You problem a real security question. The answer will not be (only) technical, but you should first wonder about your real security requirements. In security, I want a safe solution just means nothing, a solution can only be safe according to a system of security requirements.

So you should ask yourself the following questions - I do not know your use case, so I cannot answer them

what are the already known weaknesses (known vulnerabilities in used libraries or frameworks, pen testing reports...)
what are the threats to consider (information theft, unwanted modifications, denial of service, physical attack...)
what are the possible attackers you want to be protected against (script kiddies, NSA, russian mafia...)
what could be the possible consequences of data compromission

You will end with a number of risks. You then will have to say how you can mitigate the risk itself or its consequences, and whether the remaining risk is acceptable or not.

What you propose is a mere obfuscation of data requiring first an attack of the web server and then access to the database. You can say whether it is acceptable for your security requirements after doing your risk analysis, I cannot.


Solutions to decrypt data on access I want to store sensitive data on on my (public) linux server. Also, I want to be able to access the data from different locations and different OS without much hassle. I thought about using a (simple) web-form, maybe also a samba-share which is hidden behind a VPN.
Since I want to access the data very sparsely, I would also prefer a system where the data is always encrypted and is decrypted only if I want to access it.

Most solutions for data encryption I found do not seem to fulfil the latter criterium: The way I understood systems like LUKS or EncFS, they are usually holding a decrypted copy of the files. Also, I would like to have a lean system, which does not come with much overhead. Owncloud would probably do something like I'm looking for, but also comes with a lot of administration.

After thinking about the problem some time I came up with the following idea:

Encryption

Encrypt the data using a random key and EncFS
Encrypt the key using RSA and my public certificate and put it on a (public?) website.
Forget the key.

Data-Access

Open the website and copy-paste the key
Decrypt the key using a private certificate and a smart-card
Fill-in the decrypted key in a textbox on the website
Now a script either mounts the EncFs-Volume in a samba-share (see above) or in a directory of the webpage which is protected using .htaccess.

How secure would such a system be? I would assume that the critical part is the one where the data is decrypted, but accessible.
My questions are now the following:

Did I overlook something in the system which generates security problems?
How secure is .htaccess protection on a nginx web server? Are there ways to improve the part where I access the files?
If there should be existing solutions to my problem I did not find, please tell me.

Looking forward to hearing from you!

A couple of pointers:

Using SAMBA significantly reduces your security. for what you propose SSH would be a better fit (when utilizing Public keys)
nginx does NOT use .htaccess (and htaccess is horrible for performance and security). you should configure everything in the (virtual-) host directives. (so in the /etc/nginx/sites-available for most *NIX'es)
When utilizing SSH you could use a shell, and than GPG encryption could be utilized to protect your file (with the bonus of not having to disclose your public certificate, which could tip an attacker, before entering your system, that you are using it for encryption of a specific file)
Usability wise your solution is a lot of steps. many of which add no (additional) security at all. I would suggest you look into jails / chroot for additional levels of protection.


Concept of Jump-Oriented-Programming (JOP) I don't understand the concept of Jump-Oriented-Programming. Can somebody try and explain this to me in an easy to understand way?

I see that JOP is a concept that has evolved due to security measurements which have been implemented to protect software against buffer-overrun-attacks:

In a buffer-overrun-attack software makes use of a function that does not perform boundary-checks on inputs. Therefore an array can be assigned way more values than it should actually store and thus stack-memory can be overwritten.

In the early days shell-code was written on the stack. I imagine e.g. the return-address of main() was overwritten with a pointer to some other location of the stack. At this particular location on the stack, the shell-code was inserted. However, Data Execution Prevention has been introduced, which somehow makes the execution of code from the stack impossible. Furthermore, ASLR has been introduced to randomize memory. I am not sure here, which memory does ASLR randomize? Can it be stack-addresses?

Also canaries have been introduced. This is some memory-location on the stack, which is known to have a certain value. Before returning from a function, the stack checks that the canary has not been changed.

Return-Oriented-Programming is a concept that allows to exploit buffer-overrun vulnerabilities even in presence of DEP, ASLR and canaries. How does it work? In ROP the shell-code consists only of system-library function calls. Or something like this (please forgive me, I am not that good with all of this. That's why I really need your help!).

So, in ROP a buffer-overrun vulnerability may be exploited in such a way, that e.g. the return-address of main() is overwritten with a pointer to libc. In libc, there are system functions (I really don't know any, except execve). This functions, for sure, are executable. And they can be used to create a shell-code.

Now, how can a system be protected against ROP ? And how does this protection become invalid through JOP ? Can someone please help me understand JOP ?

I am grateful for just anything!

A lot of your questions are duplicates here so I'll cover them very briefly. Suffice to say that all of this has been a decades-long arms race between exploit developers and OS / compiler developers.

Initially there were no exploit protections. You could find a stack buffer overflow bug, use it to overwrite the current call frame's return address on the stack, wait for the exploited function to reach its end and return, thus gaining control over the instruction pointer (IP), which you could point back at instructions you put in the stack buffer as part of your exploit payload (shellcode), and thus execute arbitrary code.

Then there came stack cookies. These are randomly generated values that are placed just before the return pointer. At the end of each function (in the epilogue) the function would check that the cookie value was correct before returning. If you blindly overwrote a stack buffer to overwrite the return address you'd end up overwriting the stack cookie, which would then be checked at the end of the function and you wouldn't get code execution. To get around this, attackers instead started targeting exception handling structures (SEH) which typically appeared at the end of the stack frame but before the return pointer. By overwriting the SEH structures you could trick the OS into executing an exception handler at an address you controlled, again usually the stack buffer you overwrote with shellcode.

To fix this, OS developers took a couple of approaches. One was SafeSEH, which maintains a read-only table of valid exception handler addresses in a table as part of the executable structure, and verifies that the exception handler address is one of the ones in that table before redirecting control flow to it. On x86-64 Windows systems the stack is no longer used at all for storing SEH structures, which mitigates this attack completely, but I'm getting ahead of myself a bit here.

In the meantime some enterprising exploit developers had started to look into heap (i.e. dynamic memory that isn't the stack) buffer overflows and what could be done with those. Heap buffer overflows sometimes allow you to overwrite pointers (e.g. to event handlers, callbacks, etc.) that led to control over the instruction pointer and thus code execution. Again the attackers would usually put their shellcode in the same buffer they were overflowing.

The other approach I mentioned above was Data Execution Prevention (DEP). This is a bit of a confusing one because in the early days Microsoft called SafeSEH "Software DEP" despite not really being DEP at all. So if you see "software DEP" written somewhere, they mean SafeSEH. Hardware DEP, usually just called DEP these days, is a feature built around a hardware extension that enforces page access flags in the processor. The feature is called NX (No Execute) by most people but it's also sometimes referred to XD (eXecute Disable); I'll just be calling it NX. What NX does is make it impossible for the processor to execute pages that have been marked as non-executable. If you try to redirect the instruction pointer to a non-executable page the processor just throws a protection fault. Operating systems used NX to implement DEP, which marks the stack and data segments as non-executable. This made it impossible to just drop shellcode into a stack or heap buffer and execute it there - those pages were now non-executable and the CPU would refuse to execute the code.

This is where ROP, otherwise known as ret2libc (a Linuxism for the same thing), came in. Instead of trying to put shellcode into the stack or heap and execute that, ROP instead found small chunks of library code that could be chained together in order to get code execution. The initial part of the exploit would gain control of the instruction pointer somehow (e.g. via heap corruption, UAF, etc.) and either fill the stack with the ROP chain data or overwrite the stack pointer so that it pointed at the heap buffer containing the ROP chain data (this is called stack pivoting). Either way, the stack pointer ends up pointing to the top of the ROP chain. Each "gadget" in the ROP chain is a small snippet of code in the format "do something, return". By putting the addresses of these gadgets one after another on the stack, the application jumps to the first gadget, executes a few instructions, hits a return instruction, which then reads the next gadget address off the stack and transfers execution to that, repeating until the end of the ROP chain. Usually the chain would call some function like exec on Linux or CreateProcess on Windows. Another way to go is to call the memory protection function for the OS (e.g. VirtualProtect on Windows) and use it to mark a section of memory that you control as executable, then have the last item in your ROP chain redirect to that memory so you can execute shellcode. Neat, right?

The key part of this attack is that you need to know where these gadgets are in memory. In order to make this difficult (or borderline impossible), OS vendors introduced Address Space Layout Randomisation (ASLR). This randomises the base addresses of various important bits of memory like the stack and executable modules. More and more stuff has been randomised and the randomisation has become less predictable as ASLR implementations have improved. The idea is that if the attacker can't know where modules are in memory for the target process, they can't build a ROP chain. Unfortunately, however, it only takes one non-ASLR module to be loaded in a process in order to break ASLR. In newer operating systems (e.g. fully patched Win10) you can configure a policy that forces ASLR for all modules, but this is not the default (as far as I know). ASLR can also be bypassed using a pointer leak. These occur when an address of some executable memory in a process is leaked to an attacker (e.g. by a UAF bug, or by poor API design). The attacker can then calculate the module base from that leaked pointer and use it to build a ROP chain.

JOP is extremely similar to ROP. It is useful when stack protections are in use, thus preventing stack buffer overwrites, stack pivoting, or return address filtering (a form of partial control flow enforcement). This allows heap-only exploitation via heap corruption, UAF, etc.

Instead of allocating a bunch of ROP gadget addresses on the stack and using a RET of the end of each gadget to jump to the next, JOP uses a jump table in the heap (identical to a ROP chain but with JOP gadgets instead) and a dispatcher. Each JOP gadget is a chunk of library code in the form "do something; indirect jump", e.g. add rcx, 4; jmp [rdi]. Instead of each gadget directly jumping to the next, like in ROP, each gadget instead jumps back to a "dispatcher" gadget.

For example, consider the following two instructions:

dispatch:
  add rax, 8
  jmp [rax]

This instruction pair (or a compatible one) should be fairly easy to find in library code somewhere. If an attacker can set rax to the address of their dispatch table (e.g. a heap buffer they've filled), and set the instruction pointer to the address of dispatch, then they can chain together JOP gadgets to gain code execution as follows:

Attacker loads dispatch table into known heap address.
Attacker exploits bug that sets rax, rdx, and rip so that rax points to the dispatch table allocated in step 1, rdx points to the dispatch table gadget as described above, and rip is also redirected to the dispatch table gadget.
The dispatch function increments rax, so rax now points to the next entry in the dispatch table.
The dispatch function jumps to the address at rax, which executes the gadget there.
The gadget does something and then ends with jmp [rdx]. This redirects control back to the dispatch gadget.
Go to step 3, repeat until chain is completed and exploit succeeds.

The registers here (rax and rdx) are just examples, they could be swapped for any general purpose register.

You can read a more full description of JOP in the paper "Jump-Oriented Programming: A New Class of Code-Reuse Attack".

In short, though, JOP is only really useful when the stack cannot be abused due to stack protections being in place.

JOP can be mitigated using control flow enforcement, such as Control Flow Guard (CFG). Protections such as CFG identify indirect call sites in the program and build a table of valid target addresses that they can point to. For example, if you have a callback in C++ defined as typedef void (*SomeCallback)(int, int); the compiler knows that only functions with that signature (e.g. void MyCallbackImplementation(int foo, int bar) { ... }) are valid targets. The compiler then inserts a check before each indirect jump instruction that ensures that the target jump address is valid. If not, it terminates the program.

One additional ROP/JOP trick is to use unaligned gadgets, i.e. gadgets that aren't made up of instructions as they were intended to be interpreted when the compiler generated them, but instead are valid instruction patterns that happen to appear when you jump in the middle of an instruction. These can also be mitigated to some extent by the compiler but I am unsure how commonplace this particular type of protection is.

Hopefully this gets you up to speed. I've glossed over some stuff as this answer is already very long and covers a lot of different anti-exploitation topics very quickly. Some details are missing so I suggest you try to bypass each protection yourself one by one so that you gain an appreciation for all the little nuances.


Is it truly possible to store passwords securely, but be able to see the password? Every place I looked, people recommended that storing passwords via encryption is like storing passwords in plain text. But every place I've looked, everyone recommends using a password manager like KeePass.

I guess the real question I'm asking is how is KeePass or other password managers more secure than storing them in plain text?

The only reason I'm asking is that I'm planning on building a home server. I would like to eventually implement an online password manager that would send passwords through HTTPS to multiple devices. This is probably going to be solely for shits and giggles. I'm not trusting my crappy coding on all of my passwords. But it still interests me on how KeePass was able to do it.

Context is everything.

  storing passwords via encryption is like storing passwords in plain text.

This advice is about client programs implementing a faux password manager that stores password to access online service in encrypted format so you don't have to type the password to access that service at all. This kind of encryption is moot because to allow zero password login, the decrypting key for the password manager itself must be stored along side the encrypted password itself, this gives you no more security than just storing it plain text.

A proper password manager, on the other hand, encrypts your password using a master password (or more commonly, the master password encrypts the master key used to encrypt your data). This is secure because you can't unlock the password manager without the master password. This does mean that you must type the master password every time the password manager throws away the decryption key (e.g. definitely over reboot and when the password manager process is killed and depending on settings, possibly over hibernation, suspend/sleep, or screen off).


Is there any disadvantage in using OpenNIC for DNS resolution? What are the advantages/disadvantages of OpenNIC vs ISP for DNS resolution with regards to security and privacy?

NameBench is a Google engineer's side project.  It can test a large number of DNS servers to make sure that their resolution is "safe", and not a source of censorship.  It will try and resolve common domain names like www.paypal.com, and make sure that they are pointing to the right location.  (Not of the censorship checks are working properly at the time of this writing,  but this feature still works.)

Namebench also performs speed checks.  When I ran it i found out that level3's DNS resolution servers where on average 4 times as fast as the ones provided by my ISP. Also my ISP was maliciously redirecting failed DNS lookups to a spam page,  which is why I was looking to replace them in the first place.


Does PHP unserialize work with an object inside a string serialize($_POST);

where $_POST is always an array. I have control over one of the array values, e.g. $_POST['evil']. Is the unserialize exploit possible with this kind of structure?

I coulnd't get it to work with a structure like this:

a:2:{s:4:"evil";s:76:"s:26:"EXPLOIT_OBJECT_INSIDE_HERE";}

The usual way to exploit unserialize is to invoke code execution (un-serializing an object triggers the __wakeup method defined in the class using the data supplied). Arrays don't have methods so they cannot be used to exploit this. Note that the class is something already defined serverside.

This does not address a more generic vulnerability in PHP's unserialize function, but the nature of the serialization format and the way PHP manages data in variables makes such a vulnerability unlikely and I am not aware of one.


Using SSL (e.g. storing private keys) in SAAS / managed applications How does one evaluate the risk of storing a private key (secret) on services like the AWS elastic load balancer, or for the purpose of my question: any service non-self managed service that could benefit from SSL ?

In security, I consider "my identity" a key aspect. We have Certificate Signing Request to address this problem on the generation part of the pipeline but it's up to me to manage the rest of the pipeline.

My current ideas:

I know that I still have to believe that the authority chain is not compromised (vs PGP/distributed  processes).
I still have to believe that the physical access to my servers in the data center is not compromised
They are asking me to create yet another vector of attack. My problem is that the aws services are certainly a target of interest to many attackers. If there is no current problem, there will be, sometime in the future. And they have their own sysadmins, helpdesk, etc that, may or may not, have have access to the keys.
I do not do it. I store my private keys on my own servers. Traffic is routed and handled at my servers.
If I had to do it, I would reduce attack time windows by refreshing those keys periodically (I have yet to analyse the consequences of this approach)

Am I being to paranoid or is security being (once more) neglected ?

(I feel that having SSL is a trend but the security of the thing isn't taken seriously anymore)

Is HSM an option?

CloudHSM: AWS will try to sell you "CloudHSM" for this: https://aws.amazon.com/cloudhsm/ -- I think you pretty much have to take their word (legally enforceable contract or something) for it when they say that it's an actually HSM on real hardware with no back door.

Keyless SSL: CloudFlare offers something called "Keyless SSL" where you host the HSM in house. https://www.cloudflare.com/ssl/keyless-ssl/

I know that I still have to believe that the authority chain is not compromised (vs PGP/distributed processes).

If your server box is taken over (either by physical access or otherwise) then the hackers also have your SSL private keys. Unless they are in a Hardware Security Module (HSM). From which they are hard/impossible to extract. (Even with physical access, a large budget and lots of time.)


Is Postgres password-based authentication secure? According to Postgres's documentation, Postgres's password authentication method uses MD5 hashing to secure the password:

  The password-based authentication methods are md5 and password. These
  methods operate similarly except for the way that the password is sent
  across the connection, namely MD5-hashed and clear-text respectively.

  If you are at all concerned about password "sniffing" attacks then md5
  is preferred. Plain password should always be avoided if possible.
  However, md5 cannot be used with the db_user_namespace feature. If the
  connection is protected by SSL encryption then password can be used
  safely (though SSL certificate authentication might be a better choice
  if one is depending on using SSL).

I've heard from numerous sources that the MD5 hashing algorithm is no longer considered secure. Does this mean that I should avoid using password-based authentication for Postgres? If so, which alternative method should I use?

If using SSL, then what PostgreSQL does is fine. If not using SSL, but still doing the authentication across the network, then what PostgreSQL does stinks. Their games with MD5 are worthless, but not because they use MD5. MD5 has its own issues, but there they are just misusing it awfully.

With "cleartext password" authentication, the client shows a user name and a password, and the server accepts them if they match what the server stored.

With "md5" authentication, the client shows a value (which happens to be the MD5 hash of the concatenation of the password and the user name) and the server accepts it if it matches what the server stored.

So you see it: in both cases, the client shows a bunch of bytes to the server, always the same sequence. It suffices for an attacker to tap on the network to observe these bytes, and then connect to the server and sends the same bytes to be granted entry. That the bytes are the result of a MD5 hash is completely irrelevant here. This MD5 hash is said to be password equivalent. As long as the connection can be eavesdropped at all (i.e. no SSL), then security goes down the drain.

See this page for the details of the MD5 computation. They call it "encryption", which it is not at all (hashing is not encryption).

We could even argue that using this MD5 decreases security: when a plaintext password is used, it can be forwarded to another authentication server (using Kerberos, LDAP,...) and that authentication server could then employ strong storage techniques (see password hashing). With the PostgreSQL-specific MD5 hash, this cannot apply. When the "md5" authentication method is used, it MUST be against a table in the database which contains all these "md5" value as is. An attacker who can get his hands on, say, a backup tape or an old disk, will immediately obtain many free accounts on the database.

And, I insist, nothing in all this has anything to do with MD5 cryptographic weaknesses. All of this would still apply if MD5 was replaced with SHA-512.


Setup a certificate authority I am working on building a PKI within our organization in order to support code-signing certificates for embedded devices following a requirement from one of our clients.
I have the entire design in place and the only thing missing is a CA which will issue the certificates for us. The issue is that our organization (as big as it is...) doesn't have its own CA so , I am looking into the following options :

Create in-house root CA which will issue certificates (it shall
    correspond to "Minimum Requirements for the Issuance and Management
    of Publicly-Trusted Code Signing Certificates, Version 1.1"
    according to the requierment). I researched a bit online and found 2
    main approaches:

 1.Using windows server :https://msdn.microsoft.com/enus/library/ms762260(v=vs.85).aspx

 2.Using OpenSSL and linux server

Use external root-CA

about option #1 :

I need to know what is the common approach and cons vs pros of each one of the 2 approached I presented( I would be glad to hear some other approaches I haven't considered as well)

about option #2 :

Which external CA service will be most suitable for my needs (signing code-singing certificates using root-CA)?

Thanks ,

The choice of in-house or external CA will depend on a number of factors

Can you dictate a new root CA to be added to all the clients who will need to use these certificates?  If there's a large number of clients and you don't control them, then you're likely to be better getting certificates isued by a CA who are already trusted by those clients
How many certificates do you need?  If you need a large number of certs, then they might lead you to use an internal CA as an external one will likely charge per certificate, and this could become expensive.

Probably the main concern is, can your organization effectively manage a CA?  PKI/CA management requires quite a lot of care and attention to do well.  Whilst it's possible to setup OpenSSL and create a CA with a few commands, effectively running a CA has operational problems to consider.  The main one is effective and secure management of certificates and their lifecycle.

As one example, you need to maintain the absolute security of the root key.  Loss of this (either loss of the data or compromise of it) could lead to you having to re-issue all the certificates in question, which if you're looking at embedded devices, could be painful, depending on how easy it is to apply updates to these systems.


Is a "SAS 70 Type II" audited host SEC compliant? From what I have read and known, SEC compliance is quite vague.  It is best to be addressed in a strong manner, but when it comes to hosting in third-parties, the only way for you to prove their compliance is via audits.

Since there are no concrete rules (ex: "all third parties must be SAS 70 compliant"), what serves as acceptable?  Does "SAS 70 Type II" compliance serve as acceptable?  If not, what are some recommendations for dealing with third parties?

Since I know stackexchange hates vague questions, what other audits are proof that third parties are "compliant solutions?"

Thanks,

Matt

SAS-70 (including Type II) is not a certification standard. It's a statement of what you claim to do, coupled with an attestation by an auditor that you do what you say. You have incredibly wide flexibility to define exactly what it is that you do, so no two SAS-70's are exactly alike. I don't know which SEC rules you're referring to, but SAS-70's are in any case not a precisely defined certification, so they're hard to compare with anything else.


Do the Windows shared source files compile into the same binaries as the retail version? Microsoft makes the Windows source code available to certain third party organisations such as the US and foreign governments, universities etc. This is their Shared Source Initiative

Is this a complete set of Windows source files and is it possible to build the whole OS with it? If so, are the resulting binaries the exact same as the official Microsoft binaries at the time?

Of course the reasoning for this question is to know whether there are some 'independent' organisations who could find back doors in the Windows security components.

Say the Russian FSB who is part of the shared source initiative, just receives a bunch of source files claiming to be the 'real thing'. Wouldn't they only be satisfied after being able to build the OS and compare them with retail binaries?

How they would react on any of their discoveries is another question.

And if they need the Microsoft C++ compiler to build the OS, do they get the sources for that as well?

There are varying levels of access, which depend on the particular NDA and whichever agreement is signed. These are my observations made from public discussions.

As far as I know there is no level that allows direct checkout of code for compilation. It's all in a prettified format, similar to how Github et al show code. Someone with access could copy files out no problem, but they can't do a bulk export or checkout.

The majority of Windows is written in C and some newer stuff in C++, with very little written in assembly. Someone could compile the code with standard MS compilers (assuming they got the versions right), but to make the necessary DLLs and EXEs they would need to know how it builds, they would need various MAKE and related files, and those files probably aren't present in the any of the agreements. At the very least they aren't present in the less-privileged agreements (erm. supposedly. NDAs make it impossible to explain in detail what is actually present as those that know can't share or acknowledge they have access. ;) ). In the event someone could build, the results could differ because there may be some post-compilation/pre-packaging processes when shipping.

Where things get interesting though is getting access to compiler symbols for certain Windows components. This allows devs to more easily follow code paths while debugging. Between the symbols and browser access to the source, someone could look for bugs/backdoors/whatever.

However, looking for problems in code like this is more complicated than some may think. There are millions and millions of lines of code in Windows, and the structure of the files may seem precarious if you aren't familiar with it.

EDIT: In theory the code is the same, otherwise it kind of defeats the purpose of sharing the code. It isn't clear how often the code is updated for things like patches though. Whether it's really the same code, well... who knows.


Is There a Library of Well Known Threat/Attack Trees? [I'm surprised that my searches didn't find this questions before, but then I may just not be asking it "the right way."]

A project I am on is starting to look a threat trees for a connected piece of hardware that is under development. As a start, we decided to look at a simple entry point, the USB port.  That took up most of the meeting, and is still incomplete.

I am pretty certain we are not the first or last team ever to consider the attack surface presented by a USB port.  That begs my main questions

Is there a library of common attack trees exist?

Sadly, there is not a good free/community driven set. There's a set at the back of my book on threat modeling, and there's a set for sale via a company called Amenaza which I have not seen.

If there's something else, I didn't discover it when doing research for the book, and would love to hear about it.


How do you address a social engineering and or software weakness/concern in a company or organisation? Say that you call your bank and are able to start talking about your personal finances, without having given them any real proof of your identity. Well the first thing I'd think would be to change your bank. But it might not be as practical if company X is your university/college/school or government.

Let's say you are not willing/able to change to another service provider, and you don't want them to be sharing your information with the rest of the world. What do you do? It's hard to call the company and tell it that it needs to do a full pen test. They have a tendency of getting defensive in a situation like this.

So my question is how do you tell/prove to a company that its security is weak and they need to do something about it to stay within the bounds of the law? (I think this mostly applies to larger company/organizations so please focus your answers towards them.)

After all impersonation and most on line security testing is illegal. After all if your name is robert') DROP TABLE students;-- then it's just a question of time until you accidentally find something. :)

How do you address social engineering and/or software weakness/concerns in a company or organisation?

I agree that breaking in is a bad idea.

Also - you might consider that while you are a customer of the organization, going public is also of limited value, since any break-ins that occur are likely to damage you, as well.

I agree that your immediate best bet is to withdraw your affiliation and find a company with better security practices... but I'm staying within the confines of the question and assuming this isn't an option.

A good practice is to hunt down the right person and tell them about your concern.  The right person in a big organization can be very hard to find, since it is most likely NOT the guy answering the phone at customer support.  Options include:

trace through customer support management chains until you find someone with a serious enough title that he might take you seriously
research the company's executive management - in a big enough company, there should be a Chief Security Officer or similar title who has equal power to the person in charge of IT.  Often these people don't have easy to find contact information published publicly, but you might try a formal letter as a concerned customer.  Just be careful of your wording that this is a request for assistance, not a threat.
if you honestly can't through to the company, there are often government agencies that cover specific areas of law - it varies from industry to industry.  And things like the Better Business Bureau.
if the issue is truly egregious (and illegal), and the company is big enough, you could retain legal counsel and bring a class action lawsuit.

Most of these are going to take serious time.  You'll likely fail on the first few attempts to get help.  This can be a major struggle.  But if it's your data, and you don't have another option to find a better resource, this kind of battle may be the right option.

YMMV - my experience is centered in the U.S.  Can't say that other governments offer the same set of protections.


Is it possible that authorities can't block a certain website I was watching a very recent TV show, the FBI agent told the police that there is no way for anybody to block a live stream of a pedophile torturing a kid nor to trace it. Even when it's being broadcasted from within the same country.

What am I missing here? I can think of lots of ways to block and the website and trace the owner of the domain. Was it just fiction?

As far as I can tell, you’d need to define where it would be “Live Streaming” from. For example, if someone used darknet (Onion/TOR) to stream, it would be very difficult since there are a lot of randomized layers. No one would be able to block a live stream since it would come from various sources (nodes). There could be no mechanism to have ISPs block their clients from viewing it either, as they’d have to block TOR protocols, and it does nothing if someone uses even more proxies to bypass the blocks.

There would be a mechanism to determine who had watched it, based on checksums, length of the stream, and other tidbits investigators could piece together, however that too becomes a touchy subject since they’d literally have to have all ISPs do some form of flow (netflow/jflow) and calculations.

Short answer is, they would be hard pressed to stop it without breaking laws, and violating privacy while doing so.


Order of authentication and authorization This is my first question here in Information Security SE. Is there a recommendation to help telling the scenarios where authentication should precede authorization from the ones where authorization comes first?

I experienced both situations at different workplaces (the situation was very similar, switching to a system user with a certain set of privileges in Unix command line). When does authorization need to come first to spare the authentication? When should it authenticate first so as to not to tell a potential intruder that the user impersonated would not be entitled for the current operation?

Are there situation specific generic guidelines or rules for this?

--

OK, let me come up with a specific situation. Logged in with own employee user ID, SUing to another user. I mistyped the system user I was about to switch to, but the other is also an existing user in our environment. Before asking for password, I got rejected saying I wasn't authorized to perform this operation.

Given that I just finished an anti-social engineering course today, I wondered whether it was a good idea to tell me I wasn't authorized (even this may be a useful piece of information for someone trying to impersonate me in the corporate network).

How can you know who you authorise if you haven't authenticated? Authentication always comes first, except when everyone is authorised or noone is authorised.

Edit: seems like you have two questions now :)

1) You were refused most likely because there is an access control policy that prevents your own original UID from performing an operation on the UID of the user you mistyped. It's your own UID that authenticated you (called an ambient authority) because the system that performs authentication checks trusts your system to provide an accurate UID. Your UID was not authorised so you were refused access.

As a side note, some auth server protocols like NIS failed to account for the fact that a user can locally escalate privilege and their local UID cannot be used as an authentication token. I honestly don't remember how a NIS+, LDAP or Kerberos server would check your identity before checking if you're allowed to use one of their resources (such as connecting to another account).

2) Some people believe that it's a good idea to obfuscate whether an authentication attempt worked by serving a honeypot session to the poor user that misspelt an ID or password. These people are wrong. If the system hadn't told you you were not authorised, you would not have noticed that you're not logged in onto the account you expected and you would not have been able to explain why the data you expected to find isn't here, or why the data you added during that session was not actually saved to that user's home directory. These interaction breakdowns are all but straightforward to recover from, and the security benefit of obfuscation is very debatable.


What practical uses are there for the AD feature of "Confidential Attributes" Are any applications (off the shelf, or internal) leveraging Active Directory's Confidential Attributes?

Would you store sensitive information here such as a private key, or a salt here?

I'm planning a demonstration of this feature, but would like to cite as many real world usages, or implementations as possible.

I see that Stanford is using it as part of their bitlocker system recovery process Stanford link

  For computers that are part of the Stanford Windows Infrastructure, a copy of the recovery password is stored with the computer object as a confidential attribute. By default, only Domain Administrators can see confidential attributes, no matter what access is granted by standard ACLs.

Looks like a great feature to leverage for Role Based Access Control but I don't have any examples at hand.


Concerning The OWASP Security Guidelines As They Apply To Site Registration / Could honeypotting work? I'm tossing an idea around in my mind. I want to bounce it off the community to see if this holds any water.

First - the OWASP guidelines never specify any method of action when you're dealing with registrations and password resets. Obviously this has come up a few times in several forums - including stackexchange.

So the problem is really the question of how much security are you willing to sacrifice to keep the frustration level of the user experience low.
After an admittedly superficial mental review of the problem, I'm wondering a few things.

Let's set the stage with example.com, who follow the existing OWASP recommendations to the T.

In the case an attacker has an email address and uses it to attempt to find out whether or not there is an associated user account by attempting a registration. My question is as follows: Suppose you used a hybrid of intrusion attempt detection and a honey pot. So - you have a registration attempt that throws some red-flags in that it is not from a usual IP for that user, not from the usual geographical area for that user, and the client fingerprint is different. Obviously, in the case that a user already has an account, they're most likely not going to attempt to register again.

In the situation where all or most of these red flags are present, why not just allow the intruder to continue with the registration process, all the way to the completion of the account and full setup. Yes, this causes some issues with figuring out how exactly you're going to have 2 accounts with the same username (possibly dictated simply by username/salted_pw as the key difference). But in this manner - the attacker would most likely give up. You could then inform the original user, inform them and get their verification, and keep the honeypot account indefinitely until either A) the time dictated by the site before the account is closed due to non-use has passed or B) the attacker continues to attempt creating honey pots in hopes of finally landing on the real account. In this case, you could simply say - after 3 false accounts, that user is then banned for site abuse (but the real account is kept open for the user - informing the user of the issue - suggesting some actions to better secure the account and putting the account under close watch). Password reset would follow a similar honeypot-like path.

In this case - can anybody see any major issues or problems with implementing something like this? I mean - from a security standpoint - would this actually be a feasible method of deterring such attacks while keeping the user's anonymity?

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

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

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

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

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


What is an XML round trip vulnerability? I keep hearing about the XML round trip vulnerability in version 3.2.4 of the Ruby package REXML. I looked into it myself, of course, and it seems to have something to do with parsing an XML document, then putting it back into XML again, and it coming out incorrect or just different than the original.
Presumably, it can be different in dangerous ways.
Is that correct? Can someone link me to resources that explicate this kind of vulnerability, or perhaps help me (and anyone else in the future) understand exactly how this works?
Thanks!

Sigh. I figured it out by reading the HackerOne post that was right there in the Ruby link in my original post.
It's exactly what I thought - you can cleverly form XML that will be parsed and come out differently than expected, sometimes in dangerous ways.
I highly recommend reading the HackerOne post for a very clear explanation, but anyone else who cares to simplify feel welcome to post an additional answer here and I'll accept it.


during change of IP address - adware infection I have a puzzling situation. I have build a small site for a friend which I am hosting together with other site I have. His domain is registered with a certain company which is also an ISP provider.

During the redirection of his domain to the site (this is with hostgator) I tested the site and instead of the site I got an adware type looking website. Also the Laptop I viewed the website with was diagnosed after that as being infected with adware. The funny thing was that the site could be seen fine from other parts of the world even from where I am if I used a different ISP (y viewed on my phone via my phone network) or through a proxy. But I was always redirected to an adware site if I viewed it using the company in question (one with whom the domain was registered with also the ISP provider).

I have cleaned my PC and now the site can be accessed just fine. I also run an anti-virus check on my site and it was all clear.

Also my friend was also infected with an adware while he must have browsed the webpage to check for the redirection being done. So now when he tries to go to the site he gets redirected to some page with ads.

So my question is: Is it possible that the ISP was infected and (1) that infection affected the domains that go via their proxy? or (2) that affected only the site whose IP redirection was in progress. Maybe while the IP address propagation was taking place - and while we requested the site - an adware could have sneaked in?

I am puzzled by the whole thing.

Is anyone familiar with what I am describing? Sorry if this sounds puzzling.

Thank you
Amelia

Your ISP cache DNS redirected you to a different IP, most probably its a new website and it takes certain time to refresh DNS records on any DNS server depending on their configuration and DNS TTL as well as on your laptop OS.


Why did Stuxnet have command and control servers? I am currently reading Countdown to Zero Day which, amongst other things, describes Stuxnet in lay terms. It states that Stuxnet could report to two command and control servers.

Most basic definitions say command and control servers allow a hacker to communicate with or through the malware that's phoned home and as such they can do mischief on the infected machine.

If the Natanz facility was the only target of interest and if it was air gapped then you can't do any of this. Furthermore, Stuxnet was self sufficient in its objective - it didn't need any further interaction once it had found a suitable target.

Other than being made aware of when the cat is out of the bag, why would a hacker need command and control servers for malware that primarily shouldn't have ever made it on to the internet?

You have 2 questions here. Let's start with the basic one:

  Why did Stuxnet have command and control servers if it was supposed to infect airgapped computers

The CC servers had multiple functions, which is mentioned in the same book your reading if I remember right:

1: Kill Switch. The entire operation could be killed with a kill switch on those servers in case of incident.

2: Time verification: the CC servers updated the time for the stuxnet virus so it wouldn't get confused and shut down (it had multiple kinds of timers built in)

3: Tracking, which is probably the main reason. These servers allowed for the monitoring of the spread of the infection.

4: Other metric collection.

5: Version control. Yes, when a new version of stuxnet was released the CC servers literally told the old version to destroy itself.

Question 2:

  why would a hacker need command and control servers for malware that primarily shouldn't have ever made it on to the internet?

They wouldn't. Stuxnet's original intention was mass infection. 70% of computers in Iran were infected. The hope was to infect the country so effectively that they were insured of a worker bringing in a flash drive with it. If the goal had been a one off sneaker kit drop it's much, much, less likely it would have CC servers.


ArcSight logging - Windows Workstations I am reviewing a security configuration for Workstation security log review, we have an environment wherein the logs are captured and sent to ArcSight tool for analysis. However, how do we validate from the Domain Controller policies or Workstation logging settings to ensure the right security events from the workstation and user log-ins are being monitored.

The review involves other configurations as well for Workstation firewalls, HIDS and DLP settings etc. which are being addressed separately.

It ultimately depends on what you mean by "being monitored".

Here is a list of checks that you may need to make:

- Does the workstation respect its logging / policy configuration? Normally you should be able to trust that this is the case, i.e. that it raises the events that you expect given the configuration. There might be surprises in store though: I experienced the case where failed login was not getting logged - because we were using smartcards and the smartcard integration with Windows did not allow this event to be raised (the Bad PIN login failure was handled inside the smartcard and not exposed to the operating system)

- Has the workstation got the right logging / policy configuration? This depends on your requirements. I would verify that the configuration is applied correctly using a combination of provoking a subset of events that it is easy to provoke (successful login, failed login, for example), and examination of the security policy in the workstation local policy.

- Are workstation events being centralised to ArcSight? If you create an Active Channel from the smart connector that is monitoring the workstations, you should be able to see whether there are any events originating from each workstation.

- Is ArcSight filtering any events out at the point of import? Examine the smart connector configuration in ArcSight: you can check this from the Default tab of the configuration, then the Filter tab.

- Is ArcSight configured to react to particular events or chains of event? This depends on what correlation rules you have configured. The rule Conditions need to encompass workstation events. Only you know what you need to monitor. I presume you have been through the process of deciding this and then defining the correlation rules accordingly. If you want to test your rule set independently of the operational system, using synthetic events, then I believe that ArcSight provides the means to do this in a "sandboxed" fashion.


Using single or double quotes to prevent XSS and SQLi? Why it is recommended to put single or double quotes around HTML attribute values? It is recommended to prevent XSS, but why?

Same goes for SQL injection: It is recommended to use single or double quotes while declaring input values in a query?

What risks are associated with declaring unquoted input values in a SQL query or HTML attribute?

Without quotes, the payload would escape the actual attribute's value and will start a new attribute with its own payload:

Whereas with quotes it will remain a harmless single attribute value:

Note that to prevent XSS you must encode the special characters inside the value as well.

For the SQL injection the situation is different. It is strictly not recommended to declare input values in the query in the first place.

To prevent an SQL injection, a parameter must be defined in the query in place of the actual value, which must be sent to the query execution separately:

$stmt->prepare("SELECT * FROM t WHERE id=?");
$stmt->execute([$id]);

Therefore, there must be not a single quote in the query related to the dynamically added value, which makes the question on quotes just irrelevant.


find passphrase on encrypted ssh private key I have an openssh encrypted private key. I don't remember the pass-phrase. I may be able to suggest words or patterns that may be in the phrase.

I am looking for software that will help me recover the key.

I am thinking of a tool that can generate a stream of pass-phrases, based on my hints, a dictionary and some randomness. Then piping this into something like expect and ssh-add.

Can someone tell me what tools are available.

I am running Debian Gnu+Linux.

ps. next I will look at a way to not forget my pass-phrase, and a more secure encryption.

John the Ripper supports cracking SSH private key passphrases. If you provide a dictionary it will be even faster. Alternatively, you can also use Phrasendrescher.


Is KeePass a good defense against keyloggers? KeePass is a program in which you can store your password and copy and paste them into websites. Does anyone know if it is safe against key logging software? Does key logging software pick up what you copy/paste?

The point of keepass is not to prevent keyloggers.  (Granted incidentally it will almost prevent hardware keyloggers; someone inserting a keylogging device between your keyboard and computer will not be able to observe a password you used once via cutting and pasting.  It doesn't really succeed in this task though, as an attacker could trivially record your login details as well as the passphrase used to unlock your keepass file and then access all of your passwords).

It's main benefits are:

Never reuse a password (every site has a unique password), so if a password at example.com is leaked your other passwords are not compromised.  Never accidentally enter the wrong password at the wrong site if you can't remember which one you used.
Easy to generate strong random passwords at each site; e.g., 20 random upper/lower/numbers/symbols for each site, without difficulty of copying, or difficult to remember to clear your history.
Easy to protect with one global strong passphrase and keep in a strong encrypted file that you can back up and sync among your computers.  (And it doesn't lock you into one web browser or OS).

The major downside is that you shouldn't have any applications that record your clipboard history while using keepass.


Hierarchical Key Rotation. Should I rotate the lowest level keys? I have a hierarchical key system designed for my project. In this system a block of data is encrypted using a Data Encryption Key (DEK). This DEK is encrypted using a Key Encryption Key (KEK) which is encrypted using a Master Key (MK). The KEK is used to encrypt multiple DEKs.

Figure 1. The key hierarchy
Now, when I have to decide on the rotation mechanism, rotating KEK and MK seems straight forward, I'm a little confused whether I have to rotate the DEK as well, which would involve re-encrypting many blocks of data again.

NIST thinks you should.
NIST SP800-57 Part 1 "Recommendation for Key Management (Part 1 - General)" lays out definitions and recommendations for encryption keys and their management.  Under §5.3.6 Cryptoperiod Recommendations for Specific Key Types it covers DEKs:

Symmetric data-encryption key:

a. Type Considerations: A symmetric data-encryption key is used to protect stored data, messages, or
communications sessions. Based primarily on the consequences of a
compromise, a data-encryption key that is used to encrypt large
volumes of data over a short period of time (e.g., for link
encryption) should have a relatively short originator usage period. An
encryption key used to encrypt less data over time could have a longer
originator-usage period. The originator-usage period of a symmetric
data-encryption key applies to the use of that key for encrypting
information (see Section 5.3.5).

And Table 1 with the suggested cryptoperiods says:

Key Type
(Cryptoperiod) Originator-Usage Period (OUP)
(Cryptoperiod) Recipient-Usage Period

6. Symmetric Data Encryption Keys
<= 2 years
<= OUP + 3 years

Yes, re-encryption becomes part of the lifecycle when rotating DEKs.  Maintaining multiple DEKs allows you to break up re-encryption and not be forced to re-encrypt the entire data set at one time.


What should I consider as a security opt-in? I'm developing update4j, a Java based update and launch framework. I recently had a small dispute with a fellow contributor and I want to straighten things out.

I as few words possible; there is a client side updater that reads a remote "configuration" file. That file contains all information required to download the application files.

Additionally, there's an opt-in feature to sign files and verify each download against a public key. This should prevent hackers from changing files in the configuration or modify actual remote application files. In the config, next to each file a signature field is added and used by the client-side updater to verify against a known public key provided at installation.

Now, I considered developer opt-in if the certificate/public key is used in the updater when requesting to perform an update. Otherwise, the updater completely ignores the signature field. But they claim that if the config contains signatures, this by itself is considered opt-in and should force the updater to verify, and if the updater was never aware of any public keys and never asked for it, it should fail.

To quote:

  No local certificate provided

  If the config contains signatures (so the provider intends to secure the update), but no local certificate is provided, update4j downloads the configuration, the files and runs it. In my opinion, this is not secure.
  See src/test/java/org.update4j.integration.SigningTest.noCertificateWithSignatureTest()

From my perspective this feels unnecessary. The "provider" is usually the same development team of the client-side updater (at least they decided how to set up the updater). If a hacker could access files or the config itself and modify it, the "provider" no longer seeks security. If they change things knowingly that the updater never requires any signatures, why in the world would that hacker add the signature field? Additionally, it makes it really hard to add security for only some installations (say a testing feature) since you would have to add a signature but now it will blow up the old clients.

The only case I could agree would be unsecured is where the config itself was not hacked, only the remote files. Here the provider would still want to verify the files. But remember, the dev team never looked for security since they didn't configure the updater to check for signatures.

How would you handle such a case?

I would provide a user-side configuration option to control what to do, with three possible settings:

Check only if a signature field is present.  This option should be the default, and lets the user defer to the publisher as to whether or not to check the signature if present.
Always check, and issue an error if there is no signature field. This option is for those users who want (or need) to ensure code integrity, and don't trust the publisher to require it.
Never check.  This option is mostly for developers or internal usage, and should probably have a big warning on it.

Most users will leave things at the default, and therefore will get checking if the update provides a signature, and none if it doesn't, while those who need to force enable or disable checking can do so.

You might additionally consider providing something equivalent to the Strict-Transport-Security header in HTTP.  Essentially, if some flag is set in an update that's been signed, future updates for that same piece of data must also be signed or they won't be accepted, even if they don't have a valid signature field.


Legality of cookie(set by other sites) tracking I have created a website A  which asks username & password, there exists another closed source website B which again asks for login credentials.
A user uses both these websites .I want to implement SSO a way so that if user authenticates on website B then my Website A allows user to bypass the login interface.   For that will have to check a valid cookie set by website B on client browser(javascript) & decrypt (in case the cookie is encrypted). But i want to know that
:-

Is it legal to read  the cookie set by other websites (in my context) ?
Is it legal to decrypt cookie to check(not alter cookie data, just non malicious read ) data ?

can the owner of website B me sue the owner of website A legally ?

Unless "website A" and "website B" are both subdomains of the same domain, what you want to do is impossible; if they are subdomains of the same domain, the same person or organization presumably controls both.  Consequently, legality is irrelevant.


SSL (TLS v1.2) - Can i offer fallback CAs when upgrading Certificates? (Java) I am currently developing a product that involves two network situations.
At the client side, multiple computers form a P2P network (multiple locations, multiple p2p networks), and a subset of nodes of each network establish a connection with a subset of servers we host (for data exchanges, updates).
All servers and clients have certificates, signed with a CA certificate.

My problem now is the updating of (intermediate) CAs. I cannot ensure a simultaneous update of all machines at once (also for failsaves, a transition time would be appreciated), and so there has to be a period of time where multiple CA certificates are valid, a legacy version which will run out in non-negligible time, and an updated version to replace it.

Since the client waits with its authentication till it has recieved the server cert, it can react to an outdated CA and send it's own legacy certificate chain, and because the connection in the p2p networks will be attempted in both ways, I can ignore the case where a legacy client meets an updated server and just wait for it to happen the other way round.

But that does not work for the central servers, because the clients might hide behind a NAT Layer, also it would seem ugly to me to turn around the connection in a real client-server model. Just working with the legacy certificate until day x without offering a smooth transition seems risky to me.

So here finally the question, is it possible for an SSL server to offer a fallback certificate in case the current (intermediate) CA is unknown by the client.

I have two ideas for workarounds (on failure, remember the client's ip and send a different certificate on retry, or run the service on different ports with different certificates), but since updating CAs is an actual thing, i guess there should be be better solution.

Please enlighten me.

The solution is: do nothing.

SSL servers and clients send their certificates as chains precisely because they cannot assume that the peer will already have all needed intermediate CA certificate. The whole point of certificate chains and intermediate CA is that a "relying party" (X.509 jargon meaning here "a client or a server") can validate a chain, any chain, as long as it already has the trust anchor, which is also known as "root certificate" or "root CA". I.e. the CA which is not an intermediate CA.

For instance, assume that there is in your system a root CA which everybody knows a priori (that's what root CA are for). Then there is the "old intermediate CA" called CA1, and the "new intermediate CA" called CA2. The server previously had a certificate S1 issued by CA1, but now has a newer certificate S2 issued by CA2. A client connects. What shall the server send ? Well, the server just sends the chain CA2->S2. The client might never have seen CA2 before; it does not matter. CA2 is issued (signed) by the root, and the client knows and trusts the root, so the client can verify the signature on CA2's certificate, and thus learn that CA2 is a valid intermediate CA that the client just had not hitherto encountered. Certificate validation then proceeds with the verification of the signature on S2, by CA2. Things just work.

X.509 certificates work in a hierarchical PKI model in which actors need to be aware of root CA, and of nothing more. These certificates have been designed for the exact purpose of avoiding the problem you are envisioning, i.e. distribution of intermediate CA. Any client (or server) can dynamically build any required trust chain based on whatever certificates it has at any moment, and since certificates are chained, how they are obtained is not important. In particular they can be received by the peer, and this transfer requires no additional trust.

So as long as all servers (and client) send their certificates as part of chains which are valid at that time, validation will work.

Now if you were talking about updating a root CA, then yes, that would become tricky. Trust is transported through the signatures on certificates; but it is not created out of thin air. It has to start somewhere, and that somewhere is an a priori, intrinsic knowledge of a trust anchor. To sum up, you really don't want to change your root CA often, because it is a mess. A root is supposed to be very long-lived. And this implies using intermediate CA, because a very long-lived root is a precious thing, so you really want to keep the root CA offline, and to use it as little as possible.


Linux Security of typing passwords via xdotool vs keyboard driver vs other solutions I am looking for quiet universal solution how to approach software keyboard for typing passwords under Linux.

Security level expectations:
Achieve not worse (or acceptably slightly worse) security than when passwords are typed to applications on physical USB keyboard.
(as in worst case it's starting point for many applications does not supporting more advanced means, and also, I can make/buy hardware password manager acting as usb keyboard as alternative).

The scope of my concern here is comparison of attack vector/risks of solutions based on USB keyboards or keyboard drivers vs just typing them via xdootool type ?
(to unaware readers : copying passwords via clipboard has vector attack that any of your applications can read it)

Please note to all readers of question:
If your machine is compromised, there are plenty of ways your passwords or keys can be leaked: including stealing them from programs' memory.
Here I would like to consider what's "reasonable" method of transporting passwords (definitely I am looking for something better than via clipboard), while considering tradeoffs in mind (yes, keep hardware keys, etc, whenever you can, however not all systems support those more advanced means of authorisation).

Any application that you've run at least once can, if it wants to, see everything that you type, read all your files, and extract your passwords from your password manager. All it has to do is inject itself somewhere into the system:

To see everything you type: connect to the X server and ask. (To see how, run xtrace xinput test 42 where 42 is the device ID of your keyboard.)
Alternatively, grab the focus without giving any visual cue (and retransmit the input to the application that looks focused, to avoid immediate detection).
To read all your files: open, read.
To extract your passwords from your password manager: read the password database file and listen in while you're typing your master password. Alternatively, inject a wrapper around the password manager process and ptrace it.

Yes, in theory you could notice it. But in practice, you won't.

Putting password in the clipboard does have weaknesses, but local applications are not the problem. Local applications can get your passwords anyway. The main weaknesses of passwords in the clipboard are:

Browser bugs that allow web applications (i.e. any open browser tab) to access the clipboard.
Clipboard managers that retain a copy of the password in a place you wouldn't think of.
Accidental pasting into the wrong field.

The safest way to manage passwords is to avoid manipulating them. This eliminates the risk of user error. So save your passwords in your web browser and have it use the password automatically.

For non-web uses, injecting keyboard input with xdotool is as good as it gets. Local applications can get the passwords anyway, so you aren't losing anything.


What secure RFID standards are there; for high value item inventory? I am wanting to use some RFID devices to help with inventory management of some high value items (paintings).

The paintings are packed in wooden transport cases, awaiting shipment. Periodically we, have some one from security, scan the barcodes on the cases to ensure the correct items are where they are supposed to be.

However it turns out it is trivial to peel a barcode off one case and put it on another...

I am looking to physicaly atatch a RFID tag to a painting so we can check the correct one is in the correct case, without having to open it every time.

Now I understand that there are different kinds of RFID tags, some more secure than others.

Some are 128bit serial numbers. That doesn't sound much better than a barcode, and easy to copy and spoof.

Are there any other RFID tags which say have an internal counter and digitally sign the current count of reads? Or something like that?

So I guess what would like to know is what should I be looking for (features, standards?) in RFID tags, which would indicate it is reasonably secure against copying?

I've done work with class 1 gen 2 UHF tags in the past that regulated read/writes to memory with a password. Not sure how well (if) they protect against e.g. brute force but the understanding around our shop was that they're reasonably secure against tampering/cloning (although I'm not sure TIDs are as difficult to spoof as some would like to believe).

Like most everything though it depends greatly on your particular threat model.


How do hardware OTPs work? I've recently stumbled across a number of one-time-password (OTP) smartcards in some of the internet shops specialized on cryptographic equipment.

Now I know / think to know how OTP works with YubiKeys and RSA tokens:

You get the token, a shared secret with the production server is hardcoded
You do something with the token and he gives you the OTP (via display or simulated keyboard)
You send the OTP to your app which in turn asks the manufacturer's server if the code is correct
You successfully authenticated if the server responded "yes"

Now do actual cards (like the Gemalto MD 830) work the same way, e.g. hard-coding the shared secret andf requiriung online servers by the provider or how does the secret get onto the card?

Furthermore how is the generated OTP moved from the card to the computer? Will it be displayed so the user can copy and paste it? Does it require additional hardware (except for the PC connected reader)? Must it be fetched by the software?

Note: For the paragraph directly above, I'm explicitely talking about cards that don't feature a built-in display.

The smartcard based systems like the product in the link you provided are based on PKI (public key infrastructure) which is a means to authenticate a user based on their ability to sign something with a private key (held on the smartcard) that can be proven with application of the public key.  Since the private key never leaves the card (at least, in fully secure implementations) it is a means to guarantee that the user does have the card since there is no practical way to duplicate it and it is challenged to prove itself during each sign-on.

So, the RSA SecureID has a similar purpose (proving the user has the object in their possession, and is impossible to duplicate) but is not as robust because the smartcard can interact with the OS, to do things like force the user to log out if the card is removed from the computer, and provide other cryptographic functions like signing emails.

In the case of the keyfob, the "private" section is still known to RSA (or whoever issued the fob) because it is needed to validate the code.  In the case of the smartcard, the private key could (should) only exist on the card, and the public key is used to validate the card.


Authentication on remote, unmanned, unconnected machines/devices What proven methods exist for authentication of a user on remote, unconnected machines/devices where establishing unique login credentials for the users isn't practical due to the number of machines/devices?

We have an application where we have a large number of industrial devices distributed around the world and we'd like to secure these so that only authorized technicians can access them and retrieve the data. These aren't always connected to network and they are often left in unmanned locations, so physical security is not something that can be counted on and authentication with a server isn't possible.

I'm sure this kind of challenge has existed for decades, and while I've seen many really bad attempts at solving this (e.g. a single password for all technicians) I haven't personally encountered anything that seems both robust and elegant.

I suppose an encrypted certificate that requires a password (albeit shared) would be a step in the right direction. This weak 2-factor method would require the technician has something (like a USB key w/ cert) and it prevents immediate exposure of the certificate if the USB key is dropped in a parking lot but I'm wondering if there's something better.

What scares me about this is the high probability of a foolish person creating "password.txt" and putting it alongside the cert...

Thanks for your thoughts.

So I think that, given the lack of physical security of the devices, whatever you do will be only best-effort. You just can't stop someone from stripping the device down, reading the data, modifying it, etc... Let's just take that as a given and move on.

This solution utilizes HMACs. An HMAC takes two inputs, a string and secret, and produces an output string that is cryptographically difficult/impossible to forge without knowing the the secret.

Put on all devices a shared secret (the same one) that is also known by the device administrators (they're the ones who give out authentication information to technicians). As the device is not physically secure, the storage of the secret will be less-than-perfect, but we already agreed that we'd be OK with this.

An admin will give a user a username and a password. The password will be the result of HMAC(secret, username) (possibly truncated to some reasonable length). When the user logs into a device, they will enter their username and password. The device will recalculate the HMAC, truncate it to the appropriate length, and compare it with the user's password.

Depending on your needs, you can make some changes to the system:

Instead of storing the same secret on every device, you can store different secrets. This will, of course, increase administration costs, but it will add some security. You could give each device its own secret or group devices by geographic location, issue date, or other means.
Along with the username and password, you could give each user a password expiration date. They would then enter their username, password, and expiration date when logging in. Their password would be HMAC(secret, username + expiration date). The advantage of this is that passwords naturally timeout so an exposed password won't haunt you forever. The disadvantage is that users will need to continually get new passwords. Unlike more typical password expiry, users will need to contact admins to get their new password. Here too the lack of physical security may allow attackers to reset the date on the device, reactivating an expired password. Again, we agreed that perfect security won't be possible without hardware security.
Depending on the flexibility of the device, you may be able to move the credentials to a USB drive, SD card, or some other device that can be used for authentication. An encrypted USB key like this one will provide you with 2-factor authentication.
With each user having a unique login, you can implement some type of auditing.

Notable problems with this system include:

Inability to disable a password. Even if you use the date extension, you need to wait for the password to expire.
Unless you use a secure USB key (or similarly secure device) for authentication, it is still open to users creating "passwords.txt" files.
The lack of hardware security greatly reduces any security efforts.


Do applications installing into AppData folder make UAC useless? When UAC was first introduced, most well-behaving applications were installed into Program Files folder, so any tampering with executable files without explicit user consent became impossible. So when a user executes a malware application, only this user's data could be destroyed.

However, a lot of applications are installed into AppData nowadays. Some applications want to make installation for restricted users possible, some applications don't want to ask for user consent every time they are autoupdated. Other apps ask for administrator rights during installation, put their files into Program Files, but change permissions of their folders.

Some examples:

Google Chrome is installed into AppData. I've installed it into Program Files, but later found out it actually uses executable in the AppData folder.
Valve Steam gives full access to SteamApps folder for all users during installation. This folder contains executables and data of all games managed by Steam.

Okay, Google Chrome doesn't seem to ask for admin rights, so if during its work it shows UAC dialog in yellow color, it'll be highly suspicious. But Steam games regularly ask for admin permissions when being run for the first time. Users will blindly say "Yes" to any dialog which appears during installation. And the result? The whole system for all users is compromised.

Applications like this seem to make UAC even weaker, even easier to bypass. Any executable file can change executable files used by all users. I guess PCs with multiple users with admin rights is insecure by design, but UAC provided at least some protection in this case.

How does this affect security and should I worry about it? If yes, can I do anything about it?

Applications installed using something like the "for myself only" option go in that user's AppData folder.

Malicious software run from another non-privileged user's account cannot (without exploiting a vulnerability) damage content within the AppData folder of another user if the system permissions haven't been misconfigured.  The defaults leave this location secure against trivial tampering by other user accounts.

If you want UAC to be effective, then nobody can log in regularly to their workstations as administrators (even local administrators) as it breaks the model.  Emergency local admin accounts may be needed for practical reasons and you can use LAPS (Local Administrator Password Solution) to achieve that.


What exactly constitutes a scanning-threat on a Cisco ASA? TL;DR - Can anyone describe exactly what constitutes a scanning-threat hit, when using threat-detection on a Cisco ASA?

I have a client who connects to my network via a VPN to reach a hosted application, and has recently fallen foul of the configured firewall policy and swears that they are not doing anything different from usual.

The ASA is configured to temporarily block (shun) network addresses that exceed any of a series of rates.

threat-detection rate scanning-threat rate-interval 600 average-rate 5 burst-rate 10
threat-detection rate scanning-threat rate-interval 3600 average-rate 4 burst-rate 8
threat-detection scanning-threat shun except object-group SCAN_WHITELIST
threat-detection scanning-threat shun duration 900

Business demands have required me to whitelist them for now, and this will likely continue unless I can explain better what they appear to be doing wrong.  I presume the client not to be a bad actor since it's not in their interest to block themselves from the service we give them.  I'm not looking to catch them out, nor accuse them of anything underhand.

My other alternative is to re-evaluate the rates (we are simply using the defaults), but that also requires that I understand what I'm permitting.

All documentation I've found so far describes scanning-threat in terms of 'when the ASA detects a scanning threat...', but I can't find anything that explains what constitutes a scanning threat, i.e. what event(s) cause the scanning-threat counter to increment?

I could guess that it might be a series of connections with an incrementing target TCP port and that may be the case, but it doesn't seem likely for good-faith end-users, who have been told exactly what time their problems started.

I could guess that it might be a series of connections with an incrementing source TCP port, but surely many PAT-based traffic managers would fall foul of this (without adequate source-port randomisation)?

Since this is unfiltered VPN traffic (and sysopt connection permit-vpn applies), this traffic does not fall foul of a particular access-list, otherwise I might see the explicit dropped traffic in the log.

The client, themselves pre-NAT their traffic behind a single address prior to traversing the VPN, so all traffic appears to come from the same source address -- so, when it is shunned, all access to the hosted application is lost for a number of minutes.  The subsequent shunned packets are logged, and appear to be normal for the application -- pings and tcp/443.

TL;DR Scanning-Threat should not be thought of as a new feature, more of an enhancement to Threat-Detection.

I think these links could possibly help you, however considering you seem to have done the research you might've already come across them

Threat Detection Configuration

Threat Detection Cisco

Here is a list of what can cause a Threat-Detection trigger:

ACL Denial
Bad Packet Format
Exceeded Connection Limits
Denial of Service (DoS) Detection
Basic Firewall Check Failure
Suspicious ICMP packets Exceeded
Application Inspection Packet Failure
Interface Overload
Scanning Attack Detection
Incomplete Session Detection

A Scanning-Threat is not the same thing as Threat-Detection, you need to think of Scanning-Threat as an enhancement/addition to Threat-Detection to provide additional security capabilities. It allows you to keep track of "suspected attackers" when too many connections are created in a subnet and by default this feature is disabled.
A nice thing about Scanning-Threat is the fact that it builds a database of target IP addresses that are suspected to be an attacker. As per the Cisco documentation, below is a nice example of what Scanning-Threat can do.

When Scanning Threat Detection detects an attack, %ASA-4-733101 is
logged for the attacker and/or target IPs. If the feature is
configured to shun the attacker, %ASA-4-733102 is logged when Scanning
Threat Detection generates a shun. %ASA-4-733103 is logged when the
shun is removed. The show threat-detection scanning-threat command can
be used in order to view the entire Scanning Threat database. - Cisco Scanning Threat