Restrict file access in php.ini Can anyone explain me the difference between include_path and open_basedir in PHP? My php.ini looks like this:

include_path = ".:/usr/share/php:/usr/share/pear:/var/www"

If for example I try using include('../../etc/passwd'); the file will be included. On the other hand, when I'm modifying my php.ini like this the output is empty:

open_basedir = /var/www

Why is this? I thought that using include_path will restrict the file access to the directories listed there?

The include_path directive is a list of directories to look for included files first, similar to bash's $PATH environmental variable.

So an absolute file name/path like this:

include_once('/var/www/domain.com/htdocs/includes/header.php');
include_once('/var/www/domain.com/htdocs/includes/footer.php');

Can be replaced with a relative filename like this:

include_path('/var/www/domain.com/htdocs/includes:.');
include_once('header.php');
include_once('footer.php');

This is at least how I understand it. It has nothing to do with security and restricting directories, it is to create a custom search path for common includes.

open_basedir is what you are looking for, it limits the reading of files to the directories specified. Based on your question, it looks as though it is operating as designed.


Is RSA-SHA1 secure enough for licensing? We have to do a licensing system. It would be someting like A Ready To Use Software Licensing Solution in C# [CodeProject]

But our client is worried about the SHA/SHA1 "weakness".

I've searched the web about this, but the only thing I found is the Schneier estimated cost to break it.

But I do not know what is needed to break it.

Does attacker need the public key?
Are message and signature enough?
If code will be broken, what would attacker get? (I supose he would get the private key and he could create new signatures.)

SHA-1 is broken. When you use SHA-1 to verify the signature of your license files then an attacker can generate a license file which will pass your verification algorithm in reasonable time. Anything they need to do that (your verification algorithms and any shared secrets) must be a part of your program, otherwise it couldn't do offline verification.

But there are many other hash algorithms you can use as a simple drop-in replacement. When the hash algorithm has no considerable weakness and your license keys have enough entropy (long enough completely random and unique part) it doesn't even need to be a particularly slow algorithm, because brute-force attacks are unfeasible. You could, for example, use one of the algorithms from the SHA-2 or SHA-3 families. Despite the name they don't have much in common with SHA-1, so the vulnerability does not apply to them.

However, your client should rather be worried about a cracker releasing a patch to remove your license checking code from your programs binary altogether. In practice, copy protection is rarely effective against a determined attacker. When it runs completely on the users machine then it can't be 100% effective, because it runs under the users control. It mostly works by making piracy less convenient than buying, not by making it impossible.

Which brings me to another important consideration: The best copy protection is making the product easy to buy. The more hoops you have your user jump through to get and apply a proper license, the more likely that they will look for "alternative methods" to get it to run. The steps mentioned in the article linked in the question (user tells vendor device-id, vendor replies with license file...) sound far harder than googling "JMA's program crack download".


Why can't you work backwards with public key to decrypt a message? As the title suggests, I am curious to know why you can't work backwards using a message, public key and encrypted message to work out how to decrypt the message!

I don't understand how a message can be encrypted using a key and then how you cannot work backwards to "undo" the encryption?

There are one-way functions in computer science (not mathematically proven, but you will be rich and famous if you prove otherwise). These functions are easy to solve one way but hard to reverse e.g. it is easy for you to compute 569 * 757 * 911 = 392397763 in a minute or two on a piece of paper. On the other if I gave you 392397763 and asked you to find the prime factors, you would have a very hard time. Now if these numbers are really big, even the fastest computer in the world will not be able to reverse the factorization in reasonable time.

In public-key cryptography these one-way functions are used in clever ways to allow somebody to use the public key to encrypt something, but making it very hard to decrypt the resulting message. You should read the Wiki article RSA cryptosystem.


Is this redirect on my website dangerous? I have this URL that I sometimes use to redirect my users. It looks like:

https://mywebsite.com/?redirectTo=

However, I'm checking if the domain part of the  parameter ends with:

google.com
mydomains.com

and some other domains I consider valid.

So. Can someone can and hack my website if I have those checks in place?

While it is impossible to tell as you have not supplied any source code. I would say, maybe, if you are just checking the website as a sub-string to see if it is valid, have you considered the following?

https://mywebsite.com/?redirectTo=maliciouswebsite.com#google.com
https://mywebsite.com/?redirectTo=evilgoogle.com

There are many ways to get around the restriction of just validating the end of a string. It would be much better if you whitelist the exact domains that are accessible rather than relying on regex.


Secure wiping of EEPROM and flash memory Older magnetic storage exhibited some data remanence, so a recommendation emerged to wipe data by overwriting it multiple times with varying patterns — the “Gutmann wipe”. More recent hard disk technology does not require such precautions.

What are similar known results for EEPROM and flash memory (whatever the difference is)? Specifically, I would like to know the origin of the following rules for key erasure in the Mobile Operating System Protection Profile (§4.2.1 FCS_CKM_EXT.4.1), which unfortunately does not come with a rationale:

  For non-volatile EEPROM, the zeroization shall be executed by a single direct overwrite consisting of a pseudo-random pattern (…).
  For (…) non-volatile flash memory, the zeroization shall be executed by a single direct overwrite consisting of a single direct overwrite with zeros (…).

[Related: Why is there a difference between EEPROM and flash?]

EEPROMs work by storing charge in floating-gate transistors. Think of these transistors like tiny capacitors that leak extremely slowly (typically with retention lifetimes of 10+ years), except with the added provision that you can tell whether it's charged or uncharged. Programming one simply involves feeding it a power source and pulling the gate to high or low voltage for a short time. The internal mechanism is called tunnel injection. If you leave the gate "floating" (i.e. neither connected to ground or positive voltage) after disconnecting the power, it remains at the stored value.

Clearing the data on an EEPROM should simply involve setting it all to uncharged. However, tiny ferrous impurities in the die and connectors may have sufficient magnetic susceptibility to remain partially magnetised by the tiny electric field produced by the held charge. By analysing this magnetisation, it may be possible to deduce latent data. As such, writing random data may provide sufficiently overbearing charges to prevent analysis. However, a better option would be to set all cells to 1, then 0, then random. This is because there may be cases where tiny magnetisation deltas are useful to an attacker, which are guaranteed to be destroyed when all cells are charged then discharged.

Flash memory is a different story, and actually uses two different technologies. NAND flash is common, as is NOR. Both types only allow writes in blocks (or "pages"), though typically NAND blocks are much larger than NOR blocks (which are usually a byte).

NAND flash is very similar to EEPROMs in terms of construction, in that they use floating-gate transistors. However, the transistors are arranged in a series chain. This construction means that two options can be performed: setting a single bit to 1, or setting all bits in the cell to 0. NOR flash works in a similar way, but performs hot-electron injection through a charge pump instead. The most important distinction here is that NOR flash requires the charge pump to produce a very high instantaneous voltage, whereas NAND performs writes at a much lower internal voltage.

As such, NAND technology is less likely to promote detectable magnetisation of ferrous impurities than NOR, but holds about equal risk to EEPROM. I would still recommend the 1, 0, random triple-pass for high security, but a single random pass should be more then enough for anyone not worried about attackers that have access to electrostatic force microscopy equipment.

You should also keep in mind that these attacks are very much theoretical, and I don't believe anyone has ever managed to recover fully erased data from an EEPROM.


How is the iCloud keychain protected from unauthorized access? With OS X Mavericks and iOS 7.0.3, Apple has introduced a new feature called iCloud keychain.

During setup, you can choose an iCloud Security Code. This code is used when you want to grant access to the iCloud Keychain on new devices.

Although Apple states that it does not have access to the contents of the iCloud Keychain, I was not able to determine how exactly the keychain is protected.

So my question is: Which key/code/password is used to encrypt the contents of iCloud Keychain? Both locally, and when it is transferred to the cloud.

If it is just protected by the iCloud Security Code, which is by default a 4 digit number, I would not feel very comfortable about it.

Cheers

You're right to have doubts about the security of a four-digit pin code - whatever Apple does to protect your Keychain data, at least somebody within Apple would always be able to perform a brute-force attack for all 10000 possible digits with very little effort. It's simply not possible to protect against a parallel brute-force with such a low-entropy input, no matter what KDF you use.

Since the implementation is proprietary and closed-source, everything about the actual workings is speculation, so please take the following speculations with more than a grain of salt. That being said, here is how a service like iCloud Keychain could be implemented in a way that is consistent with Apple's public statements.

The Keychain contents really seem to be encrypted with a client-side symmetric key; probably only an encrypted version will be uploaded to Apple's servers.
Adding new devices probably happens via public-key cryptography (granting a "new device" requests could encrypt the symmetric key with that device's public), but unfortunately allows no fingerprint verification (which makes man-in-the-middle attacks possible, just like with iMessage).
The recovery password will likely be used to encrypt the symmetric key using a key hardening function using a salt and many iterations before it is uploaded to Apple; when using that recovery code, Apple probably uses a hash based on that code to rate-limit recovery attempts before handing out the wrapped symmetric key together with the encrypted Keychain data.

Ars Technica has an interesting article on the subject, and they come to the conclusion that using the suggested four-digit recovery code makes a brute-force attack very feasible - but only for Apple (or somebody who manages to break into their server-side infrastructure).

I've also written about this in a blog post myself, where I come to very similar conclusions.

To sum it up: If you're worried about Apple (or somebody who is able to gain access to their systems, whether hacker or law enforcement authorities) getting access to your Keychain data, use at least a strong alpha-numeric password for recovery or don't use the recovery code at all.


Password entropy in layman's terms Entropy is a term used often in relation to password security and brute-force attacks, but it is a topic that can get complicated quickly. What is the best way to describe password entropy (what it is and how it's calculated) in terms a layman can understand?

Not sure can it be of any help to you, but once I managed to describe entropy to a child.

After I said that entropy is a measure of chaos in system (to a group of people), a 12 (year more or less) year old said he doesn't understand me. I replied with - "Well, when your room is untidy, entropy is high. But when you clean your room, entropy is low - everything is in order then. So, when a thief comes to your room trying to steal your homework, when the room is clean and entropy is low, he will easly find it - it's usually on your desk or in your school bag. On the other hand, when your room is untidy and your homework is somewhere laying around, thief doesn't know exactly where it is and it can't find it quickly. If entropy is high enough (let's say roof collapse), it's almost impossible to find a piece of paper in it.

High entropy - finding a needle in a haystack.

In the game - Guess who I am, at the begging entropy is very high, but after few questions entropy is lower and lower until someone has enough information to guess who the person is (or in security, after trails (and errors) and trials, to guess what is the password).


Security sanity check A company whose services I'm trying to integrate uses this protocol:

An AES key is embedded in an Android library.
To authenticate itself, the library sends a SHA1 hash of the key over plain HTTP.
The response contains an RSA public key encrypted using the same AES key.
A temporary AES key is generated on the client.
The temporary AES key and the sensitive data are encrypted with the RSA key and sent over plain HTTP.

Their excuse for not using HTTPS is that they believe they'd have to pay for a signed certificate on every mobile device they support rather than just on their server.  They also believe that HTTPS adds too much network overhead for use on mobile devices.  Oh, and their system is "more secure than HTTPS" because they're using longer AES keys.  Did I mention this is being used for credit card processing?

I'm trying to convince them that this is utterly insane.  Can anyone point me to a clear, concise explanation that's intelligible to PHBs?  (Or which I could bring to the unemployment hearing if I get fired for rocking the boat?)

Yeah, if you are describing it accurately this is completely broken, to the point of useless.

The initial AES key is compromised by being in the app, anyone with the app has access to the AES key.  If this is global, then it is well and truly screwed, if it is unique to each application, there may be a small sliver of hope.

The SHA-1 is completely replayable.  You mention no salt, but even if there is a salt, the attacker can replay it against a legit client as a MitM and then respond validly to appear as the client to the server.

The server would then provide the attacker with the public key, in encrypted form, which isn't particularly useful to the attacker, but it is also the public key... it is supposed to be public.  Having it private offers nothing.  If the client was ever compromised (or any client if the AES key is global), then the AES key is leaked by the application and the public key is also available to the attacker.

Additionally, if the AES key is compromised, the attacker can send a public key of their choice since the client has no way to verify the RSA public key.

An AES key being generated on the client is a decent enough idea, but so far, there is nothing to prevent the attacker from generating their own AES key.  Additionally, they could likely provide the client with their own public key so they can also fool the client.

Why is the data being encrypted with the RSA key?  What is the point of the temporary AES key then?  Is it really completely unused?  Encrypting long data with RSA is generally considered less secure than using symmetric encryption since it is requires more work to process and may have other security implications, the norm is just to exchange a symmetric key and use that for data exchange.

In short, the system is completely useless.

It would actually be far more useful if they simply embedded the public key of the server in the application and used that to have the client generate an AES key and exchange that for session communication.  It wouldn't validate anything about the client itself, but that could be done through passwords or other tokens after the session is initialized.  At that point you are pretty close to just using a self signed HTTPS though, but it could be used as a custom implementation if HTTPS isn't an option for some reason (such as not being able to add a trusted root certificate on the client devices.)


Detecting C2 traffic over DNS? Let's assume I have a large enterprise network (thousands of nodes) and somewhere on that network there is malware communicating over DNS for C2.  Let's assume the requests are designed such that the traffic is legitimate DNS and doesn't contain obvious commands or other strings that can be trivially detected.  (Maybe it uses A records or AAAA to encode the data.)

It's possible to try to detect the traffic using several techniques:

Look for regularly timed DNS traffic.  (i.e., exactly every hour)
Look for infrequently requested domains -- on a network this large, the malware requests should be the outliers.  (But perhaps there's other traffic that's an outlier as well.)
Look for DNS results that keep changing (but maybe it's DNS load balancing)

Are there other techniques I have not considered?

Most malware that abuses channels (from my experience) includes some form of randomisation in connection timing. Even something as simple as 60 minutes + rand(-5,5) can defeat timing profilers. You will also find that people have some shockingly regular patterns in their browsing habits.
From experience, frequency analysis will produce a lot of false positives in a large enterprise. Everyone's into their own thing and interests shift. Instead, analyse the domains for "infancy". Look up when the domain was registered and look for domains less than 3 months old. Then look for domains not owned by a * Inc. or * Ltd. or who have a "domain privacy shield" in place. Bubble those up for further investigation.

One thing you have not mentioned is comparing the domain with blacklists from a blacklist service. I assume you thought of that, but I wanted to mention it.

Remember that it is trivial for malware authors to adjust to any detection methods that you can devise (like timing analysis). The more robust detection processes require complex statistical analysis on both the destination and the requesting node compared the node's peers and general trends in the local environment (timing, time, frequency, content, bandwidth, mismatched peer profiles (a non-peer acting like a peer)). And even then, it will require further analysis to determine the true positives.

I have developed UEBA algorithms for just this sort of thing, and once you start, you will find yourself down a bit of a rabbit hole ("maybe I can tweak it this way and get better efficiency!"). For 80% effectiveness, focus on the "infancy" analysis that I mentioned above.


Unable to see client to server traffic in MitM attack I'm attempting an MTIM attack on my home LAN just for fun. I am using arpspoof which comes pre-installed with the Linux distribution I'm using. The problem I'm having is I can see the server to client traffic, but not client to server traffic.

These are the IP Addresses in use:

Attacker: 192.168.0.4
Victim (my phone): 192.168.0.2
Gateway: 192.168.0.1

Here are the commands I use for the MitM attack:

Enabling IP-Forwarded in my attacking machine by using this command:

echo 1 > /proc/sys/net/ipv4/ip_forward

Now I use an arpspoof command to tell the computers I'm the gateway:

arpsoof -i eth0 -t victimip gatewayip
arpspoof -i eth0 -t gatewayip victimip

Then I start Wireshark, which is where I'm unable to see client-to-server traffic.

Am I missing a step?

There's a typo in your first arpspoof command (missing the p)

arpspoof -i eth0 -t victimip gatewayip

Check if that command is failing. If so it would prevent you from intercepting I need direction of traffic like you're observing.


Any known cases of government backdoors creating exploitable security holes? As the Apple v FBI battle unfolds, government backdoors will become a hot topic. As background to that, I have two questions:

Are there any known cases where governments have forced tech companies to introduce backdoors into their products? (I'm not talking about accidental security holes that governments have been able to exploit, nor am I talking about companies simply handing over unencrypted data in their posession.)
Are there any cases where a government backdoor have been exploited by other actors, or information on how to use it has become publicly available, thereby creating a serious security threat to the users of the product?

I am interested in examples from all around the world, both new and old. Basically what I want to have is examples to use as an efficient rebuttal to the argument "Well, a backdoor only the government knows about couldn't possibly hurt anyone."

Wiretapping case in Greece 2004–05: officially mandated but disabled interface for tapping into talks was used by unknown entity to listen to talks by high-profile politicians.
Juniper VPN Backdoor: use of NSA mandated insecure random generator together with the modifications added by an unknown party allowed decryption of VPN traffic by third parties by simple passive sniffing.
Backdoor in the cryptography of Lotus Notes used by several european governments. While they got the version with stronger cryptography the NSA controlled part of the key so in effect they got a version where NSA could still decrypt the content.
Government mandated export regulations lead to the EXPORT ciphers in SSL. These ciphers were used outside the USA because the stronger ciphers could not be exported. While this was long ago the ciphers are still there and ultimately lead to the FREAK attack.
GCHQ forced weak cryptography into the GSM standard so that they could decrypt mobile communication.


Incident response terminology Does incident response pertain to incidents that are currently occurring (ex: a host is spreading malware on the network) or that occurred (ex: an attacker dumped our database but we noticed it few days after) or both?

Short answer: Both.

Longer answer follows.

Incident response actually starts before either of these two cases. A mature incident response plan has specific classifications on what qualifies as an incident, and that can vary from organization to organization, but there is a second term, event. Before it is confirmed that malware is spreading on the network and incident response needs to respond, several events are likely to have occurred. One event would the user's machine sending out enormous amounts of requests for what host is alive on the network. Another event would be the user going to a questionable website. And so on, and so on. At least some of these events should be captured by logging systems on the network. Some would be caught by the user. "Hey, I got this weird email and I opened the attachment," should be a giant flashing red light that something is wrong.

How an organization classifies events, and how they handle them is up to the powers-that-be. If the IR team was spun up every time "something weird" happened, they'd probably quit from burnout.

Incident Response is a collection of technology (SIEM, logging, email filtering), and policies. I can't tell you how to organize and manage those things, because that is up to each company.

Back to your question. It's both, and more.


What are the risks of setting a cookie to have a more global scope? If I have a subdomain, and I set my cookie's scope to be / instead of examp.example.com. How can it be insecure?

You're talking about two different scoping properties.  examp.example.com is a domain scope, and / is a path scope.

/ means that the cookie is valid for any URL path within the relevant domain scope.  examp.example.com is that relevant domain scope.

To answer the question in your comment, yes, you want to specifically scope your cookies to your sub-domain to prevent them from being sent along with requests to other sub-domains, where they could be read by those who have no business reading them.   So you do not want to scope cookies that are specifically for examp.example.com to .example.com, or rely on any cookies that are scoped to example.com.


Would this authentication method prevent MiTMs getting the password? Assuming SSL/TLS cannot be used in this context, is this method secure enough to authenticate someone without someone listening to be able to retrieve the password from the information transmitted.

The client sends a login request.
The server replies with a unique identifier for the login
The user enters in the password
The client hashes the password and encrypts the identifier with the hashed password(encryption(value: identifier, key: hash(password)))
The client sends the encrypted identifier + the username
The server receives the encrypted message gets the decryption password from the database using the username the client provided and checks if its able to retrieve the identifier using the password.
If the identifier is successfully retrieved by the server authentication is successful.

The answer is no.

  The server replies with a unique identifier for the login

This step in itself contains a flaw. A MITM can simply intercept this response, change the unique identifier and observe how the client sends the encrypted identifier + the username. If the attacker has pre-computed rainbow tables for whichever unique identifier is injected, then gaining the password is trivial.


How to stop people from bypassing firewall blocks by using Google cache? I'm using a physical Stormshield Firewall to control connections of a private companies. There are rules to block some websites, like video games websites, Facebook, etc.

However, these websites can still be accessed. For this, you search the website on Google, right click-it and open the cached version of it, which bypass my restrictions.

Any idea about how to deal with this?

You can block access to "http://webcache.googleusercontent.com".

Although you have to ask yourself why you are blocking access to these sites? The cached version will not allow users to log in or navigate to new pages - it is effectively read only access.

In most cases where a block list is the preferred approach (as opposed to a system that blocks every domain that isn't white listed) read only access is fine.


Password hashes with large internal state scrypt was designed to use a lot of memory, and if all that memory wasn't used it would be some orders of magnitude slower to compute. Either way, it counters custom hardware attacks, where there tends to not be so much memory available.

I was thinking, why even bother allowing a time memory tradeoff? Wouldn't it be better to use a hash function with a very large (tuneable of course) internal state? The size of the internal state determines the memory requirements and the number of rounds is the work factor.

I think you've described SHA-3, where the capacity c (and to a lesser extent, the rate r) are exactly the "very large (tuneable of course) internal state" you're talking about.

You don't have to crank it up very high (512 bits / 1024 bits) to get your 256 / 512 bit security levels.

Remember though that the goal of cryptography is not to make the attacker do a lot of work, it's to make the attacker do a lot more work than than the legitimate user. Hashing involves doing expensive operations on the internal state, so just blindly cranking up the size of the internal state hurts the legitimate user just as much as it hurts the attacker.

Large memory requirements of scrypt is meant to exploit a resource that's abundant to the legitimate user (a server handling a small number of login requests at a time), but scarce to the attacker running on massively parallelized hardware rigs.


how to create dependency free script? I have a script which can exploit a specific vulnerability. This script works well with the latest system but in the older systems it failed to run because of dependency (glibc-2.14). So how can i make it dependency free so that i can run it without dependency issue?

This link https://unix.stackexchange.com/a/63758 explains it very well.

Basically, compile a new version on the system.


How does selection between multiple available certificate chains work? I am trying to understand the practical mechanisms of cross-signing (intermediate) certificates. As an example, I am looking at the Let's Encrypt Chain of Trust. That page mentions:

  IdenTrust has cross-signed our intermediates. This allows our end
  certificates to be accepted by all major browsers while we propagate
  our own root.

Additionally, the page contains links to both the intermediate certificate signed with the private key belonging to their own ISRG Root CA as well as the intermediate certificate cross-signed with the private key belong to IdenTrust's CA.

My expectation was to see both of those intermediate certificates coming by on the wire when setting up a TLS connection with www.letsencrypt.org, leaving it up to the client to decide which of the two intermediates to use to build a chain of trust. However, I only see the intermediate signed by IdenTrust.

I have observed this with wireshark, analyzing the TLS traffic as I browsed www.letsencrypt.org with my web browser. To force "the other" chain of trust, I un-trusted the DST Root CA X3 certificate in the Keychain Access app (I am on a Mac) and indeed I was no longer able to browse the site. Then I added the ISRG Root X1 certificate, indicating to always trust it but I could still not browse the site. This supports my observation that the intermediate certificate signed by ISRG is never provided by the server.

I also tried the openssl s_client app, but to no avail.

Suppose that I happen to trust the ISRG Root and not IdenTrust, how do I make the server share with me the intermediate certificate signed by the ISRG Root? Or more generally asked, if multiple chains of trust are available, for example because of cross-signing, how are the certificates of both chains shared with clients? Why do I not receive a bundle that contains both certificates for the intermediate?

Update: the first answer states that the TLS spec does not allow for multiple certificate chains to be exchanged. That explains a lot.

However, my expectations are set by the answers to the question What is the use of cross signing certificates in X.509?. The accepted answer there mentions: "It's about expanding trust" and "increasing the ease of verification of trust, such as situations where you've got clients that trust CA1 or CA2 (but not both). In such a case, you can cross-sign a cert to be trusted by both.".

If only one chain is allowed to be exchanged, then that does not seem like "expanding trust" but more like "modifying trust". Also, for a particular server, if it has to select one particular chain then the "ease of verification" argument no longer holds either -- at least not if your only mechanism available is the TLS handshake. Is that correct?

This question is somewhat related, and you can see from StackzOfZtuff's answer that only one chain can be sent. When connecting with openssl s_client -connect letsencrypt.org:443 it's returning the chain the the IdenTrust root (Digital Signature Trust Co. which IdenTrust bought a long time ago):

Certificate chain
 0 s:/CN=www.letsencrypt.org
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

Since the certificate chain sent has the signature from IdenTrust, it can't be verified with the ISRG root.

As noted here the client is under no obligation to use the chain the server sends, it may attempt to build its own chain to a trusted root. However, this requires that the client already have all of the necessary intermediates that weren't sent by the server.

If I add the intermediate signed by ISRG Root X1 to my trust store, s_client will discover that chain despite being sent the IdenTrust chain (unless told not to by using -no_alt_chains):

$ openssl s_client -connect letsencrypt.org:443
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = www.letsencrypt.org
verify return:1
---
Certificate chain
 0 s:/CN=www.letsencrypt.org
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3


Why does Tor use a new route every few minutes As far as I know, Tor selects three new nodes every few minutes. What is the advantage of this?

The only thing I came up with was to prevent "Bad exit nodes" from viewing too much of your (hopefully encrypted) traffic. But on the other hand, when using less nodes the chance is smaller to find a evil node at all.

Tor is best known for providing anonymity to the users communication. Every time tor uses different routes to forward the data to destination to maintain anonymity. If it is not doing so then same path can be traced to intercept the communication. I think this is the best method to anonymize the communication.


Why is Firesheep Unable to Session Hijack over SSL? Why is Firesheep unable to session hijack when a user is using SSL?

It needs to read the content of the HTTP transactions between the victim's computer and the remote server. SSL features point-to-point encryption using a key that's negotiated by the two systems, so a third system passively eavesdropping cannot read the content.

Note that it is possible to inspect SSL content by interposing the attacking system between the two parties. This is called man-in-the-middle, and is used by corporate content filters so that they can filter both HTTP and HTTPS communication.


Safari not showing GREEN lettering for EV SSL I've recently installed an EV SSL cert on my server, Chrome and Firefox show a green banner and padlock denoting the EV cert is installed, but in Safari, it just shows a gray padlock... is there something extra I have to do for Safari to recognize that it's an EV cert? When I look at the certificate details in Safari it is the same certificate I see in Chrome and Firefox. I've cleared the browser cache several times and have restarted the computer. iOS Safari is showing gray as well in the title when it should be green.

Without seeing some kind of error or warning from Safari, it's hard to tell exactly what's going on.

My best guess would be that your page contains some non-http content that Safari's not happy about [link to StackOverflow post about this].

There seem to be some other things you can do wrong in the page code that Safari won't be happy about, for example using absolute references to content rather than relative [link]


Security of faxes vs emails Background

The other day a friend who works in healthcare asked me which method of communication was more secure, faxing or email. He qualified his question by saying that his office faxes patient records all day, every day, which should not surprise anyone.

I scratched my head and rattled off some considerations, private vs hosted email service, but his question really got me thinking.

My Question

Is a sending a fax more secure or less secure than sending an email when communicating sensitive data?

Consider the following simple variations:

Self-hosted private email server vs fax.
Hosted private email server (collocated server for instance) vs fax.
Hosted GMail (for instance, not picking on Google) service vs fax.

Qualifications

For the sake of this question imagine that in each email instance above, basic best practices are being followed.

I am wondering does one method have a greater attack surface than the other. Is 'getting it right' on the security footprint easier in one instance vs the other, fax vs email?

Update

For the purposes of comparison consider the emails / faxes to be coming from patients to healthcare providers and from providers to other providers.

Example:

jane@me.com -> provider@provider.com

or

provider@provider.com -> provider@otherProvider.com

So 'best practices' would cover what the healthcare providers should be doing to guarantee that they are running as secure a system as they can given this scenario.

If you're asking whether sensitive information is safer when sent over the phone vs. over the Internet, you're probably looking for protection at the wrong layer.

If "basic best practices" are being followed, then any sensitive information that you don't want to be disclosed to third-parties is going to be protected by end-to-end encryption during transmission. At that point, it really doesn't matter whether the data is transmitted via fax, Internet, or homing pigeon. The encryption is what you rely upon for protection - not the transmission medium or infrastructure.

To address concerns of malicious attachments via e-mail vs. fax, cryptography still comes into play. Only this time, you don't use encryption. You use digital signatures. Then you trust that the sending party won't sign a package that contains a malicious attachment. Arguably, e-mail can be differentiated from faxes here, in that even with cryptography one might still receive a malicious attachment - and it has much more impact on a computer than it does on paper.

In either case, you do need to make sure that parties on both ends have the appropriate cryptographic tools and keys available to them. Again, this goes regardless of the transmission format. You're probably more likely to be able to coordinate support for encrypted & digitally signed e-mails than you are faxes, and that is what gives e-mail a distinct leg up in this discussion.

But again, the point remains that your transmission medium should not be what you rely upon for protecting sensitive data. Protect it before it goes out of your system, and you don't have to worry about the weak link(s) - or any hawks - that may be in between.

And in the end, much of the difference can become moot anyway. What you put into your fax machine is just as likely (if not more likely) to land inside of someone's e-mail inbox these days as it is to actually get printed by another fax machine.


Use of rainbow tables with the NY Times hack? The NY Times recently published a story about how they were hacked during a four month period.  The hacks allegedly were carried out by part of the Chinese military.

One part of the story that confused me was the following:

  From there they snooped around The Times’s systems for at least two
  weeks before they identified the domain controller that contains user
  names and hashed, or scrambled, passwords for every Times employee.

  While hashes make hackers’ break-ins more difficult, hashed passwords
  can easily be cracked using so-called rainbow tables — readily
  available databases of hash values for nearly every alphanumeric
  character combination, up to a certain length. Some hacker Web sites
  publish as many as 50 billion hash values.

I remember that when news about the LinkedIn passwords being stolen was announced last year that LinkedIn was criticized for not having salted their passwords, and they also said that they would salt passwords in the future to improve security.

If the NY Times had salted passwords then rainbow tables would not be useful for the hackers correct?  Does the fact that rainbow tables are mentioned in the story mean that the reporter was confused about how the hack would likely have occurred?  Or does this mean that the NY Times was likely using unsalted passwords.  If so does this point to poor security on the part of the NY Times (I guess that wouldn't be too surprising given the extent of the hack).

Basically my question is does the fact that rainbow tables were mentioned in the story imply that the NY Times had poor security policies in place.  Or are rainbow tables still useful for hacking organizations that have good security practices in place.

This is mostly speculation, but I see a number of plausible scenarios:

The article is correct, and NY Times did not salt their passwords;
They salted them, but used a hashing algorithm not slow enough;
The attackers targeted a few specific passwords (probably by guessing and/or brute forcing them).

As for your last question, AFAIK the value of salting is to increase the amortized cost of breaking N passwords (i.e. without salting, breaking 1 password or all of them have the same cost; with salting, N passwords cost N times more than 1 password). A rainbow table could be created specifically to target a single account, but the cost of doing so is always greater than just brute forcing it (see @ThomasPornin's comment), so I doubt that's what happened. So I'm guessing you're right in your suspicion that "the reporter was confused about how the hack would likely have occurred".


Are URLs viewed during HTTPS transactions to one or more websites from a single IP distinguishable? For example, say the following are HTTPS URLs to two websites by one IP over 5 mins:
"A.com/1", "A.com/2", "A.com/3", "B.com/1", "B.com/2".

Would monitoring of packets reveal:

nothing,
reveal only the IP had visited "A.com" and "B.com" (meaning the DNS only),
reveal only the IP had visited "A.com/1" and "B.com/1" (the first HTTPS request for each site),
reveal a complete list of all HTTPS URLs visited,
only reveal IP's of "A.com" and "B.com",
or something else?

Related Question:
can my company see what HTTPS sites I went to?

While this question does have additional information, it as far as I'm able to tell does not address specifically the scenario of "reveal only the IP had visited "A.com/1" and "B.com/1" (the first HTTPS request for each site)" - though possibility being wrong about this is high, and happy to delete the question if it's a duplicate.

NOTE: This is a followup question to an answer that was posted to as: Why is HTTPS not the default protocol?

TLS reveals to an eavesdropper the following information:

the site that you are contacting
the (possibly approximate) length of the rest of the URL
the (possibly approximate) length of the HTML of the page you visited (assuming it is not cached)
the (possibly approximate) number of other resources (e.g., images, iframes, CSS stylesheets, etc.) on the page that you visited (assuming they are not cached)
the time at which each packet is sent and each connection is initiated.  (@nealmcb points out that the eavesdropper learns a lot about timing: the exact time each connection was initiated, the duration of the connection, the time each packet was sent and the time the response was sent, the time for the server to respond to each packet, etc.)

If you interact with a web site by clicking links in series, the eavesdropper can see each of these for each click on the web page.  This information can be combined to try to infer what pages you are visiting.

Therefore, in your example, TLS reveals only A.com vs B.com, because in your example, the rest of the URL is the same length in all cases.  However, your example was poorly chosen: it is not representative of typical practice on the web.  Usually, URL lengths on a particular site vary, and thus reveal information about the URL that you are accessing.  Moreover, page lengths and number of resources also vary, which reveals still more information.

There has been research suggesting that these leakages can reveal substantial information to eavesdroppers about what pages you are visiting.  Therefore, you should not assume that TLS conceals which pages you are visiting from an eavesdropper.  (I realize this is counterintuitive.)

Added: Here are citations to some research in the literature on traffic analysis of HTTPS:

Shuo Chen, Rui Wang, XiaoFeng Wang, Kehuan Zhang.  Side-Channel Leaks in Web Applications: a Reality Today, a Challenge Tomorrow, IEEE Security & Privacy 2010.  This paper is fairly mind-blowing; for instance, it shows how AJAX-based search suggestions can reveal what characters you are typing, even over SSL.  Here is a high-level overview of the paper.
Kehuan Zhang, Zhou Li, Rui Wang, XiaoFeng Wang, Shuo Chen.  Sidebuster: Automated Detection and Quantification of Side-Channel Leaks in Web Application Development.  CCS 2010.
Marc Liberatore, Brian Neil Levine.  Inferring the Source of Encrypted HTTPS Connections.  CCS 2006.
George Danezis. Traffic Analysis of the HTTP Protocol over TLS, unpublished.
George Dean Bissias, Marc Liberatore, Brian Neil Levine. Privacy vulnerabilities in encrypted HTTPS streams.  PET 2005.
Qixiang Sun, Daniel R. Simon, Yi-Min Wang, Wilf Russell, Venkata N. Padmanabhan, Lili Qiu.  Statistical identification of encrypted web browsing traffic.  IEEE Security & Privacy 2002.
Andrew Hintz.  Fingerprinting websites using traffic analysis.  PET2002.
Heyning Cheng, Ron Avnur.  Traffic analysis of SSL encrypted web browsing.  Class project, 1998.
Shailen Mistry, Bhaskaran Raman.  Quantifying Traffic Analysis of Encrypted Web-Browsing.  Class project, 1998.


Can I prevent a replay attack of my signed JWTs? I have implemented a stateless auth over HTTP in Laravel, using JWTs.

I send my username/password from the frontend.
Server authenticates user, sends back a signed JWT with an expiry time.

I'm using the HS512 algorithm to sign with a private key (only available to the server).

Frontend stores the token for future requests.
Frontend sends next request with the token included.
Server verifies that the token is valid, and not expired, and lets the action continue if yes to both.
When the token expires server sends a 'logged-out' message.

All these communications happen over HTTPS.

So I can see that this is secure from these points:

Attackers can't sniff traffic and steal the JWT token because of HTTPS.
Attackers can't generate and send any odd token because server verifies the signature using its private key.
Attackers can't modify which user (and hence, the role+permissions of the requester) is making the request, because that's part of the sub claim in the token.

But, I have two questions:

What if there is a virus on the user's computer or mobile, and it stole a valid token from RAM or from the browser. It can then send more requests, and they will be accepted. Is there any way at all to protect against this?
Is there another way to attack this system that I am not seeing?

The jti claim as described here is an optional mechanism for preventing further replay attacks. From the spec:

  4.1.7.  "jti" (JWT ID) Claim

  The "jti" (JWT ID) claim provides a unique identifier for the JWT.
     The identifier value MUST be assigned in a manner that ensures that
     there is a negligible probability that the same value will be
     accidentally assigned to a different data object; if the application
     uses multiple issuers, collisions MUST be prevented among values
     produced by different issuers as well.  The "jti" claim can be used
     to prevent the JWT from being replayed.  The "jti" value is a case-
     sensitive string.  Use of this claim is OPTIONAL.

This does ultimately make your server stateful, but it prevents against unlimited replays if you detect anomalous behavior, or if a user reports suspicious activity. Consider the following scenario.

A user logs in. Your server generates a JWT, and stores the signature as well as some metadata (the user id and the type of client making the request, perhaps, and the jti).
User reports suspicious behavior.
The application "signs out" the user of all devices by deleting all JWTs in the backend store attached to that user. Now the application can say "I know you've got a valid signature, but I'm not accepting it because I didn't create it."

If your metadata is precise enough, you can use the jti plus additional information to, say, only sign the user out of given devices.

As mentioned above, this does inevitably make your server stateful. This also doesn't outright prevent replay attacks, but it can shut down further such attacks after one has been detected.

An alternative/additional method CAN outright prevent replay attacks to some degree, at the risk of potential inconvenience to the user. Make the user's IP address part of the claim AND stored metadata upon login, and validate that the IP using the JWT is the one you expect. This can be frustrating for a user that say, both works from home and a coffee shop, but it might be an acceptable requirement for high-security applications.


Is storing a JWT secret as docker env variable acceptable? I understand how JWTs work and that with my secret anyone can issue new tokens. I control the server that my node website runs on and am considering different options for hosting the key.

In code - Not acceptable because my code is in a github repo
ENV variable - seperate secrets for dev and production while not leaking to github
Store in database - Seems more like 2nd option with more work, being that an on-machine attacker can find access to the db anyways

2nd option looks like the best method for a simple website (no super sensitive user info like credit cards or SSNs).

Is this a good solution?

Use environment variables as you said, just be careful in how you actually pass the value to the variable so that it doesn't leak to logs.

For example, instead of docker run -e SECRET=foo, use docker run -e SECRET=$(cat my_secret).


Preventing path traversal knowing only the input I am tasked with preventing a path traversal attack over HTTP by intercepting and inspecting the (unencrypted) transported data without direct access to the target server.

From some research it seems that a lot of the methods to prevent such an attack are through either server configurations or programs that look at the actual server files.

My initial idea was to find all of the possible encodings of ".", "/", "\" and using regex, find any combination of these that makes up "../" or  "..\" in the GET request URI.

However, it seems that there is a myriad of ways to obfuscate a character and I will probably miss something. Are there any better avenues of research I should look into in order to tackle this problem?

thanks

You cannot do this securely. It is a fundamentally broken approach. You need contextual information about the application and the filesystem, which you cannot gain from an external perspective. The best you can do is deploy a WAF such as Apache's mod_security and enable a bunch of path traversal rules to try to block path traversal attempts, but a determined attacker will eventually find a way around those rules.

If someone has given you this task, consider that the first step in any task is to perform a feasibility study. You work out if the task is possible, what the approaches are and what benefits and drawbacks they have, then you do a cost-benefit analysis. In this case the primary cost is risk. I suggest that you go back to whoever gave you that task and explain that you technically can do this, but it's a blacklist approach that isn't ironclad and it will involve standing up some additional infrastructure in front of the web server (and that means maintaining and patching it too, particularly the WAF part!). Then you can leave it to them to weigh those costs up against a more complete solution, such as getting the web application actually fixed.

If the web application in question is made by a third party, report the directory traversal as a security vulnerability. If it's a product or service that they sell, you can use responsible disclosure to push them to fix it if they're slow about it. If the web application is something that your organisation contracted a third party to make for you, you can check the contract to see if they are liable for fixing security vulnerabilities (you should also write this into your contracts!)


Need help to exploit php script vulnerability of a challenge i am trying to exploit a vulnerability in a php script of the 'stop us' challenge of Wechall.net and I am not sure but I think I found the vulnerability, but now I don't know how to exploit it. I made some researches at PHP.net and I believe that a user can abort/close the connection and after that, the progress of the script terminates, because ignore_user_abort is not set, so after the 'domain' , in the script below, is purchased, the attacker can close the connection and the balance is not reduced. Here is the vulnerable code of that challenge: Vulnerable Code

How can I close/abort the connection at the specific time? (Race window)

In Chrome, you can simply press the ESC button to close/abort the connection. Look at the PHP code and you'll see when exactly you should press the ESC button.


How secure is TRESOR on a virtual machine? I'm investigating TRESOR as a way to prevent stealing of encryption keys from RAM by someone with physical access to the machine.

This seems solid in the case of a dedicated server, but what about a virtual machine? I saw in this answer that TRESOR stores the key in the CPU DR registers, and patches the kernel to tell userland that the number of DR registers is 0.

On a virtual machine however, where are these registers stored when the CPU switches to another virtual machine? Is this a concern?

In a virtual machine environment, the debug registers will be dumped to the host's RAM while the VM is not running. This means that, in this environment, TRESOR adds no meaningful security. In fact, it may reduce overall security by placing sensitive encryption keys in a predictable location.


When is it okay not to use anti-forgery token in login page? In this post, there is a paragraph that mentions a scenario where there is no need to validate anti-forgery token in login page:

When is it OK to leave off the anti-forgery token? In general, if the target is a URL, and accessing that URL has no side effects, then you don't need to include anti-forgery token in that URL.

I understand how a CSRF attack works but I am quite lost at this paragraph unfortunately. It says:

If the target is a URL
If accessing that URL has no side effects

Is there a target that is not URL? and what is an example for a "side effect"?
I have an ASP.NET MVC application that is hosted at a URL such as subdomain.domain.com. My users receive these errors:

“The provided anti-forgery token was meant for a different
claims-based user than the current user.”
“The anti-forgery cookie token and form field token do not match.”
“The provided anti-forgery token was meant for user "", but the current user is > "XYZ".”

In other words, my question is that what are the scenarios in which it is okay not to use anti-forgery token in login page?

Visiting a URL can cause a side effect.  For instance, if I'm logged into Amazon, visiting a URL may cause an item to be purchased and shipped to me (one-click buy).  That's a side effect.  Or, it might log me out, or log me in, or update some settings.  Those are side effects, too.

In general, a operation has a side effect if it changes some (persistent) state on the server, or has some persistent observable effect on the world.


Does brute forcing require a password and username list? I have been learning metasploit. One thing I noticed was that, all the videos on YouTube, which said "Brute forcing", used a password and a username list. My question is that, won't this be called a dictionary attack instead? Because as far as I know, brute forcing actually generates a password or a string and checks it.

A "dictionary" attack is a subset of a "brute force" attack. You are still trying every item in a list to see if it works, and that makes it "brute force". Another type of brute force, of course, is to permute all characters and lengths.


Why is Mother’s Maiden Name still used as a security question? From time to time, some web sites asks to enter a security question and an answer for it. The question list is standard and it usually includes "What is your mother's maiden name?".

Some people use their mother's real maiden name so that they are sure they can remember what to provide when asked (e.g. as part of the process to recover the account). This means that this is information is fixed for a very long period of time. If it happens that some web application is hacked and such an answer is associated with an e-mail address (or worse, with personally identifiable information), it can potentially create a vulnerability for other web applications.

Also, mother's maiden name might be shared in public space.

Assuming above issues with this security question (or any other security question that relies on a constant within one's life):

Why is Mother’s Maiden Name still used as a security question?

Because people are lazy and/or incompetent. And, well, you know, the Internet is full of chimpanzees.

I would argue that all security questions are bad, but using the mother's maiden name is exceptionally bad:

At least in Sweden, I can find out anyone's maiden name just with a simple call to the tax office. It is literally public information.
It's 2018, and fairly common for couples to adopt the bride's name when getting married. Your mothers maiden name is then your surname. Great.
Luis Casillas rightly adds:

  There are dozens of countries, with billions of inhabitants between them, where women don't change their legal name when they marry. The United States in particular has huge immigrant minorities of people from such countries.

Seriously, there are no excuses for this. It's just bad.


Open an e-mail account from only one particular system? Is there a way to configure e-mail so that it can only be opened from one particular system? Or from multiple systems having some sort of unique key or particular static IP?

If you are talking about opening a single email, then no that is not possible. However if you are talking about a mailserver, then yes this possible. You can use a firewall to restrict access from certan IPs to the mail server and prevent certain clients from accessing your mail server.


Found a backdoor and multiple trojans in a computer. Is the hacker doing everything manually? So I found a backdoor, multiple trojans and crypto miners in a client's PC. He is worried that his personal information has been compromised.
What happened:
During the installation of Kaspersky anti-virus, a user account control prompt appeared with "Kaspersky" on the name of it, but it was not from a verified publisher. He accepted this prompt, allowing someone who is not Kaspersky Labs to make changes to his PC and this is probably how the backdoor got installed.
Kaspersky actually finished installing and worked for a while. But after a while it got inoperable by the backdoor, and so did Windows Defender.
I actually have little knowledge of cybersecurity, and don't know how the process to backdooring someone is.
Is this probably an automated process the malware performed in the computer? That is, did the virus made the prompt, deactivate Kaspersky and Windows Defender all by itself? How likely it is that the hacker did it manually?

You can do this operation from all over the world.
And also control the computer remotely every time you turn the computer on. The hacker is notified about this and can do operations like listening to audio/video from pc and also each key the user types.
The hacker can also infect other devices on the network.
You must isolate this PC ASAP and change the passwords for each user account immediately from another device.


Where is my password stored on Linux? Is there a specific location where the passwords are stored ?

Is it depending on which version is used ?

Are they salted ?

Linux passwords are stored in the /etc/shadow file. They are salted and the algorithm being used depends on the particular distribution and is configurable.

From what I recall, the algorithms supported are MD5, Blowfish, SHA256 and SHA512. Most recent distributions should be on SHA512 by default if my memory serves me right.


How safe is it to give a device that has malfunctioned to just anyone? My friend's iPad 2 Air fell to the ground and something malfunctioned and the device stopped working. She took it to a repair shop where they looked at what they could do to fix it. They said if they can't do anything then they offer to get rid of it for her (model out of warranty and Apple won't replace it anyway).

How safe is it to give the device to anyone? Is there a possibility that someone (not the specific store, but in general) could be able to get personal information from the device extracted for their own purpose? Personal information includes any kind of tokens in the device's storage, files etc

It's going to be impossible to tell what can be extracted from a non-functioning device without inspecting it. It is impossible for us to know what has malfunctioned or how or if storage is accessible or damaged.

So, yes, there is a possibility that someone could extract any amount of data. If you want to be on the safe side, and you cannot factory reset (and be sure that the reset worked), then destroy the device instead of giving it to just anyone.


Are longer passwords safer even if the encryption/database security used is compromised? Let me preface this that I am having a lot of trouble wording my question. Hopefully my description will help clarify.

I have always wondered if long passwords actually provide you any more security vs. shorter ones when it comes to websites like Google, Facebook, and similar.

I have very, very basic knowledge of cryptography, but it's my understanding most websites have to store the password somewhere, and when stored they are encrypted into some sort of hexadecimal string (or similar). For example, going here and entering a string of any length will always yield a 32 character string.

Now, of course, there are several different type of encryption standards. However, it seems to me, if a user database is compromised on any website through some means, at the end of the day it didn't matter how long your password is, your credentials were still compromised and potentially made public. Your 900 character password wasn't any more secure than someone with "12345678" as their password, both of you have the username and password stolen.

I have seen questions similar to this one, none seeming to ask the same thing though. So my question is that are longer passwords safer than shorter ones even if the encryption/database security used is compromised?

Also, I seem to be assuming there are other methods of compromising user data without a brute-force type method, so please let me know if I'm making some silly assumptions.

Thanks everyone! :)

A few general cases for offline attacks (they steal the entire username and password hash table, including salts, peppers, etc.:

Weak password, ANY storage - it's broken.
ANY password, plaintext storage - it's broken
ANY password, encryption storage, keys lost or weak too - it's broken (HASH IT)
Moderate password, weak but correct hash storage - it's broken.
Moderate password, very strong and correct hash storage - it depends on the time and resources the attackers put forth

This includes AFTER the original attackers give up and post everything on the Internet for everyone in the world to take a crack at.

Extremely strong password, weak but correct hash storage - it's safe!

and so on between these.


What are the dangers with creating MySQL databases on the fly? I am building a site where people set up small, private, social networks. For ease of administration and portability, I would like each network to be stored in a different MySQL database.

I understand that there is no artificial limit on the number of databases a MySQL server can handle, and in my basic tests there is no measurable performance impact. What I would like to know is: if I allow these databases to be set up without my intervention, what are the security implications?

My thoughts so far:

For general usage, the app would connect to MySQL as a user with limited "SELECT", "INSERT", "UPDATE", "DELETE" rights.  This user would be granted rights to read/write into each created database.
When a new network is created, the app would connect to MySQL as a special user with the "CREATE" privelege, so it can create a new database.
I would only allow a new database to be created if I am convinced the person is a legitimate user (email validation, captcha etc).
If illegitimate databases are created, I will notice and delete them, and hopefully figure out how to prevent more being created.

With a setup like this, is there any security implications I have not thought of?  Is there any danger, other than the possible creation of databases by illegitimate users?

There's no inherent security issues with this architecture. Any risks will come from the implementation errors or vulnerabilities in MySQL.

It sounds like you are considering this method in order to provide separation between different networks' data, however it does sound a bit excessive. I know you tested for performance, however in a large scale this might use more resources, that's a different forum.

Remember, it's all about implementation, you could have all network data in one table and it would be secure as long as you design and code it well.


ISP provides RJ45 instead of RJ11/coaxial/modem, how to separate the network? The ISP is in the same building, they provide the internet from an RJ45 cable through a hole in the adjacent wall, instead of the conventional coaxial or RJ11 modem. Right now there is an ethernet switch directly connected to the RJ45 cable, and that gives internet and LAN to all the devices connected to the switch, which means that the RJ45 comes from a router behind the wall (on ISP's side).

I researched that if I connect the RJ45 to the WAN port of a router of mine, then the ISP couldn't reach inside of my network, but my network could still reach computers eventually available inside the ISP's network, only if I know the IP adresses of those computers, I assume this is below the conventional way in terms of security, or is less appropriate.

Besides of having a router of mine connected from its WAN port to the ISP's RJ45, what else is necessary to have a separate network, i.e. equivalent to those that are connected to an RJ11/coaxial/modem)?

The medium they use for the connection has nothing to do with security. You could equally put all your computers on the public internet by connecting it to a DSL/coax modem (not a router).

In this case it looks like due to the fact that every computer has an Ethernet card the ISP decided not to provide a router, and as a result people are putting their machines directly onto the Internet. Nothing prevents you from putting your own router/firewall in the middle if you need the extra security.

As far as reaching other computers by IP, this is exactly how the internet is designed to work. You may have had the impression that it isn't the case due to an awful hack called NAT which hides multiple computers behind one single IP - the router has the public IP and everyone else behind it uses a local, private IP, and to receive incoming connections you had to tell the router to forward particular ports to the local IP. In this case since people aren't using routers no NAT is happening and every device has a publicly routable address.


Securing Micro Services Architecture internally I am implementing a solution with set of Micro Services (Spring Rest Services)  with Rabbit MQ as the message broker. The Edge server is Authenticated using  OAuth based  Identity server.  Internal Micro Sevices calls are not Authorized or Authenticated.

My objective is to secure all internal Micro Services with Authentication and Authorization. Need to secure internal communication from MiTM attack or eavesdropping.

One thing we can do is relaying the edge server's Auth Token into internal Micro Services. But if someone captures the Auth token, they can perform a Confuse Deputy attack ( act as a legitimate Micro Service ).  And anyone can intercept or eavesdrop the communication in between Micro Services.

Please let me if you know a better solution for this.

Thanks in advance.

Reusing the edge token is a really bad idea as it simply gives more opportunities for it to be intercepted and wrongly used.

You should identify any risk boundaries first. So which services/data actually require additional or separate protection. Then you can create security boundaries that match. You should not generally try to secure "all" internal services independently as this is hard, and expensive, to scale. It wouldn't necessarily provide a lot of extra security anyway. Classifying systems and data is a boring pain but is the most important thing you can do.

Each boundary can then be secured by whatever method is best. Some might only need to be restricted by what addresses are allowed through (firewall), others might need additional token or certificate based security.

In an environment needing security, the edge servers would generally be considered as untrusted (semi-trusted at best) in any case since these will be the ones most exposed.


What are MITM proxies used for in enterprises? My company (like many others I assume), uses a "man in the middle" proxy with a personal root CA.

Disclaimer : I'm not a security expert so perhaps I do not correctly understand what this network configuration does, so the following question assumes that this config is used to be able to decrypt my HTTPS traffic.

What justifies this practice? What are the use cases? Is this to be able to catch viruses in the traffic? Or is this used to verify what website employees go to or what data they send to the internet (data leak prevention)?

Since I'm not aware why it's used, I feel like this practice is a breach of privacy. For example, some companies tolerate to check private mails or even to make a quick payment by e-banking if needed. But then if they use a MITM, people should be aware that the IT dpt will be able to read the data (login/password, account balance,...) which is supposed to be encrypted (TLS).

Most of your assumptions are correct. Inspecting traffic content allows a company to look for:

malicious traffic (not just viruses)
DLP violations
it can also be for the employee's protection against externally malicious traffic, like phishing, abuse, extortion, etc.

They will know what sites you visit through other means.

Because they own the network, the machines, and the data, they have a "duty of care" to be able to protect it all, and part of that is monitoring. But it does impact the individuals.

Companies are usually required to notify people if they can inspect traffic so that the person can choose to not engage in personal activities on the network. Many companies set up a "public" wifi so employees can connect to that, or permit the use of personal phones so people can use the cellular networks for personal business.

It sounds like you are shocked by finding this out and this might be a discussion you need to have with your IT department, HR, and/or your DPO (if applicable). You might have been given notification but you might not have known what the notification meant.


Security against IP Spoofing I am pursuing a college project, in which I am running three fake services on three ports to protect the main service (say running at port 80). The concept is that if the user is malicious, he'll try to bring the services down and access the fake services. These ports adopt a blocking process of a connection request and record the IP and port of the client. These are logged and aren't granted access on service on port 80. But what to do if the client spoofs his IP? How can I modify my system?

I'm just going to answer (very) generally and let you do the math.

IP address spoofing works just like any other form of spoofing. Spoofing means pretending to be someone who you aren't. In the context of information security, IP address spoofing (henceforth refereed to simply as "spoofing") is quite common in many attacks. For example to target systems which utilize IP address as a security control such as router access control lists, firewalls, trust relationships, etc. Additionally it's very typically used in denial of service attacks. IP spoofing in practice can vary from mundane to highly complex. In general there are really 3 common ways to do it.

You could simply just set your IP address to anything you want using ifconfig in Unix or netsh in Windows. Additionally many tools come with built in spoofing capabilities such as decoys in Nmap or you can use various packet crafting tools such as Scapy. This is great and all, but anyone with basic networking knowledge will tell you that isn't going be really very useful in many cases. Sure spoofing datagram protocols like UDP or ICMP is trivial, but what about TCP? First of all most ISPs ignore the source address so sure you can start shooting out packets with any IP you like and they'll probably get delivered, but if you actually want to have any sort meaningful interaction (ie. pretty much anything other than DoS) you're out of luck because the response will obviously be send to whomever you happen to be spoofing. This is the nature of session-oriented protocols like TCP. The three-way handshake is going to spoil all of your fun. For example: You send your spoofed packets (SYN [A, ISNa]) over then that machine (B) which will respond (ACK [A, ISNa+X] SYN [B, ISNb]) to whomever you happen to be spoofing (A), but the only response machine B will get back from machine A is a reset (RST). Now if you're on the same LAN as the system you're spoofing, this works a little differently as you could just intercept the messages. To get around this little problem with TCP one could try to predict ISNs. For this reason initial sequence numbers (ISNs) in TCP are supposed to be hard to guess.

I was actually going to go on, but I'm not really good at this and I'm tired so I'm just gonna close up.. with a few words. Maybe I will come back and finish this up at a later time. Sorry.

The easiest way that I know of to do spoofing is via source routing. Just use loose source routing, put yourself in the path and you're good to go. The only dependency is that at least one network path between you and your target supports source routing. I don't think this is really much of an issue at this time.

Now to defend against spoofing what do you need to do? Keep your TCP/IP stack patched. Don't extend trust relationships outside of firewalls unless it's over an encrypted tunnel. Don't use IP addresses for authentication (yes, people do actually do this.) Use anti-spoof filters on routers and firewalls, either direct anti-spoof or reverse path forwarding checks. Don't allow source routed packets through network gateways and especially not internet gateways. (Some networking guys seem to have a hard-on for source routing on the internal network, but it's always worth a shot) In IOS this is as easy as changing one setting. It's called "no ip source-route". Additionally anti-spoof filters can be set to generate logs and you could use some fancy machine learning techniques to detect non expected source addresses on a given network.

Sorry to cut it short, but I'm out. Cherrio.


How to perform Login Authentication at the client-side? How can we validate login credentials at the client-side itself without involving the server of a website?

You can't.

The reason is that you can't trust the client at all. An attacker can modify the client as they wish, and circumvent any and all security measures you may have put in place.

  But what if we digitally sign our code? The attacker can't modify it then, right?

Yes, they can. If you sign your code, the machine of the attacker needs to validate the signature and refuse to run it if the signature of the client does not match. Nothing stops the client from disabling this signature check and simply run code with a wrong signature or no signature at all.

Furthermore, if you don't want to involve the server at all after sending the website, then all the potentially confidential content needs to be sent to the client first (before knowing if they are authorized to see it), and later revealed to them.

Nothing stops an attacker from simply looking at the raw content being sent to them over the network, without any client-side code being run.

  But can't you encrypt the data with the user credentials?

Yes, you could. But your goal is to authenticate the user, which means you confirm if the user is actually who they claim to be. The scheme suggested by user9123 would work as follows:

User claims to be user "foo".
Website encrypts payload for "foo" with credentials for that user, e.g. "foo:bar".
User enters their credentials, which locally decrypt the payload.

This scheme does not authenticate the user to the server in any way. The server does not know if the user is really "foo" or not. Furthermore, if the user has a weak password, the attacker can attempt to crack it. Yes, a key-derivation function can make this process slow, but it is still essentially a credential leak.

What I am curious is why you would want to attempt this scheme, instead of the traditional tested method?


Does using a token and a pin for logging into a corporate internal system removes the need for using regular user names and passwords? I am evaluating an internal 2 factor authentication implementation in an organization. The system designer wants to remove regular user names and passwords from all user workstations such that each user will have his badge as a login token and will have to enter a 6 digit key to login into his workstation. Is this a normal practice? and does it make the scenario more secure or less secure? as a security reviewer, I find this as reducing the security of the workstation because the 6 digit pins are easy to capture by over the shoulder attacks and stealing a badge is not that difficult. Regular user names and strong passwords are harder to capture by similar attack. Remember that we are talking about an internal network with many other technical controls. My argument is that using just a card and a pin is more vulnerable to internal physical attacks.

In practice 2-factor auth means 2 of the following

Something you are
Something you know
Something you have

In this case he is replacing username and password which are both in the "Something you know" category for a token code and a badge which both fall under the "Something you have". So there is negligible augmentation in the way authentication is happening on that computer.

Hope this helps.


Can potential NSA spyware be detected and/or removed? Just out of curiosity (and because it sounds fascinating) . With all the Snowden revelations, it sounds like nsa has the ability to infect computers with some sort of spyware.

I'm asumming these guys are smart enough to build something that spyware scanners can't detect. Or is my assumption wrong on that?

Would simple factory reset of a windows laptop remove any malware, if they exist?

I'm asumming these guys are smart enough to build something that spyware scanners can't detect. Or is my assumption wrong on that?

Pretty sure they will explicitly design the spyware so that the common scanners will not detect it at the time when the spyware is first released. But this is not only done by government agencies but by others which sell spyware - because obviously it is usually part of the expected product features that it is not easily detectable.

But once a spyware is known it is usually possible to write heuristics which can detect it so any protection against detection is only temporarily. That's why one usually limits a lot how many systems are compromised in the first place so that the chance of the spyware gets known stays low.

  Would simple factory reset of a windows laptop remove any malware, if they exist?

Probably for most it would help. But it would not help in all cases or at least not for long. For example it might be possible that the target gets reinfected quickly since the router or other device in the network or some used data storage is compromised too. And if the attacker had physical access to the system the compromise might even be much deeper than what a simple factory reset would resolve.


If a large companies website's robots.txt file has no Disallow section, does this mean I am free to write code to crawl their website? If a large companies website's robots.txt file has no Disallow section, does this mean I am free to write code to crawl their website?

The website in question is basically a data warehouse for the type of information I need, information which is updated on a minute by minute basis (so I'm going to be polling), and their robots.txt file looks like so:

User-agent: *

They are a global company so I assume they know how a robots.txt file works, does this mean I can crawl away, or should I contact them first?

I'm not asking from a legal perspective, but more from the point of view of a developer/security expert intentionally writing the above robots.txt file, if you do this are you essentially saying crawling is ok?

A robots.txt file does NOT imply any legal permission one way or another. It's only purpose is to limit the results of a crawler for crawlers who choose to respect the content of the robots.txt file.


How should certificates be shared between a proxy and a frontend? At work, I've been asked to look into creating a reference topology for a WebSocket chat application, which includes a proxy between the web-facing frontend server and the backend.
At the moment, I am still running the frontend and backend on the same server for development, but I've temporarily set the WebSockets to point to the proxy, which is on a completely separate server in the lab. Both servers are on an internal network, and each has a separate, self-signed certificate.

When I was testing the WebSocket over TLS, it failed due to the cert being self-signed (without showing any dialogue to make an exception) until I connected directly to the proxy and made an exception for the certificate. After that, it worked perfectly fine, but in practice the visitor probably wouldn't be allowed to do that. So, I need to find out how to certify both at the same time.

As far as I can tell, the main ways of doing this are:

Put the proxy and frontend on different subdomains (e.g. frontend.domain.com and proxy.domain.com), and use a wildcard certificate for the site. This would be quicker and easier to work with in the lab, but the IETF discourages this.
Use a single cert with Subject Alternative Names, and include both frontend.mydomain.com and proxy.mydomain.com under the SAN field for www.mydomain.com. As far as I can tell, this shares the problem of vouching for rogue/buggy domains.
Use entirely separate certs for the two servers, like I'm already doing. It's more hassle to work with, especially with self-signed certs, but if one domain is compromised, that's only one point of failure. My main question here is that if the proxy and frontend certs weren't self-signed, would this be more likely to work?

Is there anything I've missed with the above, or are there other methods?

EDIT 22/07/2015: As an aside, while sending an XMLHttpRequest via the same mechanism, I found I had to turn off the cert verification between the proxy and the backend to allow the SSL handshake to go ahead, so I'm wondering if my self-signed certs were the real cause of the problem. However, that probably doesn't solve my issue above.

If you have a self-signed certificate you need your clients to trust it.

Alternatively you can have the client not check whether the certificate is trusted, but that's a terrible idea.

How you do that depends on your clients. If you have something like this:

[user-agent]---------[frontend]---------[proxy]---------[backend]

The user-agent (probably a browser) is the client for frontend, frontend is the client for proxy and proxy is the client for backend.

Each client here needs to trust the certificate offered by the server, either because it's signed by an already trusted entity, or because you add the self signed cert to the truststore.

So yes, self-signed can give you trouble

If the proxy is there for scalability reasons there will be more backend hosts in the future.

If all communications behind the frontend are internal to your organization, you can setup your own internal CA and trust its root certificate in the frontend and proxy.

This way you can add new hosts internally each with their own certificate and the clients will automatically trust it.

Using different certificates for different servers is usually a good idea, independently of whether you deploy your own CA or not. When a key is compromised you need to revoke the certificates for that key, and any host that shared certificates with the compromised one will require new certificates as well.


what order does the incremental mode of john the ripper, brute force passwords in? I am practicing reversing md5 hashed passwords using John the Riper and was curious about some behaviour. I added the md5 hash of zaa to the top of the file with the hashes and when I ran john passwordFile.txt it reversed the hash to find zaa very quickly, but when I set it to incremental mode...well it's still running. How does incremental mode work? It has sucesffuly reversed other passwords like

cilldara
5487175a
wcjzfm

but no zaa so it doesn't appear to be going in alphabetical order?

UPDATE: I have observed what I believe is the fact that john never outputs the same password more than once, even between successive invocations (unless --show option is specified). For example if a wordlist is used and cracked a password myname123 then running john again in incremental mode, won't in fact print myname123 again; you need to do john samefile.txt --show to get it to output (I think it caches the cracked passwords). My reasoning is from what I observed, another part is the statement answering why no passwords may be hashed:

  All of the password hashes found in the file (that are of the same
  type as the very first recognized hash in the file unless you're using
  the "--format=..." option) might be already cracked by previous
  invocations of John

Here is one example of trying to run the command in incremental mode

[dev@localhost ~]$ john --format=raw-md5  'passwords.md5 (copy).raw' --incremental
Loaded 2 password hashes with no different salts (Raw MD5 [SSE2i 10x4x3])
No password hashes left to crack (see FAQ)

Then if I go into passwords.md5 and add a new hash at the top and rerun the results are different

[dev@localhost ~]$ john --format=raw-md5  'passwords.md5 (copy).raw' --incremental
Loaded 1002 password hashes with no different salts (Raw MD5 [SSE2i 10x4x3])
Remaining 942 password hashes with no different salts
hi               (?)

The new (crappy) password was 'hi'

Incremental mode is not meant to be used with a wordlist. Incremental mode allows you to bruteforce a character space such as lowercase letters. For the example of the lowercase character space the bruteforce would start at one character, try all the combinations, move to two characters, and repeat until the password is cracked.


Securing Windows 7 using Bluetooth I'm thinking of using my iPhone as a device combined with a low power bluetooth usb key. So when the phone is gone the workstation locks. (I don't want it to unlock the workstation though, I'd prefer if the workstation only unlocked if the phone was in range (there is a backup account of course))

However how best can I security the bluetooth stack on Windows against attacks, eg. EMET?

No data should be transferred between the phone and my computer I won't be using the Bluetooth for anything bar just seeing if the device is in range.

Yes I'm aware you can spoof the device

http://btprox.sourceforge.net/ has some code that does this. It is an application you can install that I believe is what you're looking for.


Are private pastes on pastebin.com vulnerable? Can you trust pastebin? I use https://pastebin.com/ to organize some lists. When I select "Paste Exposure: Private" , will it be really private and only accessible via login? I read somewhere in the internet that there are programs that may capture what is inside a private paste and they only need the paste ID. Is that true?

I am also worried because some private pastes from my account have +10 'unique visitors'. That shouldn't be.

Are there alternatives? I need to manage several lists and I like it to be bound to an account but if anybody may read my stuff that would be awful.

Are private pastes on pastebin.com vulnerable?

Absolutely. Remember, if you are using a free service, then you are the product. Pastebin as a free service is definitely vulnerable. Personally, I use pastebin quite often. It's a very good service, and I am not worried about the website owners running off with my private information because I do not provide it.

However, since you are paying... I doubt a company would go out of their way to hurt their customers. Still, we can't see what the admins of the website are able to do, so we likely can't inform you.

  I am also worried because some private pastes from my account have +10 'unique visitors'. That souldn't be.

Do not rely on free services like this for things that need to be kept private/safe.

I understand Pastebin.com has a private paste option for paid accounts. Private and unlisted pastes are different.

Are my pastes truly private?

The owner(s) and moderator(s) of the website can easily know what you're pasting. And they can even do this without it showing up on the website counter if they wanted to. They could do something like this:

// finds all the latest private pastes first.
LoadFiles(db.Query("SELECT [file_name] from [paste_data]
where [access_type] = 'Private' ORDER BY [date_posted] ASC"));

If your machine is infected, or your internet connection is being monitored, people can find your pastes and pass them on to others. In the case of private pastes, your login can be shared.
The URLs, even if unlisted, can be enumerated. You can "guess" Urls. If someone stumbles across yours, they may eventually find your paste. This may not work for private pastes.

I think #1 and #2 are the most likely. However, I just wouldn't expect my pastes to be private once they go online. "Unlisted" in the context of Pastebin simply means they won't be listed on the main website, not that you can't visit them or guess the URL.

With private pastes, it's interesting that others can view your pastes. I would suspect website admins at this point.

Side note: The extra unique visitors may be an after-effect of you visiting the pastes in question under incognito/VPN. If you have a dynamic IP address or VPN, and the website counts all unique IP addresses visiting the pages, regardless of account, then it will likely update the counter. Why not test this?

Product Recommendations

Unfortunately, this isn't really a place for product recommendations. However, I would not expect anything I post online to be truly private.

If you want some decent privacy, my recommendation is to create your own website, encrypt the pastes you upload, and give people keys; one to to access files, and one to decrypt them. One Key to view them, One Key to decrypt them and on the website unbind them, In the Land of Mordor where the Shadows lie.


Can operating system installation from USB cause reinfection I'm aware of bootkits and booting a device causes it, so if i'm reinstalling the OS and the stick i'm reinstalling from is compromised will it cause infection during installation itself?

The hard drive i'm installing to is set up as GPT i no MBR is definitely effected by a bootkit, i'm assuming the only way to avoid that would be a live cd for install as long as the long as the .iso itself isn't compromised or it isn't compromised while burning the dvd/cd.

Or a brand new clean USB tho plugging such a device into a compromised system to set it up for OS installation would likely just compromise it.

I'm assuming as long as the .iso isn't compromised burning it to dvd from a potentially infected machine should end without it been able to function as a bootkit would?

Thanks.

You don't need to go overboard... Any USB installation drive created on a clean computer is enough, you don't need to buy a new USB drive just for this.

Even a computer infected with a bootkit will not load this bootkit unless booted from the infected device. If you boot from another device, the bootkit is just data sitting on the disk.

There's BIOS infection too, but those are so rare that unless you are a journalist on an oppressive regime, or a person of special interest that an attacker would pour hundreds of thousands of dollars to compromise, you don't need to worry about. So don't worry about.


Reading keystrokes of other applications Is it possible for other application running in the OS to read the keystrokes that my application uses?

What about mouse events and window handles?

Is there any security wall that the OS uses to shield my application from other potential dangerous applications that have might infiltrated into the machine?

Is there any difference between Windows in Mac in this issue?

Thank you

Oh man, you're in for a treat this evening!

Is it possible for other application running in the OS to read the keystrokes that my application uses?
What about mouse events and window handles?

Absolutely. Windows message processing is really complicated. It works a bit like this:
LRESULT CALLBACK WndProc( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam )
{

switch ( msg )
{
case WM_CREATE:

case WM_DESTROY:

case WM_COMMAND:

case WM_KEYDOWN:
}
}

and so on. Basically, this function is continually called for each message the graphics system has for your app. Each different type of message is identified by msg, and hwnd gives you your window handle. The information for each type of command is stored in wparam and lparam or some combination thereof.
It turns out there are a huge number of API Hooking Techniques in Windows. The good news is that one of them is SetWindowsHookEx() which allows you to insert your own handler into another application's message pipeline and, well, steal their messages. That's everything - every button pressed, every menu, every resize, create, destroy, mouse move, redraw, keydown, keyup etc that happens on that Window.
There is another way to invite yourself in - use DLL Injection to get your code into the process' address space and then modify the running code.
None of this is easy, but it is certainly possible
Now, you wanted to know about defences. Well, UIPI, or User Interface Privilege Isolation, is one such defence. The privilege level of the process (or Mandatory Integrity Level) controls what other processes can do as that process. Vista uses this trick to isolate certain applications from each other. Next up; Window Stations, Desktops and Sessions. Did you know that when you get that UAC dialog, you're actually running on a separate desktop and consent.exe takes a screenshot of your desktop and pastes it as the background for the new desktop?
Wait what?
Go back a bit. You can have multiple desktops per Window station and, guess what? Well:

Windows inside the Windows OS are children of Desktop objects.

So that means if you create a separate desktop for your application to run in and crucially handles to objects in the main desktop don't show up here. Windows uses this to protect the logon, lock screens, UAC screens. It's also used by me in a product I'm developing, and it's used by KeePass.
These features are fundamental to Vista/Windows 7 and they're unlikely to go away. To make the most of them, leave UAC turned on and possibly read this.
Now, Mac OS X. Disclaimer: I know very little about the OS X stack; however, I am familiar with Linux/X Server. Linux is increasingly moving towards RBAC/MAC-type systems with the introduction of posix capabilities rather than setuid bits and the like. However, in implementing SELinux in X, the developers ran up against a brick wall. X basically runs its server (the desktop) as root (should be sending you warning signals) and desktop applications (clients) connect to it locally and pass in nothing more than a cookie. See X authorization.
Fundamentally, X operates over some kind of transport, making your actions at least sniffable to outsiders if encryption is not used. Firstly, the Linux kernel might just give you permission to capture keystroke with ioperm(). Failing that, if you have the magic cookie, you can use it to connect to the X server and run all sorts of commands. This requires a dodgy setup, of course, but it is feasible.
In terms of adding in isolation between clients and servers, XACE is the SELinux equivalent.
Now, how does this apply to Mac OS X? Well, not a lot - apparently, X11 is deprecated or something. Anyway, internally, Mac OS X uses a rendering engine of its own and its own Windowing code (Cocoa). Well, it turns out with some digging you can intercept messages on Mac OS X too. Cocoa is the desktop API; underneath it uses something called Quartz which also supports taps (source).
I am not fully versed on how this all works - however, I'm imagining it comes down to getting the appropriate privileges and just making the right calls. Mac OS X uses Unix Shared objects, so its callback mechanism will basically use function pointers. I'm not sure what privilege restrictions are there.
If anyone knows more about OS X, do feel free to take what I've said and expand on it in your own answer :)