Why would hackers attack a DNS server with a DoS?

From @Schroeder's comment, I made some additional searches and found out much more about this type of attack.
I Was the Target!
First of all, it looks like I am the target of the attack. Why? Because the DNS Amplification attack means that the source port of the DNS requests is set to 53. This makes it possible to force my DNS to send a non-requested response to another server (see graph below). Since I have less than 0.1% of such hits using that port, I don't really think that my DNS was used for the Amplification, but rather that it was the target.
How does the attack work?
The attacker sets up a computer with software sending UDP packets to some random DNS servers asking for a domain name. The packet looks normal except for the fact that the attacker puts the IP address of a different computer instead of his IP address as the source. The result is that the DNS sends the reply to the wrong computer:
      10.0.0.1         10.0.0.2         10.0.0.3
+------------+   +------------+   +------------+
|            |   |            |   |            |
| Attacker   +-->| Some DNS   +-->| Me         |
|            |   |            |   |            |
+------------+   +--+---------+   +------------+
                    |      ^
                    v      |
                 +---------+--+   This step is not required, it happens if
                 |            |   your DNS is setup to accept recursive
                 | Master DNS |   requests (which is not a good idea)
                 |            |
                 +------------+
                       10.0.0.4

In the example above, the attacker's request should have 10.0.0.1 as the UDP origination address. But instead, the attacker changes his IP address with 10.0.0.3. As a result, when the DNS at 10.0.0.2 receives the UDP packet and is ready to send a reply, it sends the data to 10.0.0.3.
The Master DNS of the domain is going to be used if the DNS at 10.0.0.2 doesn't know anything about the domain name being queried.
IMPORTANT NOTE: This is true of all UDP services. DNS is probably the worst in terms of amplification, but NTP, for example, can also be targeted.
Why not just verify the Source Address?
It's not possible from 10.0.0.2 because UDP has no recollection of the real source of the packet.
What is possible is for ISPs to verify that all the packets going out of a given computer has the IP address of said computer. Some do, I think, but most probably do not. It has a small speed impact... which of course with a DNS amplification is to laugh at (the DNS amplification has a way worse effect on the Internet than a small check of UDP packet origins).
The other thing may be that a user may still be able to do by connecting to the Internet in such a way that he bypasses the ISP verification. I do not know whether and/or how that would be possible, but I wouldn't be surprised that it could be done.
Actually, this is very problematic since the origin of such attacks is difficult to track and that's certainly why they are still occurring en masse.
Why is that a DDoS?
The packet to request a DNS record, which is what happens here, is very small, maybe 300 bytes. So the attacker only has to send one small UDP packet.
The response, however, may be multiple kilobytes of data. Specifically, there is a domain which is being used in these attacks:
peacecorps.gov

and that domain returns over 3Kb of data! (It defines many 'TXT' fields which are used in that amplification attack.) This is why it is called Amplification Attack.
As a result, the requests from the Attacker are transformed in about 10× bigger responses and the computer being attacked (10.0.0.3) gets swamped with a large number of rather large UDP packets.
Here I show the resulting entry in iptables. The first number represents the number of hits to my DNS computer after about 40 minutes (so over 10,000 hits a minute...):
pkts     bytes target     prot opt in     out     source               destination
61637  4376227 DROP       udp  --  eno1   *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 STRING match  "|0a7065616365636f72707303676f76|" ALGO name bm TO 65535

Notice also how the string was fully transformed to hexadecimal numbers.
Wouldn't an HTTP request be even worse?!
HTTP 0.9/1.0/1.1/2 use TCP which is a two way protocol and no amplification can be generated with TCP. i.e. TCP breaks if you did not first properly connect with the full handshake.
HTTP/3, though, introduce the QUIC protocol which is HTTP over UDP packets. So far I have not heard of major issues with QUIC, but the protocol has changed a lot within the last 6-7 years and it is not yet widely implemented. Here is an article about the fact that QUIC has built in features to prevent amplification attacks, so there is hope that it has been taken care of.
Some people are talking about using HTTP to query for domain names. (DoH — Domain over HTTP). Hopefully that would not be implemented using QUIC...
How can I Fix the Issue?
The amplification happens because your DNS is setup to accept requests of domain names that you do not control (i.e. domains you're not the owner of).
BIND has an option that allows it to do amplification, which is called recursion in DNS parlance. This feature is now off by default, but you may have turned it on (by mistake?).
Here is the wrong setting:
allow-recursion { any; };

What you want is to use the correct settings:
trusted-servers { 192.0.2.4; }  // list all your trusted servers

allow-recursion { trusted-servers; };

This will make your server automatically deny all such requests. So if you are not peacecorps.gov and you receive such a request, BIND will just stop right there and write a note in your DNS logs about the denied request.
Could I block the IP from those requests?
Yes. I started by doing that because my server was running well over 100% in CPU time. However, it may not be wise to do so. From the picture above, you can see that your DNS server sits between an attacker and a victim. If you block the source IP address, it's not the attacker's IP that you are blocking, it's the victim's. This means you're actually preventing the victim from seeing your domain names and do legitimate requests. That's probably not what you want!
At first, I generated a log message from my firewall. If I were to detect 5 or more requests to port 53 (UDP) from the same IP address in a short amount of time (5 sec.), then I would block the IP address. To do so, I used fail2ban.
First, I have a filter which detects the links with UDP and port 53 as the destination:
# Filter: /etc/fail2ban/filter.d/named-fast-requests.conf
[Definition]
failregex = \sIN=[a-z0-9]+ .* SRC=<HOST> .* PROTO=UDP .* DPT=53\s

Second, I have a jail which gives the other parameters:
# Jail: /etc/fail2ban/jail.d/named-fast-requests.conf
[named-fast-requests]
enabled  = true
filter   = named-fast-requests
action   = named-action[scheme=all,period=year,reason=named fast requests]
logpath  = /var/log/iptables/iptables.log
maxretry = 5
findtime = 5
bantime  = 1036800

The main point here is the maxretry and findtime which are set at 5 times in 5 seconds or less. When that happens, I block the <HOST>.
You will want to update the action with your own thing. I use my own iplock tool here. The command I use in the action:
actionban = /usr/sbin/iplock -s named -b <ip>

By default, fail2ban uses iptables directly. Search their actions to see how it's done.
Don't Be the Source of Amplification
You should block requests where the source UDP port is less than 1024. These are not valid. If you offer a server, port 53 will be a destination port, not source.
iptables -I INPUT 123 -i eth0 -p udp -m udp --sport 0:1023 -j DROP

WARNING: replace the position (123) with the correct number!
This rule says that for any incoming UDP packet on eth0, which has a source port between 0 and 1023, drop the packet. This prevents someone from using your DNS server for amplification. However, it does not protect your own server from amplification from others. Note that even with the proper allow-recursion setup, you would not prevent an amplification attack if the attacker properly selects one of your domain names for the attack.
Note: if you specify a different nameserver to resolve domain names on your computer, you may want to open those connections before you block everything from port 0 to 1023. This would be something like so:
iptables -I INPUT 123 -i eth0 -p udp -m udp --sport 53 -s 8.8.8.8 \
                    -d <your-static-ip> -j ACCEPT

This is the returned data from the nameserver 8.8.8.8, which you probably want to receive. It is not likely that your provider or some other official nameserver would be the direct source of a UDP attack. If you do not have a static IP address, you do not have to include the -d option.
However, it is probably a lot better to use the ESTABLISHED feature which is now available for UDP messages (it has been for a while now, but I remember a time when that was not available...):
iptables -I INPUT 123 -i eth0 -p udp -m state \
      --state ESTABLISHED,RELATED -m udp -d <your-static-ip> -j ACCEPT

This means you'll automatically accept answers from your domain nameserver provider since the firewall will know you sent a request and you want to accept replies. This rule has to appear before the DROP rule above.
Drop Unwanted Requests Early
Obviously, having BIND accept all those requests with peacecorps.gov is not something anyone wants. You can actually block those directly in your firewall. This works because UDP packets are not encrypted so the domain name is visible.
Here is a rule one can use to block those domain name requests:
sudo iptables -I INPUT 123 -i eno1 -p udp -m udp --dport 53 \
           -m string --hex-string "|0A|peacecorps|03|gov|" --algo bm -j DROP

Obviously, if your DNS has any domain or sub-domain including "peacecorps.gov" then it should not use that iptables rule. For most of us, though it should be rare.
The --hex-string option allows you to specify a string. The way it is defined in the UDP packet uses a form of P-string (size + data). Since "peacecorps" is 10 character long, we put 0x0A just before it. Again, the "gov" is three letters so we use 0x03. If we were to use the string "peacecorps.gov", it wouldn't work since the period would not match the 0x03 byte. The first size is optional, though (although you'd match anything that looks the same such as "bestpeacecorps").
Having such a rule will save your domain name service a ton of totally unwanted traffic.
Update: Although the attack stopped about two weeks after I posted my question, the "peacecorps.gov" issue still happens about 10 times a day.
Source: https://defragged.org/2020/05/20/tips-and-tricks-blocking-dns-requests-via-iptables/
Debugging You DNS
In order to see what query your DNS server receives and replies to, you can run the following commands in your console:
sudo rndc querylog

Now look at the logs, usually here:
less /var/log/named.log

Look at the bottom (hit G in less) and you should start seeing queries from remote IPs. The logs include the domain name being checked. It's very practical, especially if you missed entering some of your own domain names in your secondary or tertiary DNS.


Authorising use of apps from a public store with no back end service

It seems like you're trying to both make the data publicly available as well as restrict it to a limited set of people, which is a contradiction in terms.

If you're just after UI-level access control in the app, you could come up with any ridiculous scheme, but somebody could then extract data from the app with likely little more than an unzip utility, depending on the data and how it's stored.

If you can use a single password, you could use key derivation to decrypt any encrypted data stored inside the app, however you already discounted 'a single "unlock" code'. Unless you have a list of codes, but that doesn't address the issue you outlined.

The only option I can think of which satisfies all the listed requirements would be two-factor: a device ID whitelist in conjunction with key derivation and encryption. There's almost no way that would make it past Apple and Microsoft, though.

It just doesn't seem particularly feasible to me.


Saving an Id on a cookie. Security point of view?

Depending on the sensitivity of the data, I would suggesting the following items, arranged from least secure to most secure.

Do Nothing: Based on the contents of your question, I'd probably choose this option. A lookup filter isn't associated to a user (apparently) and probably doesn't expose anything particularly interesting. You could even expose the PK directly without too much worry, unless those filters could expose sensitive data. I know plenty of systems that use other means of protecting filters (and all other data), most notably using an actual session ID so the filter can only be seen by users authorized to see it.

Randomize PK: Make the PK a random number instead of auto-number. This keeps people from guessing PKs by counting back and forth. This makes it harder to find a valid filter. I would use this if the filter doesn't contain any sensitive data at all; make it non-trivial for an attacker to find a random filter. I would use a large random number space, such as 64-, 128-, or 256-bit numbers. Use this if you simply want to avoid people "sniffing" your database for interesting values.

Sign PK: Attach a nonce or MAC to each PK, so that the nonce and PK together are needed to retrieve the value. This prevents casual modification of the PK on the client. Validate that the MAC or nonce matches the expected value. This should deter casual hackers, especially if the data is particularly uninteresting and doesn't contain personal information.

Encrypt PK: Simply encrypt the cookie before sending it. This is the first recommendation in the list that suggests that the PK isn't directly sent to the client, and I would only use this method for personally identifying information, or if exposure of the filter would result in potential fraud. I would also combine this step with signing and randomization for a robust solution.


Good publicly available unpredictable random number sources?

The top article on the newspaper website really might be what you want as your entropy source. This means that you can use the hash of an article:

entropy source: top article of newspaper site
length of random number (e.g. SHA256->256Bit or AES-OFB as your stream cipher)
Secret: If you fear a third party attack you should keep secret which newspaper you use and choose the newspaper randomly with your partners

Cons:

One of your partners could write a script which always shows him the current position generated by the article
The top article might change before your partners have calculated the random number

Old answer

This isn't exactly what you asked for, but it might match your use-case.

Shamir's Secret Sharing

If you need the following conditions to be met:

You don't trust the persons
All persons need to be in a room/or communicating with each other on that day to get the secret

I would suggest using Shamir's Secret Sharing Scheme:
https://en.wikipedia.org/wiki/Shamir's_Secret_Sharing

With SSS you can split a secret in multiple pieces e.g. 5 pieces and hand it out to 4 persons (you keep one for yourself).
Only if all 5 pieces are together, you can reconstruct the secret.

You may also compute SSS to make it possible that e.g. only 3/5 pieces are needed to get the secret.


Authorizing a device to access user resources

The user would be able to take ownership of a device by adding the
  device ID to a list of devices they own.

What you need is some way to prove that the user is in physical possession of the device.

Going by media (e.g. images, video) it sounds like you have a display of some form, therefore it would be easiest to display some temporary PIN on the device which the user has to enter along with the device ID into your site when they try and add the device to their account.

You could either generate this PIN online and send it to the device, or generate it offline using a protocol such as TOTP.

  This ID would be passed along with the device's request for a playlist

Once you've undertaken the authentication process I would not recommend sending the ID. Instead generate a temporary set of credentials during the authentication process and send them to the device, that way you can revoke the credentials if required or if the user re-authenticates (say they give the device to someone else).

I'd also suggest embedding a unique private key for every device, that way you can easily encrypt the temporary credentials with the device's public key knowing that if anyone else obtains the keys, only the authentic device will be able to decrypt them.


Does the advent of GDPR result in improved protections for customers based exclusively in non-EU countries?

As far as the GDPR is concerned, the protections are only afforded to EU residents. As to what organisations are willing to do, it really depends on the organisation, and what concerns one might have with regards to security, implementation, and costs.


Is there any digital communication medium that provided close-to-perfect security?

I constantly read about the weaknesses of popular "secure" messaging applications such as Signal, Telegram, and WhatsApp.

These are all commercial products. They exist to generate income for the people who develop and maintain these services. An element of privacy/secrecy exists to facilitate this. But the financial requirement undermines the security objective. They operate as legitimate organizations within jurisdictions which are under pressure to support some levels of transparency. They must maintain their customers to operating within the boundaries they define (or lose them to competitors). They must make their products simple to use or lose business.
PGP encrypted email TOR comes close to your requirement.


Setting up a remote test environment correctly

If we treat this like a networking problem, one solution could be as follows;

    internet
       |
   adsl_router
       |
    -------------------------------
    |              |              |
firewall      dirty_host_a   dirty_host_b
    |
    |
    --------------------------------------
    |                  |                 |
clean_host_a      clean_host_b      clean_host_c

In order for your clean network to remain safe;

Forward whatever ports you like on the router nat to your dirty hosts.
Configure your firewall to disallow all inbound connections.
Configure your firewall to only allow administration from the LAN side.

The 'firewall' node could be an actual hardware firewall, like a netgear FVS338, or a linux machine with two network interfaces, coupled with a switch and running iptables. Whatever you have lying around.


How can I determine what encoding is being used?

It's a pair of Base64 strings with a two character prefix:

  2c9VP8uK6VUJlJR4Lmonwk3wy1UGEBgO4VqUYjUqar6kU=vK1+rOrlrThJWBCPGY5f2vzfJOFMCGd/S5+aM/X/6No=

Is equal to:

2c
9VP8uK6VUJlJR4Lmonwk3wy1UGEBgO4VqUYjUqar6kU=
vK1+rOrlrThJWBCPGY5f2vzfJOFMCGd/S5+aM/X/6No=

These encoded strings expand to the following data:

f5 53 fc b8 ae 95 50 99 49 47 82 e6 a2 7c 24 df
0c b5 50 61 01 80 ee 15 a9 46 23 52 a6 ab ea 45

bc ad 7e ac ea e5 ad 38 49 58 10 8f 19 8e 5f da
fc df 24 e1 4c 08 67 7f 4b 9f 9a 33 f5 ff e8 da

Both are 32 bytes, which might indicate encrypted data, but it is clearly data with some pattern to it, so I suspect it's not actually a block cipher.

My first though is that the "2c" prefix might be 0x2c for some kind of xor crypto, but I didn't get any results from that. I also tried modulo addition and subtraction, and doing the same between the two string pairs, again with no result.

Unfortunately there's no obvious way to break this without a significant number of plaintext-ciphertext pairs to give us more information.


Is it valid to defend an CSRF token against replay (e.g. with a timestamp)?

If the CSRF token can be intercepted then the session cookie can usually be intercepted as well, so CSRF wouldn't be the immediate concern in that scenario.

Some CSRF token implementations have timed expirations, but this is an extra precaution and not strictly necessary. This answer from tylerl suggests that an expiration is a good precaution in case the token is leaked somehow, but expiring the CSRF token when the session ends is ok.

In a CSRF attack the attacker has the ability to submit whatever form data they want from your session, but they can't modify your cookies. For a CSRF token to be effective it should be impossible for the attacker to know its value. If the attacker exploits a vulnerability to obtain CSRF tokens, then you want to make sure that the CSRF tokens are no longer valid once the vulnerability is fixed. As long as the token cookie is expired when the session expires everything is fine (provided you force sessions to expire if you ever suspect tokens have been leaked).

From the documentation you linked it looks to me like it's actually using the Encrypted Token Pattern, which sort of combines a Double Submit Cookie with a Synchronizer Token.


First Part: the Altera FPGAs have some models that allow you to store keys in volatile and non-volatile memory.

Altera explain that they use AES with 128 or 256 bits. The private key is stored in the FPGA and the external memory have the data encrypted with the public key. In the boot-up, the data in read from the external memory, decrypted with the private key inside the FPGA, and then processed to configure all the following reads (think like a config header).

Source: http://www.altera.com/devices/fpga/stratix-fpgas/about/security/stx-design-security.html

Second Part: they have anti-tamper measures to prevent someone from doing exactly what you're afraid off. See: http://www.altera.com/literature/wp/wp-01111-anti-tamper.pdf

In general, it's "easy" to open the chip and brute-force extract each component position inside it, doing a kind of reverse-code attack. FPGA are programable, so an already programed and a virgin FPGA will look the same at the phisical level attack. And you end up destroying the programming when you try to open the chip and extract something from it.

And, to protect you from extracting the key, there's no function like *read_private_key* . You can write and overwrite it, but you can't extract it.


Compiling a buffer overflow example in modern Linux?

While the accepted answer is correct in suggesting moving everything to a different function does not explain why.

As you can see in this question and answer main() functions often perform a stack alignment to ensure that the stack is setup properly.  The following instruction is performed:

83 e4 f0                and    esp, 0xfffffff0

This will align the stack to 8 bytes.  What this means is that a subtraction operation was performed on esp.  So in order to overflow the return address you need 128 bytes + <variable stack alignment> + <optional saved ebp> + <new_return_address>.

I compiled and ran your program (I had to add a -m32).

Starting program: /home/user/Private/misc/overflow_test
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBCCCCDDDDEEEEFFFFaaaabbbbcccc
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBCCCCDDDDEEEEFFFFaaaabbbbcccc

Program received signal SIGSEGV, Segmentation fault.
0x63636363 in ?? ()

I used 128 As, and then 4 of each new letter.

Decompiling the program we see the following lines:

;      .//overflow_test.c:4
;-- main:
;-- sym.main:
0x0804842d    55             push ebp
0x0804842e    89e5           mov ebp, esp
0x08048430    83e4f0         and esp, 0xfffffff0
0x08048433    81ec90000000   sub esp, 0x90

Here we see that 0x90 (144) is subtracted from the stack.  Which means that more than 128 bytes of space is allocated for local variables.  This SO answer gives some reasons why this might occur.  So if you account for the 128 bytes, the 16 extra bytes added for the local variables, and assume 8 bytes of stack alignment: Then you have EBP overwritten with 0x62626262 and the return address with 0x63636363.

Normal functions generally don't perform this step of aligning the stack.  Which is why when you moved it into a separate function everything worked as expected.  In real exploitation the chances that you're exploiting the parameters going into a main() is highly unlikely.  It's more realistic to be running in a different function's scope.


Is there is a way to share encrypted data and allow decrypt only and prevent re-encryption?

The answer to the literal question of whether one can prevent re-encryption would be no.

Presumably your goal is to prevent the customer from tampering with the data, i.e. altering it and misrepresenting it as the original. You also want to avoid actually keeping a decryptable copy of the data.

Since you need only to encrypt and the customer only to decrypt, the straightforward solution is public key cryptography and authentication. The customer would send you their public key, which you would use to encrypt the data. You would also sign the data with your private signing key, and share your public verification key to prove that you've signed it.

The customer can then decrypt the data with their private key, which you don't have. But while they can encrypt another piece of data, they can't sign it, as they don't have your private signing keys.

With this solution, you can actually delete both your plaintext and your ciphertext. Your public verification key will suffice to conclusively prove whether any given message has or hasn't been signed by you.


No, 2048 bit RSA key is weaker than 128 bit AES key. It may sound that the RSA key should be stronger, because it has more bits, but that is not the case. The reason for that is RSA key has to be product of two prime numbers while AES key can be completely random.


Can a salt be a random ASCII string or be derived from one?

it [only] generates strings with alphanumeric+punctuation.

This means that each character in the string can be 1 of 72 symbols (26 uppercase letters + 26 lowercase letters + 10 digits + 10 punctuations).

So, if you randomly generated a string 42 characters in length, where each character is one of these 72 symbols, this randomly generated string would have more entropy than 256 randomly generated bits:

72 ^ 42 = 1.01 e78
2 ^ 256 = 1.15 e77

But, as @Steffen Ulrich points out in the comments, salts do not need to have this much entropy.


Why does our Web Security team block web-fonts?

When your site uses external resources (often JS libraries or fonts via a CDN), your visitors may leak information to the third-party host as their browsers request the resources in the background. Privacy concerns about such leaks may be the reason for whitelisting a few trusted sites.
Most notably, the current URL can leak via the Referer header. Imagine a password reset page with a secret reset token in the URL that loads an external font – the token may be inadvertently revealed to that third-party via request header. (E.g., this vulnerability report refers to this type of problem.) Even with no secrets in the URL or other countermeasures like a Referrer-Policy, the content provider can still collect usage statistics for your site by recording page visits, user-agent strings, etc.
Another risk of using untrusted third-party fonts may be defacement (although not as severe as script injection via external JS). That is, if the provider was compromised, an attacker could modify their fonts in a way that changes the shape and appearance of the glyphs, effectively rewriting texts on your site. For this scenario, a solution can be hash verification (see Subresource Integrity).
But even if you don't expect an attack, remember you'll have to rely on the host's availability. So if they aren't a reputable CDN, you might consider self-hosting the files.


Alternatives to sending out passwords in plain text via e-mail?

It's probably fine, as long as the user is prompted to login and change it immediately (and assuming it expires within hours if the user does nothing, forcing another reset cycle). A similar question is "Temporary passwords e-mailed out as plain text".

You're probably thinking of the much worse scenario whereby a system stores your passwords in plaintext, and then emails you your password if you forget it. There are a few questions dealing with why that is a bad process (and what you can do about it).


Is it secure to use a hash of a login token as an anti-csrf token?

Sure.
This is actually one of my preferred approaches. It makes the strength of your CSRF protection wholly dependent on the strength of your session token security, but session takeover strictly dominates CSRF in impact anyhow. The hashing means you can leave your session token in an HttpOnly cookie and not expose the session to JavaScript in any way.
However, drop everything in your last paragraph. Hashing only part of the token is strictly weaker than hashing the entire token. If you're hashing only part of the token, then brute-forcing that part is much easier (because it's shorter than the full token), and once you have a match you can not only launch CSRF attacks, you can also easily brute-force the last quarter (after all, you already brute-forced a string 3x as long) and take over the session. Salting is also meaningless in this context; the only value of a salt is to add entropy to the terribly predictable / repeatable strings people use as passwords, and if your token is fully random than what you propose would simply be taking out some amount of entropy and then putting it right back in, to no net benefit at all. You can't compute a rainbow table over possible 128-bit random token; every CPU and GPU on the planet working together would still take might-as-well-be-forever, and you couldn't actually store the table (even if some magical supercomputer could generate it) even if you turned every atom of the Earth into storage.
If you want a little bit of "feel good" security, you can HMAC the session token rather than just doing a simple hash. This is pretty pointless, though. Assuming the session token is already not at risk of brute force (because, if it is, you have WAY bigger problems than CSRF), any secure hash (I recommend something from the SHA2 or SHA3 family) is fine.
By the way, this works fine even with session token types other than the "secure random string stored in a cookie" approach. That approach has some of the problems that things like double-submit cookies try to get away from (it requires storing state on the server for each session, load balancing interferes with or at least complicates it, etc.) but this idea also works with things like JWTs. The main downside of the approach is if the session token changes (say, because a JWT was refreshed), the CSRF token changes, so you need to be careful not to reject valid requests for that reason.
Also, for what it's worth, login CSRF protection is a decent idea, on at least some sites. Anywhere a user will upload data that only they are to be allowed to see, login CSRF is a risk. Imagine a tax-filing webapp where you put in your highly-sensitive data into what you think is your own session, but somebody sneakily login-CSRFed your session to a session they have the password to. Then, after you've completed your tax return, the attacker logs in to the same account (it's theirs, after all) and downloads your returns.


Apache: Can I revoke certain client certificate on certain subdomain only

A certificate is like a passport: it is either valid or not, i.e. you cannot selectively revoke it only in specific areas. But you can specify which certificates/passports are accepted as authentication in which areas. This can be done for example by not accepting any certificates issued by a specific CA (SSLCACertificateFile) but additionally restricting the subject using SSLRequire. For more information about this see the Apache SSL documentation, specifically the question: "How can I allow only clients who have certificates to access a particular URL, but allow all clients to access the rest of the server?" which shows how to apply such certificate restrictions to specific Locations only.


Which 12 month time frame is used for PCI merchant levels?

According to Mastercard US, to determine your merchant level, you look at the most recent 52-week period:

  Determine merchant level using Mastercard transaction volume from the most recent 52-week period

So if you're having a PCI audit, your merchant level is determined from that moment in time.

That being said, each card brand has their own definition and requirements for each level. Many of them are similar. You can see a good breakdown here, but you should check with each card brand for the most up-to-date info.

The best solution is to contact your merchant services provider (credit card processor), and they should be able to tell you what level you fall in for each card brand, and what your PCI validation requirements are.


What is a proper way of destroying data remotely?

It's simple: Encrypt all your systems

If you have hard disks, you can securely delete them by writing random data to every location. There might be some spare area that is used to replace defective sectors, but not that much and replaced sectors are defective anyways, so this should be secure enough for you. But for your scenario, this doesn't seem to be that adequate. If you have a 4TB disk, you'd need about 3,7 hours to overwrite it, assuming a constant 300MB/s rate. If you get the information the government is searching your home, do you think they'd wait a few hours to let you delete your data?

If you have SSDs, it's even worse. You cannot reliably delete them. SSDs have more storage than advertised to the system. They use this for overprovisioning to replace defective cells, as fast cache and for wear-leveling. There is no reliable way to delete all data. The SSD might look empty or filled with random data after you "cleaned" it, but someone reading the flash chips inside will still get parts of your data.

There are newer SSDs which can be securely deleted. They work by always encrypting all the data on the SSD. If you don't set a key, they just store the encryption key in plain. If you want to clear the data, this key is deleted, everything on the SSD turns into garbage.

So there is no solution but encryption for you. If you have new SSDs and trust the manufacturers, you can just wipe it with a command. Usually it is the secure erase command, but you have to make sure that your SSD really uses hardware encryption before, else it won't delete all data (or for some drives it doesn't actually delete any flash cells, just marks them empty in the controller).

The most secure way is to use your operating system encryption tools.

For your use case, you can configure the servers to automatically unlock the encrypted drives by storing the key in plain. You just need a way to securely delete this key fast. The most secure way would be to use a smartcard, but storing it on a HDD should also work. (NOT a SSD, unless you can securely erase the whole SSD)


Web sites executing local port scans: Is this coming from a library? Can it be blocked?

Blocking WS requests

While looking for a way to disable websockets, I found two native Firefox solutions that do not work any more, then stumbled upon https://github.com/jawz101/TrackersVsFirefox, which mentions that one can block websockets with the uBlock Origin rule:

*$websocket

You can restrict this further to localhost only, but you have to come up with a pattern that matches all possible localhost references (for example, all IP addresses between 127.0.0.0 and 127.255.255.255 refer to localhost as well). I won't try to come up with such a pattern as I am afraid that there may be some exotic aliases that I am not aware of.

Testing the result

In any case, once you have the filter set up, you can try it by visiting https://www.websocket.org/echo.html and clicking the Connect button. To test blocking localhost connections specifically, you can run a dummy server that listens for incoming connections and try to connect it.

For example, on linux you can run netcat -l 4444 to listen on port 4444 and connect to it by specifying wss://localhost:4444 as the location on the WS echo page.

Without the uBlock Origin rule, you will see some gibberish showing up in the netcat output and the WS echo page won't show any output (because netcat is not replying to it, just displaying the request).
With the rule enabled, you won't see any output in netcat but the WS echo page will display the error "DISCONNECTED, ERROR: undefined".


Is Content Security Policy only enforced during initial rendering?

Introduction

CSP should be enforced by the browser as long as you stay on the page, and not just while it is originally loaded or rendered. Everything else would make it quite toothless.

So the behaviour you are experiencing has nothing to do with when the script is loaded. Instead it is about what loads it. There are two issues.

Problem 1: strict-dynamic

I'll let Mozilla explain it:

  The strict-dynamic directive specifies that the trust explicitly given to a script present in the markup, by accompanying it with a nonce or a hash, shall be propagated to all the scripts loaded by that root script.

So, when you trust a script by giving it a nonce, it can in turn load other scripts. That means that if you have a DOM XSS vulnerability in a script with a nonce, the CSP will not save you. The solution is to remove 'strict-dynamic' (but that will off course be problematic if you rely on this feature).

Problem 2: unsafe-eval

To load the script, you use jQuery .html(). Somewhere deep in the jQuery source code (line 343 to be exact) it makes a call to the good old eval().

So if you run the code

$(".test").html("<scr" + "ipt>alert('XSS');</scr" + "ipt>");

jQuery will for some reason (don't ask me why, I have tried and failed to follow the source code) run the following:

eval("alert('XSS');");

This means that the CSP no longer applies - after all you are not creating a new script tag, you are evaluating a string.

Here the solution is to remove 'unsafe-eval' from the CSP, but that would break jQuery. The solution to that might be to upgrade to jQuery 3, that upon cursory inspection of the source seems to have fixed this.

Conclusion

This means that all code (using jQuery 2) on the form

x.html(unsafeFromURL);

can be vulnerable to XSS even if a CSP is set. I think this is unexpected to a lot of people (it was for me). But it serves as a reminder of another important point: You should not use CSP as your only line of defence against XSS.

Also do note that this is not an issue with how CSP works, but with how jQuery works.


Does ISP have control on all routers in their network?

In a typical modern setup, the cable modem and router are the same device.  It is both an endpoint on the consumer's network as well as the telecom's.  As such, they have base level access to administer the device, however what they are allowed to do with it is generally governed by your terms of service.  Even when the router is separate, if it is supported by the ISP, then they need access to it to be able to provide support.

This is why I never use the router provided by the ISP.  If you want to be secure, you should always use your own hardware that you own as an additional layer of defense.  I have my ISP's cable modem/router set in to bridge mode and it relays the connection to my personal router which treats it as a WAN device.  This gives me complete control of my interior network, but it also means I'm on my own whenever there are problems with my connection and the first thing they make me do is plug in to the cable modem directly to eliminate my network as a possible problem.


EMV credit card cloning: PIN code known by a malicious person

Could a credit card cloned (chip or magnetic band) if someone has it for a few seconds and knows the PIN code?

It depends.

The magnetic band can be easily cloned and you don't even need the PIN to clone it. You only need the PIN to use the card later. This cloning is not only possible but widely done by criminals.
The chip can not be cloned, at least not with the current methods available to criminals. Even if you know the PIN code. Thus it is inherently more safe than magnetic stripe and that's why the United States mandates the use of EMV by 10/2015 (or at least the liability on misuse shifts to the one accepting non-EMV payments).  In Europa EMV is already common for years and thus cloning of credit cards is less a problem.


Do I need strong user password for an encrypted VM?

What you are asking for is a risk assessment. A strong password protects you from something. You want to know if you need to be protected at all. We can't know all the possible threats against your system, but the risk model is easy to discuss.
Default credentials are like not having a password at all. So, if you start from that point, what impacts might there be if you didn't have a password?

someone with access to your machine could log in easily and gain access to whatever that user has access to - but if there is nothing of value, then your risk is minimal
if you set up remote access, then any remote user would have easier access to the VM - but if there is no remote access, then there is no risk

Strong security is always great, but security secures against a threat. If there is no threat, then there is no need for controls to mitigate that threat.


The answer lies in the question of what is the risks and threats?

A regular person, who doesn't have any specific threat to their safety/security likely is well served by having a fire and water-resistant personal safe (1-2 hour fire rating should cover most home fires).  This is where most people store a few items, like some emergency cash, passports, birth certificate, adoption papers, will, password sheet, etc.  A backup copy can be put in a SDB.

In this day, many people have 100-200 passwords for all of the sites we visit.  I think my list has about 300, since I use a long, complex, and random password, mother's maiden name, childhood friend, and those other reset questions - unique for every site.

I've had jobs where the ROOT passwords were all kept in a physical safe that was heavy TRTL 30x6, bolted down, in a locked room, locked floor, locked building.  That was policy.

In short, personally, I think that putting in the home's safe and SDB is a good idea for family COOP.

(Note.  If you are the type of person who would be the victim on a tv show, you might consider stronger measures, like a TRTL 24x6, armed guard, etc.)


How does a code signing vender charge for creating certificate chains?

When you get your certificate signed one of the "Features" that can be enabled or disabled is if your certificate can sign other certificates. Public CA's never sign certificates with that bit set. If it was set you could just sign a cert for mail.google.com and it would appear to be perfectly valid for everyone on the internet.

Your only two options is to have your root CA that your corporation runs be trusted by the party you are sending the PDF's to, or have the PDFs signed by a certificate that is assigned to your corporation and signed by a trusted 3rd party CA.


Why must new password must be different from old

The rationale is that they want you to change your password.   If you try to use the same password, you aren't changing your password.  You're re-entering your password.

So, perhaps the question then is why do they want you change your password?  They want you to change your password to limit the amount of time a compromised password is valid.  Whether this is a helpful mitigation or a case of the cure being worse than the disease is subject to much heated debate, but this is the reason none the less and a fairly standard policy today as it has been for many years.

The thinking is that if you lose your credentials to an attacker, the attacker can then authenticate into the system as you.  However, if you're required to change your password regularly, the attacker can only authenticate as you until your next password change, at which time he will no longer have your current credentials, and will once again be locked out of the system.   If the system were to let you continue to use the same password, the policy would obviously be useless as the same credentials would continue to work indefinitely.


Understanding Prevention, Detection, and Protection

Generally, it's a circle, not a line.

Prevention means it stops before happening. But to stop it, you need Protection. To protect from something, you usually need to have the means to Detect it. And in order to detect it, you must know what to look for, which knowledge may be considered Prevention.


Which hashing algorithm is ideal for use on the web?

Which algorithm is best depends on what you're using it for.  If you're trying to spot random data corruption, for example, a blindingly-fast algorithm like CRC-32 is ideal.  On the other hand, if you're trying to secure password hashes, you want an inherently slow algorithm like bcrypt.  For protecting data transfers against malicious tampering, you want a fast, cryptographically-secure algorithm such as SHA-256.  And finally, if you need to interoperate with someone else's software, you use whatever hash function they're expecting.


restoring logged out gmail session in running instance of chromium browser?

If session handling is properly implemented, then a logout causes the invalidation of the session at the server side. This means there is no way to get access back with some client-side tricks. It is likely that Google has done this correctly, i.e. the only way to get access is by properly logging in again. Given that you have not provided any ways to recover the account in case the password is lost the account a password reset is not possible either.

It might be possible that Google has implemented some way to recover the account if you are still using the same open browser. If this is the case check the official support page for this topic.


How to properly test that an OpenVPN connection is secured?

It sounds like what you have there is a VPN option known as "split tunnelling" set-up. In this configuration, traffic for your home network is directed over the VPN and all other traffic goes straight to its destination.

If your goal is to protect all your general traffic from sniffing attacks in the coffee shop or other location that you access it from, you'll need to route all your traffic over the VPN (which as you say, may slow things down).

Depending on the resources you have, another option would be to set up a remote desktop style machine in your home network, then use the VPN to get to that system and access the Internet using that machine.  This would have the effect of protecting your traffic from coffe shop based sniffing, whilst avoiding some of the slow-down from sending all web traffic over a VPN


Compression and Encryption against security issues

To exploit the compression, as in CRIME/BREACH, the attacker must perform a chosen-plaintext attack. In other terms, this means that the attacker must already have an exploit on your computer:

Either a RCE, in which case your VPN, encrypted or not, will not help you as you are already pwned;
or a CSRF or similar, which is fairly uncommon on classical desktop software.

Avoiding compressing data before encryption is a "defense in depth" protection, in the sense that a prior exploit must be used. Compression exploitation can only be used to improve on an attack, on some very specific scenarios.
Also, as mentioned in this answer by MechMK1, you will most likely not gain much by compressing at the VPN level.
In conclusion, do as you wish, the impact in performance and security will most likely be minimal either way. If, however in your particular situation you know that you will gain a lot by adding compression, or that a CSRF is likely and unavoidable, then you now know what to choose between compression and security.


Most secure way to deliver web app for offline access

Depends on the virtualisation platform, but pretty much all bets are off if an attacker gets access to the VM whilst it is running. Assuming they can reboot without needing to enter a password, they can gain single user access and grab whatever data they want at that point.

Similarly, you have no control over the system that is used to run the image - if it dumps memory to disk, the data will get dumped. A sufficiently motivated attacker could write a compatible virtualisation system which has this behaviour.

Ideally, you don't want to store full data locally at all. A better solution, although obviously costlier, might be to look at redundant connections to this system, since it's clearly critical to the practice. Alternatively, it might be possible to run a local server with a copy of the data - this has many of the same issues as a virtualised appliance, but can probably be monitored for tampering more easily, and stored in a physically protected location making physical access more difficult. This server would otherwise need to be treated in the same way as the main application server, receiving patches and being properly firewalled - it would effectively be a mirror of the main server. This should only be considered if there is sufficient technical expertise in running high risk systems though.


- Exploit aborted due to failure: not-found: Can't find base64 decode on target

Instead of giving a full answer to this, I will go through the steps I would take to figure out what might be going wrong here.
To debug the issue, you can take a look at the source code of the exploit.
The main function is exploit. It first uses metasploit functions to check if wordpress is running and if you can log in with the provided credentials. Let's assume for now that they work correctly. What we can see is that there is no permission check in the exploit (so it will continue to the next step even if you log in as say subscriber).
Then it performs the actual exploit (sending the request to crop an image in  crop_image and change_path). It doesn't validate if any of this works or not.
Then it performs the second stage of the exploit (LFI in include_theme). Here, it has some checks on whether the user can create posts.
Finally, it checks if if the shell was correctly placed in check_for_base64 and if successful creates a backdoor.
This is where the exploit fails for you. Specifically, we can see that the Can't find base64 decode on target error means that a request to TARGETURI returns a 200 (as expected), but that it doesn't contain the result of the injected command.
Taken all of this, we can see that the base64 error basically means "exploit not successful", but that it doesn't necessarily mean it's related to base64.
Possible problems include:

you are using a user that does not have the required permissions. Eg by default, using a user in the contributor role should result in the error you get (they can create posts, but not upload files).
you are running wordpress on windows, where the injected echo #{test_string} | base64 -d command will fail.
the used wordpress version is not vulnerable, or some custom configuration prevents exploitation
there is a (possibly deliberate) error in the exploit code.

You can narrow the problem down by eg:

testing the issue with a wordpress admin user
running wordpress on linux or adapting the injected command if running on windows.
debugging the exploit code & manually exploiting the issue:

add logging to the exploit to show you the full HTTP responses (&requests). Are they what you would expect? Or are there any errors that might show a problem?
manually create the required requests to exploit the issue (you can start with the requests sent by the exploit). Is this working? If so, how are the requests different from the requests the exploit sends? If not, how can you adapt the requests so that they do work?
If none of the above works, add logging to the relevant wordpress functions. Are they doing what they should be doing? Or are there any errors?


Having a consistent "don't reveal email addresses of members" policy

If this is supposed to be a secure system to that extent and since the email address is disclosed elsewhere, the developers could make the username a randomly generated number instead of the user's email address. This closes the information leakage gap.

For instance, for a generated numerical username:

Failed login: "Username incorrect"
Failed password: "Password incorrect"
Already registered: This error won't occur with a surrogate username key unless you have a company policy that people (e.g. in a family) can't use the same email address.
Password reset (by username): Email address isn't disclosed as message can say "Reset link has been sent to the email address associated with this username."
Password reset (by email address): "Reset link has been sent to this email address for all accounts that are associated with this email address."

Besides, the either/or fallacy of login field validation adds only a few bits of extra entropy to the overall brute force security whilst decreasing usability. Just increase the minimum password length requirements to gain the same effect sensibly. One assumes that exponential delay exists on the password attempts in any case.


Exploit HTTP PUT Method in Microsoft IIS 5.0

HTTP status status message 403 means the client doesn't have the access rights, that's why you are getting this response.
HTTP PUT methods requires authorization to give access to the server content. Since PUT is dangerous method, if proper security mechanism is not used to restrict the users.
So if you want to put some content on the server so you must use Authorization, for authorization you need to know the credentials, that you might not know because you are not a administrator. The HTTP header with authorization is,

PUT /website/file.txt HTTP/1.1

Authorization  = "Authorization" ":" credentials

Host: www.targetiis.com

Content-Length: 29


Use additional "password" in Referer to hide private site?

I personally think you're doing alright. As long as your underlying login method is secure, add as many obscurity layers as you want.

I have worked with some clients that wanted the exact thing you're trying to achieve. I've always used one of these two methods:

Cross-Site login form: A local .html file that has a login form submitting to the example.com/private/login.php. The login form had a hidden field with some randomly generated token.

Of course anyone could've distributed the same .html file, but that wasn't important, because our main security method was the login process itself; the username and the password.

Any request to example.com/private was rejected and a 404 was shown to the visitor. But when a POST request with the correct credentials was received, a session is started the website worked normally.

The upside of this method is that it grants you plausible deniability. If someone gets hold of the .html file they can try to login and they'd still get 404. There's no proof that this file is related to an actual working website.

Extra password in the URL: Pretty much the same as your method, but the extra authentication token was in the URL. Any request to example.com/private was rejected and a 404 is shown to the visitor. But when a proper example.com/private/login.php?token=Zz37vQQCnLTpe527xeFfFEG9 is received the login form is viewed.

Most clients liked this method as they were able to bookmark that URL. However, the downside of this method is that it does NOT grant you plausible deniability. Anyone with the URL can prove that there's a working login form on that website.

To be honest, I like your method and I think I might use it someday.

IMPORTANT: All of the above applies only after you make sure that your login method is secure.


Is storing a JWT secret as docker env variable acceptable?

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

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


Would chip-and-PIN have prevented the Target breach?

That depends on what you mean by "prevented".

EMV is only used for transactions where both the card and the cardholder are present; it wasn't designed to improve the security of card not present (CNP) transactions. This has some implications on what an attacker can do with stolen credit card data.

Physical transactions

If all merchants and cards were using EMV exclusively today, then the stolen magstripe data would be worthless for physical transactions – there would simply be no opportunity to use a cloned magstripe.

EMV transactions are active in the sense that there is a "conversation" between the card's chip and the issuing bank, mediated by the terminal. Basically, the bank asks the card to sign the transaction details using a cryptographic key that never leaves the card. Making a copy of an EMV card is therefore assumed to be impossible. (Magstripe cards are passive in that anybody who knows the contents of the magnetic stripe is able to authorize transactions; it is trivial to create a duplicate of such a card.)

Unfortunately, EMV is widespread, but still not ubiquitous; as long as there is a single remaining magstripe-only ATM or merchant on the planet, cards will continue to be equipped with a magnetic stripe, and skimming will continue to be a problem.

Remote (CNP) transactions

The problem is that the credit card details on the magnetic stripe can also be used for CNP transactions in some cases. CNP transactions usually require the card number, cardholder name and expiry date; all those values are stored on the magnetic stripe as well. To address this problem, card networks have designed the CVC2/CVV2; a number that is only printed on the card, but not included in the magnetic stripe data.

However, not all merchants use that value – for example, Amazon (at least in my country) doesn't require it. Thus someone performing a card skimming attack would be able to use the captured card details to make fradulent purchases at any online or phone/mail order merchant that doesn't require the CVC2/CVV2.


How to detect if file is being modified while my program reads it?

Since you are already using a signature verification method on the file itself, just modify that system a little bit:

Sign individual chunks of the file, and store the signatures inline.  If your signature takes 32 bytes, and you use a 4,096 byte chunk size, you can have 4,064 bytes data + 32 bytes signature in each chunk.
Sign the list of signatures, and store that signature also.
To verify the entire file, verify all chunk signatures and the final signature.  If you then keep the signatures in RAM while you are reading your file, you can be assured that it has not changed since the time you verified it.  Any change will result in an invalid or valid but mismatching signature.

Alternatively, if you cannot store the signatures inline, use a file just for that purpose.  Either way, you can basically prove that the file hasn't modified since you verified its contents.


Is there any smarter way to crack wpa-2 handshake?

WPA2 is indeed a slow hash.  But in the real world, performance is better than you might suspect:

An attacker can leverage multiple GPUs. With hashcat, six GTX 1080s can exhaust ?d?d?d?d?d?d?d?d?d in about eight minutes (and equivalent capacity  - for basic attacks - can be rented on AWS for relatively little money).
Simple brute force and simple dictionaries are just the beginning - other techniques include using rules, masks, combinator attacks, hybrid attacks, and using larger, higher-quality dictionaries made from actual leaked passwords. These attacks are faster than brute force (often dramatically so).
Since most passwords are human-selected and not random, analyzing the context and psychology of the target is often useful - and may be necessary to make any real progress against a non-poor (but non-random) password stored with a slow hash like WPA2.

But if that WPA2 password is truly random, and draws from all four character sets .. six 1080s would take 92 years to fully exhaust the keyspace.


Neither method is foolproof at blocking automated requests, but both have been effective for me in the past. Let me explain:

Automating a response to an email is fairly easy, and thus cannot be taken as assurance that the client is not a bot. Similarly, captcha is easily broken (not even using humans). For instance, the hacker group DC949 recently released stiltwalker, which can reliably bypass recaptcha and many other popular captcha services. As is often the rule in security, if someone is determined enough, they can break in.

However, email verification and recaptcha have had great impact for me in the past when fighting spam accounts/reviews. While it can be bypassed, many spammers don't know how and/or don't bother. So, while it is not "secure", it is still effective.

P.S. Another technique I have heard about is using javascript to gauge the amount of time the user spent on the webpage before submitting. Most bots will submit things almost instantly (if they even run the javascript at all), so checking that a second or 2 has elapsed since the page rendered can block a lot of spam as well.


One of the motivations for channel binding is to prevent an attacker who is able to capture users' authentication credentials (e.g. OAuth tokens, session identifiers, etc) from reusing those credentials in another TLS session.  By tying these credentials to a unique fingerprint of the TLS session in which they are used (by way of channel binding), they cannot be reused in another TLS session initiated by the attacker.

For more information:

See "FIDO TechNotes: Channel Binding and FIDO"
for information on how channel binding is used with FIDO
authentication for this purpose.
See "Secure modular password authentication for the web using channel bindings" for information on a PAKE-over-HTTPS implementation that uses channel binding to secure the session.


Are there any filesystems that have secure deletion as a feature?

NTFS sort of does if you include The Encrypting File System as part of it.

  The Encrypting File System (EFS) on Microsoft Windows is a feature introduced in version 3.0 of NTFS

Secure deletion is supported by cipher.exe:

  You can use the Windows Cipher utility (with the /W option) to wipe free space including that which still contains deleted plaintext files

And on the Microsoft page:

  Cipher.exe is a command-line tool... that provides the ability to permanently overwrite (or "wipe") all of the deleted data on a hard disk. This feature improves security by ensuring that even an attacker who gained complete physical control of a Windows 2000 computer would be unable to recover previously-deleted data.

This would still require a two step operation in order to remove files securely:

del c:\foo\bar.txt
cipher /w:c:\foo

Therefore this would not work with applications that deleted files as part of their operation unless cipher was manually ran later. You could, however, schedule cipher /w:c:\ to run on a regular basis in order to wipe deleted files from the disk.


Has the wedge security flaw been fixed for credit cards?

I think they are slightly different attacks, in the lightbluetouchpaper blog the wedge sends a fake MAC back to the terminal, in the other attack the card sends the MAC. This is why the second attack can work online, it uses a genuine MAC that the bank will accept.

The blog is run by the Cambridge researchers, Ross Anderson, Steven Murdoch et al. The original paper which presented the second attack that works online "Chip and PIN is Broken" can be found here:
http://www.cl.cam.ac.uk/research/security/banking/nopin/oakland10chipbroken.pdf

In the paper the researchers suggest some possible fixes and why they would/would not work in the 'VI Solutions and Non-Solutions section'. The main point they make is that to implement an effective solution the EMV standard would have to be changed which would be an incredibly costly thing to do due to large number of merchants, cards and banks using the current implementation and as far as I'm aware there has been no fix rolled out for the standard.

It would be possible for individual banks to fix this by getting the terminal to send the CVMR (Cardholder Verification Method Result) to the bank so the bank could check what the card thought had happened in the transaction and compare it to what the terminal thought had happened, they could then see that the terminal thought a PIN was used and the card thought a signature was used so know something was wrong. As the paper says

  Out of many, we have only seen one EMV card which requests this ﬁeld,
  and it is not clear that the issuer actually validates the CVMR
  against the IAD. Whether this ﬁx works for a given bank will depend on
  its systems; we have not been able to test it, and given that it
  involves reissuing the card base it would take years to roll out.

So the only way to know if fixes have been made is to test newly issued cards, as far as I'm aware there hadn't been anything published on this.


The answer by @discreet gives good links, but I want to add my understanding.

Without knowing which vendor you bought your PKI from, it's hard to know exactly what the PIN is doing inside, because unlike EMV bank cards, enterprise PKI systems have no industry standards and each PKI vendor will do things differently. So here's my response to your two points based on how these things usually work:

  There is a certificate embedded in this card which contains my private key.

Correct. Usually your PKI smart card will have a mini-computer in in that powers up when you connect it to the card reader. For this reason, your smart card is more than a storage device (like an SD card), rather it is its own computer. Your PC can send requests to the card like give me your public key, sign this data, decrypt this data, etc, the card will do the processing on-board and send the data back. The card can even refuse to do certain requests, such as give me your private key.

One of the operations that all smart cards support is generate a new keypair. The card will generate a new private key (which will never leave your card, if you specify that option), then the corresponding public key will be passes back to the PC to be made into a certificate by a CA, then handed back to the card as a certificate for storage.

  My 6 digit PIN is the key to encrypt my private key

Mostly Correct. This is the part that varies by manufacturer. Even though the private key never leaves the card, you still don't want to store it in plaintext because a careful attacker can remove the flash memory chip and extract the data. My guess in that your 6 digit PIN is stretched into a symmetric encryption key which is used to encrypt / decrypt your private key while it is in storage on the card. This means that until you give it your PIN, even the card can't access your private key.

The PIN is never stored anywhere, except for in the card's RAM while it is plugged in. When the card powers up, it will ask for your PIN, if that allows it to properly decrypt your private key then the card can go ahead and do crypto things, if the PIN you gave does not produce the private key which matches the certificate (ie it produces garbage), then the card will throw an Incorrect PIN Error.

--

A quick Google shows that many smart card vendors post on their website a detailed whitepaper on how their smart cards work. I would encourage you to figure out which vendor manufactures your smart cards, and continue your reading on their site.


"unsupported certificate purpose" for nginx client auth

Indeed, as suggested, it is necessary to have a close look not only at the client certificate, but also at the other certs in the chain. In my case, it turned out, the the root cert was generated with a config entry like
extendedKeyUsage = serverAuth

This will result in the root CA having the purpose flags
SSL client : No
SSL client CA : No

(I think the second of which is the crucial one). So, when traversing the cert chain "upwards", nginx (or any other correctly working software) will find out, that the root CA itself was never "allowed" to sign client certs. At this time, it's not relevant, what the intermediate CA is "allowed" to do (in my case, both the flags were Yes indeed).
The solution is to completely omit the extendedKeyUsage line when creating your root CA, which will result a wide-purpose certificate. (This is even the suggested way! 1,2) If necessary, you could narrow down the purposes using extendedKeyUsage when creating the intermediate CA.
Anyway, in my case, it would also have been sufficient to use extendedKeyUsage = serverAuth,clientAuth for the root CA. But as stated, this is not the advised way to go.


The safest way to circumventing Iran's Internet censorship

The Onion Router (tor) was designed specifically for this purpose.

This is a program that you run locally that provides a socks proxy,  which allows you to access an unfiltered, and anonymous connection to the open internet.  It is very difficult for governments to prevent you from accessing tor.


Legal purposes and advantages for Dark Web

The dark web is not a well-defined thing. Often already the torrent protocol is listed there.

Dark web is not for the evil things, and not for the illegal things, it is for the anonymous things. These are not always the same.

For example, posting content to the internet going against the governing ideology of the political system, is often illegal, but it is often not evil.

Or - using the example of the torrent - although it is used mostly to violate the IP laws, the illegal is this violation and not the protocol. Thus, for example, you are free to download free software with torrent (example).

It can be used also as a legal defense against illegal activities. Eavesdropping others private communication is typically illegal, but it is being done quite often. For example, reading this post, your browser opened also TCP connections into the following domains:

scorecardresearch.com
gravatar.com
multiple google domains (googletagservices.com, google-analytics.com)
quantcount.com
quantserve.com
possibly others what I could say only after deactivating my adblocker

Sometimes we all have enough reason to defend against this, to overwhelm the system configuration cost of the tor.

Identity protection is required not only against some "big companies", but it may be needed also against closer attackers. For example, to circumvent some nasty rules/settings/actions of our network provider.

Because from the point, that they are trying to steal1 user data, the darkweb user becomes the defender and the Big, Secure Company becomes the attacker.

1 A lawyer could say, that by clicking some popup on the first visit of some websites you allowed the content provider to steal your data. However, no one can read all the related "general terms and services" and interpret it from the legal system of the home country of the content provider. From this moment, doing this is a misuse of the position of the user, and an "agreement" based on compulsion is invalid.


Am I safe after importing Bitdefender's fake certificate?

Bitdefender web protection is validating the certificate before reaches your browser but the certificate root itself is modified/removed/replaced by agent before sent to browser.

Now a days the browser(firefox/chrome) itself is also validating the certificate, as the certificate root/chain is modified/replaced by the one from bitdefender agent, this re-validation process by browser fail : The certificate root in chain is not signed by known agency. (Bitdefender is not the agency which issues the certificate.)

If you trust the Agent like bitdefender/avast then you can import their face/temp certificate into your browser so that browser can trust the certificate signed by them.

This avoids the browser throwing the certificate error next time.


With TPM how are the initial PCR values seeded with 'good' values?

What you asked is the PCR values from so-called "golden measurement" or "baseline measurement", which can be conducted by the platform manufacturer such as DELL or platform administrator like your department IT. Those values are saved and used for verification by TPM. This is part of the "provisioning process".

Please check the book "TCG TPM v2.0 Provisioning Guidance" for section 10 and section 11.

When you update your system, the PCR values will change. That means your updating package should be able to automatically bring your PCR the new values in the package or the platform administrator has to carry out another golden measurement. In some cases, you may have to temporarily disable some features that depend on the PCR values before updating your system - otherwise, the system may stop working when seeing a different measurement.

For example, here is a list of BIOS revision history who has the PCR0 values given for every update, because PCR0 has the measurement value of BIOS.


Per the Wiki (emphasis mine):

  To create and transmit an onion, the following steps are taken:

  The originator picks nodes from a list provided by a special node called the directory node (traffic between the originator and the
  directory node may also be encrypted or otherwise anonymised or
  decentralised); the chosen nodes are ordered to provide a path through
  which the message may be transmitted; this ordering of the nodes is
  called a chain or a circuit. No node within the circuit, except for
  the exit node, can infer where in the chain it is located, and no node
  can tell whether the node before it is the originator or how many
  nodes are in the circuit.
  Using asymmetric key cryptography, the originator uses the public key (obtained from the directory) of the first node in the circuit,
  known as the entry node, to send it an encrypted message, called a
  create cell,

The rest of the article appears to omit how the public keys for relay nodes are obtained. However, since the selection of all nodes for a given chain is done from the directory node, I'm pretty sure all public keys are taken from the directory node. Therefore the directory node (and your connection to it) must be trusted if you are to trust the public keys of any of the nodes in your Tor chain.


How can I tell if I have the citadel virus without downloading an antivirus?

If you dont like to install an antivirus you can always use a rescue disk to scan your system.

They require no installation
They are usually free
They can hunt and remove the virus even when it's attached to a system file, something you cant usually do on a live system

Kaspersky Rescue Disk
http://support.kaspersky.co.uk/viruses/rescuedisk/

Avira Rescue System
http://www.avira.com/en/download/product/avira-rescue-system

Bitdefender Rescue CD
http://download.bitdefender.com/rescue_cd/

AVG Rescue CD
http://www.avg.com/us-en/avg-rescue-cd-download

Dr. Web LiveDisk
http://www.freedrweb.com/livedisk/?lng=en


Preventing XSS and SQL-injection attacks

As Arminius mentioned, a web application firewall (WAF) (https://en.wikipedia.org/wiki/Web_application_firewall) is a service which sits in between the client and your server which attempts to filter out bad traffic.  The issue with WAFs is that they are prone to false negatives (permitting malicious traffic).  For example, a WAF may be able to block a SQL injection attempt for ' OR 1=1; --' but allow ' OR 3<4; --'

I recommend people view them as bandaids, rather than a final solution.  Use them to provide an extra layer of defense while you work on patching the application itself.


How to secure an email subscription endpoint?

Does the Lambda endpoint have to be public?
If your web application is running on AWS, perhaps you can route the traffic internally in a VPC and make the Lambda private / only accessible from the webserver.

Furthermore make sure that the you filter possible spam as much as possible at the webpage. Use honeypot field(s) and CAPTCHA if possible. This will be your 'first line of defense'.


CSRF with OAuth or Bearer Authorization headers

As long as you are not using using a built-in browser authentication scheme like Basic (or client certificates, digest, NTLM in some browsers, etc) or cookie authentication for your API you do not need to worry about CSRF.


All programs can open ports. Running a firewall would prevent inbound traffic.

Running netstat -rn on Linux or OS X will show you all open ports. The ones listening on 127.0.0.1 are not open except to other local programs.


Minimize risk with Windows 2003 end of life

Realistically, the risk reduction options available will most likely not be cost effective. Especially considering those servers may be upgraded within the year.

Two options that come to mind are network segmentation and application white listing.

Symantec has a nice guide entitled, "Windows Server 2003 Migration: A Guide to Effectively Mitigate Risks".

!! SPOILER ALERT !!

They are going to recommend you take advantage of their product offerings to do so. ;)


Choosing a vulnerability to present will be dependent on what you want to be able to show as proof of the exploit. Do you want to pop a shell? Do you want to escape the sandbox? Run arbitrary code? What browser? What security do you want to test? It will also depend on your skill level and resources. So, it will be difficult for someone else to recommend any particular exploit.

You can look through the exploit-db.com to find PoCs of exploits that match your needs, or you can use the security presenter's best friend: Metasploit.

Use their online search tool: https://www.rapid7.com/db/search?utf8=%E2%9C%93&q=browser&t=m

Metasploit shows you their pre-made exploits, and you can have a number of pre-made effects (shell, run code, etc.). Not every possible exploit has a nice, presentable effect, but you have the ability to narrow your search nicely.


Does digested passwords send over a non encrypted channel offers additional security over plain text passwords?

Brute-forcing a single round of SHA1 is extremely fast. An individual high-end graphics card can compute billions of such hashes per second; by parallelizing it even further (using multiple cards, cloud services, or custom hardware) the rate can be driven to even greater orders of magnitude. While the nonce and timestamp prevent building a rainbow table, modern hash cracking is so fast that it scarcely matters anymore. The slowest part, by far, of creating a rainbow table or any other persistent hash lookup table is simply the time to write it to storage.

Digest auth can hide your password, but doesn't protect the data itself. Without encryption, an attacker can read all data passing in both directions. Without integrity checks, an attacker can tamper with the messages, even to the extent of completely replacing your requests or the server's responses. Additionally, if you haven't authenticated the server in some way (typically, this is done during a TLS handshake by the server providing a trusted certificate and proving it has the corresponding private key, but it could also be done using a password of some sort) then you don't even know if you're communicating with the server you think you are; an attacker might have spoofed your DNS or ARP, or compromised some node along your path, etc.

This scheme means the server must store the passwords in plain text or under reversible encryption, because it cannot apply further hashing to the password part alone (in order to match the hashing used before storing in the database). Client-side hashing like this can protect the password itself from a network attacker, but only be exposing every password in the system if the server / its auth database gets compromised.

If sites A and B both use this protocol, and the attacker wants to get into your account on A but A uses a secure channel (such as HTTPS) and B does not, then the attacker can attempt the following:

Obtain a man-in-the-middle position between you and B.
Attempt to access A (via its secure channel), receiving an auth challenge with a nonce in it.
Spoofing your communication with B to present the nonce that the attacker got from A.
Your client hashes your password using this nonce (which is actually for A, not B), and the attacker intercepts your UsernameToken.
Attacker replays your token to A, along with the request that the attacker wants to make in your name. Because the token was constructed using the nonce for A, A accepts it. Because the token contains no information about what service its intended for use with, neither the server nor the victim realize that the they crafted a token for a different site (although the victim might think something's up when B rejects the token... but the attacker can suppress any awkward response messages.)

This type of attack - passing the hash intended for one server to a different one, and thus accessing the other server using the victim's account - is a very common way to compromise any system that relies on client-side hashing (even with a server-supplied salt/nonce) when the same password is used in multiple places.


Can I realistically rely on a proprietary password manager?

In the end this always comes to trust: you must trust that the program is doing what it's saying, and you should pick a company you are willing to trust. Keep in mind that a password manager is not by all means the only software you trust nor the only software that could steal or leak your passwords. Or you could accidentally paste the password to a fake web site. Or something could be monitoring your keyboard or clipboard. This level of paranoia would require ruling all these possibilities out, too.

Just like Troy Hunt reasons in Password managers don't have to be perfect, they just have to be better than not having one. I also like how this article points out that a paper copy kept in a safe place has less possible attackers than anything saved on a computer.

  Password managers are a good thing. Even when issues like the LastPass
  one above are found, they're still far superior to our frail human
  brains when it comes to your overall security posture. Until such time
  as that changes and either they're worse due to a flaw that actually
  causes some serious damage or we create something better again, this
  is where the game is at. Less sensationalism, more pragmatism.

How to pick a password manager you could trust?

The most paranoid options:

Create one by yourself. It's a hard thing to code a password manager from scratch, but it could be combined from other tools. This has a limit that you must trust them all. To fulfill all the general functionality of a commercial password manager you need:

A tool that creates (truly) random passwords.
A tool for encryption: you could store them as files in a VeraCrypt disk.
A tool that can be automated to securely sync the encrypted version between your devices, e.g. Rsync. The less you trust the encryption the more you need to secure the communication: you could e.g. do this only on your LAN.

Only use an offline password manager that doesn't communicate over the network at all. Update it manually and block its access to the Internet. If you need to have the passwords synced across multiple devices, see where the database is located and sync it with an external tool you can trust.

If you can loosen your tin foil hat a little, take a look at the described functionality of the password manager you are planning to buy. If it stores the passwords unencrypted on a cloud (or does the unencyption on server-side), forget it. If it doesn't encrypt the password (like the ones built in the browser), forget it.

If the password manager encrypts the password locally and synchronizes the encrypted version, that's a lot more secure architecture. This should be your minimum requirement. To a certain extent you can check whether the program seems to work at described. The rest comes back to trust.

Many antivirus vendors have expanded to password managers. If you already trust a company that much to give them ultimate power over your operating system, it is not very practical to avoid trusting them in this matter, is it? Aviva Zacks has compared Kaspersky, Bitdefender and Norton. I'd add F-Secure, as their TOTAL solution now comes with a license for a password manager, KEY.

What if someone finds a vulnerability in my password manager?

You can estimate your risks by reading about the vulnerability and how it can affect you. If you don't have the expertise to estimate your risks or if you find yourself at risk, wait for them to fix it, update your password manager and then change your possibly compromised passwords. Or switch to another password manager.


The answer depends on what assets you're trying to protect and your threat model.

If you're worried about the user attacking your web page content and the AJAX code in it and discovering something in the page that you didn't want them to know, then it is true that AJAX is insecure, since the user has physical access to the environment that the web page runs in.  An example of this is the gaming example that Thomas describes in one of the other answers.  If the page implements a game interface and includes information on where other players are, then the user can figure all that out and  "see thru walls" and could cheat.

On the other hand if you're worried about the user attacking your server, and you assume the user can modify anything in the web page and associated code, and you take proper precautions to protect your server against anything the user can do under those circumstances, then as others have noted AJAX is just as secure as any other good programming technique, and it mostly depends on your server side code, as always.
Update: But doing so can be tricky, and as @iivel points out, an OWASP page explains the various things you'll want to watch out for: Testing for AJAX Vulnerabilities (OWASP-AJ-001)

This all applies to other client-side techniques like Flash or Java applets or Silverlight, etc.  Heck, it also applies to Word or PDF - if you put content in there (like meta information on who the author or owner of the software is, or content that is "erased" by overlaying it with digital white-out) that you don't think people will see or you didn't even remember that it gets included automatically, then you'll be sadly disappointed when a savvy user looks at the bits.

It's really important to think carefully about your threat model and whether your tools address it.


Security risks of Read-only MySQL Database access behind firewall

As per your Question, No one can give Yes, No Answer. Because Risk is not a hacking. Security is not a providing technical security with firewall or any security devices.

  Risk is a situation involving exposure to danger.

You have to understand what is a requirement of users. And according to that you need to provide only appropriate access to users. Because if you have classified data, which has permission level.

If you give access to users, you need to make sure that they can access only data which related to their permission level. Otherwise users will gain all secret information from your database without having any technical attack.

That will be a big risk ever you face.


Is there a portable memory device with an offline erase technique? (such as an erase switch?)

Tamper-resistant devices, like the PIN pads you see at cash registers, often store their keys in a CMOS chip that requires a battery to keep the storage refreshed. If the circuit detects tampering (someone removes a screw, or drills the PCB, or breaks a tripwire cutting into the epoxy, or trips whatever other sensors the manufacturer included), the battery power is cut and the memory is drained. The chips used for this are often in a BGA package, making it that much more difficult to access the interior pins.  Adding a push-button kill switch into the tamper detection circuit would not be a problem, if one was needed.

The Mooltipass Mini offers securely encrypted password storage in a pocket-sized tamper resistant package. Three wrong guesses at the PIN and the master key is wiped.  But it doesn't have a kill switch, and it acts as a keyboard, not a mass storage device.

I have never seen a tamper-resistant mass storage device of the kind you seek. That doesn't mean they don't exist; just that if they do, they have very poor marketing.


Can I use John the Ripper to brute-force a password-protected flash drive?

No. John the Ripper is designed to look at a hash and compare it to common password hashes, salted or unsalted. It doesn't directly input values into a box, and it uses GPU acceleration when available to reduce processing time. Unless you can find the hash for the password on the flash drive, this tool is completely worthless for this purpose.


linux kernel security module smack transmutation example

Transmute feature in Smack solves a problem of two applications running with different Smack rules sharing data in a single directory. First of all, both applications need write ('w') and execute ('x') access to label of the directory in order to be able to write into it. But the files that would be created will have Smack label of the process that created them. If one of two apps would like to access files in that directory that were created by the other app, it would need access to the other app's label.

To solve that, Smack provides transmute feature. Two parts are needed:

The applications that write to the directory must have 't' access to the directory label.
The directory needs to have transmute attribute. If it is an ordinary directory, you set the attribute with security.SMACK64TRANSMUTE xattr set to "TRUE", or simpler with "chsmack -t " command. If the directory is a mount point (like /run in your Tizen example), it can be mounted with smackfstransmute="some_label" mount option to give it desired Smack label and enable transmute.

This will enable transmute, affecting Smack labels of newly created files in that directory. Every file created there by one of the apps will now get Smack label of the directory instead of Smack label of the process that created it. And every sub-directory created in that directory will also get transmute attribute.

Let me show an example:

# mkdir /tmp/test
# chsmack -a dir_label /tmp/test
# chsmack /tmp/test
/tmp/test access="dir_label"
# echo "process_label dir_label wx" | smackload
# echo process_label >/proc/self/attr/current

With directory /tmp/test having label "dir_label" and current shell running with label "process_label", let's see how new files and directories will be labeled:

# touch /tmp/test/file1
# mkdir /tmp/test/dir1
# chsmack /tmp/test/file1 /tmp/test/dir1
/tmp/test/file1 access="process_label"
/tmp/test/dir1 access="process_label"

Let's enable transmute:

# chsmack -t /tmp/test
# chsmack /tmp/test
/tmp/test/ access="dir_label" transmute="TRUE"
# echo "process_label dir_label wxt" | smackload

And transmute in action:

# touch /tmp/test/file2
# mkdir /tmp/test/dir2
# chsmack  /tmp/test/file2 /tmp/test/dir2
/tmp/test/file2 access="dir_label"
/tmp/test/dir2 access="dir_label" transmute="TRUE"


What is the point of restricting a google API key by HTTP referer?

All security measures are trade offs.  Is the cost of the control worth more or less than the value of what is being protected, and how much more work does it force the attacker to do.

A lock on your luggage may stop a casual thief from opening your bag to grab something, but it won't stop someone stealing your bag.  But the cost is low, so it is a still a useful security control.

So, just because a malicious agent could copy the referrer header, they may not have the time or inclination to do so.  Think of a valid referrer header like a concert wristband.  Can you forge them, or sneak around the guard checking wristbands?  Sure you can, but it doesn't make the band useless.

It raises the cost for the attacker.

Likewise, your standard, non-modified, well-behaved application will tell the truth about the last page it came from, and then will correctly be denied API access.  Maybe somebody trying to abuse your service doesn't know you are checking referrer headers on the server, and will give up.

So, in answer to OP's question "worthwhile" is a value judgement only you can make.  How much effort does it take you to check referrer? Probably not much.  How valuable is protecting use of your API key? Probably more.  Is that amount of effort on your part worth the speedbump you'll place in the attacker's way?

That last one is your call.


How to securely serve client-side-only web content to mobile with convenience?

Not understanding exactly what you are trying to defend against (see my comment above).

But in any way if you wish to serve html+css+js locally you could use Cordova to package your web app as a client app. Then you could also upload it to the market. (You can also use the OS's web browser controls to implement it yourself instead of using cordova)

Your other alternative is hosting your stuff on the web, probably utilizing PAAS as the preferred hosting option.


Way to practically identify punycode in Chrome?

Google Chrome doesn't provide any standard options to enforce Punycode yourself. Instead they apply their own IDN policy to all domains to determine how they should be displayed.

However, there are several browser extensions you can use to mitigate the problem. E.g., Punycode Alert warns you if a domain uses Punycode. From the description:

  Punycode Alert is a GPLv3 Google Chrome, Chromium, Opera extension that warns users when the URL they are accessing has some Punycode content to prevent them from being cheated and redirected to a different URL.

(It's also on Github.)


Would an Ubuntu server accessible from the internet be hacked within days?

The problem is less likely the security of the Ubuntu system as shipped by the distributor. It is very rare that there are critical issues which allow an remote attacker to hack the system. And while there are sometimes critical issues which allow privilege escalation by a local user they are rare too. But you can actually limit the impact further by only installing the software you really need - anything which isn't there cannot be exploited.

What you see as security updates are almost always less critical problems, like exposing address layout which might be used to bypass ASLR, security updates for software you don't even use but have installed, updates for issues which happen only in specific environments or with non-standard configuration, updates for issues which allow applications to crash (denial of service) but cannot be used to take over the system etc. See usn.ubuntu.com for the details. Anything which might help an attacker to advance is considered a security issue but in most cases the attacker needs to be local already or can only do uncritical harm.

But in no way you should feel secure just because you've applied all security updates coming with the system or feel totally insecure just because you've missed the once from the last days. It is more likely that a hack will be done be exploiting issues in your own web application you've deployed on the server or that you've used weak password to protect parts of your system. It is actually the most common way that system gets owned through thus user-generated weaknesses and not through weaknesses caused by the underlying OS.

Thus, while you should keep your system up-to-date you should not blindly rely on these updates keeping your system secure. Additionally you should make sure that your own applications and configurations are secure too.  This aspect might even be more relevant in securing the system than keeping the system always up-to-date.


Is there a security benefit in knowing if my iPhone is jailbroken?

YES! It can tell you if someone has jailbroken your phone and gained control/ability to spy on you.
This app detects the real sources of jail breaking just in case it's hidden.
If you jail broke your iPhone, then good for you you did it right. If not... something else insidious is going on. See this answer on Apple SE for more information, but basically the application tries to detect things you can only do if jailbroken. It then notifies you if you are jailbroken or not. This can be useful for finding out if someone jailbroke your phone for nefarious reasons.
The real reason someone has to jailbreak YOUR iPhone is to spy on you. This gives them access to normally locked parts of your phone, the ability to copy text from your phone to their monitoring services, to hide their activity, and many other bad things.
If your iPhone is jailbroken and you did not do it, you have a compromised phone, however this could be due to company contracts! If it's a work phone this could be for making sure you aren't leaking company secrets through your phone, to prevent access to certain websites and services they don't want running on your phone, and many other legitimate reasons for them.
If it's not a work phone, but your personal phone it could be because your providers(whoever gave you the phone) is spying on you.
If it's your personal phone and you bought it you've been compromised big time and should start changing credentials from a secure terminal for all remote accounts and get a different phone.
To get rid of the jailbreak you can reinstall from iTunes to a factory image, which will overwrite the entire phone. This is a destructive process, but ensures the jailbreak is gone.


This log entry means that someone, somewhere, tries to know the names of the directories on your server by the simple but inelegant expedient of trying a lot of possible names -- and that someone is honest enough to let his tool state it plainly.

Such attacks are very common. Whenever there is a public-facing server on the Internet, seemingly random attacks are to be expected. Most of them are from automated botnets who just try to replicate; they try random IP addresses or server names and then look for "known holes".

There is no reason to worry about DirBuster unless you have on your server a directory which is accessible from unauthenticated users, and yet you would prefer that directory to remain "hidden", and the directory name is guessable (i.e. it is something like "secret" instead of "7o8AW4dslEwrSD78C9xaUdns5"). I would argue that if this is your case, then you have reason to worry: not because of DirBuster, but because you are doing your security wrong and should go back to design phase, this time with an architect who has a clue about security.