How do I secure Apache against the Bash Shellshock vulnerability? I have an Apache webserver running, and with the recent news of the Shellsock exploit against bash I was wondering if my webserver is vulnerable. I don't think it is, but I want to make sure I'm not mistaken.

I don't use any bash CGI intentionally on the server, it is running some PHP stuff using mod_php and a Python WSGI site. But I'd like to be sure that none of the software running on the server is using CGI without me expecting it.

How can I make sure that my webserver is not vulnerable?

Aside from CGI, one overlooked use of sh is in exec() calls, or through the use of system() and popen(), on most Linux systems this means bash. The exec() family of calls are often used with "/bin/sh -c" to provide various features like shell redirection, pipelines or even just argument expansion when invoking processes.

Apache uses exactly this (via APR, see the use of SHELL_PATH  in apr/threadproc/unix/proc.c) when you use piped logs, and also in other circumstances such as external output filters (via ExtFilterDefine), and processing of #exec cmd SSI includes. This behaviour almost certainly applies to many third party modules too.

The best steps to take to secure your web server:

patch or upgrade your bash package (if you do this yourself make sure there are no stray sh instances, check for sh in any manually set up chroots too)
run Apache in a chroot, use a minimal /bin/sh if and only if it is required:

in Apache httpd 2.2 switch from using "|" to "||" in piped logs, this removes the need for /bin/sh (available since Apache 2.2.12)
in Apache httpd 2.4 make sure you're not using "|$" in piped logs, this reverts to the httpd.2.2 behaviour. 2.4 supports | and ||, neither use /bin/sh

make sure the default CGI scripts are disabled, double check from the top-level Options (e.g. <Directory /> down for ExecCGI
consider mod_security if you're not already using it. Red Hat have provided some rules which can be used to log and clean up the environment in KB article 1212303.

You may also consider using "#!/bin/sh -p" in scripts, this forces bash into privileged mode, this prevents importing functions from the environment (along with other changes). This might help if you have vulnerable CGI scripts on a system, but no patch and no compiler. This might not work on Debian and derived systems, so check carefully.

(Also, if /bin/sh is bash, don't blindly replace it with something else, it might affect your startup scripts.)

Any application code that runs via CGI (other than bash scripts), or under Apache modules (Python and PHP in your case) may also play a part in this. If any variable can be sufficiently controlled by an attacker (URI-encoding may be a challenge), and if the application uses /bin/sh when invoking processes, and if those variables are preserved while doing so, then you might have a problem.

If you are running a contemporary Linux system, but you have not set up a chroot or some other container for apache, you should be able to use unshare and a bind mount to replace /bin/sh when starting Apache (or any other service).

unshare -m -- sh -c "mount --bind /usr/local/bin/bash /bin/sh &&
    /usr/local/apache2/bin/apachectl start"

The advantages to this are

less risk of breaking things, since you can selectively replace bash
you can log and audit attempts to invoke sh more easily

(What you cannot easily do with this is write a bash script as a wrapper to inspect and log suspicious variables, you'll need to use something else of course...)

If you're running auditd on Linux, you can easily watch the use of /bin/sh by adding a couple of rules to audit.rules and reloading:

-w /bin/sh                -p x
-w /bin/bash              -p x

(I need both, since sh is a symlink to bash)

Red Hat have published an alternate approach, a runtime "fix" which you can use with LD_PRELOAD, you can find that in the advisory. This could also be adapted to log dubious variables, if required. Given that there are currently questions over the completeness of the patches so far, this solution is probably a good short-term fix for Apache at least.

You can also find more general Apache hardening tips here: Apache Server Hardening


Which hashing algorithm shoud I use for a safe file checksum? For my work I'll need to provide my customer a specific file which will be the result of the work I have done for them.
To protect the integrity of the work I have done and to guarantee it has never been modified, I intend to add a checksum to my documentation which will be provided with the file.
Since MD5 and SHA-1 are not secure for a long time now, I was wondering if we were still using them for this purpose or if there are better algorithms which could do the same job but more safely.
I'm looking for the best reliable solution. I'm aware that a 100% proof will never be possible but I was wondering if MD5 was still rated "good" for this purpose or if there are really new and safer tools.

Choice of hash algorithm

Use SHA-256 or SHA-512: either of the two “main” members of the SHA-2 family. SHA-2 is the successor of SHA-1 and is considered secure. It's the hash to choose unless you have a good reason to choose otherwise. In your case the choise between SHA-256 and SHA-512 is indifferent. There is a SHA-3 but it isn't very widely supported yet and it isn't more secure (or less secure) than SHA-2, it's just a different design.

Do not use MD5 or SHA-1. They are not obviously unsuitable in your scenario, but they could be exploited with a bit of extra work. Furthermore the fact that these algorithms are already partially broken makes them more at risk of getting more broken over time.

More precisely, for both of these hashes, it is possible to find collisions: it is possible to find two documents D1 and D2 such that MD5(D1) = MD5(D2) (or SHA-1(D1) = SHA-1(D2)), and such that D1 and D2 each end with a small bit that needs to be calculated and optionally a common chosen suffix. The bit that needs to be calculated will look like garbage, but it can be hidden in a comment, in an image that's shifted off-page, etc. Producing such collisions is trivial on a PC for MD5 and is doable but expensive for SHA-1 (unless you want it for two PDF files, in which case researchers have already spent the money on the calculation to find one and published it).

In your scenario, you mostly don't care about collisions, because you'll be producing D1. You aren't going to craft this bit in the middle. However, there's a risk that somebody could trick you into injecting this bit, for example by supplying an image to include in the document. It would be pretty tricky to achieve a collision that way, but it's doable in principle.

Since there's risk in using MD5, and zero benefit compared to using SHA-256, use SHA-256.

What to do with a hash

With a non-broken cryptographic hash like SHA-256, what you know is that if two files have the same hash then they're identical. Conversely, this means that if two files have different hashes, then they're different. This means that if you keep a trusted copy of the hash (for example you print it out and store it, or notarize it), then you can tell later “yes, this file you're showing me is the same file” or “no, this file you're showing me is different”.

Knowing the hash of the file doesn't prove that you wrote it. There's no cryptographic way to prove authorship. The best you can do is to prove that you had the file earlier than anyone else who can prove it. You can do that without revealing the file by communicating the hash to a third party who everyone trusts to correctly remember the date at which you showed them the hash; this third party could be a public notary, or the Wayback Machine if you put the hash on a web page that it indexes. (If you publish the hash, then in theory someone could figure out the file from it, but there's no better way to do that than to try all plausible files until they find the right one. If you are concerned about this then use a signature of the file instead of a hash, and notarize the signature and the public key but keep the private key to yourself.)

Example of something a hash is good for: your customer wants support, but you're only prepared to support your original product and not a modified product. So you get them to calculate the hash of what they want you to support. If the hash value is not what you provided, you refuse to provide support. Note that you need to trust the customer to calculate the hash of the product, and not calculate the hash of some copy of the original or read it off the delivery slip.

Example of something a hash is not good for: somebody else claims that they're the author of the document. You say “no, look, I know its hash, it's 1234…”. That doesn't help: anybody can calculate the hash.

Example of something a hash is good for if used appropriately: somebody else claims that they just wrote the document. You say “no, look, I notarized the hash 6 last year, so you can't have written it last week”.

Example of something a hash is not good for: somebody makes a slight modification of the document. It'll then have a different hash. All you can say is that the document is now different, but that doesn't convey any information about how different they are. The hash of a completely different document is just as different as the hash of a version with a typo fix, or a version that's encoded differently.


Can converting a virus-infected webpage to PDF format still contain viruses So I know that PDF files can contain viruses themselves if they are target specifically for that purpose. However, my question for here is this: If a webpage that has some malicious scripts or a virus is converted into a PDF using one of the popular programmatic html to pdf conversion libraries (eg. in nodejs or python), and a user opens that PDF, is there any chance at all that the PDF itself is infected as well?

I don't think it's possible. Usually, the library will render only the visual part of the page into a PDF, and not the embedded javascript, needed plugins or anything else. It's basically a screenshot.
Although it's possible to a specially crafted HTML page crash the library, perhaps executing code because of this, it would not reflect on the resulting PDF file. Depending on the attack, it would not even generate any file.
But I don't think anyone would create a crafted page attack a library in a way that generated a crafted PDF to attack your PDF reader.


How to ensure a new key has propagated I have a hub that communicates with an IoT device and needs to change the encryption key on that device at frequent intervals.

Messages are AES-256-CBC encrypted using the old key, and the new key is included in those messages.

Once the new key is sent, I need to be absolutely sure that the hub and the device are in sync on what key is being used. Why? The connection can drop at any time.

Given that, here are some things I've thought of:

Hub sends key, updating its own, then the device updates to the new key if it receives it. (What if the device doesn't receive the key?)
Hub sends key, waits to update, then the device updates its key, then sends back a 'Key received', upon which the hub updates its own. (What happens if the device's message back never gets received?)

It seems to me that no matter what, there's a final communication that can cause a party to not confirm an update. Is there a way to make sure?

I'm assuming you're using HMAC or authenticated encryption so that the messages are immune to modification and so you can cleanly detect a failed decryption.

The hub has a list of connected devices, and for each connected device, the active key to use in messages to it, and a list of additional keys to try to use to decrypt messages.
The hub decides on a new key, and for each connected device, adds it to the end of the list of additional keys. (Easy improvement by making a minor change here: you could instead create a new separate key for each device. You don't need to share keys between devices.)
Whenever there are a nonzero amount of additional keys for a device, the hub periodically sends a message (encrypted with that device's active key) containing a request to switch to a new key (the last key in the additional keys list).
Whenever the hub receives a message from a connected device, it will try to decrypt it with the active key and then each of the additional keys until decryption succeeds. If decryption succeeds with one of the additional keys, then replace the active key with that key, and then remove that key and all keys before it from the additional keys list.

Each device only needs to remember a single active key at a time.

This should mean things continue to work even in the scenario where the hub cycles between keys A->B->C, and a device doesn't confirm the switch to key B until after the hub has announced key C.


Is password protecting a VPN file enough, or do we need to whitelist the connectors IP? We have an AWS network which can only be accessed once connected to a VPN. .opvn.

Currently, in order to connect to the VPN, our IP needs to be whitelisted from within aws which can only be done by a small group of people. This can be bothersome for remote workers who then cannot access the VPN should this group of people be offline.

I proposed we add username/password / 2-factor authentication to the VPN configuration and do away with IP whitelist approach, however, there is some pushback around security concerns.

My question is are these concerns valid? Would password-based authentication be enough seeing as it's enough to access the console which controls the whitelist?

Using an IP as an authentication method is not a great practice. It can be slightly useful as second factor, but it is much better to rely on real authentication methods. IP can be spoofed in many ways, or the attacker may be able to bounce the data from your network, if he compromises a device in it.

I would suggest you use the PKI authentication paired with TOTP. TOTP should be more secure than using a password, as an attacker that can steal the private key will often be able to install a key-logger as well, but that will not help with TOTP. You can add password as a third factor if you want, just to make sure. While the password should be unnecessary assuming employees follow basic security precautions, such as having the phone with TOTP app locked, you should never trust users to do things right.

PS: If you really want to invest into security, you can also use physical tokens. But it should be completely unnecessary in most cases.


How are SSDs different from HDDs from the privacy point of view? How are SSDs different from HDDs from the privacy point of view? Is it easier or harder to recover traces of deleted and/or wiped (overwritten) files from an SSD than from a HDD?

We have a whole bunch of questions on the difficulty of wiping data from SSD's. You should have a good browse round this site.

Simple answer is:

By default, SSD's leave more data on the drive. This is because of wear leveling - overwriting doesn't exist as a concept in the same way as on a physical platter. That said, there are known solutions, the most common being the use of whole disk encryption as a way to wipe the drive, by just forgetting the key.


Can my employer surveil me while using "remote desktop"? My job uses the remote desktop application for us to work at home. I am just realizing that my laptop, and everything on it, can be opened through the file explorer on the remote desktop application. I am wondering if my emp

No, they cannot "surveil" you unless they are also using the connection and connect back to your machine. This is unlikely, and you would notice it unless you kept the connection up and they someone hijacked your RDP session.

In the RDP connection settings, you can determine what you share from your local machine in the "Local Resources" and "More..." section.


Getting the column names of a table by brute force blind SQL injection Is there a way of getting the column names of a table by brute force blind SQL injection in MySQL.
so the query would be:

select column_name from information_schema.columns WHERE table_name = ‘tablename’ and *column names first letter = "a"*

so if the first column name of that table does not begin with 'a', it would return an error if it did begin with 'a' it wouldn't. and do the same for the second, third letters and so on working through the alphabet. Is this possible? or is there a more efficient way maybe? Thanks

There are several ways of getting the column names in mysql, and the kind of attacks that are feasible will depend on the application being attacked.

For a generic answer, I would recommend studying the way SQLmap is able to discover the column, table or database names.


What steps should be taken to validate user uploaded images within an application? Recently I have worked on a number of applications that need to process user uploaded images steps have been taken to validate the extension and the mime type.

But what else can be done to ensure the image is valid?

In my case the upload is handled by PHP and then passed to GD or ImageMagick both of which suffer from vulnerabilities that can result in denial of service and possibly the execution of arbitrary code.

I would be interested in any suggestions people could offer to improve the validation process both specifically to PHP and also to any web or non-web application in general.

From my example question on Area51 Proposal

Even it sounds simple to be done, image check could be tricky. At least following actions should be done:

check size of image - width, height and size of itself;
check extension and name of image;
check content type;
limit amount of uploaded images;
limit access to uploaded images - better if user don't know where it is stored;
limit types of image extensions;
preferably change name of image;

Also, I would recommend change type of image explicitly after those checks, e.g. from PNG to JPG. Simple, but works well.


Why do we need token authentication? If I'm creating an authorization service for my application, why can't I just hash the password and save the the username and hashed password in my User table? Why should I use a token authentication service like JWT? I don't think I'm right but I feel like I'm missing something here.

Well, for starters, a token can be expired in a relatively short period of time, forcing a user to re-authenticate.  A password is generally has a much longer life.  Thus, if a token is stolen by an attacker it is useful for a relatively short period of time (this is one reason that when you have to change a password a good system will force you to enter the current password).

In addition, if you put a hashed password on the client then it can be stolen and used by an attacker in "pass the hash" attacks, which have been around for over twenty years now.  It'd be nice to get rid of them :-)


How does malware connect to FTP servers without revealing credentials to the victim? Let’s take an FTP based passwords stealer, or some keylogger, that uploads the details of our victims to our FTP server. How do they connect back to our FTP server?

As far as I know that for uploading any file to our FTP server we need its details (hostname, user and password). So do they keep our FTP details inside them? If yes then, if our victim know reverse engineering, can't he steal our FTP details and this will be reverse attack on attacker?

Does it work like this or am I misunderstanding something?

You are implying that knowledge of the server and the FTP credentials is sufficient to attack the server or account. I'm note sure what kind of attacks you envision but:

The credentials might also be used for this specific FTP account, i.e. no SSH access or similar to the server is possible
The credentials might also be sufficient for uploading data to the server but not for directory listing or downloading data. This write-only mode is actually not that uncommon with FTP, often combined with allowing anonymous uploads into a special incoming directory. This is sometimes called a "blind drop".

Assuming that these credentials are only for this server and only usable for write-only access to FTP I cannot see really useful ways to attack the server, apart from denial of service attacks.


What is the difference between single hardware firewall and router? With some googling, I learnt that routers contain hardware firewall. But I saw in many pictures that firewall and router devices are apart as follows:

I know that there are a lot of firewall devices and also router devices in the markets separately. But what is the point? Can we say that in time, router included firewall device in itself and became 2 in 1 device? Or Can we say that firewall device means router and router device means firewall?

Note: My question is not about software firewall and router device. I'm asking you the difference between hardware firewall and router device.

A router can be some simple very cheap device to connect a home to the internet. But it can also be some really expensive device managing the traffic on the backbones of the internet. Similar a firewall can be some simple software to filter packets based on port and IP address only which easily fits into the home router. But a firewall can also be something doing deep inspection with a high performance in which case you usually have an expensive appliance just for this task.


Attack Challenge/Response Authentication by requesting challenges If a client/server application uses a challenge/response pattern for authentication, e.g. SCRAM or alike, it often involves the usage of nonces (client nonce and server nonce) for preventing replay attacks.

The server will generate a server nonce, based on a secure random generated number concatenated with the client nonce. Supposing that the server stores the most recent received client nonce, and issued server nonce, to guarantee that "older" or "invalid" nonces will not be accepted, this would open an attack vector.

An attacker could brute-force request challenges to userid's that he guesses, in order to override the valid and agreed client/server nonce with a new value, that the actual client doesn't know. If this happens in between the actual client's challenge and response, the server will deny access as the nonce will not be valid anymore. Which would be some kind of Denial Of Service attack.

If the server decides to only update the actually valid server/client nonce in storage only if the challenge/response was successfully executed as a whole, it would need to decline challenge requests for users that have not responded to the most recent challenge. This would also open an an attack window. The attack could request challenges to (guessed) users in order to prevent them from requesting a challenge in the first place.

Assuming that the server will keep track of a list of unused nonces, both attacks would be prevented, but this opens another vector for the attacker to request huge amount of challenges, leading the server to store all of those nonces in storage. Provoking I/O load and potentially leading to DoS again.

Anyhow I am currently not understanding how to securely implement nonce handling on the server-side to prevent those DoS attacks. Currently I have the feeling that one trades the protection against replay attacks in favour of DoS.

I know that there are other means to prevent this, via request throttling on firewalls etc, but I'd like to solve this problem on the challenge/response implementation level if possible. Thanks for ideas and answers.

The two concerns you've raised are:

The server's copy of the server nonce can be altered by an attacker who doesn't know the password.
As the server's list of client nonces grows without bounds, it can be used in a DoS.

A common technique is to time-limit the nonces. Say, for M minutes for an appropriate M.

For the first problem, by time-limiting the nonces, the server can maintain multiple authentication sessions with the client, each one keeping track of it's own nonce. This isn't a large resource drain on the server as these sessions are automatically deleted after M minutes.

The second problem is resolved by time-restricting client nonces. For this to work, the client nonce must include a timestamp. Otherwise you're open to post-timeout replay attacks, when the server cleans out its expired nonces, thereby "forgetting" used nonces. So the client's nonce should be timestamp + secure random number. By including the timestamp in the nonce, it ensures that the nonce cannot be used post-timeout.

WHen determining the value of M, it needs to be large enough to handle network communication times and clock differences between the server and the client. M needs to be small enough to sufficiently lower your resource requirements. M being 1, or even less than 1, may be appropriate if no user interaction is required during the authentication process. If there's user input required, a larger M will be needed.

A well-resourced attacker may still be able to execute a DoS upon you as there is still a window of M minutes for this to occur. But this is a small window and would require a lot of attacker resources. That is, it would be a DDoS and not a straight DoS. Surviving DDoS attacks are a problem of their own.


Keycloak's Angular quickstart : XSS vulnerable? We are using Keycloak for the authentication of our server-side rendered applications (Java/Spring/Thymeleaf), and now we want to use it for our Angular applications.

Using the Angular quickstart, the token is set in the Authorization header (as you can see below). My question may sound dumb, but since Javascript will always be able to access the token: isn't it a huge vulnerability? (in case of XSS)

Would it be better to use a http-only cookie?

Example of request to the API using the Angular quickstart:

- Request URL:
https://my-app.com/my-resource

- Request Method:
GET

- Response Headers
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://my-app.com

- Request Headers
Authorization: bearer eyJhbGciOiJSUzI1N.............
Origin: https://my-app.com
Referer: https://my-app.com/
User-Agent: Mozilla.............

Link to the angular quickstart: https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-angular2

First of all, yes, an XSS vulnerability will allow an attacker to access the bearer token in the authentication header. But this alone isn't the full story.

Your decision, if you want to transfer the bearer token as authentication header or as cookie, is based on multiple factors:

How large is your token? Cookies are limited to 4kb. If you transfer many and/or large claims in your token, this space might not be enough. In such a case, the authorization header is the logical alternative.
Are you protected against CSRF? When you transfer your authentication tokens as cookies, you open yourself up to potential CSRF attacks. If you go this route, you must be even more careful to verify your application's resilience against CSRF.
Why do you fear that your bearer token is stolen via XSS? May sound like a stupid question, but it is highly relevant. Your application has a sever issue, if you are vulnerable to XSS, period. Stealing your bearer tokens is only the tip of the iceberg. Yes, adding the http-only flag to your sensitive cookies is a second line of defense, but your first priority must be ensuring that you do not have an XSS vulnerability in the first place. Putting your bearer token in a http-only cookie is no excuse for a lack in protection against XSS.

In summary it can be said, that both options (cookie and authentication header) are accepted methods and both have their benefits and drawbacks. Which one is the better choice, depends on the surrounding factors.


Bitdefender threat error even though I never installed Bitdefender I got this strange error today:

  A problem has occured in BitDefender Threat Scanner. A file containing error information has been created at C:\Windows\Temp\BitDefender Threat Scanner.dmp

I can see the file is there. But I've never installed Bit Defender on the machine as far as I know. It's a Win2012 R2 machine I use as a development machine. There's ITBrain by Teamviewer which does malware detection. It hasn't picked anything up nor has MalwareBytes which I downloaded to scan the machine after the error. I spoke to Bitdefender and they have said they would look at it. I was wondering if anyone here had any ideas.

I got to the bottom of it. I actually spoke to BitDefender. I use some malware detection software from TeamViewer called ITBrain. That was the culprit. It uses some "drivers" (BitDefender's term) in it's software and the error was from that.


Do I still need CSRF protection when SameSite is set to Lax? During a security assessment I noticed that Firefox automatically set the SameSite value of a session cookie to Lax. According to the Mozilla specs, this is the case for 'modern browsers'.
The SameSite attribute set to Lax seems to protect against CSRF (every cross-origin request that's doesn't use GET). Obviously, outdated browser would still be vulnerable.
Would you still bother developers with implementing CSRF protection, if session cookies are protected by default in modern browsers? It depends on your security/business philosophy, and the type of application, whether it's worth the effort. I'm interested in your opinion on the matter. Obviously, in the best case one would implement classic CSRF protection everywhere, but it keeps getting harder to sell the implementation efforts as a business case to development teams.

You still need "traditional" CSRF-protection. Maybe this will change in the years to come, but as of writing the SameSite attribute should be viewed more as defense in depth than your one and only line of defence. This is for a few reasons:

According to caniuse.com, there is currently only browser support for 85% or 92% (if you count partial support) of global users. For instance IE 11 on Windows 8 (still used in many offices around the world) doesn't support it, and neither does the UC Browser on Android.
Relying on browsers to auto upgrade to Lax is even worse, since not all supporting browsers do this. I don't have any numbers, though. But at the very least, you need to explicitly set the flag.
Do you really trust all current and future developers of your application to never change server state on a GET request? I wouldn't do so - I would not even trust myself. If you want to rely on SameSite, set it to Strict.
If you do not trust your subdomains, SameSite will not help you. See this great article by jub0bs.
As I write in this answer (second bullet point) there are some cases where you will always need a traditional CSRF-defence.

TL;DR: Just the SameSite flag is not enough to protect your users from CSRF.


Windows Session Recording Software I'm trying to monitor connections and actions made by administrators (or any user connecting) to a server through TSE (i'm simplifying).

I've heard about a software which can record a video of any TSE session (you can define framerate of the capture) started on a server (an Agent has to be installed on the target server). It is called "Observe-IT".

Do you know any similar solutions so that i can compare it to Observe-IT ?
Solution can be a Session video recorder, or any other software that would allow me to monitor all actions made on a server, including in a graphical manner.

Thanks in advance !

ManicTime records video of session activities and indexes the video with the time sequence of active applications. It is free for personal use but not for commercial use. It is not a keylogger. If this category of software would meet your requirements, you can find a few similar products at alternativeto.net.

There is also the category of software designed to enable employers to monitor employees' acceptable use of computers. A recent answer here on security.se uses the example of the "SPECTOR PRO" product.

Returning to ManicTime, it is primarily designed for one to track one's own use of one machine. However, I see that it has several features that may be useful for monitoring an untrusted user, or multiple machines, or both. It has options to suppress its system tray icon, encrypt its data with a password, and schedule local or remote backups of its data. It can be used in combination with a cost-free server product that aggregates data from ManicTime application instances. It can reportedly store 20 years' worth of data in one gigabyte.


Why would an attacker try SMTP login many times even though it is disabled? I recently set up an SMTP server for myself to use, and I am getting some traffic from two IP addresses and none else (though for obvious reasons I will not state the addresses here).

An example session (which, in fact, repeats itself EVERY TIME) would be:

Server: 220 <hostname> ESMTP
Client: HELO *.*
Server: 250 <hostname>
Client: AUTH LOGIN
Server: 503 5.5.1 Error: authentication not enabled
Client: QUIT
Server: 221 2.0.0 Bye

Why would the attacker(s) keep trying this, when LOGIN auth is clearly disabled?

Furthermore, why would the potential attacker(s) use SMTP (when ESMTP is clearly available), and what does HELO *.* mean? (I am aware of what the HELO command does)

For reference, I am getting roughly one "attack" every 15 minutes.

Attack code is often a hastily scripted affair, poorly written and without proper error handling. It’s probably only checking for a a 200 OK response, and retrying in case of any non-200 response.

To elaborate further, the attacker isn’t interested in complying with the protocol. His goal is not to make your server happy. He’s only interested in testing login credentials.

There’s not much you’ll be able to do about it. Make sure your SMTP server is patched and on the most current levels, etc.


Does changing the scrypt salt have security implications? I'm using scrypt to stretch a user-supplied password for use as an AES encryption key. The data that's being encrypted with the AES encryption never changes.

I'm aware that if the user changes the password, the random salt must be regenerated.

I'm wondering if there are any security implications for unnecessarily changing the salt. i.e changing the salt without changing the password.

Note that this is in an environment where we're assuming all past and present copies of the salt and encrypted data would be available to an attacker.

No, there are no implications. From what i know, scrypt is not vulnerable to differential cryptoanalysis.


Foolproof way to hide your IP when browsing is there a fool proof-ish way to hide your IP from websites you visit?

I heard even if you use VPN, there can be 'leaks'?

And one step more secure is Anonymizer or Tor? Can they have 'leaks', too?

I'm using Mac and iPad.

"Foolproof" does not necessarily means "NSA-proof" or whatever. A foolproof security system is meant to be a system usable by non-technical users and lowering as much as possible the risk of a misconfiguration impacting the security. Browser's, for instance, involve a lot of "foolproof" security technology against phishing sites, etc..

In case of communication tunneling and anonymity, a reference on the domain is Tails, a linux distribution preconfigured in a way that all outgoing traffic should go either through Tor network, or be blocked (cf. the DNS leaks mentioned by @schroeder and how Tails address them). Tails can be used as a physical media to boot your PC (more secure), or in a virtual machine (more practical).


Is this a security risk for us to lost TPM or others to access to reset BIOS ? In the previous post Physically secure the system case it is recommended to physically protect the system. But in case stolen laptops where intruder have physical access to TPMs. What are the security risk involved if we lost TPM or others can access to reset BIOS apart from datalost?

A well designed TPM should be pretty resilient to tampering, but a truly determined attacker could try doing something like dissolving the casing and reading information directly off the chip.  It's a pain staking and highly technical process, so probably isn't a likely case in most situations, but if the value of the material is known to be high enough, it could potentially be a risk.  (Though success is not guaranteed and they only really get one shot at it.)

BIOS itself is pretty much a joke to reset in most cases, but would typically result in a wipe of the TPM if so equipped.  It certainly isn't a desirable case to have hardware lost, but the main reason to protect a physical system is to protect data in use rather than data at rest.  If for example, you lost a computer and then it was found, it would be wise not to trust the hardware or unlock it until you had a chance to verify it wasn't tampered with.  Physical alterations could easily pull out the keys when the device is next unlocked.


Is it safe to use Orbot with the normal Firefox browser on Android I noticed that when using Orbots "VPN Mode" that my normal Firefox browser works fine and when I visit check.torproject.org it says I'm connected even though I'm not using the Tor Browser specifically. If I install the Https everywhere and NoScript extension, are there any compromises to using Tor this way?

Using normal browser such as Firefox for Android, while browsing, does not provide required privacy standards, that Orfox/Orweb provides.
To be more specific:

Orfox adds patches at the Android Java code layer to enable proxying of all Java network HTTP communications through the local Orbot HTTP proxy.
It also removes Android permissions for Contacts, Camera, Location, Microphone and NFC.
Features like WebRTC and support for interaction with
Chromecasts or Roku devices are removed, due to lack of compatibility
with proxying communication through a TCP-based network like Tor.

  Source: Orfox: A Tor Browser for Android - Guardian Project


How to tell when a masquerade attack is occurring? As I understand it, a masquerade attack is when an attacker acts as a registered/ authenticated user or entity in a system.

There are obviously ways to prevent this, for example user education, don't leave passwords around, etc. But of course hackers have other ways of getting user credentials.

This leads to the question; rather than preventing an attack, how do you respond to one? It seems that it isn't possible, as the whole point of a masquerade (or any attack) is to go unnoticed. Any insight will be appreciated.

Responding to an attack like this is a multi-step process. You need to:

Prevent
Detect
Respond and purge

Let's start with the prevent stage.
An attacker can masquerade as another user in a multitude of ways: Physical, over the Internet or even over a phone call. In each of these cases, your attack mitigation strategies will be different:

Mitigating attacks over the internet:

General checks - ensure that an attacker provides some sort of two factor authentication. The simplest example of this is a code that is displayed to a logged in user (a 'support pin') that is required to allow access to an account.
Aggressively use OTPs. Customer wants a change made to an account? OTP. Lost their phone? Ensure that they answer security questions.
Train your employees to be harsh. Sacrifice some customer happiness for security if necessary (don't overdo this.) Example - Customer calls up, sounds flustered and has conveniently lost their phone. Be brutal - don't be nice and fix things for your customer as a one time favor. Instead ask them for another form of verification (although note that a well-prepared attacker will have enough information to answer most security questions.)

Mitigating attacks over phone calls:

Use the same checks as above, plus:

Use email verification for identity checks.

Mitigating Physical threats:

Check for ID badges at every door/compartment.
Train your employees not to allow tailgaters or flash someone in because they forgot their badges.
Use a normal practice of treating every person as a threat until they've proven otherwise.

Now we come to the second part of this answer: The trick to detecting an attacker is to make their lives as hard as possible - employee training. train them to distrust any person and guard their information very carefully. Use security checks (like support codes). If someone fails to pass a security check, immediately escalate the issue. Don't help a customer just because they claim to have lost their identification proof(s). These little checks and their results are your detection mechanism. Someone fails them? Set alarms off.

This answer is very broad for a couple of reasons - your question is rather vague. I just detailed the basic process in this answer, but you'll have to port it to whatever you're trying to protect. Good luck!


Abuse complaint regarding my server I received this email for my hosting:

Please see the forwarded e-mail below for more details. Apparently,
your server is used for hacking which is strictly forbidden by our
ToS.
> 167. - [09/Oct/2020:15:37:42 +0200] "GET /wp-login.php HTTP/1.1" 200 10581 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0)
Gecko/20100101 Firefox/62.0" ```

I then used chmod 755 for all directories and changed the password for root. Is it solved?

I then used chmod 755 for all directories and changed the password for root. Is it solved?

No, it's not. If your box is compromised, this will likely not help at all. The first action any attacker will do is to install tools to ensure access.
You have to reinstall it from scratch, and secure it better this time. How to secure it depends on what software you have.


Smart card compatible with Schlumberger (Gemalto) Cryptoflex 16K and USB reader Another question related to previous ones A SW system constructed with Microsoft CNG can be FIPS 140-2 Level 2 Compliant? and About performance of Smart card for performing 3DES in a MD5 hash

We need to use Smart cards compatible with old Schlumberger (now Gemalto) Cryptoflex 16K (We are not versed in Smart card providers and their functionalities).

The Smart card is used for storing keys provided by a government agency and optionally we can use it for performing the cryptographics operations, basically 3DES on a MD5 hash. We have to provide the blank Smart card to the government and they write the keys in the card (simplified). The government agency states supports Schlumberger Cryptoflex 16K or compatible Smart card. We are thinking in Gemalto but can use any other provider.

What providers and models we can use for storing the keys? Keys accessed using preferably Microsoft CNG.

What providers and models we can use for performing also the cryptographic operations (3DES)? Operations issued using preferably Microsoft CNG.

What providers and models of readers we can use? Windows Server 2008 R2, USB, contact reader.

Looks like your are working on some solution for the chilean interoperable electronic toll collection system. If so, check the new set of ST standards, they replaced the old key interchange using cryptoflex by a far simpler asymmetric key interchange scheme.You will not find a direct replacement for the 16k cryptoflex for this application.

Carlos Paratori


HTTPS flow clarification I have done a small test and result is as expected, but I am trying to understand more.
I have configured a fake DNS server to resolve all names to the IP of my VPS. On my VPS, I installed a web server with SSL, then set my client computer DNS to fake DNS.

when I ping from CMD tool to Facebook.com the server resolves the IP to VPS web server IP (this is good).
When I am trying open Facebook from chrome browser it says connection is insecure, but if direct try open IP of VPS with HTTPS it is successful.

I want to understand how Chrome check connection is insecure before handshake with real Facebook? If VPS also includes a real SSL certificate why does chrome not open successfully?
According to my understanding Chrome gets the IP of domain (Facebook) from fake DNS, and tries to open IP of Facebook. (VPS IP in this case) If remote VPS also includes SSL that opens successfully if I try direct IP of VPS, why don't other web sites forward to VPS with SSL connection?

My browser's message is:

www.facebook.com normally uses encryption to protect your information. When Google Chrome tried to connect to www.facebook.com this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be www.facebook.com, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Google Chrome stopped the connection before any data was exchanged.

While your VPS may have a valid certificate for your domain, your browser is expecting the certificate ot match www.facebook.com.  Without a trusted certificate for that domain, the browser will be unable to connect over HTTPS.

Having a certificate for one domain is not good enough to establish a TLS connection for any other domain.


Is it possible to reliably derive a key from a biometric fingerprint? Many products (e.g. notebooks, security doors and now smartphones) support some form of fingerprint authentication. That seems simple enough: A trusted system compares a stored representation of a fingerprint with the one presented to a fingerprint reader, and the authentication succeeds or fails.

I wonder if it's possible to derive an actual encryption key from a finger; something like PBKDF2, but taking into account the inherently "fuzzy" matching that conceivably has to be applied for fingerprint scans.

This would probably also apply for other biometric technologies like retina scans, voice or face recognition etc.

Reliably deriving cryptographic keys from biometric data is hard because of thresholds: biometric data is a continuum, but cryptographic keys are binary: a bit is a zero or a one, not something in between. Whenever you design a scheme to transform biometric data into keys, there will be people whose biometric data falls "on the edge" and who will get a wrong key half of the time.

However, this does not stop people from trying. This is an active research area, which does not suffer from an impossibility result (it is not proven that it cannot be done). See for instance this article, and that one, and also that one, and, in particular, this survey.

Executive summary: it does not work... yet.


Is only using one IP address version (IPv4/IPv6) an availability risk? Most websites configure their domain name server records only with A records for the use in IPv4 networks only. Some websites have configured AAAA records as well for use in IPv6 networks, using both IPv4 and IPv6.

This basically means that a server that only has an IPv6 address is not able to reach the IPv4 address and visa versa.

Does this mean that having an IPv4 address only is an availability risk? As well as only having an IPv6 addresses?

As always: it depends :)

Because so much of the internet is still IPv4-only there is a kind of implied responsibility to have IPv4 connectivity yourself. There are however advantages to having both.

The world has a huge shortage of IPv4 addresses, which means that there are a lot of hacks like carrier grade NAT, NAT64 and DS-Lite going on to keep users connected to the IPv4 internet. That means that when your service is only available over IPv4 then your users might be forced to use those hacks. When the service is available over both IPv4 and IPv6 the user can just use IPv6 and get better connectivity to your service.

This is probably also the reason that big services like Facebook and LinkedIn see 15% to 25% better performance over IPv6: those users don't need to go through a central NAT box at the ISP and don't lose performance there.

And if those central NAT boxes get overloaded (they shouldn't, if the ISP invested in enough capacity, but...) then IPv6 users won't even notice.

So I'd argue that there is already a certain availability advantage to deploying IPv6, and it will become a bigger advantage every month. In countries like Belgium almost 60% of the home users already has Ipv6 access.


Does Self-signed certificate differ from CA from a security point of view? I know that if I use self-signed cert, browsers will warn about it to the user, but I want to know that from security viewpoint is self-signed cert as secure as certificate authority(CA)?

Features

A self-signed certificate is capable of having the same security features (encryption, extended validation, permitted usage) as a certificate issued from a leading issuer such as VeriSign or GeoTrust. These options need to be set when the certificate is created.

Trust

However the purpose and the advantage of Public Key Infrastructure (PKI) (such as Internal Certificate Authority used inside an enterprise, VeriSign/Symantec, GeoTrust, and many more) is that there is an existing trust relationship between the client and the certificate issuer (e.g. VeriSign). The client (people and browser) trusts that the issuer has checked you out and has verified you are who you say you are. Certificate issuers have stringent security practises that they have to maintain. This type of relationship is not replicated with a self-signed certificate.

You can install a self-signed certificate into a browser (needs to be done for each browser) to make it recognise the certificate as trusted.

If you do not do this step the user has no way of knowing the certificate has changed unless they manually inspect the certificate. This could be dangerous because someone could intercept the transmission (man-in-the-middle) and the user would not know the certificate/host was the wrong one.

Summary

When looking at functionality alone, a self-signed certificate offers neither more or less security then one issued from a leading certificate authority.

Websites are for users, and a certificate trust is important so the user knows your website is who it says it is.

My personal opinion is that the trust and ease of deployment gained by using a public issuing authority is very important for a public web site, especially if you don’t have an existing close relationship with the people visiting it.

A self-signed certificate may be suitable for limited internal development / testing.

An internal Certificate Authority for use is a good solution for enterprises who use certificates internally and have an expertise in PKI.

Hope that helps


Advantages of using a Digital Signature Scheme (DSS) with Appendix instead of DSS giving Message Recovery I've been looking at the EMV draft specification (pdf) for using Eliptic Curve Cryptography in payment cards instead of the currently used RSA. One thing I've noticed is that they've moved from using the RSA Digital Signature Scheme (DSS) giving Message Recovery to ECC DSS with Appendix. My question is why would this change, from Message Recovery to Appendix, have been made? What advantages does Appendix offer over Message Recovery?

I know how both DSS schemes work but all I can see so far is that messages with Appendix are longer than their Message Recovery counterparts.

Ok, let's avoid confusing terminology, because "DSS" also means "digital signature standard" as in FIPS 186-3, which is not at all RSA.

RSA is a signature scheme "with recovery", meaning that there is a bit of room to embed some arbitrary data within the signature itself. The document you quote uses ISO 9796-2, which implements this kind of embedding. For instance, if you have a 2048-bit RSA key and used it with SHA-256 as hash function, then the signature has length 256 bytes, but you can reuse 222 bytes for your message, so the actual size overhead for the signature will be only 34 bytes. On the other hand, ECDSA (the elliptic curve signature scheme which your document alludes to) does not have the "recovery" feature, so while a robust ECDSA signature is shorter than a RSA signature of similar strength (e.g. about 64 bytes for something as good as RSA-2048), the actual size overhead is higher (i.e. 64 bytes). All of this depends on the key sizes and used hash functions; your mileage may vary.

Security of ISO 9796-2 is questionable (basically, you don't get your money worth from your hash function output size; you must use a hash function with a larger output to regain your security, increasing the size overhead). Also, ECDSA is computationally less expensive for signature generation, and that can be important for some low-power embedded devices. On the other hand, RSA is mathematically simpler, more widely used and supported (because it is quite older), and, depending on the parameters, may offer a slight size advantage.

Anything with elliptic curves is, of course, highly fashionable.


Exchange 2013 blocks txt file attachments - are there security reasons? My Exchange Admin is setting up 2013, and it is set to block txt file attachments specifically (as well as others).

I have tried searching for risks associated with txt attachments but could not find any. Are there any risks I need to be aware of surrounding txt attachments?

EDIT

The Admin did not set up the rules for blocking, but found that this was the default rule for Exchange 2013 during a migration from 2010. It was causing problems in our environment, so he asked me to approve the whitelisting of .txt files.

I've been supporting and administering email for 18 years, and never had a valid reason to block text attachments.   Here are some issues that I can think of, that aren't exclusive to TXT attachments alone, but rather regard attachments in general
Unicode parsing
The only two issues I've come across is this unicode bug but it's theoretically possible that other applications that have issues parsing and/or displaying unicode.
MIME-type vs file extension
Attachments in SMTP include not only a file extension .txt but also a MIME-Type and a corresponding encoding (as mentioned above).  Should any of these "metadata" not match up (vbscript with a mime of Text, or vice versa) it's possible to get unexpected results from a client.
Issues may include

File attachment icons appearing like a TXT file in the client, but are really an EXE
Clients (or services) improperly handling the attachment, potentially executing it
A variation of the above that causes the client (outlook / thunderbird, etc) to download an image, or verify a DKIM signature, losing the anonymity of the client.

Outlook
Since the most common client in an Exchange 2013 environment is Outlook, I'll focus on that, even though most of the issues here have been thoroughly looked at and is no longer an issue (as long as you're on a current and patched build).
Outlook Preview Pane Risk
The Outlook preview pane uses a special, locked down version of IE. Given that IE could execute "text" data as if it were HTML/XSS or any other active content, this could pose as a security risk.  (Outlook vulnerabilities as the preview pane has happened in the past)
WebReady Exchange Server Risk
A similar attachment to HTML parser is installed on the Exchange server itself called WebReady, and it converts attachments into HTML for Outlook Web Access clients.  This has already been an issue in the past, causing vulnerabilities and executable code to run in the context of the Exchange Server itself.  Read more about this security feature here.
Summary
In my opinion, before your admin blocks TXT attachments they should consider disabling Webready and address the lower hanging fruit first:

Improved authentication for end users (smartcard etc)
AV/AS on the server, and gateway
SMTP security including DMARC, DKIM, SPF, and Opportunistic / Secure TLS where possible
Content scanning
On demand portal encryption, SMIME or PGP encryption

If they are disabling attachments as a form of information management, to prevent the disclosure (or liability of receiving ) data, then they should consider alternate controls.
If they are disabling TXT attachments for security / encryption reasons and want all data encrypted, know that some encryption software sends the encrypted payload or public to the clients using TXT data.  Conversely, banning this activity is easy since there is a string in the file that can be scanned for.
Just for clarification, by "blocking" do you mean classifying it as a Level 1 or Level 2 attachment in Outlook?


Does it have sense to fuzz a ASCII file format with mutators that mess with Unicode or String Case? I'm trying to fuzz an ASCII file format. Specifically, I'm defining some HTML5/HTML structures to be used as definition file for a smart fuzzer to fuzz web browsers. This smart fuzzer allows to exclude some of the included mutators. The number of iterations and the slowness of my fuzzers invites me to exclude some of them.

I would like to know your opinion about mutators that change string case or inject unicode strings in value fields. Knowing that HTML is an ASCII file format and that browsers are working well with this,

Do you think that I should exclude these mutators in order to focus the fuzzer in mutation that have higher probability of show vulnerabilities? Do you think it is important to mantain these mutators?

I obvously will mantain mutators that do the following things:
Duplicate nodes
Duplicate nodes recursively (test
Mutators that mess with sizes (height, width)
Mutators that mess with the order of the nodes
Mutators that remove nodes

Do you recommend other type of mutators that will be interesting to include when fuzzing HTML/HTML5/XML file formats?

Definitely include it. Assuming you're trying to fuzz the html file parser itself, it will definitely be worthwile to include unicode mutators to see if the parser handles it properly.


Securing API access. oAuth Client Credentials vs client ID and secret I have a REST API that will be called by other external 3rd party servers over the internet and be used only for machine to machine communication. I am looking for mechanisms to secure this API such that only servers that I designate will be allowed to use this API. I do not control the servers and cannot guarantee the IP addresses that these servers use.

I thought of using the OAuth client credentials flow to secure the API by giving each external server a client id and a client secret. But that made me realize why use OAuth at all and not directly deal with client id and secret i.e. when the external servers call my API they will pass the client id and client secret and if a compromise happens I will revoke the client secret and the communication will no longer be allowed. For the communication to start again, I will issue them a new client ID and secret.

Is this approach correct? If not, what is the advantage of using the client credentials flow in OAuth if the external server has to store and pass the client id and secret to get a token anyway.

Using client credentials flow would make sense if

there is need for separation of authorization server (which grants access) from resource server (which server API)
there is a need for separation of more trusted client part (which knows credentials) from less trusted (which uses token to call API)

if it is not a case then there is no need to complicate the API with OAuth.

I would also suggest considering client certificates for securing API access instead of id/secret combination. They have the benefit that the private key never needs to leave client machine, while secrets need to be transferred over the wire and received by the server every time they are used.


Are encrypted cookies over http safe? I am new to cookies. My understanding of encrypted cookies is that a server can store info. at client side without the client knowing about its contents. Now, let us say a server generates authentication information for a client in an encrypted cookie which the client stores at its end. Now, if an attacker sniffed the encrypted cookie and made a malicious request to the server presenting the encrypted cookie, wouldn't the server process the request as if coming from a genuine client?

What is the point of encryption when an attacker can use the same encrypted cookie?

... and made a ... request to the server presenting the encrypted
  cookie

Without knowing particular server, we cannot really answer this question. But if we assume that the server does not use any other information (user IP, user location, user device data), then very probably the server will accept such cookie and believe that the attacker is the original user.

If an attacker get access to user cookies, encryption prevents sensitive information from disclosure. But this is arguable if this is a good practice or not. Users can clean up their cookies regularly (many browser extensions clean up cookies every 1-2 hours or every time browser is closed). So more reliable way may be to keep sensitive data in the user account on the server side.

Encryption of separate cookies does not prevent from manipulation on the user side. If user knows the meaning of the cookie, then he can replace some cookies with his own cookies from the earlier sessions (if they are not expired), or exchange cookies with friends, or in some cases steal cookies. In such cases encryption gives no advantages.

Some developers encrypt cookies to prevent their modification by users. But actually such approach is error prone. Backend should never accept client data as is and should always validate them. That's why the encryption for integrity purpose makes normally no sense.

You said "over HTTP". Encrypted cookies are no readable for anyone who reads HTTP traffic. But if web sites uses HTTP, then it is very probable that the information in cookies was earlier provided by the user in previous HTTP requests to server without any encryption. Thus it is very probable that the attacker knows this information already and encryption of cookies gives only a false feeling of more security.

The users who know what are cookies, may think something like "they are spying on me". Thus encryption of cookies may break the trust in the web site.

"What is the point of encryption ...?" In many cases there is no point, developers just have a false feeling that this may give more security.


What is the difference between HTTPS and EAP-TLS? As far as I understand they do pretty much the same.

no, they don't.
HTTPS is HTTP over SSL/TLS. It is HTTP payload encapuslated in TLS transport.
EAP is credential authentication protocol which is encapsulated in TLS.
They both serve very different tasks. What is common between them is TLS transport. But TLS doesn't care what is encapsulated inside, HTTP, EAP, SMTP, whatever else. Everything can be encapuslated into TLS. But HTTP and EAP are very different payloads and can work without TLS.


PCI compliance over two domains We have an eCommerce website hosted on a dedicated server. We get our PCI compliance report from Qualays and there is no problem with that.

However, now we want to test something new on Amazon's AWS environment. But the idea is that we will still use the same checkout setup done on our main site.

So my question is will it be a breach of PCI Compliance if we capture card details on Amazon's AWS environment and then pass it to other website through web-service call and then process it there. We will not save any card data on AWS platform at the moment.

The only reason for doing it like that is because we do not want to invest time in making a different checkout.

If you haven't already done so, read Amazon PCI FAQs and request their PCI Compliance Package.

That being said, all you're doing is adding another server to your PCI scope.  As long as you add the AWS site to your Qualys scans and ensure that the handling of the data is in line with PCI requirements (e.g. encrypt across public networks), there's no reason you shouldn't be able to do what you want in a PCI-compliant manner.


Does TLS have any way of exposing only the URI in a SSL-SSL proxy, or BlueCoat style appliance? I'm writing an experimental authentication protocol and need to see the unencrypted URI's of the HTTP Call, but want to provably show that I can't see the data.

Does any standard, or feature exist that allows me to receive a HTTPSCall where I can only see

My authentication string
The URI being accessed
(nothing else, especially not the data)

From a REST-full perspective, this feels like a security guard who can inspect the doors but not see what's inside.

Does any tunneling, or cleartext "shared-variable" exist that allows me to see those properties (like Wireshark, but I have a TCP socket).

If you are asking whether or not an HTTPS connection will show the unencrypted URL in the network data, then the answer is partially YES.

Contrary to the previously accepted answer, the URL does not get encrypted like the rest of the data.

The base URL (ex. amazon.com) will appear as Server Name Indication extension (SNI) unencrypted data. Only the base URL. amazon.com/books will only show amazon.com in the SNI, the /books and beyond will not.

SNI exists to handle virtual hosted servers, multiple web sites hosted on the same IP address.

You can see this for yourself with a line capture. Fire up Wireshark (or whatever), go to a web site and look at the "Client Hello".


MITM: tools for intercepting and modifying traffic? I want to carry out a MITM attack to modify traffic, so I can strip out/modify things in the request.

For example:
When I receive a request on port 25, I want to be able to intercept all the requests, modify it (e.g. stripping out STARTTLS) and send it to it's destination on port 25.

Look into SSLStrip. It strips off the HTTPS request headers during MITM attack. If web server uses HSTS and browser supports it, then this tool won't be able to strip HTTPS. The code may give you some ideas.

Another option is scapy, which is a packet manipulation program that may be able to do what you are asking.


What are the security risks in enabling ipv6 We are considering enabling ipv6 on our webservers, so that we are reachable with both ipv4 and ipv6. Are there any security issues we should consider when enabling ipv6?

IPv6 only:

Unlimited size of header chain can make filtering difficult.
IPsec is not a panacea:

IPv6 mandates the implementation of IPsec
IPv6 does not require the use of IPsec
Some organizations believe that IPsec should be used to secure all flows:

Interesting scalability issue
Need to trust endpoints and end-users because the network cannot secure the traffic: no IPS, no ACL, no firewall
Network telemetry is blinded
Network services hindered

I recommend not using IPsec end to end in an administrative domain but for residential, hostile environment, or high profile targets.

IPv6 Attacks With Strong IPv4 Similarities:

Sniffing

Without IPSec, IPWithout IPSec, IPv6 is no more or less likely to fall victim to a sniffing attack than IPv4

Application layer attacks

Even with IPSec, the majority of vulnerabilities on the Internet today are at the application layer, something that IPSec will do nothing to prevent

Rogue devices

Rogue devices will be as easy to insert into an IPv6 network as in IPv4

Man-in-the-Middle Attacks (MITM)

Without IPSec, any attacks utilizing MITM will have the same likelihood in IPv6 as in IPv4

Flooding

Flooding attacks are identical between IPv4 and IPv6

IPv4 and IPv6 dual stack (as you mentioned):

Applications can be subject to attack on both IPv6 and IPv4 (weakest link)
Security controls should block and inspect traffic from both IP versions


Sites are signed with an incorrect VeriSign Class 3 G5 CA Previously today, I encountered a SSL error trying to access twitter.com in Chrome.  Investigating the issue, I encountered the same error accessing discussions.apple.com.  Most other HTTPS sites were working fine.  Trying Safari, the same errors occurred but I was given the option to continue regardless.

At first I thought it was this Apple security update issue, especially since it was suggested that Cyberduck with Amazon S3 was causing it and I had accessed S3 with the affected version just a couple days ago.  However, I recall previously having dealt with this issue, and looking at Keychain today I didn't see the duplicate certificates that were being reported by others.

After further investigation, twitter.com on my iMac is signed by the following certificate:

VeriSign Class 3 Public Primary Certification Authority - G5
Serial:  35 97 31 87 F3 87 3A 07 32 7E CE 58 0C 9B 7E DA
SHA1:  F4 A8 0A 0C D1 E6 CF 19 0B 8C BC 6F BC 99 17 11 D4 82 C9 D0
MD5: 32 A1 9C 63 E8 B6 02 89 3C 67 48 29 D0 40 AB C8

According to Symantec (and my Keychain), this is not the correct certificate.  My Macbook and a coworkers iMac show twitter.com signed by the correct certificate:

VeriSign Class 3 Public Primary Certification Authority - G5
Serial:  18 DA D1 9E 26 7D E8 BB 4A 21 58 CD CC 6B 3B 4A
SHA1:  4E B6 D5 78 49 9B 1C CF 5F 58 1E AD 56 BE 3D 9B 67 44 A5 E5
MD5:  CB 17 E4 31 67 3E E2 09 FE 45 57 93 F3 0A FA 1C

Similar things are happening on other Verisign sites I've tested (apple.com and subdomains, verisign.com), except for Symantec.com, which is signed with a different CA cert, but still incorrect.

VeriSign Class 3 Public Primary Certification Authority - G5
Serial:  25 0C E8 E0 30 61 2E 9F 2B 89 F7 05 4D 7C F8 FD
SHA1:  32 F3 08 82 62 2B 87 CF 88 56 C6 3D B8 73 DF 08 53 B4 DD 27
MD5:  F9 1F FE E6 A3 6B 99 88 41 D4 67 DD E5 F8 97 7A

This is signed by the correct cert on every other computer I've tested on.  No other CA seems to be effected.  I switched from wired to wireless on my iMac but the issue persisted.

This seems like symptoms of a MITM attack, but it seems to be local to my iMac since no other computers on the network are exhibiting this, which seems a direct contradiction.

I'm thoroughly confused and very worried.  I've airgapped my iMac and am running a virus scan on it now.  What's going on?  What steps can I take from here?

Don't panic.
It's just different ways of building a certificate chain of trust. Both ending in a trusted root CA. But once with and once without going via an additional intermediate certificate.

There exists more than one certificate with the CN "VeriSign Class 3 Public Primary Certification Authority - G5"

And SSL-Tools.net has a list of them.

There's your F4A8 (First two bytes of SHA-1 hash) cert in there. It turns out that it's a non self signed CA cert.

There's also your 4EB6 cert there. It turns out that one is a self signed root CA.

And your 32F3 cert is in there as well. That one is a non self signed CA cert again.

Now whether the client treats any of these three as a Trust Anchor is up to the client. Trust Anchor means: Okay, this is good enough for me. I'll do no further processing. There are different trust stores on different clients. (Microsoft, Mozilla, Apple being some of the more well known trust stores.)

What now?
So what practical consequences from this? Check your site with SSL labs. (Make sure to check the "Do not show result on boards" checkbox.) Especially: Make sure there are no chain errors.

Further reading
Your question is very, very close to the one discussed here:
StackOverflow: Python Urllib2 SSL error
Two of the CA certs are the same. And the answer by Steffen Ullrich is very good.


Is is possible to create a "signature" for a piece of JavaScript Bear with me, I may have asked this question in a botched way.

So I need some JavaScript code that creates a signature of JavaScript that is stored in a string.

Here is an example:

presignature = "<script>alert("test")</script>;

I need this JavaScript code that is stored in presignature to be made into signature.
I was thinking I could just keep on replacing the string with common uses of javascript (like changing "alert" to "a").

Any clues or tips?

Not a signature, however a Content Security Policy allows you to whitelist JavaScript for execution in your page
by including a SHA-256, SHA-384 or SHA-512 hash.

e.g. to allow <script>alert('Hello, world.');</script> you would include the following HTTP response header:

Content-Security-Policy: script-src 'sha256-sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='

Anything not matching would not be executed by supported browsers.

You can also use this to find out the expected hash of a script in development by opening development tools in Chrome and examining error messages on any mismatch.

It depends what you're trying to acheive - would a hash value be enough, or do you actually require a signature?


XSS via PDF when Content-Disposition: Inline? There are kind of two questions here:

Is it possible to have XSS in a PDF file when the Content-Disposition: is "inline"?
If it is possible, does the pdf get access to the cookies for that domain the same as if it were a normal html file?

If this is only possible with certain specific pdf file readers and/or browsers, that would be great to know.

Yes, there were problems in this area with Adobe acrobat reader plugin, just google for "adobe acrobat plugin javascript attack cookie".  I'm not sure if there are similar problems with the builtin JS viewers or if they are designed to live in a separate origin so that the same origin policy denies access. I don't think you even need to explicitly specifiy the Content-Disposition: inline.


Benefit to disabling TLS1.1 and TLS1.2? In light of recent developments on SSL issues such as BEAST and POODLE, I decided to configure my browser to only allow TLS1.1 and higher. The trouble is, that I am finding a lot of websites which do not work correctly (some websites serve all JS and CSS resources as HTTPS always) or at all. A bit of digging usually reveals that there is no cipher overlap, or no protocol overlap. In a lot of cases, I found websites are only accepting maximum protocol version of TLS1.0.

My question is, is there some good reason from a security perspective to allow only TLS 1.0, or is it simply pure "laziness", and there is no good reason not to allow TLS1.1 and TLS1.2 in addition to TLS1.0?

is there some good reason from a security perspective to allow only TLS 1.0, or is it simply pure "laziness"

It is in most cases just the TLS stack used. One of the most common stacks in web servers on UNIX/Linux is OpenSSL and the still widely used (and supported) versions 0.9.8 and 1.0.0 can do only TLS 1.0 and lower. TLS 1.1 and TLS 1.2 were only added with version 1.0.1 (04/2012). On the Windows side SecureChannel supports TLS 1.1 and TLS 1.2 since Windows 7 and Windows Server 2008 R2 (end of 2009).

And while changing the TLS stack might be doable for some sites it involves is most cases either the upgrade of the operating system or at least to run some parts of the system in a configuration not supported by the vendor.

  and there is no good reason not to allow TLS1.1 and TLS1.2 in addition to TLS1.0?

If the server has support for TLS 1.2 there is no  real reason to set the server up for only TLS 1.0. In fact, TLS 1.2 not only gives better security but also new cipher suites which can lessen the load on the server.


How do I secure my network with an open wifi? I have a business with an open Wifi router for my customers, I was wondering if I put the wifi router on a different subnet would help protect my wired network?

If the subnet is logically separated from your business network using a firewall, then it will make your network more secure.

If it's just a separate IP subnet with full access into your business network, then it will no really make things any more secure.

This question has more details: Sharing wifi at a business - Bad Policy?


SFTP, FTPS and SecureFTP differences and security implications What are the basic differences and security implications of using  SFTP, FTPS and SecureFTP.

There are 3 different protocols commonly used for transferring files over the Internet, and they are commonly confused with each other:

FTPS - an extension to the FTP protocol to support using FTP over SSL/TLS. This is typically based on a client-requested negotiation, and there are specific FTP commands to request/enforce/implement the encryption using SSL.
FTP over SSH (commonly called SecureFTP) - tunneling standard FTP over a SSH connection. Take into account that it is a bit more complicated to force the data channels to continue tunneling over SSH, even if the control channel is tunnelled.
SFTP - This is a completely different protocol, SSH File Transfer Protocol. This is not related to FTP, but is a completely different protocol. SFTP is actually a sub-protocol from the SSH protocol suite, i.e. a SSH extension (however I understand that it can be used separately, too).

Advantage of FTPS is that it is similar to HTTPS - same type of certificate, etc. Many web servers support FTPS natively, and thus it is often "simpler" to set up and have admins up to speed faster.
SFTP has advantage in *nix shops, that are typically already more SSH-friendly - if they already set up a public SSH server securely, its pretty simple to add SFTP functionality.
Note that SecureFTP (FTP over SSH) is NOT trivial in any case (even if you already have the SSH set up), and I haven't seen it in use by security-conscious orgs (that's not to say it CAN'T be, but isn't commonly).


Nginx forwarding undesired hosts to Django I've been getting errors from Django on my webserver (behind Nginx/uWSGI) complaining that it's being accessed with a request where the Host is the IP address of the server. Nginx is using virtual hosts so I'm expecting the Host to always be the server name, so Django's ALLOWED_HOSTS is just that.

Invalid HTTP_HOST header: '###.###.###.###'. You may need to add '###.###.###.###' to ALLOWED_HOSTS.

Request repr():
<WSGIRequest
path:/,
GET:<QueryDict: {}>,
POST:<QueryDict: {}>,
COOKIES:{},
META:{'CONTENT_LENGTH': '',
 'CONTENT_TYPE': '',
 'DOCUMENT_ROOT': '/usr/share/nginx/html',
 'HTTP_HOST': '###.###.###.###',
 'PATH_INFO': '/',
 'QUERY_STRING': '',
 'REMOTE_ADDR': '184.105.139.68',
 'REMOTE_PORT': '45409',
 'REQUEST_METHOD': 'GET',
 'REQUEST_URI': '/',
 'SCRIPT_NAME': '',
 'SERVER_NAME': 'subdomain.example.net',
 'SERVER_PORT': '443',
 'SERVER_PROTOCOL': 'HTTP/1.1',
 'UWSGI_SCHEME': 'https',
 'uwsgi.core': 1,
 'uwsgi.node': b'subdomain.example.net',
 'uwsgi.version': b'2.0.12',
 'wsgi.errors': <_io.TextIOWrapper name=2 mode='w' encoding='ANSI_X3.4-1968'>,
 'wsgi.file_wrapper': <built-in function uwsgi_sendfile>,
 'wsgi.input': <uwsgi._Input object at 0x7f...>,
 'wsgi.multiprocess': True,
 'wsgi.multithread': True,
 'wsgi.run_once': False,
 'wsgi.url_scheme': 'https',
 'wsgi.version': (1, 0)}>

The errors are triggered by 184.105.247.195, 1 or 2 per day, which is owned by the "Shadowserver Foundation", so I'm unsure if these (mock) attacks are being successfully thwarted (but annoying me with an error code) or if something stranger is going on...like how/why is Nginx passing a request with an IP Host to a server block that is of the following format (I have a catch-all server block that rejects Host-less requests):

server {
    listen 443;
    server_name abc.example.net;
    # ...
}

This SO answer tells me how to configure Nginx to reject malformed requests (wrong Host header), but that seems like a belt-and-suspenders approach.

Is this indicative of my belt not being closed properly while someone's trying to pants me?

As an addendum, it's using SSL (and I'm hosting multiple SSL sites on the same port, using SNI to distinguish them, not sure if that matters...). Kinda like this answer (to another question) mentions, does the "attack" consist of negotiating with one of the Nginx server blocks, then in the encrypted request changing the Host header to my server's IP?

The issue was being caused by Nginx using my Django host as the default, so an "https://293.7.10.738/" request was being delegated to it. The solution was to add a default server. The default is used when no other server block's server_name doesn't match the request. It is chosen by Nginx to be:

A server listening on the port (and address, if specified) with the default_server property
Otherwise, the first server block in the configuration.

I modified the main /etc/nginx/nginx.conf file to include implicit default server blocks that either

redirect HTTP to whatever the "default" host should be for the server, or
close HTTPS requests to invalid hostnames.

The latter has no impact on users because it's impossible to get a valid cert for an IP address. It's only strange crawler/clients that go around poking IP hosts, ignoring cert validity for some bizarre reason, that get dumped.

server {
    # Redirect IP request to primary host
    listen 80;
    return 301 https://defaulthost.example.com/;
}
server {
    # Terminate any HTTPS connections made with the IP address as host
    # (or any other unrecognized host).
    listen 443;
    server_name _;

    ssl on;
    # this is just a self-signed cert; there needs to be
    # a well-formed one for nginx to start
    ssl_certificate /srv/ssl/sham.cer;
    ssl_certificate_key /srv/ssl/sham.key;

    return 444;
}


Does the heartbleed vulnerability affect clients as severely? If I have a web crawler (using a non-patched version of OpenSSL) that can be coaxed to connect to an evil https-site, can they get everything from my process memory? To attack a server you can keep reconnecting to get more 64kb blocks (if I understand correctly), but can a client be forced to reconnect many times, to get more blocks?

Yes, clients are vulnerable to attack.

The initial security notices indicated that a malicious server can use the Heartbleed vulnerability to compromise an affected client. Sources below (all emphasis is mine).

Since then, proof of concept attacks have validated this position - it is utterly certain that clients running apps that use OpenSSL for TLS connections may be vulnerable.

heartbleed.com:

  ...When [Heartbleed] is
  exploited it leads to the leak of memory contents from the server to
  the client and from the client to the server.

Ubuntu Security Notice USN-2165-1:

  An attacker could use this issue to obtain up to 64k of memory
  contents from the client or server

RFC6520:

  5. Use Cases
  Each endpoint sends HeartbeatRequest messages...

OpenSSL Security Advisory 07 Apr 2014:

  A missing bounds check in the handling of the TLS heartbeat extension
  can be used to reveal up to 64k of memory to a connected client or
  server.

Client applications reported to be vulnerable (Credit to @Lekensteyn except where otherwise stated):

MariaDB 5.5.36
wget 1.15 (leaks memory of earlier connections and own state)
curl 7.36.0
git 1.9.1 (tested clone / push, leaks not much)
nginx 1.4.7 (in proxy mode, leaks memory of previous requests)
links 2.8 (leaks contents of previous visits!)
All KDE applications using KIO (Dolphin, Konqueror).
Exim mailserver
OwnCloud Version Unknown | Source

Note that some of these programs do not use OpenSSL. For example, curl can be built with Mozilla NSS and Exim can be built with GnuTLS (as is done on Debian).

Other common clients:

Windows (all versions): Probably unaffected (uses SChannel/SSPI), but attention should be paid to the TLS implementations in individual applications. For example, Cygwin users should update their OpenSSL packages.
OSX and iOS (all versions): Probably unaffected. SANS implies it may be vulnerable by saying "OS X Mavericks has NO PATCH available", but others note that OSX 10.9 ships with OpenSSL 0.9.8y, which is not affected. Apple says: "OpenSSL libraries in OS X are deprecated, and OpenSSL has never been provided as part of iOS"
Chrome (all platforms except Android): Probably unaffected (uses NSS)
Chrome on Android: 4.1.1 may be affected (uses OpenSSL). Source. 4.1.2 should be unaffected, as it is compiled with heartbeats disabled. Source.
Mozilla products (e.g. Firefox, Thunderbird, SeaMonkey, Fennec): Probably unaffected, all use NSS


PGP as method of sharing AES key? Would PGP work as a method of sharing the AES key, as shown below, and what would be the flaws with this method of encryption?

Server sends PGP public key
Client generates (uses as AES key for
networking) and encrypts random 128 byte key with PGP public key
Server decrypts data with PGP private key and uses as AES key for
networking

Obviously current standards such as SSL/TLS would work better, and the keys would need to be checked at some sort of CA (perhaps a public PGP key server)

When a SSL/TLS client and server talk to each other, the client needs to know the server's public key. In some dedicated applications the client already knows it (hardcoded in the client); but the normal method is for the server to send the key as an X.509 certificate. However, it is conceivable to use another kind of vessel for the server's key, for instance OpenPGP. There is even a RFC for that; GnuTLS is an SSL/TLS library that purportedly supports that usage.


Trying to GET "/iptac-xxxx" not found in nginx log. Is an attack? I've found some messages like this one, in my nginx error.log.

open() "[my-domain]/**iptac-***[a long long string]*/http:/[my-domain]/"
failed (2: No such file or directory), client: , server: , request:
"GET **/iptac-***[a long long string]*

I've changed some parts of the message for privacy, but the "long long string" seems to be something like an encrypted string.

Google doesn't know anything about iptac-, but I've found a website that reports a very similar URL (please, click on the follow link to see the reported URL with that iptac).

https://www.virustotal.com/en/url/db92d481524d4efe6d8f53358d41008c5e3695ded35d3e5f7398f5398779d2c5/analysis/

What is this?

IPTAC usually relate to a Cisco Web Security Appliance.
Can be like a cookie insert for a url redirect.


Use Tor when testing on web apps that allow testing & have bounty programs? When testing live web apps that allow / encourage security research & disclosure should I be routing my traffic through Tor?

Is there a good reason not to?

Does it imply a certain malicious intent that I'd be trying to mask the source of my traffic?  Or is it a good precaution to take in case someone misinterprets my poking around?

I've been practicing on VMs locally and I'd like to start testing on some of these sites that aren't hostile to security research but I'm not sure if there's a certain etiquette to follow (beyond their posted guidelines).

Websites with bounty programs allow live exploiting, to some extent. Be sure to read up on their guidelines on this before proceeding. I think it's better to not use Tor, since Tor usually signifies malicious intent, especially when coupled with attempts to exploit the system. And they may not take kindly to that (especially if you are using things which link you to your real account while trying to exploit the system like an API key). Just use your normal browser, and if they come a-knocking, show them the details of the exploits you tried.

Sites like Google block most Tor exit nodes, so this is usually a moot point.


risk from USB-C port on locked laptop If an attacker has access to the USB-C port on my laptop which is in powered on but at the lock screen, what is the risk that they are able to carry out an evil maid attack? Say I'm in the room but distracted by conversation and unable to keep an eye on the laptop. The attacker would not be able to open the case. Does the answer depend on the OS?

As an aside, it's getting hard to find a decent laptop which doesn't charge through USB-C, so I cannot block all the ports. Any solutions for this?

Because USB is plug and play, there are many opportunities for evil maid attacks with unrestricted port access. The article here shows how to use and human interface device to bypass the Windows lock screen: https://room362.com/post/2016/snagging-creds-from-locked-machines/

To prevent a human interface device from automatically running commands on a computer, the OS would need to be configured to ignore the USB ports. Autorunning and automounting drives should also probably be disabled, but these are usually problematic only after the computer has been unlocked. The exact method of disabling USB port access is OS dependent. Of course, if there is a bug in the OS that the attacker knows about, they may be able to circumvent the lock screen anyway. However, in the situation you presented, the biggest threat is rogue human interface devices. It only takes a few seconds for a plugged in drive to cause damage if the OS does not ignore it.

Some BIOSes also allow disabling USB ports, but I'm pretty sure that human interface devices can still connect, since it could be catastrophic to block all external control devices so early in the boot sequence.


Is my client challenge authentication secure? I have an app installed on customers' machines, a server, and a regular website between the two. In order not to have the customers configure anything (user credentials, proxy settings...), the app communicates with the server through the browser.

To prevent any random website to communicate with the app, we have decided to implement the following automatic challenge mechanism, using asymmetric public/private encryption.

For simplification purposes, I will not talk about the browser, but keep in mind that it's the browser that passes messages between the app and the server; they both don't know directly about each other.

I have generated a public/private key pair for both the app and the server. Each one knows about the other's public key and its own private key. The app private key will be deployed on the customer's computers, so it's not "really" secret (it's a business-line application, but it's always possible that the key ends up "in the wild").

The app generates a random token (a guid) and sends it to the server.
The server encrypts the token using the app's public key, signs the (original) token using the server's private key, and then sends both to the app.
The app checks the signature against the token (using the server public key), and checks that the decrypted data matches (using its own private key). If they both match, the server is authorized to do futher operations.

Is it secure enough to make sure that the server is authorized to make requests? If not, how can requests be spoofed/forged, and how can I further secure it?

Update

I have since realized that this scheme does not implement mutual authentication. Since the server is not called directly from the app but only through the browser, and the browser is authenticated on the server (using WCF), is it necessary?

This challenge response protocol doesn't really authenticate the server. Here a guid is shared with the server but the trust actually depends on the keys of the server and the client. Why not simply use those keys for communication then?
My recommendation would be to have a following mechanism:

The app generates a random GUID and encrypts it with it's private key
The server validates the freshness of the GUID and then creates a session key to be shared with the app. The key and the GUID are sent to the app by encrypting with the client's public key and signed with it's own private key.
The app decrypts the session key and sends the GUID encrypted by the session key to the server.

This way, you have a two way authentication if you have proper replay detection in place. The use of session key mitigates the risk of your key getting exposed.

If you however want to go ahead with your approach, here are a few pointers:

  To prevent any random website to communicate with the app, we have decided to implement the following automatic challenge mechanism, using asymmetric public/private encryption.

The app is totally dependent on the website. If it doesn't trust the website, how can it trust the messages that it is receiving from it?

  The app checks the signature against the token (using the server
  public key), and checks that the decrypted data matches (using its own
  private key). If they both match, the server is authorized to do
  futher operations.

What if someone does an XSS on the trusted website? The script may change the IP address/identifier of the server when it sends the response to the app. This way, an incorrect server is authenticated.

In order to completely answer your question, we would need more information on your implementation.

Do you trust the security of the website that the app is using?
An attacker my use the website as an attack vector to meddle with your communication.
Is the website communicating with the server using TLS?
If it is not over TLS, any party can act as the website to the server and keep it busy with new/repeated guids.


Can the network administrator of my university see what I have searched on Google? Before you mark this one as a duplicate, I have indeed seen similar questions here but they do not provide the direct answer I'm seeking.

Here are a few details:

I've taken google as an example because it uses SSL.
I am using my own device on their wifi network, so there is no possibility of a fake CA being installed on my system?
The padlock icon indeed is active, when I visit Google, and shows the correct certificate.

So, can I be sure that they are not able to see my Google searches?

Yes, given 1-3 you can be sure the connection is encrypted end-to-end between the browser and the server, and that a 3rd party cannot intercept the unencrypted message (without obtaining encryption keys through some other means).


Is one CSRF token per session is adequate with HTTPS? Ours is a Ajax heavy application with concurrent Ajax requests. Generating unique tokens with each request or expire and creation of new tokens after a certain interval could get tricky with multiple concurrent Ajax requests.

My question comes from the suggested approach here -

  Really, generating one each time the whole page is loaded should be
  enough if you are doing this over HTTPS, which you should be.

If we enable HTTPS, generating one CSRF token per session and using that token for all the requests in the session is enough?

To prevent CSRF you need to have something unguessable in the explicit part of the request (GET or POST). Putting it into the POST part is preferred, since it's harder to leak it, and you typically only protect requests that trigger an action, which should be POST.

A per-session random value is unguessable and should do the job. The standard anti CSRF token mechanism built into ASP.net works just like that.

HTTPS prevents leaking the token on the wire, and also prevents replay attacks. So a one-time-token doesn't seem necessary.


What is the difference between a bastion host and a dual homed host? From what I read, I understood that both the bastion host and the dual homed host are special computers that act as a link between the local network and the internet, so what is the difference between them?

Your question is a bit like asking what's the difference between a defense counsel and an attorney.  An attorney is a person who has studied law and is licensed to practice it; defense counsel is the role an attorney can play in a specific trial.

"Dual-homed" describes the networking configuration of a host that has interfaces in two networks. "Bastion" describes the role it plays: provide safe, controlled external access to resources in one of those networks to authorized clients in the other.


Is decompiling software considered unethical or illegal? Is decompiling a dynamic link library considered unethical/illegal or blackhat?

If, for instance, the result of the decompile showed methods and literals that contain passwords that the application use, is simply viewing decompiled source code breaking into that code?

Legality of reverse engineering depends on the country. As a rough summary:

In the USA, it is legal as long as the software was obtained legally, but if the license prohibits it explicitly (and most software licenses do) then it is a breach of the contract which the license constitutes -- thus "illegal", but a matter of civil law, not penal.

The DMCA also has ramifications in the matter. The reason for which you do the reverse-engineering is important: if you do it in order to circumvent a system which deliberately controls access to copyrighted work, then the Law will smite you mightily.
In the European Union, reverse engineering is legal as long as it is for interoperability purposes, whatever the license may say on the subject. Reverse engineering does not give you the right to publish your findings, though.

As for ethics, well, these things are kind of arbitrary (which is not a problem) and not completely universal (which is a problem). Not all people follow the same moral conventions; moral relativists find it normal, but all other people consider that they are right and whoever does not comply to the same conventions is wrong. Also, it is not clear whether it is possible to have a clearcut stance on the morality of reverse engineering of software in abstracto; it really depends on the circumstances. Even DMCA recognizes a moving set of "exceptions", which, as of 2012, makes jailbreak legal for smartphones but not for tablets (in the USA). Now find a moral system which can make such a distinction.

(And the Lord said: "Thou shall not jailbreak your tablet, unless it is small enough to be considered a phone". Whaaat ?)


How to find out the Chaff packets of WEP? I have a cap file in which I have lots of 802.11 packets encrypted with WEP key. The problem is lots of Chaff packets of WEP is included in that. I want to remove the Chaff packets and crack the key.

Can anybody advise me of a tool or any method to remove the Chaff packets?

You are mistaken chaff packets are sent by tools like aircrack-ng to force WEP to transmit more IV collisions and thus break the key faster.

IDS's like Snort has rule-sets to detect chaff packets.  But your looking for the opposite,  your looking for aircrack-ng.  You can use the ivstool to convert pcap files.  Although you will probably be more successful starting the attack from scratch because you can inject chaff packets which greatly speeds up the process.